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.

Current Allocations

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:

  • 5.0% (50,309,197 $DYDX) to past users who complete certain trading milestones on the dYdX Layer 2 Protocol (Retroactive Mining Rewards),
• 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.

Initial Allocations and Changes

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:

  • • • Epoch 30: 1,054,795 $DYDX

      • Epoch 31: 527,398 $DYDX

      • Epoch 32: 0 $DYDX

  • • After Epoch 0, 24,690,803 unclaimed $DYDX from the Retroactive Mining rewards program were transferred to the Community Treasury.

  • • • Epoch 30: 383,562 $DYDX

      • Epoch 31: 191,781 $DYDX

      • Epoch 32: 0 $DYDX
• 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.

Liquid Supply Curve of $DYDX

On September 8, 2021, the initial transfer restrictions on the DYDX token were lifted.

The following chart shows the total liquid supply of DYDX over time:

FAQs

 i. Trading: 1,054,795

 ii. LP: 383,562

 i.Trading: 527,398

 ii.LP: 191,781

 i.Trading: 0

 ii.LP: 0

dYdX Chain

Start Here

dYdX Unlimited

DYDX, the dYdX Chain's L1 token, serves three key purposes: Staking, Security, and Governance.

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

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

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

Overview

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.

Summary

Key Concepts and Definitions

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

Parameters

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

Staking to a dYdX Chain Validator

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.

Unbonding delegations / Unstaking

Redelegation

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.

Overview

The distribution module enables a simple collection and distribution mechanism to passively distribute rewards between validators and delegators.

Summary

Key Concepts and Definitions

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

Parameters

The dYdX Community may adjust these parameters with an on-chain governance proposal.

Staking Rewards

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.

How rewards are distributed on dYdX Chain

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.

How staking rewards are calculated

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

Overview

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.

• 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.\

Proposal Stages

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.

Summary

0. Forum Discussion

1. (Off-chain) DRC Creation

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.

The DRC should cover all the information of the potential final DIP.

2. (Off-chain) DRC Discussion and Feedback

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.

3. (Off-chain) DIP Creation

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.

1. Text Proposals: the file should contain a title, description, and deposit (in aDYDX units).

2. Community Spending Proposals: the file should contain the title, description, recipient, number of tokens, and deposit (in aDYDX units).

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

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

4. (On-chain) Submitting a Proposal

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.

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

2. --~/upgrade_plan.json indicates the file containing the proposal information.

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

4. --chain-id dydx-mainnet-1 is dYdX Chain.

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

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

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.

5. (On-chain) Proposal Deposits

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.

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

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

6. (On-chain) DIP Voting

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.

7. (On-chain) Proposal Tallying and Execution

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.

Spam Mitigation

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

Block rate limit defines the block rate limits for CLOB specific operations.

Equity Tier Limit

Equity tier limit defines the set of equity tiers to limit how many open orders a subaccount is allowed to have.

Updating a Live Market

This functionality allows the community to update parameters of a live market, which can be composed of 5 parts:

Liquidity Tiers

Liquidity Tier is updatable through MsgSetLiquidityTier.

Market

The Prices module (x/prices) is updatable through MsgUpdateMarketParam.

Perpetual

The Perpetual module (x/perpetuals) is updatable through MsgUpdatePerpetual.

Clob

The Clob module (x/clob) is updatable through MsgUpdateClobPair.

Market Margin

Isolated-margin markets can be upgraded to cross-margin through UpgradeIsolatedPerpetualToCross.

Funding Rate

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.

Epoch Information

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.

Clob Pair

Insurance Fund

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.

Deleveraging

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.

Liquidations Config

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.

Liquidity Tiers

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.

Market Types

There are two market types on dYdX:

1. Cross Margin: Cross-margined markets share the same collateral pool and insurance fund, contributing to the overall risk properties across the entire protocol.

2. Isolated Margin: Isolated markets have segregated pools of collateral and their own insurance fund. Each isolated market, then, has its own individual risk properties. This enables a protocol to more safely support a much greater range of market types.

• At least two oracle sources with > $1M USD in trading volume each.

• At least two oracle sources with > $150K depth within 2% of the mid-price.

• A minimum of four total oracle sources.

• Availability of at least 30 days of historical data.

The following are Instant Market Listings Deposit parameters (ListingVaultDepositParams) adjustable by dYdX governance:

List of relevant links and data sources for the dYdX Chain Open-Source Software can be found here:

Overview

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.

Summary

• Signing Info

• Liveness Tracking

• Messages

• Social Slashing

Key Concepts and Definitions

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

Parameters

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

Signing Info

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.

Liveness Tracking

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.

Messages

• Unjail

Should a validator want to return and potentially rejoin the Active Set after being removed due to Downtime, they must send a MsgUnjail.

Social Slashing

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.

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.

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 by adding 10,000 USDC to the new asset's sub-vault. These funds ensure that new markets launch with sufficient liquidity for efficient trading.

Launchable Markets on dYdX

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.

How to List a New Market on dYdX

1. Navigate to dYdX

2. Select a Market‍

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.

3. Begin Market Launch‍

Click on the launchable market and then on the "Preview Launch" button in the bottom right.

