How does the Solana repair protocol work?

Repair begins after a gap exists

Turbine is the first-wave broadcast. Coding shreds provide forward recovery within a fec set. Repair handles deficits that remain.

A validator notices that blockstore lacks required shreds, that a slot is incomplete, or that ancestry needed for replay is unavailable. Its repair service turns those observations into requests toward peers likely to have the missing ledger data.

The order matters. Requesting every missing datagram immediately would create unnecessary traffic because UDP reordering is normal and coding shreds may reconstruct the data without a round trip. Waiting too long delays replay and voting. Clients use timing, progress, and bounded outstanding-request logic to choose when repair becomes appropriate.

Repair is therefore a feedback loop. The receiver detects a concrete hole, asks, validates a response, updates local state, and retries or changes peers if the hole remains.

Turbine and repair have different goals

Turbine optimizes broad, timely dissemination while a leader is producing a block. It sends without waiting for acknowledgements from every receiver.

Repair optimizes eventual availability for a specific node that knows it is missing something. It can name a slot and shred index or request related information that helps locate a missing branch. The exchange spends extra messages to target a known deficit.

Combining the mechanisms lets Solana keep the production path fast without abandoning nodes that experience loss. Most packets should arrive or be reconstructed through the first wave. Repair covers the tail.

The performance interpretation is clear. A repaired shred can make the local ledger complete and keep the validator participating. It is normally later than a healthy direct or coded arrival and should not be marketed as earliest market data.

Blockstore reveals missing indices

Validators insert received shreds into blockstore, indexed by slot, shred type, recovery set, and position. Metadata tracks what has arrived, what is contiguous, and whether the slot appears complete.

An index gap is evidence, not always an immediate failure. The packet may be reordered in flight. A coding shred may soon make recovery possible. The leader may not have emitted the later index yet. Slot metadata and timing distinguish these cases.

Once a deficit blocks replay or exceeds the normal arrival window, repair logic can request it. Highest-seen indices and completion flags help the node reason about whether it is missing the middle, the tail, or an entire slot.

Incorrect blockstore metadata can create a repair storm or suppress needed requests. Storage health and repair health should be monitored together.

Erasure recovery comes before the round trip

Data and coding shreds are organized so a bounded number of missing data fragments can be reconstructed when enough members of the same recovery set arrive.

Recovery uses packets already in hand. Its latency is the arrival time of the final required member plus local decode cost. Repair adds request scheduling, network travel to a peer, peer processing, return travel, and local validation.

A well-designed receiver tracks recoverability, not only missing originals. Requesting a data shred that can already be reconstructed wastes peer and network capacity. Conversely, waiting indefinitely for coding material after the set is clearly deficient delays progress.

Raw-feed consumers can use the same principle even without running validator repair. Combine independent sources and coding recovery first, then use a ledger source for late reconciliation if the application requires completeness.

Requests identify a precise need

Repair protocol variants allow a node to ask for a specific shred, for the highest available shred around a slot, for data that helps connect orphaned slots, or for ancestry-related information. Exact request names and encodings vary by client release.

Precision bounds response size. A requester should not ask an arbitrary peer to stream its entire ledger. It identifies a limited slot or index need and carries protocol context used to match responses.

Request nonces, signatures, tokens, pings, and rate controls have evolved to resist spoofing and amplification. Implementers should use the active client's request constructors and validators instead of copying a historical wire layout.

The stable rule is least data necessary. A bounded request should lead to a bounded response that the requester can independently authenticate as valid ledger content.

Peer selection affects repair time

The requester needs a peer that is reachable, has progressed far enough, retains the relevant slot, and will serve the request promptly. Gossip and local observations provide candidates.

Stake, reported slot progress, response history, latency, and randomized selection can influence client policy. Randomization prevents every recovering validator from concentrating on one popular server. Performance history avoids repeatedly choosing an unresponsive peer.

No peer advertisement proves possession. A node can claim progress but lack one shred, have pruned old data, or be overloaded. Repair logic rotates candidates and retries within limits.

For an old slot, archival retention becomes the dominant constraint. For a recent slot, path latency and serving load dominate. One peer-selection formula need not be optimal for both cases.

Responses still require shred validation

A repair response does not become trusted because it answered a request. Returned shred bytes must pass the same structural and leader-authentication checks as data arriving through Turbine.

The slot should map to the expected leader. The shred variant, index, recovery metadata, signature or Merkle proof, and packet size must be valid for the active feature set. Duplicate or conflicting shreds need explicit handling.

A malicious peer can return garbage, stale data, or a valid shred unrelated to the request. Matching request context and validating content prevents it from poisoning blockstore.

Repair peer identity and shred origin are different. The serving peer is usually not the leader that created the packet. It relays stored leader-authenticated bytes after the normal broadcast.

Repair has a latency floor

The earliest a repair can finish is after the receiver knows enough to ask. That detection delay is followed by a round trip and response processing.

Suppose a receiver waits 12 milliseconds to decide a data shred will not arrive, sends to a peer 3 milliseconds away, the peer takes 1 millisecond to serve, and the return path takes 3 milliseconds. The repaired copy arrives no earlier than 19 milliseconds after the expected event, before local validation.

A healthy Turbine copy might have arrived in 4 milliseconds, and coding recovery might have completed in 8. Repair is valuable because 19 is better than a permanently incomplete slot. It is not competitive with the first wave for a short HFT deadline.

