x/distribution | Explore the SDKLoading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
DYDX is the dYdX Chain's Layer 1 token, as adopted by the dYdX community, through dYdX governance (Snapshot and on-chain).
DYDX, the dYdX Chain's L1 token, serves three key purposes: Staking, Security, and Governance.
Staking: DYDX holders have the option to serve as validators (and self-delegate) or to delegate their stake to existing validators. Such delegation increases the likelihood of the chosen validators entering or staying in the active validator set, thereby becoming a participant in the network’s consensus process.
Security: Staking DYDX directly contributes to dYdX Chain security. As more DYDX holders choose to stake their tokens across a diverse range of validators in the network and the total amount of stake on the network increases, it becomes increasingly difficult for a coordinated attack to influence a consensus decision.
Governance: DYDX 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.
An overview of parameters that are not covered in other sections of the governance documentation and are adjustable through a dYdX Chain governance Parameter Change Proposals.
This documentation is divided into the following subsections:
Trading Stats and Fees: this section covers the trading statistics look-back window and 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.
Adding & Updating A Live Market: this section explains the message required to add a new or 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.
Crypto-assets can be highly volatile and trading crypto-assets involves risk of loss, particularly when using leverage. Investment into crypto-assets may not be regulated and may not be adequate for retail investors. Do your own research and due diligence before engaging in any activity involving crypto-assets.
dYdX is a decentralised, disintermediated and permissionless protocol, and is not available in the U.S. or to U.S. persons as well as in other restricted jurisdictions. The dYdX Foundation does not operate or participate in the operation of any component of the dYdX Chain's infrastructure.
The dYdX Foundation’s purpose is to support the current implementation and any future implementations of the dYdX protocol and to foster community-driven growth in the dYdX ecosystem.
The dYdX Chain software (including dYdX Unlimited) is open-source software to be used or implemented by any party in accordance with the applicable license. At no time should the dYdX Chain and/or its software or related components (including dYdX Unlimited) be deemed to be a product or service provided or made available in any way by the dYdX Foundation. Interactions with the dYdX Chain software (including dYdX Unlimited) or any implementation thereof are permissionless and disintermediated, subject to the terms of the applicable licenses and code. Users who interact with the dYdX Chain software, including dYdX Unlimited (or any implementations thereof) will not be interacting with the dYdX Foundation in any way whatsoever. The dYdX Foundation does not make any representations, warranties or covenants in connection with the dYdX Chain software (or any implementations and/or components thereof, including dYdX Unlimited), including (without limitation) with regard to their technical properties or performance, as well as their actual or potential usefulness or suitability for any particular purpose, and users agree to rely on the dYdX Chain software (or any implementations and/or components thereof, including dYdX Unlimited) “AS IS, WHERE IS”.
This documentation contains one of many multiple approaches that can be considered in connection with the subject matter hereof. Nothing in this documentation should be used or considered as legal, financial, tax, or any other advice, nor as an instruction or invitation to act by anyone. The dYdX Foundation makes no recommendation as to how to vote on any proposal in dYdX governance related to a potential migration or otherwise, whether to migrate any assets to the proposed new dYdX Chain, or to take any action whatsoever. The dYdX community is sovereign to make decisions freely and at its sole discretion, in accordance with the governance rules, principles, and mechanisms adopted by the dYdX DAO. dYdX community discussion and interaction on the contents of this post are encouraged. The dYdX Foundation does not directly participate in governance decisions to be made by the dYdX community, including, without limitation, by making and/or voting on governance proposals.
Depositing into the MegaVault carries risks. Do your own research and make sure to understand the risks before depositing funds. MegaVault returns are not guaranteed and may fluctuate over time depending on multiple factors. MegaVault returns may be negative and you may lose your entire investment.The dYdX Foundation does not operate or has control over the MegaVault and has not been involved in the development, deployment and operation of any component of the dYdX Unlimited software (including the MegaVault).
We encourage readers to remain vigilant and only rely on information coming from legitimate sources, as we anticipate an increase in potential scams and phishing attacks via social media, messaging apps, and websites.
The dYdX Foundation may alter or update any information in this post in the future and assumes no obligation to publicly disclose any such change. This post is solely based on the information available to the dYdX Foundation at the time it is made and should only be read and taken into consideration at the time it is made and on the basis of the circumstances that surround it. The dYdX Foundation makes no guarantees of future performance and is under no obligation to undertake any of the activities contemplated herein, including but not limited to the direct or indirect open-sourcing of any commissioned code.
An overview of the Distribution Module.
The distribution module enables a simple collection and distribution mechanism to passively distribute rewards between validators and delegators.
Community Pool: a pool of tokens funded by a portion of staking rewards (community_tax) that the dYdX community could use to fund contributor grants, community initiatives, liquidity mining, and other initiatives.
Distribution ModuleAccount Account: an account that collects and distributes trading and transaction fees among validators, delegators, and the community pool.
Staking Rewards: the total portion of the Fee Pool that a DYDX staker can claim at a given block.
Fee Pool: fee pool from maker trading fees (USDC), taker trading fees (USDC), DYDX-denominated gas fees from transactions, and USDC-denominated gas fees from transactions for a given block.
Staking Rewards Withdrawal: a DYDX staker may claim their portion of the Fee Pool for each block. If a DYDX staker does not claim staking rewards, their respective rewards will accrue in the Distribution ModuleAccount Account.
Total Bonded Power: the sum of all tokens that are currently staked by validators to themselves and tokens staked to validators by DYDX holders.
Block Rewards: fees distributed to validators and delegators for successfully proposing and validating a new block on the blockchain.
The dYdX Community may adjust these parameters with an on-chain governance proposal.
On the dYdX Chain, all transaction fees (trading fees denominated in USDC, DYDX-denominated gas fees from transactions, and USDC-denominated gas fees from transactions) collected by the protocol will be distributed to validators and DYDX holders that stake to dYdX Chain validators.
The Cosmos x/distribution module is a simple mechanism to allocate rewards earned by Validators and Stakers. For a detailed understanding of the Cosmos rewards mechanism, read here.
DYDX holders who stake to (a) validator(s) are entitled to a portion of the following fees:
DYDX-denominated gas fees from transactions,
USDC-denominated gas fees from transactions,
USDC maker trading fees, and
USDC taker trading fees.
Fees will accrue in the Distribution ModuleAccount Account each block. Each block a DYDX staker may claim their portion of Staking Rewards. If a DYDX staker does not claim Staking Rewards, their respective rewards will accrue in the Distribution ModuleAccount Account.
Note, Staking Rewards are not automatically staked to a dYdX Chain validator. Any DYDX earned by a staker as Staking Rewards will need to be claimed from the Distribution ModuleAccount Account and staked to a dYdX Chain validator to contribute to the security of the network and qualify to earn staking rewards.
Fee Pool = fee pool from maker trading fees (USDC), taker trading fees (USDC), DYDX-denominated gas fees from transactions, and USDC-denominated gas fees from transactions for a given block.
Number of DYDX staked by DYDX holder = total DYDX tokens that a dYdX Chain address has staked to (a) validator(s) at a given block.
Total bonded power = the sum of all DYDX that are currently staked by validators to themselves and DYDX staked to validators by DYDX holders.
Staking Rewards = the total portion of the Fee Pool that a DYDX staker can claim at a given block.
Community tax = A tax that directs a percentage of the fee pool to the community pool.
Validator commission rate = commission set by each validator and applied to the staking rewards of each delegator. Validators are required to follow the min_commission_rate parameter but are otherwise free to set their own commission rates.
An overview of the Governance module.
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 x/gov module 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.
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 TallyParams 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.
These parameters may be adjusted by the dYdX Community with an on-chain governance proposal.
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.
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 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 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 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.
The upgrade module facilitates smoothly upgrading a live Cosmos chain to a new (breaking) software version. Software Upgrade Proposals need to be created with a plan. Such a plan outlines when the update will occur (block height), the name of the new version of the software, and the UpgradeHandler which instructs the upgrade module on how to carry out the upgrade (the latest consensus version of each module and other software).
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.
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.
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.
For example, if an expedited proposal starts on July 1st, the vote would end on July 5th if the expedited proposal fails to meet the higher tally threshold by July 3rd.
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.\
An overview of the Staking Module.
dYdX Chain leverages the Cosmos SDK Staking module which supports a Proof-of-Stake blockchain and enables DYDX holders to become validators and/or delegate the validation rights (stake) of their DYDX to a dYdX Chain validator.
Staking: the act of delegating and locking up (‘bonding’) DYDX tokens to a dYdX Chain validator to secure and govern the network.
Bonded Validator: once the validator receives sufficient bonded tokens they automatically join the Active Set EndBlock and their status is updated to Bonded. A bonded validator (1) is signing blocks and receiving rewards (2) can receive further delegations, and (3) can be slashed for misbehavior.
Active Set: the Active Set represents the validators that can participate in consensus, receive rewards, and secure the dYdX Chain at a given time. The active set includes the top validators according to staked tokens (delegated from third parties and self-delegation) and is determined by the max_validators parameter. The Active Set is updated during EndBlock by retrieving validatorsbypower and the max_validators parameter.
EndBlock: A function is called after all transactions in a block have been processed. EndBlock is generally used to execute logic that should happen after a block is executed to finalize state transitions, such as determining the active validator set of the dYdX Chain.
Inactive Set: Validators who are not in the Active Set, do not participate in consensus and do not receive rewards.
Unbonded Validator: The validator (1) is not in the Active Set, (2) cannot sign blocks and (3) does not earn rewards, but they can receive delegations. DYDX holders who stake to an unbonded validator will not earn any staking rewards.
Validator Commission: Commission set by each validator and applied to the staking rewards of each delegator. Validators are required to follow the min_commission_rate parameter but are otherwise free to set their own commission rates.
These parameters may be adjusted by the dYdX Community with an on-chain governance proposal.
On the dYdX Chain, DYDX holders can serve as validators or delegate their stake to existing validators. Such delegation increases the likelihood of the chosen validator(s) entering or staying in the active validator set, thereby becoming or maintaining their position as a participant in the network’s consensus process.
DYDX holders who stake DYDX to a validator can send a transaction to unstake and remove their tokens (fully or partially) from being staked to a validator. After this transaction is sent, the DYDX tokens enter an unbonding period which lasts for the duration of the unbonding_time parameter.
Redelegation in the Cosmos SDK is a feature that allows a delegator to shift their staked tokens (delegations) from one validator to another without having to wait for the unbonding period.
During the redelegation process, the tokens remain staked, meaning they continue contributing to the network's security and potentially earning rewards for the delegator.
However, a user’s slashing risk with the original validator remains until the unbonding period concludes. For example, a user stakes 20 DYDX to validator A for 59 days, on day 60 the user decides to redelegate their 20 DYDX to validator B. If validator A is slashed between days 60-90, the user is at risk of having a portion of their 20 staked DYDX slashed. After the 90th day, the slashing risk transitions to validator B.
After redelegating, you must wait 30 days before redelegating again from this new validator.
Welcome to the community documentation for dYdX Unlimited!
The dYdX Chain is a proof-of-stake blockchain network built using the Cosmos SDK and leveraging CometBFT for consensus. The software was fully audited by Informal Systems and open-sourced by dYdX Trading Inc. ("dYdX Trading").
The dYdX Chain open-source software was deployed and the first block of the dYdX Chain was created by the dYdX Chain validators on October 26, 2023, at 17:00 UTC.
The dYdX Community approved the dYdX Chain software upgrade to v7.0 ("dYdX Unlimited") on November 9, 2024. This software upgrade included significant improvements, such as:
An overview of the $DYDX token allocation.
A total of 1,000,000,000 $DYDX have been minted on August 3rd, 2021, at 15:00:00 UTC, and started to become accessible over five (5) years. The current allocation of the total supply of $DYDX is as follows:
50.0% (500,000,000 $DYDX) to the community as follows:
26.1% (261,133,225 $DYDX) to the Community Treasury,
14.5% (144,693,506 $DYDX) based on the Trading Rewards Formula,
5.0% (50,309,197 $DYDX) to past users who complete certain trading milestones on the dYdX Layer 2 Protocol (Retroactive Mining Rewards),
3.3% (32,794,525 $DYDX) based on the Liquidity Provider Rewards Formula(s),
0.6% (5,779,608 $DYDX) to users staking $USDC to a Liquidity Staking Pool,
0.5% (5,289,939 $DYDX) to users staking $DYDX to a Safety Staking Pool,
27.7% (277,295,070 $DYDX) to past investors of dYdX Trading Inc.,
15.3% (152,704,930 $DYDX) to founders, employees, advisors, and consultants of dYdX Trading Inc. or dYdX Foundation, and
7.0% (70,000,000 $DYDX) to future employees and consultants of dYdX Trading Inc. or the dYdX Foundation.
Although the community allocation has been established as laid out above, $DYDX holders have full control, via governance, over how it is used going forward.
The initial five-year allocation of the total supply of $DYDX was as laid out below, it was then followed by several governance proposals that changed the initial allocation:
50.0% (500,000,000 $DYDX) to the community as follows:
5.0% (50,000,000 $DYDX) to a Community Treasury,
25.0% (250,000,000 $DYDX) based on the Trading Rewards Formula,
In DIP 16 and DIP 20, the dYdX community voted to reduce trading rewards by a total of 2.3M $DYDX. (958,904 $DYDX from DIP 16 and 1,294,520 $DYDX from DIP 20). The 2.3M $DYDX will accrue in the Rewards Treasury and can be used by the dYdX community with a governance vote.
In DIP 29, the dYdX community voted to reduce trading rewards by ⅓ from Epoch 30-32 on dYdX v3 to the following values:
Epoch 30: 1,054,795 $DYDX
Epoch 31: 527,398 $DYDX
Epoch 32: 0 $DYDX
7.5% (75,000,000 $DYDX) to past users who complete certain trading milestones on the Layer 2 protocol (Retroactive Mining Rewards),
After Epoch 0, 24,690,803 unclaimed $DYDX from the Retroactive Mining rewards program were transferred to the Community Treasury.
7.5% (75,000,000 $DYDX) based on the Liquidity Provider Rewards Formula(s),
In DIP 24, the dYdX community voted to reduce Liquidity Provider rewards by 50% from 1,150,685 $DYDX per epoch to 575,343 $DYDX per epoch. The excess 575,342 $DYDX per epoch will accrue in the Rewards Treasury and can be used by the dYdX community with a governance vote.
In DIP 29, the dYdX community voted to reduce Liquidity Provider rewards by ⅓ from Epoch 30-32 on dYdX v3 to the following values:
Epoch 30: 383,562 $DYDX
Epoch 31: 191,781 $DYDX
Epoch 32: 0 $DYDX
2.5% (25,000,000 $DYDX) to users staking $USDC to a Liquidity Staking Pool,
In DIP 14, the dYdX community voted to set the rewards associated with staking $USDC to 0. The 383,562 $DYDX previously distributed to $USDC stakers will accrue in the Rewards Treasury and can be used by the dYdX community with a governance vote.
2.5% (25,000,000 $DYDX) to users staking $DYDX to a Safety Staking Pool,
In DIP 17, the dYdX community voted to set the rewards associated with staking $DYDX to 0. The 383,562 $DYDX previously distirbuted to $DYDX stakers will accrue in the Rewards Treasury and can be used by the dYdX community with a governance vote.
27.7% (277,295,070 $DYDX) to past investors of dYdX Trading Inc.,
15.3% (152,704,930 $DYDX) to founders, employees, advisors, and consultants of dYdX Trading Inc. or dYdX Foundation, and
7.0% (70,000,000 $DYDX) to future employees and consultants of dYdX Trading Inc. or dYdX Foundation.
On September 8, 2021, the initial transfer restrictions on the token were lifted.
The following chart shows the total liquid supply without inflation:
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.
| Title | Value | Definition |
|---|
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 as it transitions from dYdX Layer 2 Protocol built on Ethereum to the dYdX Chain.
The fee tier structure has the following characteristics:
different fees for either maker or taker,
fee discounts based on each user’s 30 days trading volume across sub accounts and markets, and
uniform fee structure across all markets.
The following strategies that can be updated by governance exist to prevent spam on the orderbook and prevent the blockchain state from getting too large:
Block rate limit defines the block rate limits for CLOB specific operations.
Equity tier limit defines the set of equity tiers to limit how many open orders a subaccount is allowed to have.
| Title | Value | Description |
|---|---|---|
| Title | Value | Description |
|---|---|---|
| Title | Value | Description |
|---|---|---|
This fee tier was at block height 6,912,000.
0
A tax that directs a percentage of the fee pool to the community pool.
0
Part of the block reward reserved for the validator that proposes a given block.
0
Bonus incentive for block proposers based on the number of transactions included in a given block.
True
Whether a delegator can set a different withdrawal address (other than their delegator address) for their rewards.
Deposit Params
The parameters for deposits on governance proposals.
2000000000000000000000 adydx
2,000 DYDX
The minimum token deposit for a governance proposal to enter the voting period.
604800s
7 days
The maximum time permitted for DYDX holders to deposit enough DYDX tokens to satisfy the min_deposit for a governance proposal to enter the voting period.
0.20000
The percentage of the min_deposit that needs to be submitted by the address that creates the proposal.
Voting Params
The parameter for vote length of governance proposals.
345600s
~4 days
The duration of the voting period.
0.33400
The parameters for tallying votes on governance proposals.
0.50000
The minimum proportion of Yes votes for a proposal to pass.
*Abstain votes are not counted.
0.33400
The minimum percentage of NoWithVeto votes required to reject a proposal, regardless of the number of Yes votes.
Burnable Params
The parameters for burning or returning a proposal deposit to depositors.
True
If True, this boolean parameter will burn the proposal deposit for any proposals that are vetoed.
False
If True, this boolean parameter will burn the proposal deposit if the proposal vote does not reach quorum.
False
If True, this boolean parameter will burn the proposal deposit if the proposal does not enter the voting period.
Expedited Proposal Params
The parameters for expedited proposals
0.75000
The minimum proportion of Yes votes for an expedited proposal to pass.
*Abstain votes are not counted.
86400s ~1 day
The duration of expedited proposal's voting period.
adydx
Denomination of the L1 staking token.
10000
Number of records of a validator's past performance at a given point in time.
7
Limit on the number of entries for unbonding delegations or redelegations per staker account for each validator they interact with.
60
The maximum number of Validators in the Active Set.
0.05
The chain-wide minimum commission rate that a validator can charge their delegators.
2592000s
~30 days
The time it takes to unbond (full/partial) from a validator.
This functionality allows the community to update parameters of a live market, which can be composed of 4 parts:
Liquidity Tier is updatable through MsgSetLiquidityTier.
The Prices module (x/prices) is updatable through MsgUpdateMarketParam.
The Perpetual module (x/perpetuals) is updatable through MsgUpdatePerpetual.
The Clob module (x/clob) is updatable through MsgUpdateClobPair.
Information about the Fee Schedule in the dYdX Chain open source software is available here.
Below, we outline the flow of dYdX Chain governance, from the idea's inception to implementation. These processes are subject to change according to feedback from the dYdX community.
Anyone can sign up and set up a thread on any topic on dYdX’s governance forums hosted at https://dydx.forum/. dYdX community members are required to register using an email address or an Ethereum wallet.
dYdX Request for Comments (DRCs) creation is the first step in the governance improvement process. Anyone can participate in the dYdX governance forum, create an off-chain DRC, and discuss potential improvements to the dYdX Chain and/or dYdX ecosystem.
To create a DRC, dYdX community members should use this template.
The DRC should cover all the information of the potential final DIP.
Once posted on the dYdX governance forum, the proposer should reasonably respond to questions and incorporate constructive feedback to further improve the DRC. The DRC Discussion and Feedback step aims to establish a rough consensus before a vote starts.
While a rigid timeline is unnecessary, four days likely makes sense to ensure the dYdX community has sufficient time to review and comment on the DRC.
Before submitting a transaction to create a governance proposal, the prospective proposer must create a json file containing relevant information for the governance proposal. Depending on the type of proposal, the contents of the json file will differ.
Text Proposals: the file should contain a title, description, and deposit (in aDYDX units).
Community Spending Proposals: the file should contain the title, description, recipient, number of tokens, and deposit (in aDYDX units).
Parameter Change Proposals: the file should contain title, description, changes, subspace (module with the parameter that is being changed), key (the parameter that is being changed), value (value of the parameter that will be changed by the governance mechanism), and deposit (in aDYDX units).
Software Upgrade Proposals: the file should contain title, description, deposit and plan.
The plan outlines when the update will occur (block height), the name of the new version of the software, and the UpgradeHandler which instructs the upgrade module how to carry out the upgrade (the latest consensus version of each module and other software).
As a general rule, any information specific to a proposal (e.g., Title, description, deposit, parameters, recipient) can be placed in a json file, while information general to a transaction of any kind (e.g., chain-id, node-id, gas, fees) can remain in the CLI (the command-line interface).
Below is a template json file that can be used for a Text proposal:
The description must at least contain:
a short summary of the DRC that has been posted on the dYdX governance forum,
a link to the completed DIP template, and
a link to the forum post,
so that prospective voters have access to the full context of the DIP.
The description within the json file will be visible to the prospective voters when they:
query the proposal using the CLI,
view the proposal on their wallet dashboard (such as Keplr or Leap), or
view the proposal on a block explorer (such as Mintscan).
If you have never submitted a proposal on dYdX Chain before, it would be helpful to familiarize yourself with this technical guide.
An on-chain DIP may be submitted by a dYdX community member using the following generic command format (on the command-line interface):
Here is an example using the above command format to submit a software upgrade proposal:
If <proposal type> is left blank, the type will be a Text proposal. Otherwise, it can be set to param-change, software-upgrade, or community-treasury-spend.
dydxprotocold is the command-line interface client that is used to send transactions and query the dYdX Chain and tx gov submit-proposal software-upgrade indicates that the transaction is submitting a software upgrade proposal.
--~/upgrade_plan.json indicates the file containing the proposal information.
--from wallet-1 is the account key that pays the transaction fee and deposit amount. This account key must exist in the keychain on your device and it must be an address you control. To register an account in the keychain, you can follow the steps here.
--chain-id dydx-mainnet-1 is dYdX Chain.
--gas 500000 is the maximum amount of gas permitted to be used to process the transaction.
The more content there is in the description of your proposal, the more gas your transaction will consume.
If this number isn't high enough and there isn't enough gas to process your transaction, the transaction will fail.
The transaction will only use the amount of gas needed to process the transaction.
You can simulate the amount of gas needed to submit the proposal by adding --dry-run at the end of the CLI command above.
In practice, the simulation function isn’t always accurate, so you may want to multiply the return the gas unit by a ~1.3x multiplier. For example, with the following result, you will need to input around --gas 1100000
--fees is a flat-rate incentive for a validator to process your transaction, it is denominated in USDC (ibc/8E27BA2D5493AF5636760E354E46004562C46AB7EC0CC4C1CA14E9E20E2545B5).
The network still accepts zero fees, but many nodes will not transmit your transaction to the network without a minimum fee.
Many nodes use a minimum fee to disincentivize transaction spamming.
The number is divided by 10^18.
--node is RPC endpoint address that can be found here. Remember to append :443 to the end of the RPC URI to access the endpoint properly and securely.
To submit the proposal on-chain, the proposer will need to deposit a number of DYDX that is equal to or greater than the min_initial_deposit_ratio.
As soon as the proposal is created the max_deposit_period begins and the min_deposit must be satisfied before the max_deposit_period concludes for the vote to start.
After the proposal is created, any DYDX holder can contribute to the deposit by sending a deposit transaction.
To contribute to the deposit of a governance proposal, the prospective depositor must know the proposalID that they intend to add a deposit to. The prospective depositor can query list of proposals on dYdX Chain by entering this command on the CLI:
Once the prospective depositor knows the ID of the proposal, they can add a deposit using this command:
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.
If the min_deposit is satisfied within the max_deposit_period, the vote will start and the deposit is kept in escrow and held by the governance ModuleAccount until the proposal is finalized (passed or rejected). Depositors of a proposal will have their deposit refunded, unless enough voters vote NoWithVeto and satisfy the veto_threshold.
If the min_deposit is satisfied within the max_deposit_period, the vote will start and voting will last for the voting_period.
Note, only staked DYDX tokens can vote on dYdX Chain governance proposals.
Prospective voter can vote by following the steps on the How to Vote Guide.
If a DYDX staker does not vote on a proposal, they will inherit the vote of their validator for the respective proposal.
When the voting_period ends, the TallyParams (quorum, threshold, and veto_threshold) determine whether the proposal is approved and implemented or rejected.
The execution process according to the respective vote type is as follows:
Text Proposals: will not result in any on-chain changes, but could result in an off-chain action.
Community Spending Proposals: the number of DYDX encoded in the proposal will be transferred from the from the dYdX community account to the address encoded in the proposal.
Parameter Change Proposals: the parameter will update go into effect without a hard fork.
Software Upgrade Proposals:
Signal - Validators upgrade their software to the new version and signal that they are ready for the upgrade.
Block Height: The dYdX Chain reaches the specified block height for the upgrade and pauses its operation.
Upgrade and Restart: Validators apply the upgrade and restart their nodes, which resumes the blockchain's operation with the new software.
2592000s
30 days | The desired number of seconds in the look-back window. |
Tier | Absolute_volume_requirement [30 day Trailing Volume] | Total_volume_share_requirement_ppm [Exchange Market Share] | Maker_volume_share_requirement_ppm [Maker Market Share] | maker_fee_ppm [Maker Fee (bps)] | Taker_fee_ppm [Taker Fee (bps)] |
0 [< $1M] | 0 [-] | 0 [-] | 100 [1.0] | 500 [5.0] |
1000000000000 [≥ $1M] | 0 [-] | 0 [-] | 100 [1.0] | 450 [4.5] |
5000000000000 [≥ $5M] | 0 [-] | 0 [-] | 50 [0.5] | 400 [4.0] |
25000000000000 [≥ $25M] | 0 [-] | 0 [-] | 0 [-] | 350 [3.5] |
125000000000000 [≥ $125M] | 0 [-] | 0 [-] | 0 [-] | 300 [3.0] |
125000000000000 [≥ $125M] | 5000 [≥ 0.5%] | 0 [-] | -50 [-0.5] | 250 [2.5] |
125000000000000 [≥ $125M] | 5000 [≥ 0.5%] | 10000 [≥ 1%] | -70 [-0.7] | 250 [2.5] |
125000000000000 [≥ $125M] | 5000 [≥ 0.5%] | 20000 [≥ 2%] | -90 [-0.9] | 250 [2.5] |
125000000000000 [≥ $125M] | 5000 [≥ 0.5%] | 40000 [≥ 4%] | -110 [-1.1] | 250 [2.5] |
Title | Limit | Num_blocks | Definition |
200 | 1 | How many short term order attempts (successful and failed) are allowed for an account per N blocks. |
2 20 | 1 100 | How many stateful order attempts (successful and failed) are allowed for an account per N blocks. |
200 | 1 | How many short term order cancellation attempts (successful and failed) are allowed for an account per N blocks. |
Title | limit | usd_tnc_required | Definition |
0 | 0 | how many open short term orders are allowed per equity tier.
|
4 | 20000000 |
8 | 100000000 |
10 | 1000000000 |
100 | 10000000000 |
1000 | 100000000000 |
0 | 0 | how many open stateful orders are allowed per equity tier. |
4 | 20000000 |
8 | 100000000 |
10 | 1000000000 |
100 | 10000000000 |
200 | 100000000000 |
An overview of the slashing module.
The slashing module is a mechanism to penalize validators for a violation of protocol rules by slashing their bonded tokens. Penalties under the slashing module include burning a portion of a validator’s bonded tokens and/or temporarily removing their ability to vote on future blocks.
Signing Info
Liveness Tracking
Messages
Social Slashing
States: In the state machine, a variable number of validators are registered, and during each block, the top max_validators (defined in the Staking module) who are not jailed become bonded and can propose and vote on blocks, with a ValidatorSigningInfo record tracking their liveness and potential protocol faults.
Double Signing: When a validator is proven to have signed two blocks at the same height, causing conflicting blocks or transactions on multiple branches of the dYdX Chain.
Downtime: When a validator does not vote on a dYdX Chain block for a period of time.
Jailed: A period of time when a validator is not allowed to rejoin the Active Set due to a violation of protocol rules.
Staking Tombstone: When a validator is permanently removed from the Active Set due to a double signing infraction. More information about Staking Tombstone is available here.
More information about the slashing module is available here.
These parameters may be adjusted by the dYdX Community with an on-chain governance proposal.
In every block, validators contribute to a set of precommits for the previous block, forming the LastCommitInfo in CometBFT. This LastCommitInfo is valid if it includes precommits from +2/3 of the total voting power.
If a validator fails to be included in the LastCommitInfo for a certain number of blocks, they will be automatically jailed, slashed or unbonded.
dYdX Chain stores Information about validator's liveness activity on ValidatorSigningInfo. At the start of each block, the ValidatorSigningInfo for each validator is updated, and their liveness status over signed_blocks_window is checked.
The sliding window is defined by signed_blocks_window and the index is determined by the IndexOffset in each validator’s ValidatorSigningInfo. The IndexOffset is incremented with each block whether the validator signed or not, and the MissedBlocksBitArray and MissedBlocksCounter are updated accordingly once the index is determined.
To make sure whether a validator falls below the liveness threshold, the maximum number of blocks missed (maxMissed) and minimum height of liveness threshold (minHeight) are retrieved.
If the current block is past minHeight and the MissedBlocksCounter exceeds maxMissed, the validator is slashed by slash_fraction_downtime, jailed for downtime_jail_duration, and has their MissedBlocksBitArray, MissedBlocksCounter, and IndexOffset reset.
Note, slashing due to liveness tracking failure does not lead to tombstoning.
Unjail
Should a validator want to return and potentially rejoin the Active Set after being removed due to Downtime, they must send a MsgUnjail.
The MEV (Maximal Extractable Value) extraction by validators can undermine a fair and transparent trading environment. MEV refers to the profit a dishonest validator can gain by censoring and/or re-ordering orders and cancellations to their advantage. Validators could take advantage of the architecture of the dYdX Chain - an in-memory orderbook design - to manipulate, re-order, or censor trades before suggesting a new block for profit extraction, resulting in trades executing at worse prices relative to the best price possible and cancellations potentially being ignored.
To show how much MEV value could be extracted by each validator, dYdX Trading, Inc. ("dYdX Trading") and Skip Protocol have collaborated to create a dashboard that displays data on orderbook discrepancies.
Currently, there is no protocol-level solution to mitigate MEV on the dYdX Chain, despite MEV extraction being considered a harmful validator behavior. However, the dYdX community, through a governance vote, could approve the implementation of a social slashing framework to penalize validators engaged in MEV extraction.
Perpetual contracts, unlike traditional futures contracts, lack an expiry date and use funding rates to encourage the perpetual price to align with the underlying asset's price. The Funding Rate is determined algorithmically based on the Index Price and Mid-Market Prices, prompts long traders to pay shorts when the perpetual trades at a premium and vice versa.
These payments are proportional to traders' positions and are exchanged directly between traders, not involving the exchange. The goal of the Funding Rate is to maintain the perpetual market's price close to the Index Price by incentivizing trading actions that bring it in line with the underlying asset's value.
Funding rate and premium payments are credited or debited at a fixed interval based on the Epoch Information parameters. These parameters define the funding rate interval and premium sampling interval:
Next Tick: when the next epoch starts in seconds.
Duration: duration of the epoch in seconds.
Is Initialized: whether the epoch has been initialized.
Fast Forward Next Tick: specifies whether next_tick.
should be fast-forwarded to be greater than the current block time.
Instant Market Listings enable users to list and trade perpetual futures on virtually any asset on dYdX instantly without waiting for governance approvals or third-party permissions. This new product feature eliminates the traditional costs and delays associated with market creation, allowing users to respond swiftly to market trends.
With this feature, users can list established cryptocurrencies or emerging assets as perpetual markets on dYdX with a 10,000 USDC deposit. This deposit ensures that new markets launch with sufficient liquidity for efficient trading.
Not all markets are currently eligible for instant listing. Skip, a third-party entity elected by the dYdX community as the Market Map Updater, manages the "launchable" markets on-chain.
To ensure compatibility and stability within the dYdX ecosystem, listed markets must meet specific volume and liquidity thresholds. These criteria guarantee seamless integration and provide a stable trading environment from the outset.
Most assets from Base, Ethereum, Solana, and centralized exchanges (CEXs) are supported, covering many of your favorite markets. The dYdX market mapper is actively working to expand this list, aiming to allow virtually any asset to be listed, including perpetual prediction markets.
Head to https://dydx.trade/
Type the name of the market into the search bar. If the market is supported it will appear showing a "launchable" label next to it.
Click on the launchable market and then on the "Preview Launch" button in the bottom right.
Deposit 10,000 USDC into your connected wallet to provide the required liquidity, then click "Deposit and Launch." Your deposit will be locked for 30 days to support liquidity in the new market, providing the necessary orderbook depth to facilitate seamless trading. After the lock-up period, you are free to withdraw your funds if you choose.
Once the deposit is confirmed, the MegaVault supplements your deposit, providing liquidity to the new market. Trading can begin immediately.
Congratulations! Your market is now live on dYdX and supported by MegaVault’s liquidity.
After 30 days, you can withdraw your deposit at any time.
On dYdX Chain, each market pair has a set of parameters that can be adjusted by governance, the parameters are as follows:
| Title | Definition |
|---|---|
Markets of similar risk are categorized into Liquidity Tiers based on standardized risk parameters. These tiers define the margin requirements for each market and should be determined according to the depth of the relative market's book and the market capitalization of the token.
Initial_margin_ppm = the margin fraction needed to open a position.
Maintenance_fraction_ppm = the fraction of the initial-margin that the maintenance-margin is.
Base_position_notional = the maximum position size at which the margin requirements are not increased over the default values.
Impact_notional = the impact notional amount (in quote quantums) is used to determine impact bid/ask prices and its recommended value is 500 USDC / initial margin fraction.
| id | name | initial_margin_ppm | maintenance_fraction_ppm | base_position_ notional | impact_notional | impact_notional (as is) |
|---|---|---|---|---|---|---|
An overview of the dYdX Chain Community Treasury.
The Community Treasury is a community-controlled module account on dYdX Chain. DYDX will vest to the Community Treasury on a continuous basis until August 3, 2026. Any dYdX community member satisfying the min_initial_deposit_ratio can submit a Community Spending proposal to spend DYDX in the Community Treasury.
The Community Treasury was created with the following objectives:
Fund programs and initiatives that drive the growth of dYdX.
Develop grant programs to fund community hackathons, analytics dashboards, swag, third-party tools, translations, and other projects.
Develop a best-in-class governance system and incentivize robust governance.
| Name | Address |
|---|---|
Currently, 26.1% of the total token supply of DYDX, which amounts to 261,133,225 $DYDX, is allocated to the Community Treasury. This allocation is designed to sustainably support contributor grants, community initiatives, liquidity mining, and other assorted programs.
Initially,5.0% of the token supply (50,000,000 $DYDX) was allocated to the Community Treasury, and 766,703 $DYDX vests in the community treasury each epoch. Currently, 3,787,251 $DYDX vest in the community treasury because several governance proposals resulted in a 3,020,548 $DYDX increase in the amount of $DYDX available to the dYdX community each epoch:
DIP 14 - set the rewards for staking USDC to 0 (383,562 $DYDX per epoch),
DIP 16 - reduce trading rewards by 25% (958,904 $DYDX per epoch),
DIP 17 - set the rewards for staking $DYDX to 0 (383,562 $DYDX per epoch),
DIP 20 - further reduce trading rewards by 45% (1,294,520 $DYDX per epoch), and
DIP 24 - reduce Liquidity Provider Rewards by 50% (575,342 $DYDX per epoch).
DIP 29 - reduce Liquidity Provider Rewards by ⅓ from Epoch 30-32 on dYdX v3 to the following values:
Epoch 30: 383,562 $DYDX
Epoch 31: 191,781 $DYDX
Epoch 32: 0 $DYDX
After Epoch 31, there will not be any Liquidity Provider Rewards on dYdX v3. In DIP 29, the dYdX community voted to reduce Trading Rewards by ⅓ from Epoch 30-32 on dYdX v3, however the remaining allocation of Trading Rewards was migrated to the dYdX Chain for Trading Rewards.
In DIP 29 on dYdX v3, the dYdX community also voted to migrate 40,703,630 vested $DYDX from the Rewards Treasury and 39,788,640 vested $DYDX from the Community Treasury to the dYdX Chain Community Treasury. In addition to the 80,492,270 DYDX from the dYdX v3 Rewards Treasury and Community Treasury, DYDX vests every second from the community_vester to the community_treasury.
In DIP 2 on the dYdX Chain, the dYdX community voted to credit the dYdX Community Vester with 172,762,268.210688518 unvested DYDX tokens based on the balance of the dYdX v3 Community Treasury Vester and the dYdX v3 Rewards Treasury Vester, less the DYDX that was sent to the dYdX Chain Rewards Vester for Trading Rewards.
The insurance fund (`dydx1c7ptc87hkd54e3r7zjy92q29xkq7t79w64slrq`) is the first backstop to maintain the solvency of the system when an account has a negative balance. The account will be liquidated, and the insurance fund will take on the loss when it occurs. This insurance fund will be used before any deleveraging occurs.
The current size of the insurance fund can be viewed here.
If the insurance fund is depleted, positions with the highest profit and leverage may be used to offset negative-balance accounts, ensuring system stability. This process, known as deleveraging, is a last-resort feature in perpetual contracts.
It works similarly to "auto-deleveraging" in other markets, requiring profitable traders to contribute profits to offset underwater accounts. Deleveraging is used only when the insurance fund is depleted and prioritizes high-profit, high-leverage accounts. This approach reduces uncertainty for traders at lower risk levels compared to a socialized loss mechanism. The most highly leveraged offsetting accounts are deleveraged first.
Assume an initial margin requirement of 10% and a maintenance margin requirement of 7.5%.
Trader A deposits 1000 USDC, then opens a long position of 1 BTC at a price of 2000 USDC. Their account balance is -1000 USDC, +1 BTC. During a period of intense and prolonged volatility, the index price reaches 1080 USDC. Trader A is in a risky position, but not yet liquidatable. The price then rapidly drops further, and before A can be liquidated, the index price reaches 900 USDC, making the nominal value of A’s account -100 USDC.
The insurance fund is already depleted due to recent price swings, so deleveraging kicks in. Trader B, whose current balance is 10000 USDC, -9 BTC, is selected as the counterparty, on the basis of B’s profit and leverage, and the fact that B’s short position can offset A’s long position.
Trader B receives A’s entire balance, leaving A with zero balance, and bringing B’s total balance to 9000 USDC, -8 BTC. Trader B’s nominal loss due to deleveraging is 100 USDC, at an index price of 900 USDC. Trader B’s margin percentage increased (and leverage decreased) as a result of deleveraging, from 23.46% to 25%.
When accounts fall below the maintenance margin requirement, the liquidation engine can automatically close their positions at the specified liquidation price. The insurance fund absorbs any profits or losses resulting from these liquidations.
An overview of Trading Rewards and the Rewards Module.
Trading Rewards will be distributed to users who trade on dYdX Chain based on the Trading Rewards formula. The objective of Trading Rewards is to (1) incentivize all traders to use the dYdX Chain and (2) accelerate market liquidity and overall product usage.
| Title | Value | Definition |
|---|---|---|
| Module | Name | Address |
|---|---|---|
The characteristics of the dYdX Chain Trading Rewards are as follows:
self-trading should not be profitable,
any distributed rewards should be proportional to fees paid to the protocol,
trading rewards should be deterministic,
trading rewards should be settled and distributed every block,
trading rewards should limit the protocol overspending on trading activity.
DYDX will be distributed to traders on the dYdX Chain using the formula below. DYDX from Trading Rewards will be sent directly to a given user’s account after each order fill (which takes place at the end of a given block). Users can earn trading rewards up to, but not exceeding, 100% of a fill’s net trading fees. As such, Trading Rewards distributed by the protocol, each block, are capped at the dollar equivalent of the total net trading fees generated by the protocol that block.
The calculation of the trader scores (S) incorporates the following elements:
The sum of all traders’ rewards scores at a given block (“S”) is essentially the amount of total fees paid accounting for maker rebates and fees.
In the event there is a remaining amount of DYDX in the Rewards Treasury (T-A), such DYDX will remain in the Rewards Treasury and be distributed to traders in a proceeding block.
DYDX vests every second from the Rewards Treasury Vester to the Rewards Treasury. At the end of a given block vested DYDX (Trading Rewards) will be automatically distributed to a trader’s dYdX Chain account.
In DIP 2 on the dYdX Chain, the dYdX community voted to credit the dYdX Chain Rewards Vester with 54,077,073 unvested DYDX tokens based on the remaining allocation for Trading Rewards from DIP 29 on dYdX v3.
This all-in-one dashboard contains important metrics of dYdX Chain, all information are downloadable in .csv format.
This block explorer provides information on individual transactions as well as overall chain metrics on dYdX Chain.
This dashboard contains important trading and risk assessment metrics on dYdX Chain. It also features a dynamic leaderboard that offers real-time tracking and visibility into traders' points, providing transparency and clarity regarding their positions in the Launch Incentives Program.
This dashboard provides complete validator and chain performance metrics on dYdX Chain.
This dashboard contains real-time validator status and simplified information on validator performance on dYdX Chain.
The Indexer is a read-only collection of services that indexes and serves blockchain data to end users more efficiently and web2-friendly. It consumes real-time data from a dYdX Chain full node, stores it in a database, and serves that data through a web socket and REST requests to end users.
List of relevant links and data sources for the dYdX Chain Open-Source Software can be found here:
- release of the completed, audited and open-sourced dYdX Chain software.
- Validator and indexer code, protobuf definitions, scripts to generate Python and Javascript libraries using Telescope
- Shared client business logic used across both web and mobile
- The web front end for the dYdX Chain
- Python and Javascript SDK clients
- Translations for all copy across the web and mobile apps
- dYdX Chain documentation
- Coordination repos for previous testnets
- Terraform for indexer deployments, metrics ingestor, indexer dashboards and monitors
| Term | Definition |
|---|---|
Title
Value
Definition
6000000 [6%]
Used for clamping 8-hour Funding Rates according to the equation: funding_rate_clamp_factor * (initial margin - maintenance margin).
60000000 [60%]
Used for clamping 8-hour Premium Votes according to the equation: premium_vote_clamp_factor * (initial margin - maintenance margin).
15
Minimum number of premium votes per premium sample.
Name
Next Tick
Duration
(seconds)
Current Epoch
Current Epoch Start Block
Is Initialized
Fast Forward Next Tick
30
60
0
0
False
True
0
3600
0
0
False
True
0
3600
0
0
False
True
sequentially-generated value
human-readable name of the market pair
exponent of the price.
e.g. if Exponent == -5 then a Value of 1,000,000,000 represents $10,000. Therefore 10 ^ Exponent represents the smallest price step (in dollars) that can be recorded.
the minimum number of exchanges that should be reporting a live price for a price update to be considered valid.
the minimum allowable change in price value that would cause a price update on the network. Measured as 1e-6 (parts per million).
A string of json that encodes the configuration for resolving the price of this market on various exchanges, otherwise also known as “oracle”.
On dYdX Chain, oracles are used for the following:
Ensuring that each account is well-collateralized after each trade,
Determining when an account should be liquidated.
0
20000 [0.02]
600000 [0.6]
1000000000000 [1,000,000 USDC]
500 USDC / IM
10000000000 [10,000 USDC]
1
100000 [0.1]
500000 [0.5]
250000000000 [250,000 USDC]
500 USDC / IM
5000000000 [5,000 USDC]
2
200000 [0.2]
500000 [0.5]
100000000000 [100,000 USDC]
2,500 USDC / IM
2500000000 [2,500 USDC]
3
1000000 [1]
200000 [0.02]
1000000000 [1,000 USDC]
2,500 USDC / IM
2500000000 [2,500 USDC]
4
Isolated
50000 [0.05]
600000 [0.6]
0
2,500 USDC / IM
2500000000 [2,500 USDC]
5
Mid-Cap
50000 [0.05]
600000 [0.6]
0
500 USDC / IM
5000000000 [5,000 USDC]
6
FX
10000 [0.01]
500000 [0.5]
500000000000 [500,000 USDC]
2,500 USDC / IM
2500000000 [2,500 USDC]
Title
Value
Definition
8192
~ 3 hours 11 minutes
(assuming 1.4s block time)
The window in terms of the number of blocks for which a validator's signing activity is monitored.
0.2
The minimum of blocks in the signed_blocks_window that a validator must sign to avoid being jailed.
7200s
2 hours
The length of time a validator is temporarily removed from the Active Set.
0.0
The fraction of a validator's staked tokens that will be slashed in the event of a double signing violation.
0.0
The fraction a validator will be slashed by if they miss a fraction (min_signed_per_window) of blocks within a sliding window (signed_blocks_window).
community_treasury
dydx15ztc7xy42tn2ukkc0qjthkucw9ac63pgp70urn
community_vester
dydx1wxje320an3karyc6mjw4zghs300dmrjkwn7xtk
Field name
Description
The account to vest tokens from
The account to vest tokens to
The token that is vested
The start time of vesting
The end time of vesting
Value
community_vester
community_treasury
adydx
2021-08-03T15:00:00Z
2026-08-03T15:00:00Z
Account
dydx1wxje320an3karyc6mjw4zghs300dmrjkwn7xtk
dydx15ztc7xy42tn2ukkc0qjthkucw9ac63pgp70urn
Title
Value
Definition
15000 [0.015%]
When an account is liquidated, up to the entire value of the account may be taken as penalty and transferred to the Insurance Fund. The liquidation engine will attempt to leave funds in accounts of positive value where possible after they have paid the maximum liquidation fee.
Contains the following parameter values:
The minimum (in notional value) and maximum (in parts per million) amount of how much a single position can be liquidated within one block.
1000000000
100000 [0.1%]
Contains the following parameter values:
The maximum amount of how much a single subaccount can be liquidated within a single block in notional value.
100000000000
1000000000000
The maximum number of quote quantums (exclusive) that the Insurance Fund can have for deleverages to be enabled.
Contains the following parameter values:
Configuration regarding how the fillable-price spread from the oracle price increases based on the adjusted bankruptcy rating of the subaccount.
1000000 [1%]
1500000 [1.5%]
rewards_treasury
The account which Trading Rewards are funded from
adydx
The token that Trading Rewards are funded in
-18
The decimals of the Trading Rewards token
1000001
The market which tracks the oracle price of the token that Trading Rewards are funded in
0.50
The protocol constant “ C” for the Trading Rewards
x/rewards
`rewards_treasury`
dydx16wrau2x4tsg033xfrrdpae6kxfn9kyuerr5jjp
x/rewards
`rewards_vester`
dydx1ltyc6y4skclzafvpznpt2qjwmfwgsndp458rmp
Field Name
Description
The account to vest tokens from
The account to vest tokens to
The token that is vested
The start time of vesting
The end time of vesting
Value
rewards_vester
rewards_treasury
adydx
2021-08-03T15:00:00Z
2026-08-03T15:00:00Z
Account
dydx1ltyc6y4skclzafvpznpt2qjwmfwgsndp458rmp
dydx16wrau2x4tsg033xfrrdpae6kxfn9kyuerr5jjp
A
Amount of tokens distributed from T in a given block.
C
Constant value ranging from 0 to 1.
T
The size of the Rewards Treasury pool, which fluctuates according to protocol activity and contains vested DYDX tokens.
p
Price of DYDX
S
Sum of all trader’s scores
Title | Definitions |
| ID of the orderbook that stores all resting liquidity for this CLOB. |
| Status of the CLOB, which could be any of the following:
|
| Product-specific metadata. |
| Minimum increment in the size of orders on the CLOB, in base quantums. |
| This parameter defines the tick size of the orderbook by defining how many subticks are in one tick, i.e. the subticks of any valid order must be a multiple of this value. |
|
|
.ico)