Solana shred feeds for liquidation bots
A stage-by-stage latency budget for updating borrower health from shreds and submitting a liquidation with current oracle and reserve state.
Where the milliseconds go
6 stages separate insolvency from execution
Liquidation begins when protocol-defined collateral value no longer covers debt by the required margin. The profitable action is narrower: identify an eligible obligation, calculate the allowed repayment and collateral receipt, submit a valid transaction, and land before the state changes.
A raw shred feed advances the first observation. It does not alter the lending program's rules or guarantee transaction priority. shredstream.sh delivers raw UDP from Frankfurt to one IP and port for $100 over 30 days. The feed measured 54.3 Mbps, 5,585 packets per second, and 1,216 mean packet bytes on 2026-08-31, which implies 17.6 TB over 30 days.
The decoder therefore processes billions of datagrams to identify a small set of price, reserve, and obligation mutations. A liquidation system earns its timing advantage by narrowing that work before it touches the health engine.
Eligibility is an ordered state calculation
A borrower can cross a threshold because an oracle price changes, accrued interest changes a reserve, collateral is withdrawn, debt is borrowed, or protocol configuration changes. Several of those events can appear close together. Applying them out of order can invent an insolvency that never existed or miss one that did.
Slot and shred indexes provide the first ordering frame. FEC set indexes constrain recovery. Entry and transaction order complete the sequence after reassembly. The state store should label every update with its fork and observation status. Confirmed state and current proposed state are different products and must not share an unlabeled row.
Account keys connect transactions to reserve, obligation, price, and vault records. Program IDs and instruction discriminators select the supported layouts. Instruction data provides deposits, borrows, repayments, liquidations, and configuration changes. Oracle payloads need protocol-specific validation, including publish time, status, confidence, and any aggregation rule used by the lending program.
The leader signature authenticates the proposed shred. Transaction signatures deduplicate and support later audit. Completion flags tell the decoder when an entry boundary is usable. None of those fields says the slot will survive or the transaction will succeed.
There is no public pending liquidation queue
Solana has no public mempool. A borrow or oracle update observed in a shred is already included in a proposed block. The bot is reacting to the earliest form of on-chain execution it can observe, not inspecting a queue of pending transactions.
A borrower rescue transaction may already be on another private path. Another liquidator may have direct leader connectivity. A price update may be followed by a correcting update in the same or next slot. Seeing the threshold crossing first does not settle any of those races.
The bot should distinguish trigger time, decision time, send time, and execution time. Marketing often collapses them into one latency number. That hides the part that matters most, landing under contention.
A defensible latency budget
Detection through submission totals 2.55 to 19.25 milliseconds. Landing adds a much wider interval. The local total is defensible from first principles: sub-millisecond routing, bounded entry decode, recomputation only for affected obligations, one Ed25519 signing operation, and no connection setup. Violate one assumption and the range must change.
The upper decode target includes modest packet reordering or recovery. It does not include waiting for slot completion. A liquidation whose trigger is blocked behind a missing shred needs a deadline. When recovery misses that deadline, the candidate becomes incomplete rather than silently late.
Decision time depends on indexes. An oracle update can affect thousands of borrowers. Recomputing the entire market serially will not fit 3.5 milliseconds. Maintain a collateral-to-obligation index and debt-to-obligation index, then process candidates in parallel or by distance to the threshold. Precompute invariant terms that do not change with price.
Signing assumes the transaction accounts are already known for each supported market. Address derivation, token-account creation, remote signer calls, and RPC simulation add time. They may still be required, but they belong in the measured budget that the actual desk uses.
Work one health-factor example
Assume an obligation holds collateral worth $10,000 under the protocol's accepted oracle price. Its liquidation threshold is 80 percent, so threshold value is $8,000. Debt is $7,920 before a price update. The health ratio against the threshold is 8,000 divided by 7,920, or about 1.0101. It is not liquidatable.
An authenticated oracle update lowers accepted collateral value by 2 percent to $9,800. Threshold value becomes $7,840. Debt remains $7,920 for this simplified example. The ratio is now 7,840 divided by 7,920, or about 0.9899. The obligation crosses below one.
The bot still must apply the protocol's close factor, liquidation bonus, reserve liquidity, minimum amounts, rounding, token decimals, oracle freshness requirements, and transaction fees. Suppose the maximum allowed repayment is $3,960 and the bonus is 5 percent. Headline collateral receipt is $4,158 before swap cost and execution effects. If converting that collateral costs more than the bonus after fees and price movement, eligibility does not imply profit.
The example also assumes no earlier missing mutation. If the borrower repaid in an entry that the receiver did not reconstruct, the calculated liquidation is false. State completeness belongs in the decision input.
Oracle semantics set the boundary
The lending program, not the bot, determines which price source and confidence rule count. A faster external exchange price may predict an upcoming oracle update, but it does not necessarily make an obligation eligible on chain. Submitting before program state crosses the threshold produces a failure or no-op according to program behavior.
Read the exact accounts and instruction versions used by each supported market. Cache decimal scales and fixed-point rules. Match the program's rounding direction. A one-unit boundary error can convert an apparently valid liquidation into rejection.
Price confidence and staleness need explicit treatment. If the program rejects a stale oracle, the local model should reject it too. If the program uses a conservative confidence bound, a midpoint-only model will disagree near the threshold. Fast arithmetic is useful only when it is the same arithmetic execution will apply.
Submission competes on writable accounts
Liquidations often touch heavily contested reserves, token vaults, oracle accounts, and borrower obligations. Account locks can serialize transactions even when compute capacity remains. A higher fee can improve scheduling incentives but cannot make two conflicting writes execute together.
The response needs a recent blockhash or another supported validity mechanism, correct compute limits, sufficient balance, associated token accounts where required, and bounded slippage for collateral disposal. Preparing these elements before the trigger keeps them out of the critical path.
Landing success must be reconciled from confirmed state. The bot should record attempted repay amount, expected collateral, actual token deltas, fee, failure reason, slot, and fork. A sent transaction is not revenue. An accepted relay response is not execution.
UDP loss becomes financial risk
Raw UDP has no ordering, retransmission, or backpressure. Duplicate packets are normal. Missing packets are possible. The receiver must group, reorder, deduplicate, and recover shreds while the rest of the feed continues.
Kernel receive buffers protect finite pauses. They do not fix a processor slower than the sustained feed. At the measured mean, a 250 millisecond stall brings about 1,397 packets before a burst multiplier. Monitor NIC drops, kernel receive-buffer errors, application queue drops, FEC gaps, decode failures, and age of the oldest queued packet.
The source is 64.130.40.90. Firewall policy should allow inbound UDP from that IP to the selected destination port. The challenge is valid for 600 seconds and verifies reachability. It does not benchmark sustained packet loss, decode throughput, or landing latency.
Fail closed when the inputs for a lending market are incomplete. A bot can continue processing other markets while one fork or FEC set is degraded. Global stalls turn one missing packet into missed liquidations everywhere.
Build a reconciliation lane
The fast lane consumes proposed state. A slower lane reads confirmed blocks and account state. It compares every provisional mutation and every submitted liquidation with the canonical result. Differences should update a fork-loss metric, decoder correctness metric, and state-repair process.
Replay captures are valuable when scrubbed and retained under policy. Inject out-of-order packets, duplicates, missing data shreds, and late coding shreds. Confirm that the health engine never emits a candidate from an incomplete prefix. Test network upgrades and instruction version changes before enabling a market.
Use shadow mode first. Calculate candidates and hypothetical profit without signing. Compare predicted eligibility and amounts against actual program execution. A low false-positive rate across calm periods is not enough. Threshold events and volatile slots are the cases that define risk.
When raw shreds are not the constraint
A lending market with slow oracle cadence, wide liquidation windows, or low competition may not need raw input. A parsed stream can reduce maintenance cost. A strategy that sends through a remote signer and a distant generic RPC may lose more time after decision than it saves at detection.
Frankfurt-only origin matters for receiver placement. One IP and port is a delivery endpoint, not a redundant architecture. Teams that need multiple regions, independent sources, or guaranteed replay must add them explicitly.
Acceptance uses threshold cases
Replay obligations immediately above, exactly at, and immediately below every supported protocol threshold. Match fixed-point scaling, decimal conversion, confidence adjustment, close factor, rounding, and collateral receipt against program execution. Boundary fixtures are more useful than random healthy accounts because one unit can change eligibility.
Run the live engine in shadow mode through volatile oracle updates. For each candidate, save the state prefix, completeness flag, calculation version, expected repay, expected collateral, fee estimate, and deadline. Reconcile with the first canonical state in which the response could have executed. Classify false candidates by missing mutation, fork loss, price correction, model error, or contention.
An operational test should remove one required shred and supply enough coding shreds later. The bot must remain closed before recovery, emit at most one candidate afterward, and preserve the later readiness timestamp. A permanently incomplete set must not block independent markets.
Measure landed profit by reserve and leader, not only overall. A 10 millisecond local pipeline with poor account contention or submission placement can underperform a slower but better-routed system. The acceptance result is correct profitable execution after all fees, not candidate count.
The economic test is the full path. Earlier proposed state has value when health recomputation is correct, the candidate survives conservative costs, the outbound route is competitive, and actual land rate improves. Detection alone is a timestamp. Liquidation is the settled result.
What this desk reads
- slot and shred index, to preserve the order of oracle, reserve, and borrower mutations
- FEC set index, to recover missing data without blocking on the rest of the slot
- leader signature, to authenticate proposed state changes before recomputing health
- program ID and instruction discriminator, to select supported lending and oracle updates
- account keys, to map each mutation to reserves, obligations, price accounts, and vaults
- instruction amounts and price data, to recompute debt, collateral value, limits, and bonus
- transaction signature, to deduplicate events and reconcile provisional decisions later
Questions
- Does a shred feed show liquidations before they happen?
- A shred feed can show the price, reserve, or borrower mutation that creates eligibility while its proposed block is being broadcast. It does not expose a public pending queue, and it does not guarantee the triggering slot survives. The liquidation response still competes for a later execution position.
- Why can an oracle update require more than one health calculation?
- One price account can affect many obligations that hold the asset as collateral or debt. A low-latency engine needs indexes from each reserve to affected borrowers, cached invariant terms, and a priority rule near the threshold. Recomputing every obligation after every price update can exhaust the decision budget.
- What should a liquidation bot do when shreds are missing?
- The bot should attempt bounded FEC recovery, mark the affected fork state incomplete, and reject decisions that depend on absent mutations. It can continue on independent markets. A confirmed or parsed source should later reconcile state, but it cannot validate a trade retroactively at the moment of signing.