What happens when a bot's RPC node goes down mid-trade?
When a trading bot's RPC node goes down in the middle of a trade, your transaction either never reaches the blockchain, gets stuck in a pending state, or executes partially - and in every case, you lose control of the timing and price you intended. The RPC node is the bot's direct line to the network; when that line cuts, the bot cannot see what the chain is doing or send new instructions.
The immediate problem: blind submission
An RPC node failure during a trade means the bot sent your transaction to the node but never received confirmation that it landed. From the bot's perspective, the transaction status is unknown. The bot cannot tell if:
- The transaction was rejected by the node before it reached the mempool.
- The transaction entered the mempool but hasn't been included in a block yet.
- The transaction executed but the node crashed before returning the receipt.
Your funds are now in a gray zone. The bot's interface may show "pending" indefinitely, or it may display an error and assume the trade failed. Neither assumption is reliable.
Partial execution and stuck funds
If the transaction did execute on-chain before the RPC node went down, you might end up with a partially filled order. This is common on decentralized exchanges like Raydium, where a swap instruction buys tokens from a liquidity pool. If the RPC node fails after the buy leg but before the bot can send a sell instruction or a follow-up transaction, you hold a position you did not plan to keep.
Worse, if the transaction was a two-step operation - such as buying a token and then immediately setting a stop-loss - the second step never fires. The bot has no way to know it needs to retry that second instruction because it never received confirmation of the first.
The bot's recovery behavior varies
Different Telegram bots handle this situation differently, and the documentation is rarely clear. In general, three things can happen:
-
The bot retries the transaction. Some bots will resubmit the same transaction with a higher priority fee, hoping to push it through on a working node. If the original transaction already executed, the retry will fail with a "transaction already confirmed" error, and the bot may or may not update its internal state.
-
The bot marks the trade as failed. The bot assumes the node failure means the transaction did not go through. Your wallet balance in the bot's interface may be wrong - showing tokens you actually own, or missing tokens that were swapped.
-
The bot goes into a waiting loop. It polls the failed node repeatedly until the node comes back or a timeout expires. During this time, you cannot send new trades through that bot. Some bots allow you to switch to a different RPC endpoint mid-session; most do not.
What you can actually do
If your bot's RPC node goes down during a trade, your options are limited but worth knowing in advance:
-
Check the transaction on a block explorer. Open Solscan or Solana Explorer and paste your wallet address. Look for any recent transactions that match the time of the failed trade. If you see a swap that went through, you own the tokens regardless of what the bot says.
-
Manually revoke token approvals. If the bot's wallet still holds an active approval for the traded token, revoke it immediately via a token approval checker like Solscan's "Approve" tab or a dedicated revoke tool. This prevents the bot from attempting a second trade on the same approval if it recovers and retries.
-
Export the private key. If your bot wallet is a Telegram-generated wallet (not a connected external wallet like Phantom), you should have exported the private key during setup. If you did not, you may be locked out until the bot's node recovers. Use that private key in a wallet like Phantom or Solflare to manually manage any stuck tokens.
-
Set a manual stop-loss. If the trade went through and you now hold a position you want to exit, do not wait for the bot to recover. Use a manual swap on a decentralized exchange or a different bot with a working RPC node to sell.
Prevention is the only reliable fix
No bot can guarantee RPC uptime. But you can reduce the chance of being caught mid-trade:
-
Use a bot that supports custom RPC endpoints. Some Telegram bots let you supply your own private RPC node (such as Helius, Triton, or QuickNode). A private node with a dedicated connection is far less likely to go down than a shared public endpoint.
-
Check the bot's node health before trading. A few bots display a "node status" indicator in the settings menu. If it shows errors or high latency, wait.
-
Avoid trading during network congestion. When Solana is under heavy load, RPC nodes drop connections more frequently. If you see transaction failure rates climbing on your block explorer, it is a bad time to rely on a bot for a time-sensitive trade.
-
Keep your bot wallet small. Never leave more funds in a Telegram bot wallet than you are willing to lose to a node failure, a stuck transaction, or a recovery error. The bot wallet is a hot wallet with limited control - treat it accordingly.
An RPC node failure mid-trade is not a rare edge case. It is a known limitation of relying on a third-party connection to the blockchain. The bot cannot save you from it, and the bot's developer will not refund your losses. The only person who can act is you, and only if you understand what actually happened on-chain.
Not financial advice. pepecoinsol.xyz publishes market data and general information about Pepe. Crypto assets are volatile and you can lose everything you put in. Nothing here is a recommendation to buy, sell or hold, and we make no price predictions.
Prices are sourced from third parties and may be delayed or wrong. Verify anything you intend to act on against a primary source.