Skip to content
All use cases
Solutions

Solana shred feeds for arbitrage

A measured latency budget for detecting a Solana price dislocation in shreds, deciding whether it survives costs, and submitting the next transaction.

Where the milliseconds go

StageBudgetNotes
Detection0.2 to 1.0 msMatch decoded account keys and instruction discriminators as entries become available.
Decode0.4 to 2.0 msReassemble the needed FEC set, deserialize entries, and update only touched pools.
Decision0.3 to 1.5 msReprice a prepared route with fees, slippage, and a stale-state haircut.
Signing0.05 to 0.30 msSign a prebuilt message with an in-memory key or local signer.
Submission1 to 12 msSend over a warm path to the scheduled leader or a low-latency relay.
Land50 to 450 msWait for leader scheduling and execution in a later slot; this dominates variance.

6 stages decide the race

Arbitrage starts with a price difference and ends only when all legs settle. A raw shred feed moves detection closer to block production. It does not remove execution risk, state contention, fees, or the chance that another transaction changes a pool before the response lands.

shredstream.sh sends raw UDP from Frankfurt to one IP and port. The plan costs $100 for 30 days. The measured feed on 2026-08-31 averaged 54.3 Mbps, 5,585 packets per second, and 1,216 bytes per packet, or 17.6 TB over 30 days. Those numbers define the receive path. They do not define an arbitrage profit.

The useful comparison is not raw shreds against a perfect state oracle. It is raw shreds against the first alternative source that can tell the desk enough to act. A websocket account update, parsed transaction stream, or RPC block notification arrives after more assembly and processing. The value of removing those stages depends on whether the remaining route can fit inside the opportunity lifetime.

The observation is already inside a proposed block

Solana has no public mempool that exposes every pending swap. A swap found in a shred is not waiting to land. The leader has included it in a proposed block and has started broadcasting the block fragments. An arbitrage response normally targets a later execution position, often in a later slot.

That distinction changes the model. Ethereum-style pending-transaction logic asks what will happen if a visible transaction executes. Shred logic asks what state the current leader appears to have produced, whether that state will survive, and what transaction should be sent to a leader that can still accept it. The signal is early on-chain observation, not advance notice of private intent.

A cross-venue route may combine a Solana pool with a centralized exchange order book. The external leg can move while the Solana leg waits. A Solana-only route may touch two or three automated market makers and compete for the same accounts as other searchers. Both cases require an explicit freshness bound.

Fields that earn their place

The slot is the first partition key. State from two forks must never enter one price calculation without a policy that labels the uncertainty. The shred index provides order inside the slot and supports progress estimates. The FEC set index limits repair and reassembly to the smallest useful group. Waiting for the whole slot sacrifices the timing advantage.

The data or coding variant separates content from recovery material. Data shreds enter the immediate decode path. Coding shreds remain useful because a missing data shred may block an entry that contains the pool update. Completion flags identify useful boundaries, but they do not certify finality.

The leader signature authenticates the producer. Signature verification has a cost, so a desk may verify in a parallel lane after cheap structural checks. Skipping verification entirely turns malformed or spoofed input into trading state. The right pipeline rejects invalid sizes and impossible indexes before expensive work, then refuses to trade on content that has not met the desk's authentication policy.

At the transaction layer, account keys and instruction data matter more than a fully formatted transaction object. The matcher needs program IDs, pool and vault accounts, direction, amount, and any instruction fields that change the invariant. Signatures are useful for deduplication and later reconciliation. Log strings are usually unavailable until execution context is reconstructed and are often too late or too costly for the first filter.

A defensible latency budget