4. Add Funds for Liquidity

Add 10,000 USDC into your connected wallet to provide the required liquidity, then click "Deposit and Launch." Your funds will be locked for an estimated 30 days to support liquidity in the new market, providing the necessary orderbook depth to facilitate seamless trading. After the lock-up period, you can remove your funds if you choose.

5. Automatic Liquidity Activation‍

6. Your Market is Live‍

7. Remove Your Funds Anytime‍

After an estimated 30 days, you can remove your funds at any time.

FAQ

The program currently features a lifetime commission model, meaning affiliates continue to earn as long as their referred users keep trading on dYdX. Additionally, commissions are paid out instantly and automatically on-chain in USDC, ensuring real-time transparency and quick access to earnings without any delays.

To safeguard the protocol against fraudulent activity, users must generate at least $10,000 in trading volume before gaining access to their unique affiliate link on dYdX.

Affiliate Tiers

The dYdX Affiliate Program is divided into two tiers:

1. Standard affiliates can earn up to 15% of the taker fees from their referrals, with potential earnings of up to 3,000 USDC per referral within a 30-day period.

2. VIP affiliates can earn up to 50% of referred user taker fees, with a maximum of $10,000 per referral per 30-day rolling period.

VIP Affiliate Program

How to become a dYdX Standard Affiliate

1. Unlock affiliate access: In order to unlock your affiliate link, you need to have generated at least $10,000 in trading volume on dYdX. This can be done with or without leverage. For example, opening a 1000 USDC position with 5x leverage, and then closing it would suffice.

3. Spread the word: Share your affiliate link with your friends and across social media.

4. Monitor Your Performance: Use the affiliate dashboard to track your referrals, trading volumes, and earned commissions. This transparency allows you to optimize your strategies and maximize your rewards.

This documentation is divided into the following subsections:

Fee Tiers Module

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.

The dYdX Operations SubDAO ("DOS") was established to operate and enhance the infrastructure for dYdX Chain, prioritizing reliability, scalability, and community engagement.

The dYdX Ecosystem Development Program ("DEP" fka "dYdX Grants Program") was established to source partnerships and provide funding for third parties that help support dYdX's infrastructure, services, protocol development, and growth.

dYdX Chain Open-source Code

Milestones

Deep Dives

MEV

Lenses by Numia

This all-in-one dashboard contains important metrics of dYdX Chain, all information are downloadable in .csv format.

Mintscan by Cosmostation

This block explorer provides information on individual transactions as well as overall chain metrics on dYdX Chain.

dYdX Chain Risk Monitoring Portal by Chaos Labs

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.

Observatory by Rockaway Labs

This dashboard provides complete validator and chain performance metrics on dYdX Chain.

Validator Info by Allnodes

This dashboard contains real-time validator status and simplified information on validator performance on dYdX Chain.

dYdX Chain Indexer

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.

Overview

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.

Module Accounts

Vest Module

Community Treasury

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.

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

Community Vester

FAQ

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.

MegaVault is a user-facing feature that enables dYdX users to add USDC to provide liquidity to various markets, and earn yield in return. By aggregating liquidity from users, MegaVault ensures that every market maintains the necessary liquidity for smooth and efficient trading.

Vault Mechanics

At a technical level, MegaVault will operate multiple “sub-vaults.” A sub-vault uses users' USDC to run an automated market-making strategy for a given market. Users' USDC is allocated to these sub-vaults, and the yield they generate is aggregated and distributed to users who added USDC to MegaVault.

Adding and Removing Funds

Users can add funds into MegaVault at any time and start earning yield immediately. At a high level, users can think of adding funds as owning a percentage of the vault’s net equity (i.e., the vault’s USDC and position values).

Operator

For MegaVault to work effectively, it requires a dedicated operator to configure and optimize settings across all sub-vaults continuously. This includes spread parameters, skew factors, and liquidity allocation weights determining how capital is deployed across markets. The operator must monitor market and vault activity and maintain these settings in real-time to ensure optimal market efficiency while protecting vault depositor returns.

How to Add USDC into MegaVault

1. Visit dYdX

2. Connect Your Wallet

3. Select USDC Amount

Enter the amount of USDC you wish to add to MegaVault. Choose an amount that aligns with your investment strategy and risk tolerance.

4. Approve and Confirm the Transaction

Approve the transaction through your wallet by signing and confirming it. Ensure you have enough funds to cover the gas fees associated with the deposit.

5. USDC is added into MegaVault

Once approved, your USDC will be added to MegaVault and start earning yield immediately.

6. Generate Passive Income

8. Remove USDC Anytime

FAQ

(30 day PnL/current TVL) * (365/30) 

(total PnL/current TVL) * (365/number of days for which data was available) 

current PnL of MegaVault - previous PnL of MegaVault at the beginning of the 30 period  

the sum of all USDC held by MegaVault + current value of all positions held by MegaVault 

size of position * oracle price 

current PnL of MegaVault - previous PnL of MegaVault at the beginning of the period 

Overview

Trading Rewards are 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.

Parameters

Module Accounts

Vest Module

Rewards Vester

Rewards Treasury

Trading Rewards Formula

FAQ