Solana liquidation bot guide: infrastructure and latency setup

TL;DR

→  Liquidation bots earn a bonus for closing underwater loans on lending protocols—Kamino, MarginFi, Drift, Save. When a position's health factor drops below 1.0, whoever liquidates it first captures a 2–8% bonus on the collateral.

→  It's a pure latency race. Every bot watches the same oracle feeds and sees the same price tick at the same instant. The bonus goes to whoever recomputes health, builds, and lands the liquidation fastest.

→  The detect-to-submit budget is under 65 ms. Oracle ingest, health recompute, build + simulate, submit—a competitive bot completes all four in the time a public-RPC bot spends just talking to its endpoint.

→  Health factor = (collateral × liquidation threshold) / borrowed value. It falls when collateral prices drop or borrow interest accrues. Your bot recomputes it on every relevant account write, not on a polling loop.

→  Atomic execution matters. Bundle the oracle update and the liquidation call together so they land in the same slot or neither does—otherwise you liquidate against a price that already moved.

→  Infrastructure caps your ceiling. A perfect health-factor engine on public RPC still loses to a simpler bot on dedicated, co-located, SWQoS-staked infrastructure. The spread is stable and measurable.

→  Higher bonus means more competition. Save offers ~8% but draws a crowd; Drift's ~2% is less contested. The trade-off is bonus size versus how fast you must be to win it.

‍

This guide walks through how liquidation bots actually work on Solana in 2026—the mechanics of health factors and the liquidation lifecycle, the latency budget that separates winners from bots that pay priority fees to revert, and the specific infrastructure decisions that determine whether your bot captures bonuses or watches other bots capture them. It's written for people building or operating liquidation infrastructure, not for a general audience.

What a liquidation actually is

Lending protocols let users borrow against collateral. You deposit SOL, borrow USDC against it, and as long as your collateral is worth enough relative to your debt, the position is safe. But collateral prices move. When the value of your collateral falls—or your debt grows through accrued interest—the position can reach a point where the protocol is at risk of bad debt. At that point, the protocol allows anyone to step in, repay part of the debt, and seize a portion of the collateral at a discount. That discount is the liquidation bonus, and it's the incentive that keeps lending protocols solvent. Protocols like Kamino, MarginFi, Drift, and Save (formerly Solend) all run some version of this mechanism.

From the protocol's perspective, liquidation bots are a feature, not a nuisance. They're the distributed keeper network that keeps the system solvent. Every underwater position that gets liquidated promptly is bad debt that never materializes. The bonus is the protocol paying for that service. Your job, as a bot operator, is to provide that service faster than anyone else competing for the same bonus.

The health factor

The core metric every liquidation bot tracks is the health factor (some protocols call it the health ratio or use the inverse as a "risk" number, but the concept is identical). It's a single number that expresses how close a position is to being liquidatable:

When the health factor crosses below 1.0, the position is liquidatable and the race is on. Two things push a position toward that threshold: the collateral price falling (an oracle tick downward) or the borrowed amount growing as interest accrues over time. The first is fast and unpredictable; the second is slow and calculable. Competitive bots track both, but the money is made on the fast path—reacting to oracle updates the instant they land.

The liquidation lifecycle

A liquidation is a five-step pipeline, and every step is on the critical path. The clock starts the moment an oracle price update lands and stops when your liquidation transaction confirms on-chain. Everything in between is latency you're racing to minimize.

1. Oracle update—the starting gun

Solana lending protocols price collateral using oracles, primarily Pyth and Switchboard. When a price update lands on-chain, it can instantly change the health factor of thousands of positions. Your bot needs to see that update the moment it hits—not a few hundred milliseconds later when it propagates through Turbine. This is the ingestion side of the race, and it's where streaming infrastructure earns its keep.

2. Detection—recompute health, flag the position

The instant an oracle update arrives, your bot recomputes the health factor for every position that references that price feed. This must be an in-memory operation against a cached position set—if you're making RPC round-trips to fetch position data at this stage, you've already lost. A competitive detection engine holds every open position in memory, indexed by the oracle feeds that affect it, and recomputes health in microseconds when a relevant feed updates. Target: under 20 ms from oracle update to flagged position.

3. Build and simulate—construct the liquidation