StageTargetWhat the number assumes
Detection0.2 to 1.0 msA receive thread routes candidate fragments by slot and known program accounts without allocation.
Decode0.4 to 2.0 msThe relevant entry is present or recoverable, and decoding stops after the touched transactions are extracted.
Decision0.3 to 1.5 msPool curves and route templates are resident in memory; only affected edges are repriced.
Signing0.05 to 0.30 msThe message is prepared, the blockhash policy is valid, and the signer is local.
Submission1 to 12 msA warm connection reaches an appropriate leader path from a nearby host. Geography can make this much larger.
Land50 to 450 msThe response reaches a leader with capacity and executes in a following opportunity.

The first five stages total 1.95 to 16.8 milliseconds. That sum is a target for controlled infrastructure, not a claim about the public internet. Landing adds a wider 50 to 450 millisecond interval because leader timing, queue position, account contention, compute limits, transaction validity, and the current point in the slot dominate it.

Detection below one millisecond is credible when it means classification, not full semantic decode. A batch receive call can timestamp multiple datagrams and place references into per-slot queues. A compact account-key prefilter can reject most entries. Copying every packet, allocating one object per shred, and logging on the hot thread will consume the budget before strategy code runs.

Decode time depends on boundaries. One shred may contain fragments of several transactions, and one transaction may cross shreds. The lower bound applies when all necessary data is present. The upper target assumes limited erasure recovery or short reordering, not a long wait for slot completion. Record separate histograms for clean decode and recovered decode.

Decision time stays small because the route graph is prepared before the signal. The desk keeps pool parameters, fees, token decimals, address lookup data, and transaction templates in memory. The event invalidates a small set of edges. A full graph search, remote database call, or RPC read belongs outside this budget.

Signing is rarely the largest local stage. A local Ed25519 signature can fit below a fraction of a millisecond on ordinary server hardware, but a network hardware security module will not. A remote signer can add several milliseconds and tail spikes. Security policy may require that trade, and the latency budget should show it rather than hide it.

Submission measures application send to acknowledgement or a local send milestone, not landing. A prepared connection avoids DNS, TLS, and session setup on the critical path. Direct leader paths change with the schedule. Relay paths add their own queues and policies. The Frankfurt origin of the incoming feed says nothing about the location of the next leader or the desk's submit route.

Price the state that could exist

The response should be evaluated against at least three states. The first is the last confirmed state. The second applies every decoded transaction from the observed fork in order. The third adds a conservative contention model for transactions that may land before the response. A route profitable only in the second state has no safety margin.

Suppose a decoded swap moves pool A from 100.00 to 100.42 while pool B remains at 100.18. The headline spread is 24 basis points. A useful calculation subtracts pool fees on both legs, priority fee, expected adverse movement, failure cost, and inventory hedge cost. If those total 19 basis points, only 5 basis points remain. A 10 basis point stale-state haircut rejects the trade.

The decision is not improved by pretending the observed swap is final. The slot can be skipped. The transaction can fail. A fork can replace the block. The decoder can be missing a preceding entry that changes the same account. Each case needs a confidence state that follows the event into the order record.

Landing is a separate system

Seeing a dislocation before an RPC client does not establish transaction priority. The response must still reach a leader, carry a recent blockhash, fit account and compute constraints, bid an appropriate priority fee, and avoid expiration. Competing searchers may have a shorter submission path or a better execution position. The leader may already have built the relevant part of its block.

Atomicity also has boundaries. A single Solana transaction can make multiple on-chain legs atomic when account and compute limits permit. A centralized exchange leg cannot share that atomicity. Inventory must cover partial fills and exchange outages. A raw feed reduces observation delay, but it does not make a cross-venue trade atomic.

The correct success metric is not detected spreads. Measure submitted opportunities, simulated profitability at decision time, landed transactions, executed profit, failed fees, hedge slippage, and profit after all costs. Join each outcome to the source slot, shred arrival timestamps, decode completion, sign time, send time, and landed slot.

UDP loss changes confidence

