Transaction Spam Strategy
Transaction Spam Strategy — is a high-frequency arbitrage strategy, in which the bot continuously sends pre-prepared transactions through different processors to achieve maximum reaction speed and coverage of arbitrage opportunities. Unlike reactive strategies, Spam Strategy does not wait for signals from the network — it constantly sends transactions, ensuring constant presence with leaders.
How it works
Thus, Transaction Spam Strategy becomes the optimal solution for scenarios where maximum speed. Transactions are very likely already at the validators before the arbitrage window appears, which ensures instant execution when a price imbalance occurs. The strategy does not require Yellowstone gRPC, since it does not depend on network events. The Spam Strategy is especially effective on high-volatility tokens, where the price changes frequently and sharply.

Strategy requirements
Any gRPC Yellowstone Provider — is used to monitor the current blockhash, speed is not important. Even the public https://solana-yellowstone-grpc.publicnode.com/ will do,
Priority and fees
Each transaction in the Spam Strategy is almost guaranteed to land, therefore a fee is paid for each submission. The higher the TPS, the greater the fee expenses.
Plan your budget! Even at a moderate rate (10 tx/sec) and an average fee of ~0.000001 SOL/tx you can spend up to 0.864 SOL per day.
Automatic pool management
Transaction Spam Strategy also supports working with multiple pools simultaneously, similar to Backrun. Thanks to the Pool Loader, the system can dynamically fetch and update the list of active, liquid and volatile pools, supporting full automation 24/7.
However, unlike Backrun, where pools are analyzed reactively when the state changes, in Transaction Spam the sending of transactions is performed cyclically and evenly among all active pools. Each active processor has its own TPS and independently iterates the pools in the queue — following the scheme A → B → C → A → B → C.
The fewer pools are specified, the greater the concentration of transactions on a single pool. For example, with a total TPS = 10 and two pools, ~5 transactions per second will be sent to each. If there are ten pools, each pair will receive only one transaction per second. Therefore it is optimal to set a small number of poolsto maximize the chance of hitting the arbitrage window.
Nevertheless, the strategy remains fully automated — Pool Loader regularly updates the list of pools: removes inactive ones and adds new ones that match the specified filters.
Last updated