Solana shred feeds for oracle publishers

6 stages move an observation on chain

An oracle publishes a price or other external fact under a defined aggregation and trust model. A shred feed can reduce the delay for Solana-native market observations. It cannot turn one proposed trade into objective truth, remove manipulation risk, or guarantee that an update transaction lands.

shredstream.sh delivers raw UDP from Frankfurt to one IP and port. The price is $100 for 30 days. On 2026-08-31, the feed measured 54.3 Mbps, 5,585 packets per second, and 1,216 mean packet bytes, or 17.6 TB over 30 days. Oracle infrastructure must process the stream while preserving enough provenance to reject bad observations.

The latency case is strongest when a publishing rule already depends on Solana state and the difference between proposed observation and normal RPC is material. A sound oracle still combines sources, applies confidence, and states exactly when proposed data can affect a published value.

Proposed trades are not a public pending feed

Solana has no public mempool. A trade decoded from a shred has already been included in a leader's proposed block. It may be observed before parsed RPC or account notifications, but it can fail or disappear with its fork. An oracle that uses it immediately is choosing a provisional input.

That choice can be valid under a documented model. For example, a fast risk signal may include proposed venue state at reduced weight while the canonical price uses confirmed inputs. A liquidation-critical oracle may require stronger status. The feed does not decide this policy.

An on-chain update also lands after the observation. Consumers can act only when the oracle transaction reaches program-visible state. Local decode speed and on-chain freshness are separated by signing, submission, leader scheduling, and account contention.

Fields establish source and sequence

Slot, shred index, entry order, and transaction order establish the proposed sequence of trades and reserve changes. FEC set index and completion flags show whether the relevant entry range is complete or recovered. The leader signature authenticates the shred producer, and shred version selects the parser.

Account keys and program IDs map a transaction to a supported venue, pool, mint pair, vault, or oracle account. Instruction data can supply trade limits and sizes. Reserve account changes can support a pool-implied price. A multi-hop transaction needs care because an intermediate token amount is not necessarily an independent market observation.

Transaction signature deduplicates the event and lets reconciliation remove its contribution when a fork loses. Arrival and decode timestamps support staleness checks. The platform should retain whether a value came from direct data shreds, FEC recovery, a confirmed API, or an external venue source.

None of these fields establishes economic independence. Ten pools controlled by one actor are not ten independent sources. Source topology and manipulation cost belong in the aggregation method.

A defensible latency budget

Detection through submission totals 3.18 to 31.2 milliseconds. Decision receives up to 10 milliseconds because an oracle should not discard aggregation controls to win a local benchmark. Landing adds a wider 60 to 550 millisecond planning range and can exceed it during congestion, skipped slots, or route failure.

Detection is a candidate route. Decode is semantic extraction under supported program versions. Decision is the oracle method: source selection, normalization, outlier handling, weighting, confidence, staleness, and circuit breakers. Signing authenticates the publisher's payload. Submission sends its transaction. Land is when consuming programs can read the update.

The lower figures require prepared data structures and no synchronous external call. External exchanges can still contribute through independent adapters with their own timestamp and latency distributions. The aggregator should not wait indefinitely for one slow source.

Work a weighted-median example

Assume the oracle has five eligible observations for SOL/USD after normalization: 99.92, 99.98, 100.01, 100.04, and 103.50. Their effective liquidity weights are 20, 25, 30, 15, and 10 percent. The final value is a weighted median under the oracle's published method.

Sorted cumulative weight crosses 50 percent at 100.01, so the candidate price is 100.01. The 103.50 observation is far from the group and has only 10 percent weight. A deviation rule can exclude it or widen confidence without letting it drag a volume-weighted mean upward.

Now assume the 100.04 observation came from a proposed shred transaction and the other four are confirmed or external. The method assigns proposed input half of its normal weight until processed. Its effective contribution falls from 15 to 7.5 units for this update. The median remains 100.01.

This example is one transparent method, not a prescription for every oracle. The actual design must document source eligibility, weight caps, status discounts, confidence calculation, update threshold, and fallback. The key point is that early input has an explicit influence rather than an undefined one.

Avoid circular market truth

An oracle used by a lending market may observe the same on-chain venues that liquidations trade against. A large trade can move the pool, move the oracle, trigger liquidations, and produce more trades. Fast feedback can intensify that loop.

Use source diversity, liquidity thresholds, weight caps, time-weighting where appropriate, and deviation circuit breakers. Model the cost to manipulate each source. A pool price with shallow reserves should not receive the same confidence as a deep venue merely because both arrived within one millisecond.

