Backrun Strategy
Backrun is a reactive arbitrage strategy, which allows executing transactions immediately after a price imbalance occurs between pools. Unlike Transaction Spam, where transactions are sent continuously, Backrun waits for a signal from the blockchain and uses pre-signed transactions.
How it works
Monitoring pools via Yellowstone gRPC
We don't track all program transactions or all network events, but monitor the account states of specific poolsin which we want to arbitrage.
By monitoring only the necessary accounts and only the necessary fields in accounts we minimize traffic and speed up processing.
Pre-prepared transactions via Durable Nonce
In the Backrun strategy the transaction is assembled and signed in advance. This is achieved using Durable Noncewhich allow sending the transaction instantly at the moment of the signal, without spending time on generation and signing.
As soon as an Event arrives from gRPC (for example, a large swap that changed the price), the transaction is sent immediately through many servers and providers.
Distributed transaction sending
Transactions can be sent from different servers (Germany, New York, Japan, etc.).
On each server a the same Durable Nonce, synchronized for a specific token pair, is assigned.
All transactions are sent simultaneously through different Transaction Processor:
Jito, ZeroSlot, Nozomi, Sender (Helius), SWQOS, FAST...
Only the first transaction goes through, the others do not consume fees.
Thus the Backrun strategy becomes more than competitive compared to the same Transaction Spam Strategy. From signal to transaction send — about 0.2 ms with optimal infrastructure. Thanks to Durable Nonce we can monitor this signal immediately from many locations, which is critically important. And thanks to it we can send the same pre-prepared arbitrage transaction from all regions at once to all RPC / Landing services (Nonce between servers is synchronized per token pair). And only one transaction will go through, the others are not initialized and no fee will be charged for extra transactions.
Strategy requirements
Fast gRPC Yellowstone Provider — the faster the event arrives, the higher the probability of success. (Currently you can specify only one provider, in the future it will be possible to specify many)
Durable Nonce accounts must be created in advance — via the bot CLI you can create the required number of Durable Nonce accounts.
Priority and execution frequency
Unlike Transaction Spam, where the bot sends tens to hundreds of transactions per second, Backrun Strategy works differently — it sends fewer, but much more valuable transactions. This is the key advantage that allows improving the quality of each submission and increasing the chances of including the transaction in a block.
Temperature
The parameter Temperature controls how sensitively the strategy reacts to price discrepancies between pools. This is effectively a trigger threshold: how large the imbalance must be for the strategy to send an arbitrage transaction.
Low temperature → more signals, more transactions, but some of them will be false.
High temperature → the strategy reacts only to truly large, worthwhile discrepancies.
This regulates the execution frequency: the higher the temperature, the less frequent the triggers, but the higher the quality of each trade.
For the Backrun strategy it is recommended to start with TEMPERATURE ≈ 300% and adjust based on results; higher values require a larger imbalance and reduce the number of triggers.
Priority Fee
Since Backrun sends few transactions, but does so at a critically important moment, we can and should strengthen them with an economic priority for validators. Even with a perfect gRPC provider and instant delivery via Landing Service, the transaction must be financially attractive to be included in a block.
Set TRANSACTION.COMPUTE_UNIT_PRICE.DEFAULT no lower than 1,000,000 lamports.
This greatly increases the likelihood that a validator will prioritize your transaction among many others.
Automatic pool management
One of the key advantages Backrun Strategy is that it allows monitoring a large number of pools simultaneously, without losing speed or efficiency. Since the strategy tracks only the necessary accounts and only the necessary fields in those accounts, the system load remains minimal — even if you monitor hundreds or thousands of pools.
Scalable monitoring
Backrun is not limited to one token pair. Thanks to the Pool Loader module you can easily set up monitoring for 100, 200 or even 1000 pools simultaneously.
At the same time the system remains fast because:
we do not analyze program transactions or the entire blockchain;
we monitor only the necessary account states (for example, reserves or the active BIN);
we filter updates at the gRPC level down to the minimal possible data volume.
Thus, you can arbitrage the entire ecosystem, not single pairs, without sacrificing reaction speed.
Last updated