Bot Configurations

Version 2.0.0 uses [bot], one or both settlement profiles under [auto], and a repeated [[senders]] entry for each sending service. [auto_rebalance] and [log] are optional.

Unknown config fields are rejected. Start from a 2.0.0 example instead of carrying forward a 1.x config.

Bot

[bot]
rpc_url = "https://YOUR_READ_RPC"
encrypted_key_path = "~/keys/ENCRYPTED_PRIVATE_KEY"
flashloan = true

See Getting Started for first-run key setup.

Automatic market selection

Configure [auto.sol], [auto.usdc], or both. Each profile selects routes that start and end in its settlement token. The SOL profile settles in wrapped SOL (WSOL).

[auto.sol]
min_total_profit = 5_000_000
min_tx_count = 2
lookback_secs = 3_600
max_routes = 50
process_delay = 50

[auto.usdc]
min_total_profit = 750_000
min_tx_count = 2
lookback_secs = 3_600
max_routes = 25
process_delay = 50

For example, 5_000_000 is 0.005 SOL in [auto.sol], while 750_000 is 0.75 USDC in [auto.usdc]. These are historical selection thresholds, not per-trade profit requirements. The program checks current pool state when a transaction executes.

Each route runs independently. process_delay is not a global requests-per-second limit; use each sender's rate_limit_per_second, or from 2.0.4 each key's, to cap submissions across all routes and both settlements.

Senders

Add at least one enabled sender to submit transactions. Each sender builds transactions using its own prices and tips.

[[senders]]
name = "rpc"
type = "json_rpc"
urls = ["https://YOUR_SENDING_RPC"]
rate_limit_per_second = 20
compute_unit_price = { strategy = "Random", from = 1000, to = 2000, count = 1 }
request_params = { maxRetries = 10 }

Sender types and defaults

type is required. For jito, supply a block-engine URL ending in /api/v1, not /api/v1/bundles; a key's grpc_urls take the block engine without a path, such as https://ny.mainnet.block-engine.jito.wtf (see Jito with several uuids and gRPC). For harmonic, supply a regional URL such as https://fra.be.harmonic.gg; see Harmonic. For temporal, supply a regional host with your key, such as https://fra2.nozomi.temporal.xyz/?c=YOUR_API_KEY. See Temporal Nozomi bundles.

Sender fields

A rate limit counts submissions, not requests. A submission counts once against each lane it goes through, including a lane it moves on to. With AllAtOnce, a submission goes to every endpoint of its lanes, so the number of HTTP requests can be higher.

JSON-RPC transaction options default to encoding = "base64", skipPreflight = true, preflightCommitment = "confirmed", and maxRetries = 10. Bundle options default to encoding = "base64". request_params overrides matching options. Keep base64 encoding, since that is how the bot serializes transactions.

Multiple credentials

Use [[senders.keys]] when one sender has multiple endpoint groups with different credentials. Each group supports urls, auth_header, auth_value, and request_params. From 2.0.4, a group can also set rate_limit_per_second, and a Jito group can set uuid, or list grpc_urls with an optional auth_keypair instead of urls.

[[senders]]
name = "rpc-keys"
type = "json_rpc"
rate_limit_per_second = 10
sending_strategy = "OneByOne"
request_params = { maxRetries = 0 }

[[senders.keys]]
urls = ["https://YOUR_FIRST_RPC"]
auth_header = "authorization"
auth_value = "YOUR_FIRST_API_KEY"

[[senders.keys]]
urls = ["https://YOUR_SECOND_RPC"]
auth_header = "authorization"
auth_value = "YOUR_SECOND_API_KEY"

When using keys, omit sender-level urls, auth_header, and auth_value. A key's request_params replaces the sender-level table for that key; the chosen table is then merged into the request defaults.

Rate limits per key

Requires bot 2.0.4 or later. A key that sets rate_limit_per_second gets a limit of its own, apart from the sender's and other keys'. Keys that set none share the sender's limit. If every key sets its own, leave the sender's rate_limit_per_second unset; the bot rejects a sender limit that would apply to no key.

Each limit is a lane. OneByOne sends each submission through the next lane that has room, and moves on to another lane that has room when every endpoint of its lane is unreachable or the lane is rate limited. AllAtOnce sends through every lane that has room. A rate-limit reply pauses only its lane, for two seconds. With OneByOne, the sender can send up to the sum of its lanes' limits. Logs name the shared lane by the sender's name, and a key with its own limit by the sender's name and the key's position counting from 0, such as jito keys[1] for the second key of a sender named jito. See Jito with several uuids and gRPC for an example.

Tips and no-failure mode

With no_failure_mode = false, a transaction must profit at least its tip. For jito, send_bundle, and harmonic from 2.0.3, and temporal from 2.0.4, whose bundles do not land when they revert, it must also cover the bundle's fees: the signature fee, the priority fee, and the tip forwarder's transaction if there is one. For other senders the floor does not cover transaction fees. For USDC settlement, the bot converts the floor into USDC with a 20% margin.

With no_failure_mode = true, the bot removes that profit floor. A transaction may succeed without a trade and still pay its tip and network fees. This setting does not make submissions free or guarantee a profit.

Astralane endpoints without a supplied API key use the bot's shared default key and require no_failure_mode = true. Use an api_key header or an api-key/api_key URL query parameter to supply your own key.

See Sending Vendor Examples for service-specific setups.

Price and tip strategies

compute_unit_price and tip_amount use the same strategy structure, except Helius is supported only for compute unit prices. Strategy names are case-sensitive.

For the four range strategies, provide count of at least 1 and from no greater than to (ExponentialRandom requires a strict increase). An optional min sets a lower bound on generated values for non-Helius strategies. max applies only to Helius.

Each send pass tries the combinations of generated tip amounts and compute unit prices, subject to the sender's rate limits. For example, two tips and three prices produce six candidate submissions per basket.

Helius priority prices

[[senders]]
name = "rpc-helius-prices"
type = "json_rpc"
urls = ["https://YOUR_SENDING_RPC"]
compute_unit_price = { strategy = "Helius", api_key = "YOUR_HELIUS_API_KEY", from = 90, to = 130, count = 3, max = 20000, fetch_interval = 5 }

Here from and to are percentages of the estimate, not micro-lamport amounts. This example generates three prices from 90% to 130% of the estimate, capped at 20,000 micro-lamports per CU.

Auto-rebalance

This optional section checks the wallet every minute. When native SOL falls below min_sol_balance, the bot unwraps WSOL and wraps min_wsol_balance again. It skips rebalancing if the combined SOL and WSOL balance is below the two configured amounts added together.

[auto_rebalance]
min_sol_balance = 500_000_000
min_wsol_balance = 200_000_000
compute_unit_price = 10_000

All three fields are required when this section is present. Balances are in lamports; compute_unit_price is in micro-lamports per CU. Rebalancing does not sell USDC, and it is not an initial funding mechanism for the WSOL account.

Logging

[log]
enable_sending_log_summary = true
summary_interval_seconds = 60

enable_sending_log_summary defaults to false. When enabled, periodic summaries replace the per-transaction logs of successful sends; failed sends are still logged, except replies that the transaction was already processed. summary_interval_seconds defaults to 60.

Applying config changes

The bot checks the config file every second. Sender settings and filters for the existing settlement profiles can update while it runs. Invalid edits keep the previous config active.

Restart after adding or removing a settlement profile, changing the RPC or wallet, or changing auto-rebalance settings. These changes take effect on the next start.

Removed 1.x settings

Remove old fields rather than leaving them alongside the new ones: unknown fields prevent the config from loading.