Bot configurations
This is an example config.toml file.
Routing
In routing, you define which mint(X), a raydium pool that is SOL/X, a meteora dlmm pool that is SOL/X. The bot's onchain program will check if there's a profitable route between the two onchain, and find the optimal trade size, and execute the trades if there's any.
Currently the bot only support one raydium pool and one meteora dlmm pool for each list, you can define multiple different ones for the same mint/raydium pool and different meteora dlmm pool. A later version will alow using multiple meteora dlmm pool together.
mint_config_list
You can define multiple mint and pools. The bot will send out a tx, wait for process_delay ms, then send again and repeat for every mint you define.
You can also define more than 1 meteora dlmm pool. If you use more than 2 you likely need to add an address lookup table for it as well, otherwise the tx will be too big.
Currently Pumpfun swap/Raydium AMM/Raydium CPMM/Meteora DLMM/Orca whirlpool/Meteora Pool are supported. You can define multiple ones in the same config as long as it can fit. You may need to add look up tables if you are using too many pools.
Arb between DLMM/DLMM, DLMM/Orca, Orca/Orca is not supported yet.
Define multiple mints
You can define multiple mints by simply copy the [[routing.mint_config_list]] config.
Example:
RPC
You just need to put your rpc's url here. This is NOT the rpc you use to send transactions.
Spam
You can set the rpcs you use to send transactions. This can be the same as your reading rpc.
compute_unit_price
You need to config compute unit price when enable spam.
You can set from equals to to value and use any strategy to get a fixed tip amount for all your tx.
Note: the transaction generated from this will be send out together.
You can define it in two format. Define it under [spam] directly
or define it in its own section
Or you can load from a file using file strategy
Your file should have one number on each line, example with 2 compute_unit_price:
Jito
You can also enable sending through jito. Though the success rate of using jito is much lower due to the tip auction and how jito works, but the up side about it is you won't have any failed transactions.
Note: If you use multiple ip with jito, make sure you don't have ip rotation setup locally, instead you should use the bot's build in support for it. You can just set all the ips you want to use within the config, you can use either single ip or CIDR format like "192.168.1.0/24"
use_min_profit
Default to true.
YOU MAY LOSE MONEY WHEN YOU SET THIS TO FALSE.
When this is set to true, the onchain program will use the tip amount as min profit so you never lose money. Though this will make it very hard to land.
When this is set to false, the onchain program will NOT use the tip amount as min profit, so it will land as long as there's profit(without considering your tip amount). Make sure you understand what this does before setting this to false. The recommended way to use this is to use a very small tip amount + a lot of ips, basically using jito as a way to land your transactions and consider the tip as gas fee.
min_profit
Default: 0
This is the number you want to set in addition to your tip amount. For example if you don't want to lose money with jito, you should set this to 10000 if you use separate tip accounts and 5000 if not to cover the basic transaction fee.
use_separate_tip_account
Default: false
You need to set this to true if you are using ip to get around the jito rate limit.
no_failure_mode
Default: false
YOU MAY LOSE MONEY WHEN YOU SET THIS TO TRUE.
When this is enabled, transaction without profit will NOT fail. This means all your tx sending to jito will succeed, pass all simulations, and landed on chain. So you will pay ALL the transaction's tip even if there's no profit.
On the other hand, this does help to land tx through jito, especially land successful ones as you by pass all simulations. You are basically using it as a spam rpc in some sense, and all the jito tip you pay is the gas fee.
tip_config
You need to config tip when enable jito.
You can set from equals to to value and use any strategy to get a fixed tip amount for all your tx.
Note: the tx generated from this will be send out together. So make sure you have enough rate limit to handle it.
You can define it in two format. Define it under [jito] directly
or define it in its own section
Or you can load from a file using file strategy
Your file should have one number on each line, example with 2 tips:
block_engine_strategy
Default: "OneByOne"
OneByOne: The bot will send out tx through all the different urls one by one. This way you can have an effective 6/s rate limit with jito as this bot requires sending out a lot of tx.
AllAtOnce: The bot will send out the same tx to all regions together. This will give a higher chance for the tx get through if a few of the regions are rate limited.
Kamino flashloan
When enabled, you don't need a lot of wsol in your wallet.(You need some to keep your wsol account open). But this will add 73,000 compute unit to your tx.
NOTE: Kamino only works with SOL/USDC base mint.
Bot
compute_unit_limit is a required param. If you have meteora dlmm in your pool you should set it to be at least 300_000. If not you should set it to at least 250_000. If you use kamino add another 80000 to it. If you have more than two dlmm pool you should consider adding more compute unit limit here.
When you have dlmm pool, the compute_unit_limit you set will affect how many bins the bot will look at when doing calculation onchain. Roughly each bin lookup will take ~ 10000 compute unit. 300_000 will allow the bot to look at ~10 bins onchain.
compute_unit_price_for_ata_creation the compute unit price you pay for creating ata transaction. Default is 1_000_000 if not set.
base_mint
Default: So11111111111111111111111111111111111111112
The base mint you want to use to trade between pools. Currently support SOL/USDC. If you need supports for other mints please raise the request in discord.
merge_mint
The merge_mint config allows you to find opportunities for different mints and pools within one transaction. This sounds good but has it's own limitation.
The tx is usually harder to land as you add more mints and pools. This is likely due to the transaction is locking too many accounts and the validator is impossible to find a slot to fit it in. You may also need to use higher fees when the market is hot.
You also need higher compute unit limit as the bot's program need to look at more pools onchain with this.
Note: Bot current support merge up to 3 mints, and 7 pools in total. If you try really hard and have the proper lookup table you can go up to 4 mints and 8 pools.
memo
Will add an additional memo instruction to all your tx. This is useful if you run multiple bots/strategies on the same wallet and trying to understand which one performs better.
Wallet
Last updated