Trading on data that might not survive
Seeing a transaction in shreds proves a scheduled leader signed bytes that contained it. It does not prove execution, success, or survival. Three outcomes can erase the observation: the transaction reverts, the slot is skipped, or the fork loses. Systems that act early stay solvent by tagging the action provisional and reconciling it against a confirmed-commitment source.
protocol desk · updated 2026-09-15
A shred feed shows you a leader's proposal. Consensus decides later whether the proposal becomes history. Between those two moments sits the entire risk model of shred-level trading, and it gets far less attention than the latency numbers do, presumably because latency is what vendors sell and risk is what buyers keep.
This page is the risk half. What "I saw it in shreds" actually guarantees, the three distinct ways it can turn out to have guaranteed nothing, and the reconciliation patterns that let systems act early anyway.
What a shred-level observation is
By the time your receiver hands you a transaction, you know three things. A machine claiming to be the slot's scheduled leader signed these bytes. The transaction was well-formed enough to deshred. It sat inside that leader's proposed slot at a particular position.
You do not know that it executed. You do not know that it succeeded. You do not know that the slot it rode in will be part of the chain tomorrow. Execution results, the difference between a swap and a reverted swap, do not exist yet anywhere, including on the leader.
The three ways the ground moves
The transaction fails. It executes and reverts: slippage bound hit, account state changed between build and execution, compute exhausted. The shred stream cannot warn you, because failure is an execution outcome and you are upstream of execution. On busy launches, failure rates on the exact transactions snipers chase are brutal, since hundreds of bots race the same curve and most lose.
The slot is skipped. Leaders miss their slots: offline, late, or outvoted. Mainnet's skip rate moves around by epoch, but it is persistently in the low single-digit percent range. Read that against your fill count. A strategy acting on every shred-level signal takes a phantom-slot event every few dozen slots' worth of signals. Skips cluster around leader transitions and degraded validators rather than arriving uniformly, which is worse for you: your risk spikes exactly when the network is at its most interesting.
The fork loses. A leader builds on a parent that consensus abandons. The slot was real, packets and all, and then it was not. Rarer than plain skips in the current era of the network, but with a nastier signature: the same transaction commonly reappears in a later slot, so a naive system either double-counts the event or, having acted on the dead fork, holds a position it thinks is hedged and is not.
Vote transactions, 70-odd percent of everything, are how the network settles all of this, and they are in your feed too. Some shops parse them for early fork evidence. Most should not; it is a research project wearing the costume of a quick win.
Reconciliation, or how to act early without lying to yourself
The workable pattern is boring and has three parts.
Act on the shred signal, tagged as provisional. Position sizing belongs here: the sizing on a provisional signal should already price in the few-percent chance the slot never happens plus your strategy's own execution failure rate, which is usually the larger number.
Confirm against a slower, truthful source. A confirmed-commitment subscription, ordinary gRPC or WebSocket, tells you within a second or two whether the slot rooted and the transaction succeeded. Every provisional action gets a deadline; a signal that is not confirmed within a couple of slots is presumed dead.
Unwind deliberately. Decide before deployment what happens when confirmation says no: cancel, exit, re-enter on the replayed transaction. The fork-replay case deserves an explicit dedupe by signature, or the retry logic and the replayed transaction will conspire to double your position at the worst available price.
None of this deletes the shred advantage. It means the advantage buys you the front of the queue rather than certainty, and that queue is the thing worth leading. The systems that lose money at the shred level are almost never slow. They are fast systems that treated a proposal as a fact.
In practice
A detector fires on a launch seen in the current leader's proposal and the system opens a provisional position tagged with the transaction signature, the slot number, and a deadline two slots out.
The slot is skipped. No confirmed-commitment report ever arrives for it, so the deadline expires and the provisional entry is marked dead rather than filled. Because the position was never treated as real, there is nothing to unwind beyond releasing the reserved size.
Three slots later the same signature reappears in a different leader's slot and confirms. The dedupe keyed on signature recognises it as the same event rather than a second launch, so the system enters once at the price that actually existed instead of twice at the price it assumed.
Scope of this page
This page is about what a raw observation does and does not guarantee, and the shape of the reconciliation that follows. It does not model fork choice, describe how validators vote, or predict skip behaviour for a particular epoch, and the rates named here move with network conditions rather than sitting at a fixed value.
Position sizing, deadlines, and unwind policy are business decisions. What belongs to the data is only this: a proposal is not an outcome, and no amount of delivery speed converts one into the other.
Related questions
It guarantees that a machine presenting itself as the slot's scheduled leader signed bytes containing a well-formed transaction, and that the transaction sat at a known position in that proposed slot. It guarantees nothing about execution, success, or permanence. Execution results do not exist anywhere at that moment, including on the leader that produced the packets.
Skip rates move by epoch and sit persistently in the low single-digit percent range, which means a strategy acting on every early signal will meet a slot that never produced a block reasonably often. Skips also cluster around leader transitions and struggling validators rather than spreading evenly, so exposure rises exactly when activity and volatility are highest.
A skipped slot never produced accepted block data at all, so there is nothing to reconcile beyond the absence. A lost fork did produce real packets that were later abandoned when consensus chose a different parent. The lost fork is the more dangerous case because the same transaction often reappears in a later slot, which a naive system reads as a second event.
They treat the early action as provisional, size it against the combined probability of execution failure and slot loss, and attach a deadline measured in slots. A slower confirmed-commitment subscription then reports whether the slot rooted and the transaction succeeded, and anything unconfirmed by its deadline is presumed dead and unwound according to a policy chosen before deployment.
Usually not. Votes make up the large majority of traffic and they are how the network settles fork choice, so they do carry early evidence in principle. Turning that into a reliable signal is a research effort with its own failure modes, and most desks get more from disciplined reconciliation against a confirmed source than from trying to predict consensus themselves.
Read next
Ready to build against this? The documentation covers the implementation.