What faster block propagation is worth to a Solana validator

Methodology · counterfactuals · robustness

How this was measured, and what could break it

Every number above is either measured on-chain or a clearly-labelled counterfactual. Below is the full pipeline, the identifying assumption, the live statistical evidence, and an honest catalogue of the objections plus the tests that answer them. All inputs are public; the pipeline submits no transactions and holds no key.

The live statistical evidence

The whole dollar column rests on these two within-window slopes, re-estimated on every daily run with cluster-robust standard errors (clustered by leader) and a wild cluster bootstrap. A slope indistinguishable from zero means the corresponding value is too.

What can stand against the data

The objections I take seriously, each with its current status, stated before anyone else can raise them.

1. Demand simultaneityopen
   The biggest problem, and why the slope is an upper bound. Within a window, a slot completes later largely because more transactions arrived and got packed: and more transactions mechanically means more fees. A demand shock causes later completion AND higher revenue jointly, so what I estimate is closer to 'busy slots pay more' than 'an exogenous millisecond causes revenue'. Window fixed effects hold the leader's stake, hardware and geography fixed; they cannot hold load fixed slot-to-slot. Compute units enter as a control, but CU is the mediator (packing is how delay earns), so it under- or over-corrects rather than solving it. Cluster-robust SEs and the wild bootstrap fix inference on the slope; they do nothing about what the slope is. This is a genuine downgrade from the Ethereum study, where dV/dt came from relay bid traces, an ex-ante auction price, clean of realisation confounds. Closing it needs an instrument orthogonal to demand: congestion spilling over from a different leader, network-level shred-loss events, or position-1 slots following a skipped predecessor.
2. The window is not transitopen
   Why κ exists. COMPLETED−FIRST_SHRED shares a clock, so path delay cancels, which also cancels the network transit it was meant to capture. What remains is mostly the leader's own shred-emission span, which no transport compresses. Applying a network speedup to all of it (as the first version of this page did, implicitly κ=100%) contradicts the stated principle that publication timing is not compressible, and inflates every dollar. Only the differential component (path jitter, repair and FEC rounds) is compressible. Separating the two needs leader-side emission timestamps or a multi-vantage sighting spread; one node provides neither.