This floor is why feed quality should report repair dependence or unrecoverable gaps, not only eventual block completion.

Retry policy needs bounds

Packet loss can affect the request, the response, or both. The selected peer can be slow or lack the data. Repair services need timeouts and retries.

Unbounded retries amplify outages. Thousands of validators asking repeatedly for the same popular shred can overload the peers most capable of serving it. Backoff, peer rotation, outstanding-request caps, and per-peer rate controls reduce that risk.

Timeouts must fit the target. Too short causes duplicate requests while valid responses are in flight. Too long stalls replay behind a dead peer. Clients tune policy for observed network conditions and protocol progress.

Operators should track attempt count and peer sequence for every long-lived gap. A final success timestamp without request history hides inefficient or abusive behavior.

Orphans require more than one index

A node can possess a slot whose parent chain is missing locally. That slot is an orphan from the node's blockstore perspective even if its shreds are internally complete.

Repair needs to discover or fetch the absent ancestry so replay can connect the slot to known state. Protocol requests for orphan or ancestor information support this process, with details depending on client version.

An orphan is not proof that the network produced an invalid fork. It can result from asymmetric loss, restart, snapshot state, retention, or delayed propagation. The local node lacks the path needed to evaluate it.

Market-data systems that track forks encounter the same concept. A child proposal without parent state cannot yield trustworthy execution, even when its transactions parse cleanly from shreds.

Repair load is a network symptom

A rising repair rate often indicates an upstream issue: Turbine packet loss, underprovisioned retransmit nodes, stale contact information, receive-buffer overflow, storage stalls, or a regional route problem.

Repair can mask the symptom by eventually completing blocks. Consensus continues, while replay latency and network load quietly worsen. Monitoring only completed slots misses the erosion of first-wave quality.

Useful ratios include repaired shreds per slot, fec sets recovered locally, unique missing indices, attempts per successful response, time-to-first-repair, and repair completion delay. Group by leader, upstream peer, and receiving interface.

Correlate with kernel drops and gossip changes. A burst of local socket overflow requires a different fix from one unreachable early Turbine branch.

Serving repair consumes real resources

A validator serving repair reads blockstore, validates request policy, and sends response packets. Under cluster stress, request volume can compete with replay, voting, Turbine retransmit, and ledger storage.

Rate limits protect the server and reduce amplification risk. They also mean a requester cannot assume immediate service from one peer. Well-distributed peer selection is part of cluster resilience.

Storage retention determines what can be served. A validator that has purged an old slot cannot answer from memory it no longer holds. Archival services have different retention and throughput goals from consensus validators.

Capacity planning should include outbound packet rate and disk read behavior during catch-up events. Normal steady-state repair volume can understate the correlated load after a network partition.

Repair does not select the canonical fork

The protocol retrieves data needed to evaluate ledger paths. It does not tell the requester which fork to choose.

A peer can serve valid shreds from a fork that later loses. The local validator verifies and replays available data, then applies fork choice and tower rules using votes and bank state. Repair restores information, not consensus authority.

This distinction matters to external consumers. Fetching a missing shred makes a proposed entry complete. It does not upgrade the transaction from probable to confirmed.

A correct pipeline retains fork identifiers and later commitment state. Repair completion is an availability milestone, separate from execution success and canonical adoption.

Raw feeds and repair serve different customers

A raw feed is optimized for immediate continuous delivery. It sends packets as observed, accepts UDP loss semantics, and does not wait for per-customer acknowledgement. A repair service responds to explicit gaps after they are detected.

Combining them in one ordered reliable stream would change the latency contract. Waiting for gaps would create head-of-line blocking, while retaining arbitrary history for every subscriber would add state and request load.

shredstream.sh therefore publishes no retransmission in its wire contract. The service sends raw UDP from Frankfurt, and a slow receiver cannot apply backpressure. Customers needing completeness should use coding recovery, multiple sources, and a later reconciliation path appropriate to their application.

The absence of feed retransmission is not the absence of Solana repair. They operate at different boundaries and deadlines.

Designing repair-aware market data

A trading receiver should make a deadline decision per recovery set or entry. Before the deadline, combine raw sources, deduplicate, and attempt erasure recovery. After the deadline, decide whether late completion still has value for state reconciliation.

Do not block every later entry behind one old gap if the strategy can isolate independent state safely. Do not skip a gap silently when it affects the state needed for later execution. The policy is application-specific.

Record why data became available: original packet, duplicate feed, coding reconstruction, repair-like retrieval, or confirmed RPC backfill. This lineage supports latency and correctness audits.

The fastest path and the complete path can be separate pipelines joined by slot and fork. That architecture respects both HFT deadlines and ledger integrity.

The operational conclusion

Repair is Solana's targeted response to an incomplete local ledger. It converts known gaps into bounded peer requests and validated shred responses.

Its value is resilience. Validators can recover from loss, restart, and asymmetric propagation without forcing the leader to acknowledge every packet. Its cost is delay and extra load after a problem has already occurred.

An early-data service should minimize how often a customer needs any catch-up path, but it cannot promise zero UDP loss. Receiver metrics should expose first-wave coverage, coding recovery, and late reconciliation separately.

The protocol lesson is precise: forward redundancy protects the deadline, repair protects eventual progress, and consensus later decides which recovered fork matters.