Raw UDP provides no ordering, retransmission, or backpressure. The receiver must tolerate duplicates, reorder by index, and use coding shreds for recovery. A kernel buffer can absorb a finite stall. It cannot repair sustained overload. At the measured 5,585 packets per second, a 100 millisecond pause means about 559 packet arrivals at the mean before burst allowance.

Track gaps by slot and FEC set. If the entry containing a pool mutation cannot be reconstructed within the strategy deadline, mark the derived state incomplete. Do not silently carry the last price forward. A slower decoded source can act as a reconciliation lane, even when it is too late for the trade.

Source filtering matters. The feed arrives from 64.130.40.90. The firewall should allow inbound UDP from that address to the purchased destination port and deny unexpected sources according to local policy. The destination challenge expires after 600 seconds. Passing that challenge proves a datagram can reach the receiver at that moment. It does not prove loss-free delivery under production load.

Architecture for a narrow hot path

The receive thread should do four things: read batches, timestamp them, perform cheap validation, and enqueue references. FEC workers group by slot and set. Decode workers reconstruct entries. Strategy workers maintain fork-labeled pool state and evaluate prepared routes. A submission process owns keys and outbound connections. Separating these responsibilities makes each queue measurable.

Backpressure is local because the sender will not slow down. Every queue needs a bound and an overload rule. Dropping oldest work may be correct when stale arbitrage has no value. Dropping coding shreds first may save decode capacity until loss makes recovery necessary. The chosen rule must surface as a metric.

Clock discipline gives the measurements meaning. Kernel receive timestamps, a monotonic process clock, and synchronized hosts permit stage comparisons. One-way latency from the leader is harder because leader clocks and capture points differ. Compare distributions and controlled paths, not a single attractive minimum.

When raw shreds are the wrong input

Raw shreds are a poor fit when the strategy holds opportunities for seconds, the team does not operate a packet pipeline, or the submit path already adds hundreds of milliseconds. A decoded stream may offer lower engineering cost with enough timing margin. Confirmed RPC is the better authority for accounting, settlement, and customer balances.

Frankfurt-only delivery also matters. A receiver far from Frankfurt pays network propagation before detection. One IP and port means the plan is not a global multicast design. A desk needing regional redundancy, multiple independent sources, retransmission, or a service-level guarantee should design those separately and should not infer them from raw UDP.

The edge is the measured remainder

An arbitrage desk can defend a shred feed only when it measures the whole path. The meaningful number is the opportunity lifetime minus detection, decode, decision, signing, submission, and landing uncertainty. If the remainder stays positive after fees and failure costs, earlier observation has value. If landing dominates the window, faster input creates prettier timestamps rather than profit.

What this desk reads

  • slot, to reject stale state and bind every observation to a fork candidate
  • shred index, to order payload fragments and estimate progress through the slot
  • FEC set index, to group recovery work without waiting for unrelated shreds
  • data or coding variant, to prefer data on the fast path and use coding shreds for repair
  • completion flags, to know when an entry boundary or slot boundary is available
  • leader signature, to authenticate the proposed data before it changes a price model
  • transaction account keys and instruction data, to identify pools, vaults, direction, and amount

Questions

Does a shred feed reveal pending Solana swaps?
No. Solana has no public mempool comparable to Ethereum's. A swap found in shreds has already been included in a leader's proposed block. The feed exposes that proposal during block production, before normal RPC delivery, but a response still targets a later execution position and may not land.
How much local latency should an arbitrage system target?
Detection through submission can target roughly 2 to 17 milliseconds under the stated assumptions. Landing then adds about 50 to 450 milliseconds of wider variance. Geography, recovery work, signer policy, leader access, account contention, and priority fees can move those ranges, so every stage needs production histograms.
Can raw shreds guarantee an arbitrage profit?
No. Raw shreds reduce observation delay. They do not guarantee finality, transaction priority, atomicity across external venues, state freshness, or a successful landing. Profit must be measured after pool fees, priority fees, failed transactions, adverse movement, inventory carry, and any hedge slippage.