3. Single vantage pointopen
   Everything is measured at one Geyser node, not an independent multi-region fleet, so there is no cross-validation and leader geography contaminates the level of the window. Same-clock differencing removes the constant path delay but not the differential component (route changes, congestion drift, my node's own load across the streaming window). The Ethereum study took a sentry median across vantage points; this is n=1. A second independent provider is the top open item, and it is what would identify κ.
4. Vote credits not measuredopen
   Solana built Timely Vote Credits (SIMD-0033) specifically to reward vote latency: a vote earns max(1, 16 − max(0, latency − 2)) credits, and inflation is paid in proportion to credits. Dismissing the protocol's own latency-incentive channel in a study about the value of latency is a real gap. The bound: a validator already landing votes within the 2-slot grace earns the full 16 and gains nothing from being faster; one improving from 3 slots to 2 gains 1/16 = 6.25% of its inflation. Since inflation dwarfs fees, even a small movable share rivals the fee channel, so this is not safe to wave off. It is measurable from vote-transaction latency on-chain and is the first thing I would add.
5. Skip risk assumed, not measuredopen
   The delay budget is spent 'at unchanged skip risk' by assumption. On Ethereum the orphan-hazard curve was the honest half of the trade, the measured cost of delaying. Here the cost side is asserted, and with 17 dead forks observed the hazard cannot yet be fit. A delay budget without a measured hazard is half a model, and it is the half that made the Ethereum version credible. It is also what would pin θ.
6. Fixed transaction poolopen
   The delay gain is drawn from a pool roughly fixed over any short window: a slot that seals later absorbs fees that would otherwise land in the next slot, a transfer, not creation. Each per-operator bar is a lone-adopter bound; the combined total is not additive network value. The sweep above models this as (1 − α) decay, with φ setting whatever floor survives saturation.
7. A Solana-native lever?open
   Ethereum proposers make a discrete publication decision against a 4s deadline. Solana leaders stream shreds continuously inside a PoH-paced 400ms window. The claimed lever (extend packing into the window's tail before emitting the final shreds) is real but narrower, and it is fair to ask whether the delay-budget abstraction survives the port intact or whether it has been carried over from a scheduler that has the knob in a different form. I have not established the leader-side mechanism, only the reduced-form association.
8. Inference clusters one wayaddressed
   Congestion shocks cluster in time across leaders (the same minute hits everyone) so leader-only clustering could understate the errors. I ran the fix (Cameron-Gelbach-Miller two-way, leader × hour). The fee slope does not hold at t +1.26, p 0.2095, with standard errors inflating 0.86×; tips inflates 0.91×. So the headline does NOT survive the correction my own catalogue demanded. The caveat I will not bury: this panel yields only 49 hour-clusters, which is few for asymptotics in that dimension, so it is reassurance rather than proof, a multi-day panel is the real test.
9. Operator clustering heuristicopen
   Operators are union-found by shared vote-withdrawer or website. Its error mode is false merges: a shared custodian or a hosting provider's site could fuse unrelated operators into one. It also under-groups anyone using per-node cold withdrawers with no published site, so concentration here is a lower bound, never an over-count.
10. Magnitude is volatileopen
    The fee slope moved ~15× between the 4-hour and 1-day runs, and the top-operator figure swung ~4×. The direction (fees > tips, positive) is stable; the magnitude is not. The daily re-estimate tracks whether it settles.
11. Behavioural assumptionto do
    The value requires leaders to actually re-tune sealing to spend the budget. A passive install earns far less. The framing is conditional on that behaviour change, and stated as such.
12. Fee = total, not priorityaddressed
    The block-meta Fee reward mixes base + priority fees. Priority dominates in the busy periods that drive the estimate; base is a small, near-constant floor.
13. Fixed inputsto do
    6× is a free parameter, not a Solana measurement. SOL is priced as of the render timestamp in the header. Both scale the result linearly, swap either and every figure rescales.

How I show it's solid

The design and the checks that make the causal reading credible, what's already in place and what's still owed.

1. Within-window FEaddressed
   The core identification: comparing a leader's own four consecutive slots strips the cross-sectional confound (busy slots are both slower and richer). The gap between the confounded slope (t≈2.5) and the within-window slope is that bias, and it is large.
2. Cluster-robust + bootstrapaddressed
   Standard errors clustered by leader (650+ clusters), plus a restricted wild cluster bootstrap with Rademacher weights. The p-values above come from that empirical distribution, not a normal approximation that over-rejects.
3. Placebo that firedaddressed
   The position design asks the naive question, do later slots in a leader's window earn more? It came back significantly negative (t −3.9), and I publish it. Why that does not invalidate the main design: position is not a clean proxy for delay, because slot 0 inherits the backlog accumulated across the leader handoff and later slots work a drained queue. That drain is a real nuisance structure, and it is exactly why the sealing variable is defined as the residual from the position-implied schedule (t_completed − window_start − position×400ms), so position is differenced out by construction. The fired placebo documents the nuisance the sealing design already removes, and kills the coarse "position = delay exposure" reading, which is why I do not use it. What it does not do is rescue the sealing slope from the demand confound in objection 1, that remains open.
4. No-op recoveryaddressed
   By construction, at speedup = 1 the counterfactual reproduces the measured baseline exactly, a model that can't recover reality with the treatment off is untrustworthy everywhere.
5. Full-range skip accountingaddressed
   Slots skipped outright never appear in the stream, so skips are counted against the full leader schedule, the skip rate isn't silently undercounted by only-what-I-saw.
6. Second independent vantageto do
   A non-HelloMoon node in another region, to measure the transit spread and cleanly separate transit from publication delay.
7. Skip-hazard capto do
   P(dead-fork | transit) to bound how far the delay budget can be spent before a block is lost, currently underpowered; needs more days.
8. Longer panelopen
   More continuous days for Channel-B power and a tighter confidence interval on the fee slope. Collection is ongoing; the page re-estimates daily.