This section combines the parameters that determine, exactly how arbitrage transactions are executed — whether it's a reactive strategy to blockchain events (Backrun) or a constant high-frequency spam of prebuilt transactions (Spam), and also through which processors (Landing Services) these transactions are delivered to validators.
MONITORING_STRATEGIES
Description:
MONITORING_STRATEGIES — defines the strategy for executing arbitrage transactions.
This is the behavioral layer that specifies when and under what conditions the bot should initiate sending a transaction.
Two types of strategies are available:
Backrun Strategy (gRPC Account Monitoring) — reacts to large swaps and sends a transaction only when there is an arbitrage signal.
Spam Strategy (Transaction Spam) — continuously spams transactions at a given TPS, increasing the chance of hitting an arbitrage window.
Options:
ACTIVE_STRATEGY — Determines which strategy is active at the moment.
"BACKRUN" — enables the Backrun
"TRANSACTION_SPAM" — enables the Spam
Example:
# Monitoring strategies for detecting arbitrage opportunities.# BACKRUN: monitors pool updates via gRPC and executes on price discrepancies# TRANSACTION_SPAM: continuously sends transactions for spam[MONITORING_STRATEGIES]# Active monitoring strategy to use (BACKRUN, TRANSACTION_SPAM)ACTIVE_STRATEGY="BACKRUN"
BACKRUN
Description:
Reactive execution strategy focused on blockchain events.
Uses a gRPC connection to monitor all liquid pools and reacts to large swaps, causing price imbalances.
When the price difference between pools exceeds a set threshold, the bot executes a prebuilt arbitrage transaction.
Options:
TEMPERATURE — the strategy's sensitivity parameter to price fluctuations. Specified as a percentage and shows how much the current price divergence must exceed the minimum allowed.
The lower value TEMPERATURE, the more often arbitrages will be executed.
The higher — the less often, since a greater deviation is required.
BLOCK_TIMEOUT — the lockout time for a pair of pools after executing an arbitrage (in milliseconds). During this period the strategy will not re-execute arbitrage on the same pools, even if the conditions are met again.
Example:
Increasing TEMPERATURE reduces execution frequency but decreases the risk of false-positive signals.
TRANSACTION_SPAM
Description:
Continuously generates and sends arbitrage transactions with prebuilt logic.
This approach ensures that when an arbitrage window appears, transactions are already present on validators, which increases the likelihood of successful execution.
The strategy has no separate configurations.
Example:
TRANSACTION_PROCESSOR
Description:TRANSACTION_PROCESSOR — is a module that defines through which Landing Services transactions are sent to Solana validators.
Each processor is a separate API service responsible for landing and priority delivery of transactions with minimal latency.
General parameters:
The parameter
Type
Description
ENABLED
boolean
Enables or disables the processor.
TPS
integer
Transaction-per-second limit for this processor.
USE_PROXY
boolean
Specifies whether to use a list of proxies for sending. Proxies are iterated sequentially.
TIP_AMOUNT
integer
The size of the tip fee paid to the service for priority inclusion of the transaction.
API_KEYS
array[string]
List of API keys. Each new request uses the next key in rotation.
REVERT_PROTECTION
boolean
Includes transactions in the block only upon successful execution. Failed transactions are not finalized in the blockchain, but the probability of success is reduced.
JITO
ZERO_SLOT
NOZOMI
NEXT_BLOCK
BLOCKRAZOR
ASTRALINE
SENDER
FAST
SWQOS (Custom RPC)
Notes:
This mechanism allows the user to specify custom RPCs.
# BACKRUN strategy: executes arbitrage when pool state changes trigger price differences
[MONITORING_STRATEGIES.BACKRUN]
# Sensitivity multiplier for arbitrage execution (percentage).
# Formula: adjusted_min_delta = min_delta * (1 + TEMPERATURE/100)
# Higher values = more aggressive (execute with smaller price differences)
# Lower values = more conservative (require larger price differences)
# Example: TEMPERATURE=300 means 4x multiplier (1 + 300/100 = 4)
TEMPERATURE = 300
# Cooldown period in milliseconds after arbitrage execution on a pool pair.
# Prevents repeated execution on the same pair within this timeframe.
# Typical: 6000ms (6 seconds)
BLOCK_TIMEOUT = 6000
# TRANSACTION_SPAM strategy: continuously sends transactions for spam purposes.
# No configuration options available
[MONITORING_STRATEGIES.TRANSACTION_SPAM]
# Custom RPC configuration.
# You can specify multiple [[TRANSACTION_PROCESSOR.SWQOS]] blocks.
# Each SWQOS processor will submit transactions to all URLs in parallel for increased throughput and redundancy
[[TRANSACTION_PROCESSOR.SWQOS]]
ENABLED = true
TPS = 100
USE_PROXY = false
# Array of custom RPC endpoint URLs to send transactions to in parallel
URLS = ["https://mainnet.helius-rpc.com/?api-key=<your_key>", "https://another-rpc.com"]
[[TRANSACTION_PROCESSOR.SWQOS]]
ENABLED = false
TPS = 100
USE_PROXY = false
# Array of custom RPC endpoint URLs to send transactions to in parallel
URLS = [ "https://api.mainnet-beta.solana.com" ]
