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

1

Endless transaction sending

At the core of the strategy lies a continuous stream of transactions. The bot signs on the fly preprepared transactions using regular blockhash (and not a Durable Nonce, as in Backrun).

2

Independent operation of processors

Each Transaction Processor (for example, JITO, ASTRALINE, SENDER, 0_SLOT, NOZOMI and others) operates independently from the others. Each of them can be configured separately.

3

Sending across multiple pools

If several pools are specified, each processor iterates them in a round-robin. For example, if we have 2 pools (A and B), then each individual processor will send transactions to the pools A → B → A → B → A → B → …

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.

triangle-exclamation

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