Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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
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.
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.
Name
Next Tick
Duration
(seconds)
Current Epoch
Current Epoch Start Block
Is Initialized
Fast Forward Next Tick
30
60
0
0
False
True
0
3600
0
0
False
True
0
3600
0
0
False
True
The following strategies that can be updated by governance exist to prevent spam on the orderbook and prevent the blockchain state from getting too large:
Block rate limit defines the block rate limits for CLOB specific operations.
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.
4
20000000
8
100000000
10
1000000000
100
10000000000
1000
100000000000
0
0
how many open stateful orders are allowed per equity tier.
4
20000000
8
100000000
10
1000000000
100
10000000000
200
100000000000
An overview of parameters that are not covered in other sections of the governance documentation and are adjustable through a dYdX Chain governance Parameter Change Proposals.
This documentation is divided into the following subsections:
Trading Stats: this section covers the trading statistics look-back window.
Fee Tiers: this section covers the tiers of fees and discounts for each trader on dYdX Chain, based on their taker and maker volume.
Trading Core: this section covers the core aspects of trading, namely insurance fund and liquidations config. The insurance fund acts as the first backstop to maintain systemic solvency when an account has a negative balance. The liquidations config defines the mechanism to close an account’s position when it falls below the margin requirements.
Markets: this section covers the Prices module (x/prices) parameters on dYdX Chain as well as the liquidity tier of each market based on standardized risk parameters.
Perpetual: this section covers the Perpetual module (x/perpetuals) parameters on dYdX Chain, such as funding rate and epoch information. The perpetual funding rate enables the perpetual price to align with the underlying asset's price. Epoch information is a fixed interval where funding is credited or debited to each account.
Clob: this section covers the Clob module (x/clob) that configures the order creation, placement, and cancellations on dYdX Chain.
Updating A Live Market: this section explains the message required to update a live market on dYdX Chain.
Safety: this section explains the safety parameters on dYdX Chain, namely the spam mitigation that is related to order creation and cancellation using the Clob module.
On dYdX Chain, each market pair has a set of parameters that can be adjusted by governance, the parameters are as follows:
sequentially-generated value
human-readable name of the market pair
exponent of the price.
e.g. if Exponent == -5
then a Value
of 1,000,000,000
represents $10,000
. Therefore 10 ^ Exponent
represents the smallest price step (in dollars) that can be recorded.
the minimum number of exchanges that should be reporting a live price for a price update to be considered valid.
the minimum allowable change in price
value that would cause a price update on the network. Measured as 1e-6
(parts per million).
A string of json that encodes the configuration for resolving the price of this market on various exchanges, otherwise also known as “oracle”.
On dYdX Chain, oracles are used for the following:
Ensuring that each account is well-collateralized after each trade,
Determining when an account should be liquidated.
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]
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]
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.
2592000s
30 days
The desired number of seconds in the look-back window.
Clob pair represents a Perpetual, Spot or a given product in the state. Each clob pair has the following parameters:
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.
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.
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.
The insurance fund (`dydx1c7ptc87hkd54e3r7zjy92q29xkq7t79w64slrq`) is the first backstop to maintain the solvency of the system when an account has a negative balance. The account will be liquidated, and the insurance fund will take on the loss when it occurs. This insurance fund will be used before any deleveraging occurs.
The current size of the insurance fund can be viewed here.
If the insurance fund is depleted, positions with the highest profit and leverage may be used to offset negative-balance accounts, ensuring system stability. This process, known as deleveraging, is a last-resort feature in perpetual contracts.
It works similarly to "auto-deleveraging" in other markets, requiring profitable traders to contribute profits to offset underwater accounts. Deleveraging is used only when the insurance fund is depleted and prioritizes high-profit, high-leverage accounts. This approach reduces uncertainty for traders at lower risk levels compared to a socialized loss mechanism. The most highly leveraged offsetting accounts are deleveraged first.
Assume an initial margin requirement of 10% and a maintenance margin requirement of 7.5%.
Trader A deposits 1000 USDC, then opens a long position of 1 BTC at a price of 2000 USDC. Their account balance is -1000 USDC, +1 BTC. During a period of intense and prolonged volatility, the index price reaches 1080 USDC. Trader A is in a risky position, but not yet liquidatable. The price then rapidly drops further, and before A can be liquidated, the index price reaches 900 USDC, making the nominal value of A’s account -100 USDC.
The insurance fund is already depleted due to recent price swings, so deleveraging kicks in. Trader B, whose current balance is 10000 USDC, -9 BTC, is selected as the counterparty, on the basis of B’s profit and leverage, and the fact that B’s short position can offset A’s long position.
Trader B receives A’s entire balance, leaving A with zero balance, and bringing B’s total balance to 9000 USDC, -8 BTC. Trader B’s nominal loss due to deleveraging is 100 USDC, at an index price of 900 USDC. Trader B’s margin percentage increased (and leverage decreased) as a result of deleveraging, from 23.46% to 25%.
When accounts fall below the maintenance margin requirement, the liquidation engine can automatically close their positions at the specified liquidation price. The insurance fund absorbs any profits or losses resulting from these liquidations.
Title
Value
Definition
15000 [0.015%]
When an account is liquidated, up to the entire value of the account may be taken as penalty and transferred to the Insurance Fund. The liquidation engine will attempt to leave funds in accounts of positive value where possible after they have paid the maximum liquidation fee.
Contains the following parameter values:
The minimum (in notional value) and maximum (in parts per million) amount of how much a single position can be liquidated within one block.
1000000000
100000 [0.1%]
Contains the following parameter values:
The maximum amount of how much a single subaccount can be liquidated within a single block in notional value.
100000000000
1000000000000
The maximum number of quote quantums (exclusive) that the Insurance Fund can have for deleverages to be enabled.
Contains the following parameter values:
Configuration regarding how the fillable-price spread from the oracle price increases based on the adjusted bankruptcy rating of the subaccount.
1000000 [1%]
1500000 [1.5%]
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.
The fee tier structure has the following characteristics:
different fees for either maker or taker,
fee discounts based on each user’s 30 days trading volume across sub accounts and markets, and
uniform fee structure across all markets.
This fee tier was at block height 6,912,000.
Tier
Absolute_volume_requirement
[30 day Trailing Volume]
Total_volume_share_requirement_ppm
[Exchange Market Share]
Maker_volume_share_requirement_ppm
[Maker Market Share]
maker_fee_ppm
[Maker Fee (bps)]
Taker_fee_ppm
[Taker Fee (bps)]
0 [< $1M]
0 [-]
0 [-]
100 [1.0]
500 [5.0]
1000000000000 [≥ $1M]
0 [-]
0 [-]
100 [1.0]
450 [4.5]
5000000000000 [≥ $5M]
0 [-]
0 [-]
50 [0.5]
400 [4.0]
25000000000000 [≥ $25M]
0 [-]
0 [-]
0 [-]
350 [3.5]
125000000000000 [≥ $125M]
0 [-]
0 [-]
0 [-]
300 [3.0]
125000000000000 [≥ $125M]
5000 [≥ 0.5%]
0 [-]
-50 [-0.5]
250 [2.5]
125000000000000 [≥ $125M]
5000 [≥ 0.5%]
10000 [≥ 1%]
-70 [-0.7]
250 [2.5]
125000000000000 [≥ $125M]
5000 [≥ 0.5%]
20000 [≥ 2%]
-90 [-0.9]
250 [2.5]
125000000000000 [≥ $125M]
5000 [≥ 0.5%]
40000 [≥ 4%]
-110 [-1.1]
250 [2.5]
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
.
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]
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.