Where the milliseconds go: the full budget of a shred-driven trade
A shred-driven trade has six legs: leader emit, feed delivery, decode, decision, submission, and inclusion. Only the second is what a feed vendor sells. On a typical setup the controllable cost sits in the decision path and the submission path, so measuring each leg separately is what tells you whether buying a faster tap would change anything at all.
measurement desk · updated 2026-09-15
Buyers of shred feeds tend to obsess over one number, the delivery latency from leader to their NIC, and ignore the other five numbers that decide whether the trade lands. This page walks the whole path with rough costs attached. The rough costs are the point: once you see the shape of the budget, you usually discover the wire was never your problem.
The path has six legs. Leader emits, feed delivers, you decode, you decide, you submit, the next leader includes. A slot is 400 milliseconds. Everything below is measured against that clock.
Leg 1: leader to feed tap. Not yours to control.
The moment a leader emits a shred, it starts down the Turbine tree. Where your provider's node sits in that tree, and where the machine sits physically, sets a floor nothing downstream can recover. This is covered properly in why position determines latency; the budget summary is that the difference between a well-positioned tap and a poorly-positioned one is single-digit to low-tens of milliseconds, and you buy it, you cannot engineer it.
Leg 2: feed to your NIC. The number on the invoice.
Provider to you is a network path. Same city over a cross-connect: well under a millisecond. Same city over the public internet: one to a few. Frankfurt to Virginia: eighty-plus, and no vendor benchmark changes the speed of light. This is why the useful question about any shred provider is not "how fast are you" but "how fast are you to the machine I trade from", which is a question only your own harness answers.
Leg 3: NIC to decoded transaction. Yours, and usually fine.
Kernel receive, deshred, signature-check what you must, extract transactions. On a tuned host this is hundreds of microseconds to single-digit milliseconds. On an untuned host it is that, plus unbounded queueing delay when a busy slot bursts. The failure mode is not slow processing, it is your socket buffer absorbing a burst and your process reading packets that are 40ms stale and looking exactly as fresh as live ones. The receiving-them section of this site exists mostly because of leg 3.
Leg 4: decision. The silent killer.
The decode-to-decision gap is where more budgets die than every network leg combined, and nobody measures it. A detector doing two byte-comparisons: microseconds. A detector that calls out to an RPC to fetch metadata before deciding: congratulations, you added a network round-trip in the middle of your hot path and turned a 5ms pipeline into an 80ms one. Any state your decision needs, hold warm before the packet arrives. If the strategy cannot decide from what is in the transaction plus pre-warmed state, it is not a shred-level strategy yet.
Leg 5: submission. The half people forget.
Shreds are the receive side. The trade still has to travel back. Submitting through a generic RPC's sendTransaction puts you at the back of a forwarding chain; landing consistently means submitting toward the upcoming leader directly, or through a bundle path with its own auction dynamics and its own latency distribution. Either way, leg 5 is a real network trip to wherever the next leader is, and the leader schedule is public, which means where the next leader is, is knowable in advance. Teams colocate the receive side and then submit from the same box to a leader on another continent, and wonder where 70ms went.
Leg 6: inclusion. Not a latency, a lottery weighted by legs 1 through 5.
Arriving early does not include you; it enters you into the slot's ordering with better position than whoever arrived later. This leg is priced in priority fees and tips rather than milliseconds, but every millisecond saved upstream buys you a cheaper seat.
The uncomfortable summary
Add it up for a typical setup: a well-positioned feed (say 5ms of tap advantage), same-metro delivery (1ms), a tuned receiver (1ms), an in-memory decision (near zero), leader-aware submission (10 to 30ms depending on where the leader is). The controllable budget is dominated by legs 4 and 5, the two legs no feed vendor can sell you. We sell leg 2, so it would be commercially convenient to tell you leg 2 is everything. It is not. It is the ticket that makes the rest worth optimizing, and the rest is where most teams are actually slow.
Measure each leg separately before spending money on any of them. The one-way latency page covers how to do that without fooling yourself.
In practice
A desk moves from a shared provider to a better-positioned tap and expects its fill rate to improve. The tap advantage is worth about 5ms and the delivery hop into its cage is under a millisecond, so leg 1 and leg 2 together improve by roughly 5ms.
Its receiver is tuned, so leg 3 stays near a millisecond. Leg 4 is the problem nobody had timed: the strategy fetches token metadata over an RPC connection before deciding, which costs 60ms to 80ms on every candidate. Leg 5 submits from the same cage to whichever leader is next, which is sometimes on another continent.
The 5ms bought at legs 1 and 2 is invisible beside a 70ms decision path. Pre-warming the metadata the detector needs recovers more than the upgrade did, and costs nothing per month.
Scope of this page
The millisecond figures here are shape, not measurement. They describe the order of magnitude each leg tends to occupy so that a reader can see which legs dominate, and they are not a benchmark of any particular provider, host, or route. Your own numbers will differ with facility, route, hardware, and strategy.
This page also stops at inclusion. Priority fee levels, tip auction behaviour, and how an upcoming leader orders what it receives are decided by economics rather than by the clock, so arriving first settles none of them.
Related questions
For most teams it is the decision path and the submission path, not the wire. A detector that reaches out to an external service before deciding adds a full round trip inside the hot path, and a submission sent to a leader on another continent adds a real intercontinental trip. Both are usually larger than the difference between a good feed and a mediocre one.
Only if the rest of the path is already tight. A feed buys earlier sight of a proposal, which is worth nothing if the strategy then spends tens of milliseconds deciding or submits into a slow path. The honest order of work is to time every leg first, fix whichever dominates, and treat the feed as the ticket that makes the other optimisations worth doing.
Shreds are inbound only. After a decision, the transaction still has to reach the machine that will build the next block, and that machine is wherever the schedule says it is. A desk can colocate its receiver perfectly and still lose tens of milliseconds sending the order across an ocean, because the receive side and the send side are two different network problems.
Separately, with timestamps taken at the boundaries rather than one end-to-end number. Record arrival at the socket, completion of decode, completion of the decision, and the moment of submission. A single aggregate figure hides which stage moved, and it is the stage-level split that tells you whether a purchase or a code change is the cheaper fix.
No. Early arrival improves your position relative to whoever arrived later, but inclusion is decided by the block producer according to fees and tips as well as arrival. Time saved upstream lowers what you have to pay for a given position rather than removing the payment, so the budget should be read as buying a cheaper seat rather than a reserved one.
Read next
Ready to build against this? The documentation covers the implementation.