DoubleZero was first envisioned to support validators, tailoring its filtration and connectivity features to optimize the block-building and consensus processes, and especially the Solana validator set. DoubleZero can support the efficacy of Turbine, reduce slot times from 400ms, and enhance the performance of the Agave and Firedancer clients.
In exchange for these filtration and communication services, the DoubleZero protocol proposes to charge each validator a “seat fee.” This seat fee is set at 5% of the validator’s consensus-related revenue streams, denominated in SOL (or the native token of the L1 for future networks).
This model — flat seat fees, as a percentage of revenue, denominated in SOL — is useful for both aligning incentives and easing operational complexity. As compared to a pay-per-byte model, this one both encourages an abundance mindset (wherein validators are not disincentivized to limit communication) and directly aligns the DoubleZero protocol with the validator set. Finally, the commission rate of 5% is chosen to align with current Solana commission rates.
As outlined in the whitepaper, validators who join DoubleZero receive filtration and connectivity services. But those can be made more concrete in the case of Solana, where DoubleZero offers six types of improvements.
These advantages get further magnified by features like future multicast, where the network — rather than the validator — does replication of packets. This alone reduces latency and conserves bandwidth; but more critically, it can transform certain systems like Turbine — moving it from the status quo, i.e. a waterfall of shreds sent out in sequential steps, to a simpler and faster model, where the block is transmitted a single time and reaches all validators on the most direct path.
The six improvements can be combined into a more abstract visualization, which plots the value accruing to a single validator as a function of the share of the validator network and the share of the RPC/MEV ecosystem on DoubleZero.
This visualization summarizes various scenarios. For instance, if no validators or RPC/MEV participants are on DoubleZero, an incremental validator would still receive some baseline value from filtration. As validators join the system, the value to an incremental validator grows: it sends and receives blocks faster, and can potentially expand into new regions. There is a critical step change at 2/3 of the stake, where the protocol itself can make certain changes (e.g. shorter slot times or larger blocks) safely. Separately, suppose there are no validators on DoubleZero but RPC/MEV participants join instead. The incremental validator benefits from better delivery of these systems, which offer more priority fees and MEV rewards, and this is a fairly linear increase. Put together, the following visualization sketches out the entire value curve to a validator across these two dimensions, where light colors are higher than dark colors.
Seat fees, and more specifically a share of consensus-related revenue denominated in SOL (set at 5%), might seem like an unusual pricing model, especially compared to the more standard pay-per-byte model. However, this particular model has both economic and operational advantages.
DoubleZero is a network, and so almost tautologically, network effects are its heart. As the value function diagram shows, the more users who use it, the better the network becomes. Thus, it is critically important for the pricing model to not disincentivize traffic. Fees that are conditional on usage, i.e. fees that impose a marginal cost per transaction sent, would fail to leverage these network effects properly. Even for the same total cost outlay, validators would be disincentivized on the margin to communicate with one another, both in terms of breadth and depth. Validators would perhaps reserve DoubleZero for communication only with high-stake validators or high-value packets, and instead use the public internet for low-stake validators or low-value messages.
By contrast, seat fees do not impose a marginal cost per unit of information sent. Validators are encouraged to have an abundance mindset, rather than a bean-counting one. As soon as one of its peers joins DoubleZero, it should communicate freely with that validator and not condition traffic on whether any particular packet meets some threshold of value.