Once a position is flagged, the bot constructs the liquidation transaction: the specific instruction the protocol exposes for repaying debt and claiming collateral, with the right accounts, amounts, and slippage bounds. Then it simulates. Simulation against current state catches the common failure modes—the position already liquidated by someone else, the collateral amount changed, the price moved again—before you spend a priority fee on a transaction that will revert. Simulate against the same endpoint you'll submit through, referencing the Solana transaction model. Target: under 15 ms.

4. Submit—get to the leader first

This is where the liquidation either lands or doesn't. Submission isn't a single API call—it's a routing decision. The disciplined pattern is to bundle the liquidation atomically (often alongside the oracle update itself, so both land in the same slot) via Jito bundles, attach a calibrated priority fee, and submit in parallel to multiple relays and regions so the bundle reaches whichever leader is producing the current slot. A staked submission path matters enormously here—during the congestion that often accompanies the price moves that trigger liquidations, non-staked paths get deprioritized exactly when you need them most. Target: under 30 ms.

5. Capture—or revert

The liquidation lands and you capture the bonus plus the seized collateral, or it reverts because another bot got there first and the position no longer exists. On a revert, you've paid the transaction fee and the priority fee for nothing. This is why steps 2 through 4 matter so much: the difference between capturing a bonus and paying to revert is often a handful of milliseconds spread across the pipeline.

Why it's a latency race, not a strategy game

Here's the uncomfortable truth about liquidation bots: there's very little strategy. Every competent bot knows which positions are close to liquidation. Every bot watches the same oracle feeds. When a price update lands, every bot recomputes the same health factors and identifies the same liquidatable positions. There's no hidden signal, no clever edge in the logic. The position is public, the trigger is public, the bonus is public.

What separates the bot that captures the bonus from the five bots that revert is pure speed—the end-to-end latency from oracle update to landed liquidation. And that latency is dominated not by your code, but by your infrastructure.

The chart above shows the race in raw form. Two bots, identical logic, same oracle tick. The fast bot—dedicated, co-located infrastructure—completes the full pipeline in about 60 ms and lands the liquidation. The slow bot on public RPC spends 60 ms just ingesting the oracle update, another 75 ms detecting and building, and 180 ms fighting through a congested public submission path. By the time its transaction reaches the leader, the position is already gone. It pays a priority fee to revert.

Notice where the slow bot's time goes. It's not that its code is worse—the detection and build steps are only modestly slower. The killer is the two infrastructure-bound segments: oracle ingest (60 ms vs 8 ms) and submission (180 ms vs 25 ms). Those are not code problems. No amount of optimizing your health-factor engine closes a 155 ms submission gap. That gap lives in the infrastructure layer, and it's the whole ballgame.

The infrastructure stack that wins

A competitive liquidation bot is four layers, and each layer is only as fast as the one below it. You build from the bottom up, because a fast application layer on slow infrastructure is a fast car with no road.

Layer 1—oracle and account streaming

The foundation is how fast you see chain state. Polling is dead for this use case; you need push-based streaming. Yellowstone gRPC gives you structured account and slot streaming, filtered server-side so you only receive the oracle feeds and lending-protocol accounts you care about. Paired with Jito ShredStream for sub-slot shred delivery, you see oracle updates 50–200 ms earlier than a bot waiting for standard Turbine propagation. On a strategy measured in milliseconds, that head start is often the entire margin.

Layer 2—the health-factor engine

Above streaming sits your detection logic. The design principle is that nothing in the hot path touches the network. Every open position across the protocols you cover is held in memory, indexed by the oracle feeds that affect it. When a feed updates, you recompute health only for the affected positions—not a full scan—and you do it in microseconds. This is a classifier-fast operation: no RPC calls, no database round-trips, no waiting. The moment a position crosses below 1.0, it's flagged and handed to the execution layer.

Layer 3—execution and submission

The execution layer turns a flagged position into a landed transaction. Pre-signed transaction templates mean you're not building from scratch at the critical moment—you mutate only the volatile fields (amounts, accounts) and fire. Atomic bundling ensures the liquidation and any dependent operations land together or not at all. Multi-relay, multi-region submission gets your bundle to the current leader by the fastest path. And a staked submission identity keeps you prioritized during the congestion that price-move events reliably produce.

Layer 4—dedicated bare-metal RPC

The bottom layer is the one that caps everything above it: the RPC infrastructure itself. Dedicated bare-metal nodes co-located with validators in the major regions (US East, EU, APAC) minimize the physical round-trip that no code change can touch. Sub-1-slot lag means the state you read is current. Sub-50 ms automated failover means a node hiccup doesn't cost you a liquidation. This is the layer where the race is actually won or lost, because it sets the floor on every latency number above it.

