Stats Module

The Stats Module tracks user maker and taker volumes over a period of time (aka look-back window). This is currently set to 30 days. The maker and taker volume info is used to place users in corresponding fee-tiers.

This documentation is divided into the following subsections:

• Trading Stats: this section covers the trading statistics look-back window.

• Fee Tiers: this section covers the tiers of fees and discounts for each trader on dYdX Chain, based on their taker and maker volume.

• Trading Core: this section covers the core aspects of trading, namely insurance fund and liquidations config. The insurance fund acts as the first backstop to maintain systemic solvency when an account has a negative balance. The liquidations config defines the mechanism to close an account’s position when it falls below the margin requirements.

• Markets: this section covers the Prices module (x/prices) parameters on dYdX Chain as well as the liquidity tier of each market based on standardized risk parameters.

• Perpetual: this section covers the Perpetual module (x/perpetuals) parameters on dYdX Chain, such as funding rate and epoch information. The perpetual funding rate enables the perpetual price to align with the underlying asset's price. Epoch information is a fixed interval where funding is credited or debited to each account.

• Clob: this section covers the Clob module (x/clob) that configures the order creation, placement, and cancellations on dYdX Chain.

• Updating A Live Market: this section explains the message required to update a live market on dYdX Chain.

• Safety: this section explains the safety parameters on dYdX Chain, namely the spam mitigation that is related to order creation and cancellation using the Clob module.

Fee Tiers Module

The current fee tier structure on dYdX Chain was developed to stimulate liquidity, incentivize traders with substantial volume and contribute to the platform's overall growth and competitiveness.

The fee tier structure has the following characteristics:

1. different fees for either maker or taker,

2. fee discounts based on each user’s 30 days trading volume across sub accounts and markets, and

3. uniform fee structure across all markets.

This fee tier was implemented at block height 6,912,000.

Overview

dYdX Chain is a proof-of-stake blockchain network and holders of DYDX can participate in governing the dYdX Chain. dYdX Chain uses the standard in the Cosmos SDK.

The governance module empowers DYDX holders to propose and vote on proposals, directly influencing the evolution of the dYdX Chain through a democratic process. The subject matter of proposals can vary from changing a governable parameter on the dYdX Chain, spending dYdX community funds, and updating the software that dYdX Chain nodes are running, among other things.

Summary

Key Concepts and Definitions

• Deposits: Unstaked DYDX tokens pledged by the proposer and potentially other DYDX holders in support of the creation of a governance proposal.

• Inheritance: If a DYDX staker does not vote on a proposal, they will inherit the vote of their validator for the respective proposal.

• Vote Weight: A DYDX holder's vote weight is equal to the amount of DYDX the user has actively staked (1-1). DYDX tokens that are not staked or are in the unbonding period will not count towards a DYDX holder's vote weight.

• Tallying: After the voting period concludes, the aggregate the vote results to determine if the proposal was accepted or rejected by the dYdX community.

• Execution: If a proposal passes, the execution process depends on the type of proposal.

Parameters

These parameters may be adjusted by the dYdX Community with an on-chain governance proposal.

Proposal Submission and Deposits

All DYDX holders have the right to create a proposal. A DYDX holder can only use unstaked DYDX tokens to contribute to a given proposal deposit.

To create a proposal, a DYDX holder needs to send a msgsubmitproposal transaction and satisfy the min_initial_deposit_ratio parameter by sending a deposit transaction.

After the proposal is created, any DYDX holder can contribute to the deposit by sending a deposit transaction.

For the voting period to start, the min_deposit parameter needs to be satisfied within the max_deposit_period. Note, (1) the proposal is in an inactive proposal queue until the min_deposit is satisfied and (2) the voting_period will start as soon as the min_deposit is reached.

The deposit is kept in escrow and held by the governance ModuleAccount until the proposal is finalized (passed or rejected).

If a proposal fails to satisfy the min_deposit within the max_deposit_period and the burn_proposal_deposit_prevote parameter is set “False”, any DYDX holder who contributed to the respective deposit of a proposal will have their deposit refunded.

Proposal Types

Governance of the dYdX Chain includes 5 distinct types of proposals: text proposals, parameter change proposals, community spending proposals, software upgrade proposals, and new market proposals.

Text Proposals

Text proposals are votes that occur on-chain without directly triggering any changes on the dYdX Chain. Text proposals can be used (1) to establish dYdX community consensus for an off-chain matter, such as a strategic plan, a dYdX DAO action, or a dYdX DAO commitment, or (2) as signalling for a future vote that will directly cause changes on the dYdX Chain.

Community Spending Proposals

Community Spending Proposals involve a request to spend DYDX from the community treasury, community pool, or any other community-controlled account. The inputs for a Community Spending Proposal are (1) the number of DYDX and (2) the recipient address.

Parameter Change Proposals

Parameter change proposals are for changing one or more of the dYdX Chain parameters that are controlled by the governance module.

If a parameter change proposal is successful, the parameter change takes effect in the block after the voting period ends.

Software Upgrade Proposals

After the dYdX community accepts a software upgrade proposal there are two important steps:

• Signal - After a SoftwareUpgradeProposal is accepted, validators are expected to download and install the new version of the software while continuing to run the previous version. Once a validator has downloaded and installed the upgrade, it will start signaling to the network that it is ready to switch by including the proposal's proposalID in its precommits.

• Switch - Once a block contains more than 2/3rd precommits where a common SoftwareUpgradeProposal is signaled, all the nodes (including validator nodes and full nodes) are expected to switch to the new version of the software.

Proposal Voting Options

The voting options for governance proposals on dYdX Chain are:

• Yes

• No

• NoWithVeto - allows voters to express strong disagreement with a proposal to the extent that if burn_vote_veto is “True” and the veto_threshold is reached the respective deposit in the governance module account for the proposal is burned.

• Abstain - allows voters to signal that they do not intend to vote in favor or against the proposal but accept the result of the vote.

Expedited Proposals

A proposal can be expedited, which shortens the voting duration to 1 day and sets a higher tally threshold by default. The expedited proposal threshold is 0.75 (75%) and the quorum is 0.334 (33.4%). If the expedited proposal does not meet the threshold within the shortened voting period, it is converted to a regular proposal, and the voting restarts under standard conditions.

Users can set their proposal to expedited proposal by setting the expedited field in the proposal submission JSON file to true. Expedited proposals can be used for any vote type, including Text, Community Spend, Parameter Change, Adding Markets, and Software Upgrades.\