This post outlines the Principles, Validator Selection Criteria and Secondary Criteria that will be applied for the selection of delegators as part of the Staking Program run by the dYdX Treasury SubDAO.
If you think you are eligible based on the Validator Scoring Criteria, please reply to this forum post with your email (or, if preferred, respond with a note on this post and send your email to @karpatkey as a personal message). We will send you a self-declaration form to gather additional information on the Secondary Criteria.
Principles
The principles for delegating DYDX tokens to dYdX Chain validators are based on the Stake Delegation Principles published by the dYdX Foundation.
- Independence: the Treasury SubDAO will delegate to validators that are independent from each other to the best of the Treasury SubDAO’s knowledge.
- Decentralisation: the Treasury SubDAO will aim to distribute its delegated stake across as many validators as possible, subject to administrative constraints and reasonable operational limitations.
- Proportionality: the Treasury SubDAO will aim to make proportional delegations to dYdX Chain validators based on their respective stake weight. However, certain factors, such as decentralisation goals outlined in the selection criteria below, may justify overweighting delegations towards a given validator.
- Non-Majority Delegation: the Treasury SubDAO’s delegated stake weight in the dYdX Chain will aim to be less than 50% of the network’s total active stake weight.
- Meritocracy: The Treasury SubDAO will have complete and absolute discretion in deciding which dYdX Chain validators it wishes to delegate to.
- Periodic Reviews & Rebalancing: The Treasury SubDAO will periodically review and rebalance its delegations when appropriate. The review of the Treasury SubDAO’s stake delegations shall occur at least quarterly.
The above principles are introduced for transparency and serve as practical, non-binding guidelines for the Treasury SubDAO. The Treasury SubDAO shall retain complete and absolute discretion over any stake delegation and related decisions. For clarity, compliance with applicable laws and regulations will always precede adherence to these principles.
Validator Scoring Criteria
This is the list of metrics considered when selecting validators to receive Treasury SubDAO delegations. The criteria were heavily inspired by “Good Practices for Validators and Stakers” published by the dYdX Foundation and the “MEV Committee - Validator Guidelines” published in the forum.
Primary data sources used in the evaluation scoring are the Observatory dashboard, Numia and Mintscan.
Orderbook discrepancy
- Validator average orderbook discrepancy ≤ mean average orderbook discrepancy
- Incentivise decreasing orderbook discrepancy across the network, as high discrepancy negatively impacts the trading experience on dYdX.
Performance
- Validator uptime
- Incentivise high validator uptime for consistent block production and addition to the network, as this creates greater guarantees of timely order execution.
- We think Validator uptime ≥ 98% is a reasonable target.
- Validator commission ≤ asset-weighted commission
- Incentivise healthy commission rates and competition among validators and optimise staking rewards for the Treasury SubDAO.
- Validator average block time ≤ mean average block time
- Incentivise low network latency, as latency is one the most relevant components of dYdX user trading experience.
Governance Participation
- Validator governance participation rate (since Treasury SubDAO delegation) ≥ 80%
- Incentivise high validator participation in governance. It’s measured since delegation date but past participation rate while in the active validator set will be considered as indicative.
Nakamoto Coefficient
- Delegating to certain validators would contribute to a higher Nakamoto coefficient
- Improve network decentralisation and distribution of stake weight among the active validator set.
Secondary Criteria
Secondary Criteria are criteria that rely on a self-declaration from the validators or are otherwise subjective and challenging to verify independently. These are desirable characteristics and not a firm requirement for validator eligibility.
If you think you are eligible based on the Validator Scoring Criteria, please reply to this forum post with your email (or, if preferred, respond with a note on this post and send your email to @karpatkey as a personal message). We will send you a self-declaration form to gather additional information on the Secondary Criteria.
Operations & Security
- Validator uses self-owned hardware
- Incentivise bare-metal setups, as they promote higher decentralisation versus cloud servers.
- Validator securely stores keys outside of the validator machine
- Incentivise good validator security practices.
- Validator has a backup node
- Incentivise increased operational efficiency and security of validators.
- Validator does not have any potential conflicts of interest related to MEV, Market Making, Professional Trading Firms or other similar business lines
- Reduce conflicts of interest & strong incentives to extract MEV from users.
- Validator operates through a limited liability entity
- Incentivise proper legal setting for protection of validator’s operation and DYDX stakers/Treasury SubDAO delegation.
- Validator is compliant with local laws and regulations
- Incentivise compliance to reduce legal risk of the validator’s operation and DYDX stakers/Treasury SubDAO delegation.
Transparency
- Validator has introduced itself in the forum
- Incentivise validators to follow the dYdX Foundation’s intro framework for increased transparency and information available to stakers.
- Validator has an available two-way communication channel
- Incentivise validator responsiveness and communication.
Ecosystem Considerations
- Validator contributes to the dYdX ecosystem
- Incentivise ecosystem alignment and value add from validators based on (and not limited to): tooling, educational material, block explorers, threat identification, and upgrades.
- Validator runs or supports dYdX Chain infrastructure (e.g. testnet node, price feeds, RPC, relayers).