Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
List of relevant links and data sources for the dYdX Chain Open-Source Software can be found here:
Welcome to the community documentation for dYdX!
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.
Order Router Rev Share enables third-party order routers to direct orders to dYdX and earn a portion of the trading fees (maker and taker).
For detailed technical specifications, including integration steps, see .
To enable an Order Router Rev Share, the interested party must submit a governance proposal and obtain approval from the dYdX community. The steps are generally in line with the .
The current on dYdX Chain was developed to stimulate liquidity, incentivize traders with substantial volume and contribute to the platform's overall growth and competitiveness.
To update the fee tiers, a parameter change proposal can be submitted by dYdX community with MsgUpdatePerpetualFeeParams.
The fee tier structure has the following characteristics:
DYDX is the dYdX Chain's Layer 1 token, as adopted by the dYdX community, through dYdX governance ( and ).
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.
is designed to provide clear and attractive incentives for affiliates. Affiliates can earn commissions based on the taker fees generated by the users they refer to the protocol.
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.
The dYdX Affiliate Program is divided into two tiers:
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:
: this section covers the trading statistics look-back window.
: this section covers the tiers of fees and discounts for each trader on dYdX Chain, based on their taker and maker volume.
: 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.
An overview of Trading Rewards and the Rewards Module.
The dYdX community has on simplifying rewards on dYdX by removing protocol-level trading rewards. All rewards are now consolidated under the , eliminating redundant rewards mechanisms and improving clarity for all users.
fee discounts based on each user’s 30 days trading volume across sub accounts and markets, and
uniform fee structure across all markets.
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.
Markets: this section covers the Prices module (x/prices) parameters on dYdX Chain as well as the liquidity tier of each market based on standardized risk parameters.
Perpetual: this section covers the Perpetual module (x/perpetuals) parameters on dYdX Chain, such as funding rate and epoch information. The perpetual funding rate enables the perpetual price to align with the underlying asset's price. Epoch information is a fixed interval where funding is credited or debited to each account.
Clob: this section covers the Clob module (x/clob) that configures the order creation, placement, and cancellations on dYdX Chain.
Updating A Live Market: this section explains the message required to update a live market on dYdX Chain.
Safety: this section explains the safety parameters on dYdX Chain, namely the spam mitigation that is related to order creation and cancellation using the Clob module.
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.
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.
The dYdX Grants Program onboarded CryptoLearningClub to manage the VIP Affiliate Program. Their responsibility includes regularly submitting an on-chain proposal to whitelist new and/or remove underperforming VIP affiliates.
If you're interested in becoming a VIP Affiliate, you can apply here. The VIP Affiliate tier is generally reserved for those with a track record of successful referrals in other crypto affiliate programs, a large social media following of at least 30,000 genuine followers, and a notable social influence. Professional market makers or trading firms are not eligible to apply as a VIP affiliate.
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.
Copy your affiliate link: Next, head over to the Affiliate page, click on “Invite Friends” and copy your unique affiliate link.
Spread the word: Share your affiliate link with your friends and across social media.
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.
Below is the example JSON for the Order Router Rev Share:
{
"messages": [
{
"@type": "/dydxprotocol.revshare.MsgSetOrderRouterRevShare",
"authority": "dydx10d07y265gmmuvt4z0w9aw880jnsr700jnmapky",
"order_router_rev_share": {
"address": "{Insert}", // insert dYdX Chain address where the revenue is going to be routed to
"share_ppm": 500000
}
}
],
"deposit": "2000000000000000000000adydx",
"metadata": "",
"title": "Add order router rev share for {Insert}", // insert your project's name
"summary": "Add order router rev share for {Insert}" // insert your project's name
}perpetual_clob_metadata
Product-specific metadata.
step_base_quantums
Minimum increment in the size of orders on the CLOB, in base quantums.
subticks_per_tick
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.
quantum_conversion_exponent
10^Exponent gives the number of QuoteQuantums traded per BaseQuantum per Subtick.
Title
Definitions
id
ID of the orderbook that stores all resting liquidity for this CLOB.
status
Status of the CLOB, which could be any of the following:
STATUS_UNSPECIFIED: Default value. This value is invalid and unused.
STATUS_ACTIVE: this represents an active clob pair.
STATUS_PAUSED: this represents a clob pair that is paused until further notice.
Instant Market Listings allow users to list a perpetual market on dYdX immediately, without governance or third-party approvals. Funds are locked in a sub-vault to ensure initial market liquidity.
The following are Instant Market Listings Deposit parameters (ListingVaultDepositParams) adjustable by dYdX governance:
Title
Value
Definitions
10000000000 [10,000 USDC]
The amount of funds that will be added to the new sub-vault.
0 [0 USDC]
STATUS_CANCEL_ONLY: clob pairs in this state only accept cancellations.
STATUS_POST_ONLY: clob pairs in this state only accept orders which are post-only.
STATUS_INITIALIZING: this represents a newly-added clob pair. Clob pairs in this state only accept orders which are both short-term and post-only.
The amount of funds that will be added to the main vault (MegaVault).
30 * 24 * 3600 [2,592,000 blocks or approximately 30 days based on 1 second block time]
The number of blocks for how long the funds will be locked or cannot be removed from the sub-vault.
2592000s
30 days
The desired number of seconds in the look-back window.
Information about the fees on dYdX is available here.
This functionality allows the community to update parameters of a live market, which can be composed of 5 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.
Isolated-margin markets can be upgraded to cross-margin through UpgradeIsolatedPerpetualToCross.
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.
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 is a simple mechanism to allocate rewards earned by Validators and Stakers. For a detailed understanding of the Cosmos rewards mechanism, read .
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.
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.
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.
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.
Title
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.
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.
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
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.
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.
Once the funds are added, the supplements your funds, providing liquidity to the new market. Trading can begin immediately.
Congratulations! Your market is now live on and supported by liquidity.
After an estimated 30 days, you can remove your funds at any time.
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.
The dYdX Operations SubDAO ("DOS") was established to operate and enhance the infrastructure for dYdX Chain, prioritizing reliability, scalability, and community engagement.
More information about DOS can be found .
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.
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.
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.
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%.
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%]
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%]
should be fast-forwarded to be greater than the current block time.
0
0
False
True
0
3600
0
0
False
True
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
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.
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.
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.
Validators operating a node on the dYdX Chain may choose to wind down their operations at any time. The recommended best practices for doing so are as follows:
Announce on the dYdX Forum
Create a post to notify the dYdX community about your intent to wind down, particularly your delegators.
Provide Advance Notice
Allow at least 21–30 days before fully winding down to give delegators sufficient time to undelegate their stake.
Notify the dYdX Operations SubDAO
Inform the dYdX Operations SubDAO team so they can remove your node from the Signotifier, Metrics Ingestor, and internal monitoring tools (e.g., Slack alerts).
Update Your Validator Moniker
Consider updating your validator name to reflect that you are winding down. This has proven to be an effective way to prompt stakers to take action.
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.
Equity tier limit defines the set of equity tiers to limit how many open orders a subaccount is allowed to have.
Title
limit
usd_tnc_required
Definition
0
0
how many open short term orders are allowed per equity tier.
10
20000000
20
100000000
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.
: When a validator is permanently removed from the Active Set due to a double signing infraction. More information about Staking Tombstone is available .
More information about the slashing module is available here.
These parameters may be adjusted by the dYdX Community with an on-chain governance proposal.
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.
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.
An overview of the dYdX Chain Community Treasury.
The 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 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.
dYdX Grants Ltd. (“dYdX Grants”), a wholly-owned subsidiary of the dYdX Foundation, was established to source partnerships and provide funding for third parties that help support dYdX's infrastructure, services, protocol development, and growth.
More information on dYdX Grants can be found .
The dYdX Treasury SubDAO was established to handle key financial responsibilities for the dYdX DAO, including but not limited to, forming a Cayman Foundation and multisig for tax and legal certainty, developing a staking program to support dYdX Chain validators, diversifying assets received from the and generating returns to ensure adequate runway, and providing financial planning, funding and operational support for the dYdX DAO.
More information about the dYdX Treasury SubDAO can be found .
maxMissed = signed_blocks_window - min_signed_per_window * signed_blocks_windowmessage MsgUnjail {
string validator_addr = 1;
}50
1000000000
200
10000000000
1000
100000000000
0
0
how many open stateful orders are allowed per equity tier.
10
20000000
20
100000000
40
1000000000
100
10000000000
200
50000000000
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).
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.
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
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),
- further reduce trading rewards by 45% (1,294,520 $DYDX per epoch), and
- reduce Liquidity Provider Rewards by 50% (575,342 $DYDX per epoch).
- 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.
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.
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 ,
14.5% (144,693,506 $DYDX) based on the ,
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.
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 ,
25.0% (250,000,000 $DYDX) based on the ,
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:
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. 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 .
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).
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 , and
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.
--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 . 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:
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.
community_treasury
adydx
2021-08-03T15:00:00Z
2026-08-03T15:00:00Z
Account
dydx1wxje320an3karyc6mjw4zghs300dmrjkwn7xtk
dydx15ztc7xy42tn2ukkc0qjthkucw9ac63pgp70urn
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).
a link to the forum post,
so that prospective voters have access to the full context of the DIP.
--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
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.
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,
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.
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.
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 trading and LP rewards by ⅓ from Epoch 30-32 on dYdX v3 to the following values:
a. Reduce rewards to the following values on Nov 21, 2023, 15:00 UTC (start of Epoch 30)
b. Reduce rewards to the following values on Dec 19, 2023, 15:00 UTC (start of Epoch 31)
c. Reduce rewards to the following values on Jan 16, 2024, 15:00 UTC (start of Epoch 32)
40% in equal monthly installments from January 1, 2024, to June 1, 2024;
20% in equal monthly installments from July 1, 2024, to June 1, 2025; and
10% in equal monthly installments from July 1, 2025, to June 1, 2026.
Note that all of the above dates shall be interpreted to refer to UTC time zone.
Various founders, employees, advisors, and consultants of dYdX Trading Inc. and dYdX Foundation are also subject to the transfer restriction schedule set forth in the Amendment.
All employees and consultants also will be subject to various vesting schedules that could result in them losing their rights to $DYDX. No employee’s or consultant’s receipt of $DYDX is, or will in the future be, based on providing services related to the dYdX Protocol or other services that may benefit the Protocol. Instead, employees and consultants may receive $DYDX for services that benefit only dYdX Trading Inc., dYdX Foundation or another party.
Regardless of any lockup on $DYDX, investors and prior employees or consultants of dYdX Trading Inc. or dYdX Foundation may use $DYDX to make proposals, delegate votes, or vote on proposals related to the dYdX Protocol. Current employees and consultants of dYdX Trading Inc. or dYdX Foundation will initially not make any proposals or participate in any votes but may do so in the future. Current employees and consultants of dYdX Trading Inc. or dYdX Foundation may delegate votes without attempting to influence voting outcomes.
All investors are required to comply with the transfer restriction enforced through contractual agreements with the dYdX Foundation and dYdX Trading Inc. dYdX Foundation tracks wallet addresses to determine whether any transfers have been made in violation of that restriction.
The dYdX Foundation has expressed its willingness to bring legal action against investors who do not comply with these requirements.
{
"title": "Title",
"deposit": "2000000000000000000000adydx",
"summary": "Summary [max 255 characters]",
"messages": [
{
"@type": "/cosmos.gov.v1.MsgExecLegacyContent",
"content": {
"@type": "/cosmos.gov.v1beta1.TextProposal",
"title": "Title goes here.",
"description": "Additional summary or blank if not needed."
},
"authority": "dydx10d07y265gmmuvt4z0w9aw880jnsr700jnmapky"
}
]
}dydxprotocold tx gov submit-proposal <proposal type> \
-- <json file> \
--from <submitter address> \
--chain-id <chain id> \
--gas <max gas allocated> \
--fees <fees allocated> \
--node <node address> \dydxprotocold tx gov submit-proposal software-upgrade \
--upgrade_plan.json \
--from wallet-1 \
--chain-id dydx-mainnet-1 \
--gas 500000 \
--fees 12500ibc/8E27BA2D5493AF5636760E354E46004562C46AB7EC0CC4C1CA14E9E20E2545B5 \
--node https://rpc-dydx.imperator.co:443/ \dydxprotocold tx gov submit-proposal
~/dydx/proposal_enable_all_clob_pairs.json
--from dydx199tqg4wdlnu4qjlxchpd7seg454937hjrknju4
--dry-run
gas estimate: 837840dydxprotocold query gov proposalsdydxprotocold tx gov deposit <proposal-id> <deposit> --from <key> i. Trading: 1,054,795
ii. LP: 383,562 i.Trading: 527,398
ii.LP: 191,781 i.Trading: 0
ii.LP: 0An 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 aggregate the vote results to determine if the proposal was accepted or rejected by the dYdX community.
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 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.
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.\
dYdX Chain open source software - release of the completed, audited and open-sourced dYdX Chain software.
v4-chain - 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
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.
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.
On dYdX Chain, each has a set of parameters that can be adjusted by governance, the parameters are as follows:
Execution: If a proposal passes, the execution process depends on the type of 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.
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.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.
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).
Except in the case of Instant Market Listings, users will be able to remove funds from MegaVault at any time after adding them, though they may experience slippage based on MegaVault’s status, positions, and market conditions.
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.
On November 21, 2024, dYdX community elected Greave as MegaVault's operator, granting it the ability to update the parameters mentioned above.
1. Visit dYdX
Navigate to dydx.trade/vault to access the MegaVault page.
2. Connect Your Wallet
To interact with MegaVault, connect a compatible wallet such as MetaMask, Coinbase Wallet, OKX Wallet, Keplr, or many others.
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
With your USDC added, MegaVault begins automated market-making activities. You’ll earn a share of the profits from MegaVault’s operations and a portion of protocol revenue. Your earnings are added to your initial balance.
8. Remove USDC Anytime
MegaVault has no lock-up periods. Adding and removing USDC are instant. Visit the MegaVault page to remove your funds whenever you like.
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.
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.
0
20000 [0.02]
600000 [0.6]
1000000000000 [1,000,000 USDC]
500 USDC / IM
10000000000 [10,000 USDC]
There are two market types on dYdX:
Cross Margin: Cross-margined markets share the same collateral pool and insurance fund, contributing to the overall risk properties across the entire protocol.
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.
The following criteria are recommended to determine compatibility with cross-margining, hence allowing dYdX community to propose upgrading an isolated market to cross:
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.
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.
(30 day PnL/current TVL) * (365/30) 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]
1,000 USDC / IM
2500000000 [2,500 USDC]
3
1000000 [1]
200000 [0.02]
1000000000 [1,000 USDC]
1,000 USDC / IM
2500000000 [2,500 USDC]
4
Isolated
50000 [0.05]
600000 [0.6]
0
1,000 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]
1,000 USDC / IM
2500000000 [2,500 USDC]
7
IML 5x
200000 [0.2]
500000 [0.5]
0
1,000 USDC / IM
2500000000 [2,500 USDC]
Scenario 2 (medium leverage): MegaVault has one isolated margin sub-vault position with 1x leverage, and no balance in the main vault. The isolated margin market has an initial margin fraction of 10% and a maintenance margin fraction of 50%. The sub-vault has quoting parameters of a half-spread of 30bps and a skew of 2.
A removes $50k, A would pay a 4.9% slippage fee and receive $47,550
Subsequently, B removes $30k, B would pay a 19.06% slippage fee and receive $24,280.26
C is the final party to remove funds, C removes $20k and would pay a 35.5% slippage fee and receive $12,900.18.
Scenario 3 (high leverage): MegaVault has one isolated margin sub-vault position with 8x leverage and a balance in the main vault. The isolated margin market has an initial margin fraction of 20% and a maintenance margin fraction of 10%. The sub-vault has quoting parameters of a half-spread of 30bps and a skew of 2.
A removes $50k, A would pay a 100% slippage fee and receive $0
Subsequently, B removes $30k, B would pay a 100% slippage fee and receive $0
C is the final party to remove funds, C removes $20k and would pay a 100% slippage fee and receive $0
Pre-slippage positions
Alice: $90
Bob: $10
Pre-slippage positions
Alice: $99
Bob: $11
Pre-slippage positions
Alice: $81
Bob: $9
Carl: 10%
Pre-slippage positions
Alice: $81
Bob: $9
Carl: $10
(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
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.