Building a Solana Liquidation Bot: Oracle Updates, Bundles and Landing First

The Solana liquidation bot acts according to the stream of oracle updates and the rhythm of lending protocols to attack the vulnerable positions precisely when they become undercollateralized and attempt to execute an atomic repay-and-seize transaction before other bots do. The reward for such actions is a protocol liquidation bonus, and this strategy is the most legitimate way to exploit MEV on Solana as the opportunity is defined by protocol rules, the payoff is known in advance, and the competition is won by how fast you observe the oracle update and how successfully you place a Jito bundle. This guide will explain the architecture, the feeds, the bundle construction process, and the economics that will distinguish a successful liquidator from one who pays tips for nothing.

Key Takeaways

• Liquidations are triggered by oracle price updates, so the race starts with the oracle account update rather than a risky position appearance. Observing the price change first is the only edge.
• Repay-and-seize must be executed atomically. With a Jito bundle it either succeeds or fails; a regular transaction can leave you repaying someone's loan without receiving the collateral.
• Keep all the at-risk positions in memory using a gRPC feed to make the hot path free of RPC requests when the oracle updates.
• Tip sizing is the profitability key: the bonus is known, so tip a fraction of the bonus which will help you to win the auction without giving the edge to the validator.

How liquidations work on Solana lending protocols

The borrower provides the collateral and takes a loan. Protocols define a certain health factor or loan-to-value ratio, so once the price of the collateral decreases or the price of the debt increases, passing the ratio limit, the position becomes liquidatable. Then any user can repay the debt or a part of it and get collateral valued higher than the repaid debt; the excess of collateral price over the repaid debt will be the liquidation bonus.

Here is what you need to consider when building a liquidation bot:

1. The trigger is the oracle update. Prices change once the oracle account is updated. Positions do not become liquidatable on a timer; they become liquidatable the very instant the oracle price crosses the limit.
2. The payoff is known. Protocols publish the bonus percent. You can calculate in advance how much a successful liquidation is worth.
3. It is a race. All the liquidators see the same oracle update. Whichever bundle lands first gets the position.

Architecture

The indexer and the oracle watcher are the two feeds, and they deserve different observation points. The position state must be complete and precise, and this is ensured by Yellowstone gRPC. The oracle update must be seen as early as it is physically possible, so the shred-level feed is the way to go: you can observe the price update while the block containing it is still being built. This mechanism is explained in What is Shredstream; the feed is Jetstream gRPC.

The hot path, step-by-step

1. An oracle account update is received from the shred-level feed with the new price.
2. The evaluator calculates health for all the positions exposed to the asset in question. As the positions are stored in memory and sorted by their sensitivity, it is a scan of the at-risk tail, not the entire book.
3. For every position that became liquidatable, calculate the maximum repayable amount, collateral, and the net bonus after any swap needed to bring the collateral back to the repaid asset.
4. The bundle is built: repay instruction, seize instruction, possibly the unwind swap, and the tip transfer in the final transaction.
5. The bundle is simulated locally against the observed state. Bundles which fail the simulation or have a net bonus less than the floor are discarded.
6. The tip size is calculated from the simulated net bonus and the bundle is submitted to the nearest Jito block engine.
7. Everything is recorded regardless of the landing success.

None of steps two to six depends on a network request. This is the design principle, and that is what the shred-level oracle feed and the in-memory position book give you.

Why the bundle must be atomic

Liquidation is a process of two state changes: your repayment of the debt and your acquisition of the collateral. Executed as two separate transactions, these actions can be interrupted by a competitor, or the second can fail, leaving you repaying the debt of another participant. A Jito bundle executes these transactions sequentially and atomically in the same block, or drops the bundle entirely. It is this feature that makes liquidation bots use bundles rather than staked lanes. Jito bundles and tips explained describes the construction and limitations.

Also, a bundle enables the unwind: if you receive the collateral in one token, but need another one, the swap in the same bundle will convert it before the price change happens.

Tip economics

The bonus is known before the bundle is submitted, so the tipping is a rational decision, not a gamble.

• Floor: the tip and the priority fees should leave the net bonus above your minimum; otherwise skip the position.
• Ceiling: tipping the entire bonus wins the auction but leaves nothing for you. The goal is to tip a fraction which historically wins for positions of this size.
• Adaptation: record tips on bundles that beat you (visible on-chain via tip-account transfers) and adjust. In volatile periods competition (and thus winning tips) is increased, and in calm periods it is decreased.

A costly mistake: tipping fixed, high tips to "guarantee" the win. Your bot will be winning more liquidations, but losing money on each of them.

Infrastructure

• Placement: collocated near stake and near a Jito block engine region. This way both oracle feed and bundle transmission latencies are minimized.
• Feeds: Jetstream for oracle accounts and Yellowstone for position state, both from the same region where the bot is placed.
• Dedicated capacity: a dedicated node with the Jito client eliminates the shared-infrastructure variation from both feeds.
• Multi-region setup is preferable if protocols that you cover operate all the time and leaders switch across the globe; see the low-latency infrastructure guide about routing.

Risk management

Volatile periods concentrate liquidations and trigger many risks simultaneously. Design for the crash, not calm days.

Measuring the bot

• Oracle observation lag: the difference between the observed slot and the slot where the oracle update landed. Zero with the shred-level feed in the correct region.
• Latency from the oracle update to bundle submission: your code's latency must be well under a millisecond.
• Auction win rates: by position sizes and by tip fraction.
• Net bonus realized vs simulated, per liquidation.
• Rejected bundles by reason: stale state (read side too slow) versus lost auction (tip too low).

It is this last line that will tell you whether you need to invest in the infrastructure or tips.

Conclusion

The Solana liquidation bot is a race of oracle updates with an atomic payoff. Keep all the positions in memory using the Yellowstone gRPC feed, observe the oracle accounts using the shred-level feed, evaluate and assemble the bundle without a single network call, simulate it, size the tip from the known bonus, and submit to the nearest block engine. Then measure the oracle observation lag and reasons for rejected bundles, and spend accordingly.

The two feeds are provided by Jetstream gRPC; for the bundle side and comparison with other approaches see Solana MEV relayers compared.