Solana shred feeds for liquidation bots

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 lending rules or guarantee transaction priority. The bot timestamps full-stream packets at its registered address as they arrive from Frankfurt. At $100 across 30 days, this destination costs less than every published standalone raw-feed offer, so the relevant expense is measured against each liquidation outcome.

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. Supported layouts are selected through the program identifier plus instruction discriminator. Instruction bytes describe deposits, borrows, repayments, liquidations, and configuration changes. Oracle payloads need protocol-specific validation, including publish time, status, confidence, and the lending program's aggregation rule.

Authenticate each proposed shred against its leader signature. Use transaction signatures for event deduplication and later audit. Completion flags tell the decoder when an entry boundary is usable. None of these fields says the slot will survive or the transaction will succeed.

Liquidation signals appear after inclusion begins

The liquidation bot cannot inspect a public Solana mempool. A borrow or oracle update becomes visible only after inclusion in candidate block data. The bot reacts at the moment that mutation arrives, not while it waits in a pending queue.

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.

Time the race from price mutation

Before send, the five local liquidation stages consume 2.55 to 19.25 milliseconds. Landing adds a much wider interval. That local range follows from sub-millisecond routing, bounded entry decode, recomputation only for affected obligations, one Ed25519 signature, and no connection setup. Break any assumption and the budget changes.

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 matters only when it matches the calculation 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 leaves the liquidation bot without ordered delivery, retransmitted gaps, or backpressure. Duplicate packets are normal and gaps are possible. The receiver groups, reorders, deduplicates, and recovers shreds while later traffic continues.

Kernel receive buffers protect finite pauses, not processors slower than sustained input. Size them from declared stall tolerance plus measured burst traffic in short windows. Monitor NIC loss, socket-buffer errors, application queue drops, FEC gaps, decode failures, and oldest queued age.

The bot expects sender 203.23.178.228. Restrict its chosen UDP port to this address. Run the 600-second reachability challenge to check arrival without benchmarking sustained 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.

Pair early input with a fast execution path

Raw shreds deliver their largest timing gain when oracle cadence, liquidation windows, and competition reward millisecond detection. Keep the signer local and the submission route warm so the early observation carries through to execution.

Frankfurt-origin delivery reaches the bot's sole configured IP and port. Raw UDP supplies neither packet order nor retransmission, and offers no backpressure, regional redundancy, or guaranteed replay. Receiver placement, recovery, and completeness policy must reflect those properties.

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.