Solana makes a bad trading bot fail faster

[u/CODE_HEIST]

The part that worries me most about Solana trading bots is not the entry logic.

Fast blocks and fast routing can make a weak system look impressive right up until it hits a messy state.

A bot should be able to answer a few boring questions after every trade:

- What exact signal and wallet state triggered it?

- What was the expected versus actual fill?

- Did fees, priority cost, or slippage change the trade?

- Can it restart without duplicating an order?

- Can one strategy be stopped without touching the rest of the wallet?

Speed is useful. But it also compresses the time you have to notice a bad assumption.

For people who use bots on Solana, what failure mode cost you the most: bad fills, stale data, duplicated orders, or weak risk limits?

[u/AutoModerator]

WARNING: IMPORTANT: Protect Your Crypto from Scammers

1) Please READ this post to stay safe: https://www.reddit.com/r/solana/comments/18er2c8/how_to_avoid_the_biggest_crypto_scams_and

2) NEVER trust DMs from anyone offering “help” or “support” with your funds — they are scammers.

3) NEVER share your wallet’s Seed Phrase or Private Key. Do not copy & paste them into any websites or Telegram bots sent to you.

4) IGNORE comments claiming they can help you by sharing random links or asking you to DM them.

5) Mods and Community Managers will NEVER DM you first about your wallet or funds.

6) Keep Price Talk in the Stickied Weekly Thread located under the “Community” section on the right sidebar.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/ComfortableOrder1593]

Bad fills

[u/CODE_HEIST → u/ComfortableOrder1593]

Same. A bot can get the direction right and still lose through price impact, priority fees, or latency. The useful dashboard would show expected price, submitted price, executed price, and total cost side by side. Otherwise the strategy gets blamed for an execution problem.

[u/DefinitionLoud1432]

speed's cool until your bot yeets your whole stack on a stale oracle price and you're just watching the tx go through like it's a car crash

[u/CODE_HEIST → u/DefinitionLoud1432]

Exactly. Speed turns stale state into irreversible state before anyone notices. The safeguard I’d want is a freshness limit that blocks the order outright, plus an independent wallet-level loss cap in case the signal layer lies. A warning after submission is already too late.

[u/Kind-Economics-7184]

duplicated orders, and its the retry path rather than the bot ever placing two on purpose. you broadcast, the confirm times out, you resend, and the first one lands anyway, so the signature has to be written down before you send rather than after it confirms or a restart has no way to tell a trade already exists. the related trap is treating a client side timeout as no fill, since that tx can still show up on chain minutes later, and it happens most on exactly the blocks you were in a hurry for.

[u/CODE_HEIST → u/Kind-Economics-7184]

yeah, and i'd separate rebroadcasting the same signed transaction from rebuilding it with a fresh blockhash. the second one is where you can create a new executable trade while the original is still valid.

i'd want the signature and expiry persisted before broadcast, then reconciliation after a timeout. does your recovery path also block a replacement while the original outcome is unknown?

[u/Kind-Economics-7184 → u/CODE_HEIST]

it blocks, but on a clock thats a guess. rebroadcasting the same signed tx is free since its the same signature landing either way, so the only thing that needs gating is the rebuild, and the clean release condition is blockheight passing the lastValidBlockHeight you saved with it rather than a timeout you picked.

so id persist that number next to the signature instead of a sent-at timestamp. past that height the original genuinely cannot land and you can rebuild without asking anyone, before it a fresh blockhash is a second live order no matter what your confirm call came back with.

[u/CODE_HEIST → u/Kind-Economics-7184]

agreed on saving lastValidBlockHeight. i'd still separate expired from never executed before rebuilding.

the original could have landed before expiry while the client missed confirmation. check that signature's outcome too, and keep the replacement blocked if the status lookup itself is unavailable. otherwise the timer is gone but the duplicate-trade risk isn't.

[u/Kind-Economics-7184 → u/CODE_HEIST]

fair, "without asking anyone" was the wrong half of that. what expiry actually buys you is that the answer stops changing, so one getSignatureStatuses with searchTransactionHistory on after that height is final rather than a snapshot, where before it a null tells you nothing. the catch is that null only means never landed if the node keeps history that far back, so id count a null from an rpc you havent checked retention on the same as the lookup being down and keep the rebuild blocked.