❗ Running & Debug
Environment preparation
The system supports Windows, macOS and Linux, but for continuous operation it is better to use a Linux server — it is more stable, consumes fewer resources and gives better performance in Node.js.
The application is written in Node.js and runs in a single thread, so each running application uses only one CPU core. Hence a simple rule: 1 instance = 1 CPU. Adding cores only makes sense if you want to run multiple instances of the system simultaneously.
Minimum requirements: 1 CPU, 2 GB RAM. This is enough — the system is not resource-intensive and on average uses 10–20% of one core. The main thing is high CPU frequency, since Node.js heavily depends on single-thread speed.
More important is the server location. The closer it is to Solana validators, the lower the network latency and the higher the chance to get into a block. It is better to place servers in the regions and with the providers where the main Solana validators operate (for example, TerraSwitch or CherryServers).
System preparation
1. Configure a preset
Create resources/presets/<name>.toml with the required parameters. Be sure to specify:
PAYER_PRIVATE_KEY— the private key of the wallet from which all transactions will be executed;DEFAULT_RPC.URL— a reliable endpoint. Speed is not important.GRPC.URL— a fast endpoint for monitoring events on the network; critically important for theBACKRUNTRANSACTION_PROCESSOR.[name].API_KEYS— API keys for each active processor (optional);
Below are personal recommendations of RPC / gRPC providers whose services you can use.
Helius
Shreder
Also preconfigure Pool Filters, which the system will use to load pools and between which arbitrage will occur. You can test before launching which pools come through the specified filters via the CLI utility "Fetch Pools"
Full list of all configurations:
Preset Configuration2. Create Durable Nonces (required for Backrun)
Durable Nonce — required for the Backrunstrategy, they allow synchronizing transactions. It is recommended to create 100 accounts. Creating 100 accounts costs ~0.145 SOL, these funds are allocated for account rent and can be fully returned when these accounts are closed. You can Create / Close via the CLI utility "Manage Nonce"
More details on why this is needed:
Backrun Strategy3. Fund the wallet and convert SOL to wSOL
For the system to function correctly, IT IS MANDATORY to pre-create a wSOL account and fund it. The system DOES NOT create this account automatically. You can convert SOL via the CLI utility "Wrap Sol".
Also make sure you have a SOL balance in the wallet. From it the following will be paid:
transaction fee for failed transactions
the fee for creating / expanding LUT tables (can be fully returned later)
tips to JITO and other processors
fees to lending protocols for Flash Loan
It is recommended to have about 0.3 SOL and 0.1 WSOL in the wallet for proper operation.
Thanks to the Flash Loan no more is required, since we can take liquidity for executing arbitrage as a safe loan.
4. Specify your LUTs (optional)
In system.toml the TABLE_LOOKUP_STORAGE section you can specify your custom tables. They will be used by the system for all arbitrage transactions in advance.
Starting the system
When starting the system it is important to be cautious, especially if you are running it for the first time. Follow these recommendations to minimize risks and unpredictable expenses:
1. Do not set a high Priority Fee
Priority fee is configured in the preset via the block TRANSACTION.COMPUTE_UNIT_PRICE
If the strategy is enabled Transaction Spam with high TPS, the system will start sending a large number of transactions to the blockchain. Each transaction, even if unsuccessful, charges a fee for inclusion by the validator. Therefore at startup set a minimal Priority Fee (for example, 100 µLAM/CU) and a small number of transactions per second to safely test the system and the predictability of expenses.
2. Check the pool filters (Pool Filters)
If filters are not set, the system will load all available pools (there may be up to 1000+), which will lead to massive table creation via Table Lookup Manager (if it is enabled). For each new pool tables will be expanded automatically. Although the fee for creating and expanding tables can be returned, at startup it is better to test which pools will come to avoid unexpected behavior.
3. Monitor the logs
When the bot runs a folder is created logs, in which a file for the current run is generated. All unpredictable events, errors and warnings are logged there. Regularly check this file to identify problems in time and understand how the system works.
Last updated