A multi-strategy trading bot for Solana: DEX arbitrage, liquidations, keepers and LST spreads. It ran on mainnet with real capital, lost money, and taught me more in that hour than weeks of simulation had.
Ran on mainnet with real capital, then was switched off4 strategy families in one process, sharing one wallet300 tests green, and none of them caught the bug that matteredJito bundles on the liquidation path, plain submission everywhere else
Solana has more short-lived inefficiencies than any single strategy can absorb: price gaps between venues, undercollateralised loans waiting to be liquidated, protocol jobs nobody has run yet, and liquid-staking tokens drifting from their redemption value.
Chasing them one strategy at a time means four separate bots, four wallets, and four ways to lose an account. The part I wanted to work out was not the trade. It was running four strategies from one process without letting any of them take the others down.
One process runs four strategy families against Raydium, Orca, Meteora, Drift and MarginFi. Risk checks gate each trade, per strategy and across the account. The capital allocator that would cap each budget is written and tested, but no strategy calls it yet. Liquidations go out as Jito bundles, since those are the ones worth sandwiching.
A local dashboard shows what each strategy is doing and the ceilings it runs under. Telegram carries the alerts. A single kill switch stops submission everywhere at once.
All four strategies pass the same risk gates. The path after them is DEX arbitrage, and its job is to kill a bad trade before it costs gas.
5 scenariosPick one, the steps above follow itPick one, the diagram replays its path
Drawn from the code. Liquidation and LST leave the gates for their own executors, and the re-quote exists only on this path. The kill switch did not fire in the mainnet test.
Scanners
Scanners
Decision
Execution
Four of them, one per strategy. Two read polled HTTP quotes, two hold live subscriptions to on-chain accounts, and they all emit the same shape of candidate.
Runs the four strategy loops in one process and arbitrates when two of them want the same capital at the same moment.
A budget per strategy and one for the account as a whole, covered by tests. No strategy requests capital from it yet, so these budgets are configured, not enforced.
Global and per-strategy limits, with a kill switch that halts submission everywhere at once rather than unwinding strategy by strategy.
Runtime
Chain
State
Operations
Every stage runs on hardware I own
Quotes the same pair on three venues, looks for a gap wider than the fees on both sides, and takes it in two swaps. Keeper transactions aside, this is the only one that ever executed against real money, and the trade it executed lost.
Spread check
Risk gates
Two swaps
Watches borrowers on two lending venues and repays a loan that has fallen under water, taking a bonus on the seized collateral. It is the only strategy that submits through Jito, because a liquidation is worth front running. The MarginFi half stopped decoding when the protocol changed on chain.
Health factor
Health factor
Bonus check
Jito bundle
Meant to fill other people's orders on a perpetuals venue for a small fee paid by the protocol. It subscribes to the book, polls it every two seconds, and discards every candidate, because the reward it estimates sits below the floor it enforces on itself.
Fillable orders
Reward floor
Nothing emitted
Computes what a liquid staking token is really worth by dividing the SOL held in its stake pool by the supply, compares that to what the market pays for it, and swaps when the two drift apart. The fair side of that comparison is arithmetic read from chain, not an oracle, so it cannot be quoted wrong the way an illiquid pool can.
Fair value gap
Fair value gap
Divergence gate
Swap
Same grid, same reading direction, one path per strategy
The first version recorded what a trade was expected to earn, computed before submission, as the trade's result. That is a comfortable way to build a strategy that always looks profitable. Now the keeper executor reads the wallet balance from the confirmed transaction and takes the difference, so a recorded profit is something that actually arrived. Liquidations still book the estimate minus gas. The estimate still exists, but it is only used to decide whether to try, never to say what happened.
// Calculate real profit from wallet SOL balance change
const preBalance = txDetails?.meta?.preBalances?.[0] ?? 0;
const postBalance = txDetails?.meta?.postBalances?.[0] ?? 0;
const balanceChangeSol = (postBalance - preBalance) / 1e9;
actualProfitUsd = balanceChangeSol * solPrice;What replaced a line that read: estimated reward, minus gas.
The first version stopped strategies one by one. That is fine while you are watching. It is useless at 3am, when the reason you want to stop is that you do not yet know which strategy is misbehaving. It now halts submission everywhere at once and leaves the diagnosis for later.
The keeper strategy settled other users' unrealised profit on a perpetuals venue, on the assumption that the protocol paid a share of what was settled. It does not. That instruction moves accounting between accounts and pays the caller nothing at all. The scan is now switched off behind a constant rather than deleted, because the reasoning is worth more in the file than in a commit message.
if (!SETTLE_PNL_DISABLED) {
this.scanUnsettledPnl().catch(() => {});
this.settlePollTimer = setInterval(() => {
this.scanUnsettledPnl().catch(() => {});
}, this.settlePollIntervalMs);
} else {
log.info('Settle PnL scanning disabled (no external keeper reward)');
}
Nothing to try. It is switched off.
It works, in the narrow sense that it did what it was told against real venues with real money. What it does not do is win, because these strategies are a race decided by proximity to the validators. I built it, ran it, learned what I wanted from it, and stopped it before it could teach me the same lesson at a larger size.
The architecture section is the interesting part, and it is all on this page.
The keeper strategy wrote its own pre-trade estimate into the field meant to hold the result. Seven transactions went out on mainnet, each one real, each one costing gas, and each one was recorded as a large gain. The ledger showed a winning strategy while the wallet showed nothing arriving. An estimate and a result must never share a field, and the result has to be read back from the chain.
The scanner found a gap of roughly sixty-six percent on an illiquid token between two venues and took it. Both legs executed on-chain exactly as designed, which is the uncomfortable part: the code was correct and the signal was not. The quoted price was not executable at size, and slippage ate the trade. The detector now rejects anything above ten percent outright and simulates before committing.
Four strategies signing in parallel from one account will race for blockhashes, so I built a single authority to hand them out, with a mutex and a queue. It is still there, and not one executor imports it. The same is true of the transaction queue next to it. I had described both as load bearing until I went looking for their callers, which is the uncomfortable lesson: a component you designed carefully is the one you are least likely to check is wired in.
It estimates a filler reward as a flat five cents per fill, then refuses anything paying under fifty cents. Every candidate is discarded before it becomes work, and the other half of the strategy, settling other users' profit, is switched off because it pays nothing at all. The process still subscribes to the order book and polls it every two seconds. A strategy can be alive in the logs, green on the dashboard, and structurally incapable of doing anything.
In simulation the strategy was profitable with a perfect win rate, replaying the same route dozens of times. Real execution disagreed on the three things a dry run cannot model: slippage, competition, and the fact that an arbitrage can only be taken once. An hour against real money found four critical bugs and settled the viability question. I would spend it again rather than scale a simulation I trusted.
The bots that win these races sit in the same datacenter as the validators and measure the whole loop in milliseconds. This one polls from a home connection on a free RPC tier, three orders of magnitude slower. There is no version of the code that closes that gap, and renting the gap away costs more per month than the bot would plausibly make at my size. So it is off, and that is the honest answer.
Nothing to open from here.
Not public
Not public.