General Concepts
A validator in the context of the dYdX Chain is responsible for verifying transactions and producing blocks on the dYdX Chain. Validators run programs called full nodes that allow them to participate in consensus, verify blocks, participate in governance, and receive rewards. The top 60 validators with the highest total stake can participate in consensus.
In the dYdX Chain, a proof-of-stake blockchain, dYdX Chain stakers (referred to as delegators in the Cosmos SDK documentation) play an important role in determining the strength of the network by delegating the validation rights associated with their L1 protocol tokens to one or more validators and directly increasing those validators’ chances of entering or staying in the active set of validators who can participate in the network’s consensus process.
Staking is a mechanism through which the dYdX Chain secures its network and validates transactions. Staking provides stability and economic security for the dYdX Chain through the amount of bonded L1 tokens. In return for this service, stakers may earn rewards. Staking is a critical process for the dYdX Chain.
A full-node runs the state machine, starting from a genesis file. It connects to peers running the same client to receive and relay transactions, block proposals, and signatures. The full-node comprises the application, defined with the Cosmos SDK, and a consensus engine connected to the application via the ABCI.
A delegator in the context of the dYdX Chain is a token holder who stakes their DYDX tokens to a validator node. Once a delegator has staked their tokens, they will earn rewards based on the number of staked tokens, the performance of the network, and the terms set by the applicable validator node to which they have staked.
Validator Keys and States
There are two types of keys:
- Tendermint/CometBFT key: A unique key used to sign consensus votes.
- ///It is associated with a public key cosmosvalconspub (To get this value, run gaiad tendermint show-validator)///
- ///It is generated when the node is created with gaiad init.///
- Application key: This key is created from the gaiad binary and is used to sign transactions.
- ///Application keys are associated with a public key that is prefixed by cosmospub and an address that is prefixed by cosmos.///
- ///The Tendermint/CometBFT and application keys are derived from account keys generated by the gaiad keys add command.///
Note: A validator's operator key is directly tied to an application key and uses the cosmosvaloper and cosmosvaloperpub prefixes reserved solely for this purpose.
After creating a validator with a create-validator transaction, it can be in four states:
- In validator set: The Validator is in the active set and participates in consensus. The validator is earning rewards and can be slashed for misbehavior.
- Jailed: Validator misbehaved and is in jail, i.e., outside of the validator set.
- Unbonded: Validator is not in the active set and, therefore, not signing blocks. The validator cannot be slashed and does not earn any reward. It is still possible to delegate DYDX to an unbonded validator. Undelegating from an unbonded validator is immediate, meaning the tokens are not subject to the unbonding period.
- Tombstoned: Validator is permanently banned and cannot rejoin the validator set.
The validator operator's "self-bond" refers to the amount of DYDX stake delegated to itself. You can increase the self-bond by self-delegating more DYDX to your validator account.
There is no minimum. The active validators are the top 60 validators with the highest total stake (where total stake = self-bonded stake + delegators stake).
Delegators are free to choose validators according to their subjective criteria. That said, criteria anticipated to be important include ones highlighted in the dYdX Foundation blog post: A take on good practices for dYdX Chain Validators and Stakers.
Responsibilities
No, they do not. Each delegator can value validators based on their criteria. Validators can register a website address when they nominate themselves to advertise their operation as they see fit. Some delegators prefer a website displaying the team operating the validator and their resume, while others might prefer anonymous validators with positive track records.
We encourage validators who want to be part of the ecosystem and active set to submit a validator profile on the dYdX Forum.
Validators have two main responsibilities:
- Be able to constantly run a correct software version: Validators must ensure that their servers are always online and their private keys are not compromised.
- Actively participate in governance: Validators are required to vote on every proposal.
Additionally, validators are expected to be active members of the community. Validators must always be up-to-date with the ecosystem's current state to adapt quickly.
Staking DYDX can be thought of as a safety deposit on validation activities. When a validator or a delegator wants to retrieve part or all of their deposit, they send an unbonding transaction. Then, DYDX undergoes a 30-day unbonding period during which they are liable to be slashed for potential misbehaviors the validator commits before the unbonding process is complete.
Validators and by association delegators receive protocol rewards and have the right to participate in governance. If a validator misbehaves, a certain portion of their total stake can be slashed. This means that every delegator that bonded DYDX to this validator gets penalized in proportion to their bonded stake. Delegators are incentivized to delegate to validators that they anticipate will function safely.
Validators and delegators can vote on proposals to change operational parameters, coordinate upgrades, or decide on any given matter.
Validators play a unique role in the governance system. As pillars of the system, validators are required to vote on every proposal. It is crucial since validators inherit the voting power of their delegators who do not vote.
By delegating to a validator, a user delegates voting power. The more voting power a validator has, the more weight they have in the consensus and governance processes. This does not mean the validator has custody of their delegators' DYDX. A validator cannot run away with its delegator's funds.
Even though delegated funds cannot be stolen by their validators, delegators' tokens can still be slashed (if the applicable governance community so decides) if their validator suffers a slashing event, which is why we encourage due diligence when selecting a validator.
The validator selected to propose the next block is called the proposer. Each proposer is selected deterministically. The frequency of being chosen is proportional to the voting power (i.e., the amount of bonded DYDX) of the validator. For example, suppose the total bonded stake across all validators is 100 DYDX, and a validator's total stake is 10 DYDX. This validator is expected to be the proposer of ~10% of the blocks.
Each member of a validator's staking pool earns a proportional amount of USDC.
This total protocol fees is divided among validators' staking pools according to each validator's stake weight. Then, within each validator's staking pool, the protocol fees is divided among delegators in proportion to each delegator's stake. A commission on delegators' protocol fees is applied by the validator before it is distributed.
Validators earn proportionally more protocol fees than their delegators because of the commission they take on the staking rewards from their delegators.
Validators also play a significant role in governance. If a delegator does not vote, their voting power is inherited by their validator. This voting inheritance gives validators a major responsibility in the ecosystem.
Protocol fees received by a validator's pool is split between the validator and its delegators. The validator can apply a commission on the part of the protocol fees that goes to its delegators. This commission is set at a minimum of 5% per the Genesis block and can reach 100%. Each validator can set its initial commission at or above 5%, maximum daily commission change rate, and maximum commission.
100% of the fees go to validators, who can share them with stakers (with a commission ranging from 5% to 100%).
Note the fee schedule contemplated in the initial dYdX Chain open-source software will be subject to adjustments by the applicable governance community.
If a validator misbehaves, its bonded and delegators' stake may be slashed. The severity of the punishment will depend on the type of fault. Three main faults can result in the slashing of funds for a validator and its delegators.
Double-signing: Double-signing by a validator is considered a severe violation as it can cause instability and unpredictability in the network. When a validator double-signs, they are slashed for SlashFractionDoubleSign, jailed (removed from validator set), and tombstoned (cannot rejoin validator set).
SlashFractionDownTime: Defines the slashing penalty for downtime if a validator misses more than 20% of the last 8,192 blocks. At Genesis, the initial slashing % is set at 0.0%.
Downtime Jail Duration: Failure to maintain MinSignedPerWindow leads to the validator being jailed (removed from the active validator set) for 7200 seconds.
Note that even if a validator does not intentionally misbehave, it can still be slashed if its node crashes, loses connectivity, gets DDoSed, or if its private key is compromised. Notably, validators could be slashed pursuant to a governance decision if they misbehave, including, for instance, malicious MEV extraction.
The applicable governance community can adjust all these parameters.
No, they do not need to self-delegate. Even though validators are not obligated to self-delegate, delegators may want their validator to have self-delegated DYDX in their staking pool. In other words, validators share the risk.
However, some validators may self-delegate via a different address for security reasons.
The community is expected to behave in a smart and self-preserving way. When a validator gets too much power, the community usually stops staking to that validator. The dYdX Chain will rely on the same effect.
When delegators switch to another validator, they are not subject to the unbonding period, which removes any barrier to quickly redelegating tokens to improve decentralization.
In the future, other mechanisms may be deployed to improve this process, such as:
- Community dashboards displayed to users regarding redelegation criteria and/or
- A community funding pool to support global delegation.
Technical Requirements
Validators should expect to provision one or more data center locations with redundant power, networking, firewalls, HSMs, and servers.
A modest level of hardware specifications is initially required and rises as network use increases. Participating in the testnet is the best way to learn more. You can find the current hardware recommendations in the dYdX Chain mainnet documentation.
Validators are recommended to set up sentry nodes to protect their validator node from DDoS attacks.
In addition to running a dYdX Chain node, validators should develop monitoring, alerting, and management solutions.
The minimum recommended specs for running a node are the following:
- 8-core, x86_64 architecture processor
- 64 GiB RAM
- 500 GiB of locally attached SSD storage
For example, an AWS instance like the r6id.2xlarge, or equivalent.
The dYdX Chain has the capacity for very high throughput relative to chains like Ethereum or Bitcoin. Ultimately, multi-gigabyte per day bandwidth is realistic as the network becomes more heavily used.
Validators are expected to run an HSM that supports ed25519 keys. Here are potential options:
YubiHSM 2
Ledger Nano S
Ledger BOLOS SGX enclave
Thales nShield support
Strangelove Horcrux
The dYdX Foundation does not recommend one solution above the other. The community is encouraged to bolster the effort to improve HSMs and key management security.
Running an effective operation is key to avoiding unexpected unbonding or slashing. Operations must be able to respond to attacks and outages and maintain security and isolation in the data center.
Validators are expected to perform regular software updates to accommodate chain upgrades and bug fixes. Consider using Cosmovisor to partially automate this process.
During a chain upgrade, progress is discussed through a private channel in the deployers of the dYdX Chain’s Slack channel. This information will also be relayed through to the dYdX Discord. If your validator is in the active set, we encourage you to request access to the private Slack channels by submitting a request form.
Denial-of-service attacks occur when an attacker sends a flood of internet traffic to an IP address to prevent the server at the IP address from connecting to the internet.
An attacker scans the network, tries to learn the IP address of various validator nodes, and disconnects them from communication by flooding them with traffic.
Validator nodes should only connect to full-nodes they trust because they operate them themselves or are run by other validators they know socially. A validator node will typically run in a data center. Most data centers provide direct links to the networks of major cloud providers.
Good operating procedures for validators are expected to mitigate these threats.
Testnet
To obtain testnet tokens, you can claim them by following the steps in the faucet documentation.
Community and Communication
Active validators of the dYdX Chain are encouraged to join the closed validator group channels by completing the Google Form, this form will be provided early next week. You will receive technical and operational support from the deployers of the dYdX Chain.
Validators can monitor the dYdX Forum and check for any Requests for Proposals, Submissions, and core themes that the dYdX Grants Program focuses on.
Get Involved with the Community
Become a part of our journey to reshape the financial landscape
