As dYdX continues to scale, the reliability and performance of block production have become critical to the trading experience. While CometBFT’s existing proposer selection algorithm is fair and deterministic, it doesn’t always optimize for real-world liveness, latency, or infrastructure coordination.
To address this, we’re exploring changes to the dYdX open-source software introducing a new capability: designated proposers — a governance-controlled subset of validators responsible for proposing blocks. This is a fully deterministic enhancement to CometBFT that brings increased resilience, network performance, and operational clarity — while preserving the full validator set, stake-based voting power, and decentralized governance of the network.
Why Change the Proposer Selection Model?
Under the default CometBFT behavior, block proposers are selected pseudo-randomly from the active validator set, weighted by voting power. This works well in theory — each validator proposes blocks proportionally to its stake — but in practice, it introduces several challenges:
- Liveness risk from inactive or misconfigured validators.
- Block time variability when proposers are slow or offline.
- Operational uncertainty due to unpredictable proposer schedules.
- Incentive misalignment — validators earn rewards whether or not they propose reliably.
- Inefficient network topology — because the next proposer is unknown until each round begins, mempool messages (like orders or cancellations) must be gossiped broadly across the network. This introduces unnecessary latency and limits the benefits of optimized peering.
Over time, we’ve seen that unreliable proposers, while technically bonded, can severely impact trading UX and infrastructure performance — particularly during volatility or load spikes.
By contrast, a small, stable set of designated proposers enables a predictable network structure. Transactions can be routed directly to the reduced proposer set — eliminating the need for random hops and significantly reducing propagation latency. In the future, orders could be routed directly to the next block proposer. This leads to faster, fairer, and more deterministic block inclusion, improving the overall responsiveness of the chain.
What We’re Proposing:
We’re introducing a governance-defined designated proposer set P, which is a subset of the full validator set V. Under this new system:
- Only validators in P are eligible to propose a block.
- Governance-selected Proposers in P are then selected deterministically to propose blocks, using weighted round-robin by voting power, consistent with the existing algorithm.
Importantly, this change does not affect validator staking, voting, or block finality rules. The full validator set still signs and verifies all blocks, and consensus still requires 2/3+ voting power.
Governance Flow
This change is gated by governance and unfolds in two stages:
- Software Upgrade Vote: Enables the feature in the dYdX open-source software via a consensus-breaking upgrade. Initially, all validators remain eligible proposers (can_propose = true).
- Runtime Governance Vote: Sets the initial proposer set P via a MsgSetEligibleProposers. Validators outside P are excluded from proposing blocks.
This structure provides maximum flexibility — the feature is opt-in, but fully controllable via governance once activated.
What Happens When a Proposer Fails?
If a validator in P becomes jailed, they are excluded from both the validator set V and the proposer set P. There’s no need to reassign blocks — the network skips them cleanly.
- If at least one proposer in P is live → network continues normally.
- If all proposers in P are jailed or offline → the network halts.
In practice, governance can reconfigure P quickly via an expedited governance proposal if performance issues arise.
Why Weighted Round-Robin?
To keep things simple and aligned with the existing behavior of CometBFT, designated proposers will be selected using a weighted round-robin approach - meaning validators in the proposer set P will propose blocks proportionally to their stake.
This ensures the proposer schedule remains fair, deterministic, and aligned with tokenomics - all while enabling performance gains and better coordination through a smaller, governance-controlled set.
Benefits of Improvements to Network Topology
Reduced Order Latency
- Transactions (especially orders and cancellations) can be routed directly to the reduced proposer set or the known proposer for each block.
- Eliminates multi-hop gossip and minimizes latency to block inclusion.
- Improves fairness, determinism, and responsiveness.
Improved Performance and Liveness
- Fewer missed proposals.
- Reduced block time variance.
- Smoother UX during volatile periods.
Operational Clarity
- Easier coordination between proposers and infrastructure providers.
- Predictable peering relationships between nodes.
- Easier monitoring and accountability for performance.
Economic and Governance Flexibility
- Validators still compete for proposer slots based on stake — maintaining incentives.
- Governance can curate and update P as needed, based on performance or behavior.
- Misbehaving proposers can be removed via governance, no slashing required.
What This Means for Validators
This change does not impact your ability to earn staking rewards, vote on proposals, or participate in consensus — even if you’re not part of the designated proposer set P.
We recommend governance initially selects 8 professional validators with proven track records across the Cosmos ecosystem and beyond. These validators should be:
- Highly reliable — strong uptime, minimal missed blocks.
- Operationally mature — responsive to upgrades and infra coordination.
- Network-optimized — capable of maintaining low-latency peering and fast propagation.
Validators in P will carry greater responsibility for block production and are critical to overall network performance. Governance may consider additional incentives for proposers, given their elevated role and service expectations.
If you’re a validator aiming to join P, now’s the time to:
- Ensure your infrastructure is performant and monitored.
- Stay responsive in validator coordination channels.
- Proactively engage in testnets and protocol discussions.
Special Disclaimer
dYdX is a decentralised, disintermediated and permissionless protocol, and is not available in the U.S. or to other restricted persons. All use of dYdX software is subject to the dYdX Software Terms of Use.
This post describes anticipated features in the open source dYdX software. The implementation of these features in any live deployment of dYdX software will be decided by the relevant deployer community. dYdX International Ltd. (“DI”), dYdX Trading Inc. and their affiliates do not develop, control or operate any component of dYdX software for public use. The information provided in this website is for general informational purposes only and DI reserves the right to update, modify, or amend any contents herein, at its sole discretion and without prior notice. Nothing herein should be used or considered as legal, financial, tax, or any other advice, nor as an instruction or invitation to act in any way by anyone.
Engaging in any activity involving crypto-assets (including trading crypto assets and depositing into the MegaVault) is risky due to high volatility. Returns are not guaranteed and may fluctuate over time depending on multiple factors, and you may lose your entire investment, particularly when using leverage. Investment into crypto-assets may not be regulated and may not be suitable for retail investors. You should perform your own research and due diligence before engaging in any activity involving crypto-assets.
In no event will DI or its affiliates be liable for any loss or damage, including without limitation, indirect or consequential loss or damage, arising from or in connection with the use of this website. By continuing to access this website, you agree to the above and accept the possibility of changes in the information provided.
.avif)