Why DoubleZero matters
Solana’s speed is not only about how fast a validator can compute. It also depends on how quickly clean data reaches the node. The public internet is noisy and uneven; during busy periods validators burn cycles on duplicates and junk, and messages arrive later than they should. That shows up as missed votes, weaker fee capture, and revenue that trails what your hardware could deliver.
DoubleZero is a contributor-run bandwidth layer that sits underneath the network. Traffic is filtered at the edge, then routed over dedicated links between exchange points so validators see less spam and more consistent propagation. It is not another validator client. It is the route your messages take to other nodes, designed to lower latency and jitter when the network is loud. Better routing can translate into more realized revenue for participating validators.
I highly recommend reading the DZ whitepaper at https://doublezero.xyz/whitepaper.pdf
DoubleZero’s value will show up, in the revenue your validator actually realizes during busy periods. Since access is priced as a percentage of validator revenue, the right question is simple: does the extra you earn outweigh what you pay to participate. The 3-Number Check turns that into a solvable on-chain calculation.
The 3-Number Check
You only need three percentages from your on-chain activity.
Delta % = Uplift % − Seat fee % − Payment costs %
- Uplift %: how much your revenue went up while on DZ compared to your own recent baseline
- Seat fee %: seat fees you paid during the DZ window divided by DZ-period revenue
- Payment costs %: any on-chain costs from funding and paying the fee. This can include swap slippage, realized gains or losses when you move tokens to fund the fee, and transaction fees
If Delta % is greater than zero, DZ was accretive for that period.
Example
- Baseline revenue for the period: 100
- DZ revenue for the same length period: 107 → Uplift % = 7%
- Seat fees paid: 5 on 107 revenue → Seat fee % = 5%
- Swap and tx costs to fund fee: 0.3 on 107 → Payment costs % ≈ 0.3%
Delta % = 7% − 5% − 0.3% = 1.7% → Net positive
How to get the numbers
- Pick a baseline window of recent epochs before DZ and a DZ window of the same length after you start participating
- Sum total on-chain revenue in each window: inflationary rewards, base and voting fees, priority fees, and Jito tips credited to your wallets
- In the DZ window, total your seat fees paid plus payment costs you can see on-chain, such as swaps you did to fund the fee and their transaction costs
- Compute the three percentages and apply the rule above
- If your active stake changed a lot between windows, also compute the same math per 1,000 SOL of average active stake. Keep both views
Why this framing works
- It is on-chain only. No black-box metrics
- It aligns with how access is priced: a percentage of validator consensus revenue
- It captures real-world frictions from paying the fee, so you do not overstate the benefit
Private networking should be judged by outcomes you can defend. If DZ improves how your messages move during the busiest hours, the benefit will appear in your on-chain revenue. If the cost of access and the way you fund payments eat that benefit, the math will show that too. The 3-Number Check turns a complex engineering choice into a simple financial test that anyone on your team can understand. Run it regularly, publish the result internally, and make the decision with confidence.