Building the detection engine

The heart of a liquidation bot is the detection loop: ingest an oracle update, recompute affected health factors, flag anything below threshold. Here's the shape of it, simplified to the core logic:

The critical property here is that onOracleUpdate does zero network I/O. Every position is already in memory. The oracle price arrives via the stream. The health factor is pure arithmetic. A flagged position goes straight onto the execution queue with a timestamp, so you can measure your own detect-to-submit latency afterward. Everything expensive—loading positions, subscribing to feeds, warming the cache—happens at startup, off the hot path.

Keeping the position set fresh is its own discipline. New positions open, existing ones change, others close. You subscribe to the lending protocol's account changes via the same gRPC stream and update your in-memory cache incrementally, so it always reflects current on-chain state without a periodic full reload that would blow your latency budget.

Choosing your protocols: bonus vs competition

Not all liquidation venues are equal. Each protocol sets its own liquidation bonus, and that bonus directly shapes how much competition you'll face. Higher bonuses attract more bots; the richest opportunities are also the most contested.

The strategic decision is where to compete. The highest-bonus venues draw the most sophisticated, fastest bots—winning there requires top-tier infrastructure and leaves little room for error. Lower-bonus venues are less contested, which can mean more consistent captures for a well-built bot even if each individual bonus is smaller. Many operators run across multiple protocols simultaneously, letting the same detection engine and infrastructure serve several venues at once, since the marginal cost of covering another protocol is mostly just more positions in the in-memory cache.

Bonus figures are indicative and change with protocol governance; always verify current parameters against each protocol's documentation before deploying capital. The broader point holds regardless of the exact numbers: bonus size and competition intensity move together, and your infrastructure quality determines which tier of that trade-off you can profitably play in.

Operational realities and risk

A few things that separate operators who run liquidation bots sustainably from those who burn capital learning:

• Reverts cost real money. Every failed liquidation still pays a base fee and whatever priority fee you attached. A bot that reverts 60% of its attempts can be net-negative even when the captures are profitable. Simulate ruthlessly, and track your revert rate as a first-class metric.
• Capital and inventory management. Liquidating means repaying debt, which requires holding the repayment asset ready. You also end up holding seized collateral you need to unwind—often immediately, to avoid price risk on the position you just acquired. Some bots bundle the collateral sale into the same atomic transaction.
• Oracle staleness and edge cases. Acting on a stale oracle read is a fast way to liquidate against a price that already moved. Verify oracle freshness as part of your health computation, and encode defensive assertions so a liquidation reverts cleanly if state drifted between detection and execution.
• Congestion is correlated with opportunity. The price moves that trigger waves of liquidations are exactly the moments the network congests. Your infrastructure has to perform best under precisely the conditions where public infrastructure performs worst. This is not a coincidence you can engineer around in code—it's an infrastructure requirement.

What good looks like: liquidation bot latency benchmarks

Reference numbers from RPC Fast internal benchmarks, comparing liquidation-bot pipeline performance across infrastructure tiers, Q1 2026, sampled during oracle-driven liquidation events:

Numbers are illustrative aggregates and vary by protocol, region, and market conditions. The shape is what matters: the win-rate spread between tiers maps almost entirely to the ingest and submission latencies, which are infrastructure-bound, not code-bound. On dedicated infrastructure, you win most of the liquidations you contest; on public RPC, you win a small fraction and pay to revert on the rest.

What actually matters

Liquidation bots are the clearest case in all of Solana MEV where infrastructure, not strategy, decides the outcome. There's no clever signal to discover, no proprietary logic that beats a faster competitor. Every bot sees the same oracle tick, computes the same health factors, and identifies the same liquidatable position. The bonus goes to whoever lands the liquidation first—and landing first is a function of how fast you ingest oracle updates and how fast you get your transaction to the leader.

Both of those are infrastructure. You can write a perfect health-factor engine, index your positions flawlessly, and pre-sign every template—and still lose every contested liquidation to a bot with simpler code on dedicated, co-located, staked infrastructure. The application layer is table stakes. The infrastructure layer is the edge. If your liquidation bot is reverting more than it's capturing, the fix is almost never another round of code optimization. It's the road underneath the car.