The New iOS Trading Experience Is Now Live!
Learn More
Guides
Bridge
How to bridge guide
Stake
How to stake guide
Vote
How to vote guide
Validator
How to validate guide
Ecosystem
Blog
Read the latest updates
dYdX Ecosystem
Explore the ecosystem
Integrate
Join the dYdX Ecosystem
Trading
API Integration
Clients information
Documentation
Technical information
GitHub
View dYdX github
Media
Press
Latest press features
Podcasts
Latest podcast features
Brand
Our brand assets
Press Enquiry
Get in touch
Explore
dYdX Foundation
About us
Careers
We are actively hiring
Institutions
Integrate
Join the dYdX Ecosystem
Ecosystem Enquiry
Get in touch
Trade App
v4
Trade App
v4

Menu

Introduction
Validating on Mainnet
Validating on Testnet
FAQs & Resources
Get in Touch
Disclaimer

General Concepts

What is a validator?

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.

What is staking?

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.

What is a full-node?

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.

What is a delegator?

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

What are the different types of keys?

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.

What are the different states a validator can be in?

After creating a validator with a create-validator transaction, it can be in four states:

  1. 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. 
  2. Jailed: Validator misbehaved and is in jail, i.e., outside of the validator set.
  3. 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.
  4. Tombstoned: Validator is permanently banned and cannot rejoin the validator set.
What is "self-delegation"? How can I increase my "self-delegation"?

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.

Is there a minimum amount of DYDX that must be staked to be an active (bonded) validator?

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).

How will delegators choose their validators?

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

Do validators need to be publicly identified?

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.

What are the responsibilities of a validator?

Validators have two main responsibilities:

  1. 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.
  2. 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.

What does staking imply?

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.

What does 'participate in governance' entail?

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.

Can a validator run away with its delegators' DYDX?

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.

How often will a validator be chosen to propose the next block? Does it go up with the quantity of DYDX staked?

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.

What is the incentive to stake?

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.

What is the incentive to run a validator?

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.

What is a validator's commission?

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.

How are staking rewards distributed?

Staking rewards are distributed proportionally to all validators and stakers relative to their stake weight.

For example: Let’s say 10 validators have equal stake weight, 10% self-bonded DYDX, and a commission rate of 5%. In this example, the rewards distributed in a block are 5000 USDC. These rewards do not go directly to the proposer. Instead, the rewards are evenly spread among validators. So now, each validator's pool has 500 USDC. The pool of 500 USDC are distributed according to each participant's stake:

Commission: 500*90%*5% = 22.5USDC
Validator gets: 500\*10% + Commission = 72.5 USDC
All delegators get: 500\*90% - Commission = 377.5 USDC
Then, each delegator can claim their part of the 377.5 USDC in proportion to their stake in the validator's staking pool.

How are fees distributed?

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.

What are the slashing conditions?

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.

Are validators required to self-delegate DYDX?

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.

How to prevent the concentration of stake weight in the hands of a few top validators?

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:

  1. Community dashboards displayed to users regarding redelegation criteria and/or
  2. A community funding pool to support global delegation.

Technical Requirements

What are hardware 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.

What are software requirements?

In addition to running a dYdX Chain node, validators should develop monitoring, alerting, and management solutions.

What are bandwidth requirements?

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.

How to handle key management?

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.

What can validators expect in terms of operations?

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.

What are the maintenance requirements?

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.

How can validators protect themselves from Denial-of-Service attacks?

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

Is there a testnet faucet?

To obtain testnet tokens, you can claim them by following the steps in the faucet documentation.

Community and Communication

How can validators receive technical and operational support?

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.

Beyond standard validator operations, where can validators find opportunities to contribute to the dYdX ecosystem?

Validators can monitor the dYdX Forum and check for any Requests for Proposals, Submissions, and core themes that the dYdX Grants Program focuses on.

Essential Reading & Helpful Resources

Testnet: Full documentation

MEV: ‍

  • dYdX v4 & MEV
  • An Update on MEV: Catching a Bad Validator
  • Skip dYdX MEV Dashboard
  • MEV on the dYdX Chain

Governance:

  • The role of Endorsed Delegates 
  • Validators and their governance participation 
  • Sufficient Decentralization: A Playbook for web3 Builders and Lawyers
  • Progressive Decentralization: A Playbook for Building Crypto Applications
  • Validator Commons
Last updated on November 14, 2023
Previous
Validating on Testnet
Next
Get in Touch

Get Involved with the Community

Become a part of our journey to reshape the financial landscape

X
Forum
Discord
YouTube
Hedgies nft images
About
Foundation
Careers
Brand
Terms of Use
Privacy Policy
Bug Bounty Program
Video Disclaimer
Guides
Bridge
Stake
Vote
Validators
dYdX Chain Onboarding
Ecosystem
Blog
dYdX Ecosystem
Integrate
Trading
Documentation
GitHub
Public Bridge UIs
dYdX DAO
dYdX Grants Program
dYdX Operations subDAO
Socials

Leaving site

Leaving site. By clicking ‘Continue’, you will be leaving the dYdX Foundation (“dYdX Foundation”) website and accessing a website made available by a third party using dYdX v4 open-source software that is independent from and unaffiliated with the dYdX Foundation. The dYdX Foundation does not deploy or run dYdX v4 software for public use, nor does it operate or control any such infrastructure. The dYdX Foundation is not responsible for any action taken by independent third parties or for content on any third-party websites, including the one you would access by clicking ‘Continue’.

‍

The dYdX Foundation services and products are not available to persons who are residents of, are located or incorporated in, or have a registered office in the U.S., Canada or a Restricted Territory.  More details can be found in our Terms of Use. Learn more about dYdX v4 third-party front end options here.

Continue