If the oracle update itself changes a market that feeds the next calculation, label that dependency. Independence is an architectural property, not a count of adapters.

Proposed state adds fork risk to the loop. A transient trade can create a transient oracle update that nevertheless lands on a surviving fork. The publisher must decide whether it is acceptable to write from a source observation that has not reached the same commitment.

Timestamps need a stated origin

Kernel receive time is a strong local timestamp for packet arrival. Entry-ready and decode-complete times show processing delay. Venue event time may be derived from slot context, but it is not the same clock. External exchange timestamps have their own clock quality and transport delay.

Use a monotonic clock for local intervals. Synchronize wall clocks for cross-host analysis and monitor offset. Do not subtract timestamps from unrelated machines and call the result one-way latency without an error bound.

Staleness should be evaluated at publication decision and again if submission is retried. A candidate value can be fresh at sign time and stale before landing. Include an expiry or publish-time rule that consuming programs can enforce where the oracle protocol supports it.

Signing is both latency and authority

The oracle key authorizes data that downstream protocols may trust with substantial value. An in-memory signer can meet the low range but expands host risk. A local isolated signer or remote quorum can add time. The security model should determine the path, then the latency table should reflect measurements.

The signer can enforce feed IDs, maximum deviation, freshness, sequence, and rate limits independently of the aggregator. A compromised parser should not gain authority to sign arbitrary payloads. Rotate keys and test failure behavior without putting emergency network calls in the critical path.

Signing a candidate does not publish it. A recent blockhash, compute budget, account set, fee, and submission route still matter. Record the payload hash so the signed decision can be joined to the landed account value.

Landing defines consumer freshness

An oracle can calculate a value in 20 milliseconds and still expose an old on-chain account for hundreds of milliseconds. Consumers see the landed update, not the publisher's internal candidate. Measure observation-to-candidate, candidate-to-send, send-to-land, and land-to-selected commitment.

Account contention can arise when many publishers or aggregation instructions write the same price account. Transaction size and compute can constrain batching. Larger batches amortize fees but can delay the first instrument and increase the blast radius of one failure.

Priority fees should be tied to the value of freshness and the protocol's cost model. A high fee improves incentives but does not make an invalid transaction valid or guarantee position. Retries need unique sequencing and expiry rules to avoid publishing stale values later.

UDP loss must lower input confidence

Raw UDP has no ordering, retransmission, or backpressure. A missing fragment can hide a trade or the reserve change needed to price it. A duplicate can overweight an event if transaction signatures are not deduplicated. Out-of-order entries can invert a local price path.

Group by slot and FEC set, reorder, and use coding shreds for recovery. Set a bounded deadline for proposed observations. If state remains incomplete, exclude or downweight it according to published policy. A later confirmed source repairs history but cannot make an earlier publication decision complete.

At 5,585 mean packets per second, batch receive and memory reuse protect the hot path. Monitor network drops, kernel drops, queue age, FEC gaps, recovery delay, parser errors, source count, aggregate confidence, signer delay, submission delay, and land delay.

Allow inbound UDP from 64.130.40.90 to the selected port. The 600-second destination challenge checks that one datagram can arrive. It does not validate the oracle method or sustained receiver capacity.

Reconciliation is part of publishing

Join every observation to its final transaction outcome and every oracle candidate to its landed account update. Record which inputs survived, which fork lost, and whether the published value would change under canonical-only data. This measures the real cost of proposed inputs.

Replay captures through parser and aggregation versions. Inject gaps, duplicates, outliers, stale sources, clock jumps, and signer timeouts. Verify circuit breakers and fallback behavior. A fallback that has never been tested is another unknown source.

Publish the method in enough detail to reproduce sample outputs. Users should know the formula, source policy, update threshold, confidence meaning, and commitment treatment. Low latency earns trust only when its calculation can be audited.

When a shred feed does not fit

An oracle based mainly on off-chain venues may gain little from raw Solana data. A protocol that updates every minute can use a parsed or confirmed source with lower operational cost. An oracle without fork-aware reconciliation should not adopt proposed observations merely for a smaller timestamp.

The service is Frankfurt-only raw UDP to one IP and port. It provides no retransmission, ordering, backpressure, global source diversity, or transaction landing. Those remain oracle design responsibilities.

The defensible benefit is a measured reduction in one input path. A prepared publisher can turn available bytes into a submitted update in about 3 to 31 milliseconds. Consumer freshness still depends on landing, and oracle truth still depends on method.