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.

Raw UDP from Frankfurt reaches the oracle ingestion host through its own registered socket, preserving provenance before aggregation. That oracle destination costs $100 over 30 days; every other published standalone amount is higher, so source-diversity budgets can focus on independent observations and validation work.

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

Because pending Solana transactions are not exposed through a public mempool, an oracle sees a shred-derived trade only after candidate block inclusion. It may arrive before parsed RPC or account notifications, yet failure or a losing fork can remove it. Immediate use therefore selects 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

The proposed trade sequence combines slot and shred position with positions for entry and transaction. Recovery-set identity and completion flags show whether the relevant range is complete or recovered. Authenticate its producer through the leader signature, then select a parser from shred version.

Program identity together with account keys maps a transaction onto a supported venue, pool, mint pair, vault, or oracle account. Instruction data can supply trade limits and sizes. Reserve changes can support a pool-implied price. A multi-hop transaction needs care because intermediate token amounts are not necessarily independent market observations.

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.

Give aggregation its own time allowance

Oracle work before outbound publication totals 3.18 to 31.2 milliseconds. Decision receives up to 10 milliseconds because aggregation controls matter more than a local benchmark. Landing adds a broader 60 to 550 millisecond planning interval 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.

Measure local intervals against monotonic time. Cross-host analysis requires synchronized wall clocks and monitored offset. Never subtract unrelated-machine timestamps and label 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 yet expose an old on-chain account for hundreds more. Consumers see the landed update, not the publisher's internal candidate. Measure arrival through candidate, candidate through send, outbound duration until land, and land until 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

The oracle's raw UDP input offers no ordering, retransmission or backpressure. Missing fragments can hide a trade or reserve change needed for pricing. A duplicate can overweight an event without signature deduplication, and reordered entries can invert a local price path.

Key observations by their slot and FEC set, restore order, and recover with coding shreds. Give proposed inputs a bounded deadline. If state remains incomplete, exclude or downweight it under published policy. Later canonical commitment repairs history but cannot complete an earlier publication decision.

Busy packet intervals require batched receives and memory reuse on 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.

The oracle firewall associates sender 203.23.178.228 solely with its selected UDP socket. The activation probe expires in 600 seconds and checks one datagram's arrival, without validating pricing method or sustained 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.

Use raw shreds in a fast publishing rule

Oracle rules make raw shreds valuable when they consume Solana-native observations, preserve forks, and update quickly enough for millisecond input to matter. A prepared publisher combines early observation with explicit aggregation, confidence, and reconciliation policy.

At its designated socket, the oracle receiver gets raw UDP originating in Frankfurt. It gets no packet order, retransmission, sender backpressure, regional redundancy, or transaction landing. Build recovery, source policy, and outbound publication explicitly into oracle architecture.

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.