Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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.
This functionality allows the community to update parameters of a live market, which can be composed of 4 parts:
Liquidity Tier is updatable through MsgSetLiquidityTier
.
The Prices module (x/prices) is updatable through MsgUpdateMarketParam
.
The Perpetual module (x/perpetuals) is updatable through MsgUpdatePerpetual
.
The Clob module (x/clob) is updatable through MsgUpdateClobPair
.
The current fee tier structure on dYdX Chain was developed to stimulate liquidity, incentivize traders with substantial volume and contribute to the platform's overall growth and competitiveness.
The fee tier structure has the following characteristics:
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 implemented at block height 6,912,000.
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 .
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.
The following strategies that can be updated by governance exist to prevent spam on the orderbook and prevent the blockchain state from getting too large:
Block rate limit defines the block rate limits for CLOB specific operations.
Equity tier limit defines the set of equity tiers to limit how many open orders a subaccount is allowed to have.
On dYdX Chain, each has a set of parameters that can be adjusted by governance, the parameters are as follows:
Title | Definition |
---|
Markets of similar risk are categorized into Liquidity Tiers based on standardized risk parameters. These tiers define the margin requirements for each market and should be determined according to the depth of the relative market's book and the market capitalization of the token.
Initial_margin_ppm
= the margin fraction needed to open a position.
Maintenance_fraction_ppm
= the fraction of the initial-margin that the maintenance-margin is.
Base_position_notional
= the maximum position size at which the margin requirements are not increased over the default values.
Impact_notional
= the impact notional amount (in quote quantums) is used to determine impact bid/ask prices and its recommended value is 500 USDC / initial margin fraction.
id | name | initial_margin_ppm | maintenance_fraction_ppm | base_position_ notional | impact_notional | impact_notional (as is) |
---|
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]
2592000s
30 days
The desired number of seconds in the look-back window.
Title | Definitions |
| ID of the orderbook that stores all resting liquidity for this CLOB. |
| Status of the CLOB, which could be any of the following:
|
| Product-specific metadata. |
| Minimum increment in the size of orders on the CLOB, in base quantums. |
| This parameter defines the tick size of the orderbook by defining how many subticks are in one tick, i.e. the subticks of any valid order must be a multiple of this value. |
|
|
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%] |
Title | Limit | Num_blocks | Definition |
200 | 1 | How many short term order attempts (successful and failed) are allowed for an account per N blocks. |
2 20 | 1 100 | How many stateful order attempts (successful and failed) are allowed for an account per N blocks. |
200 | 1 | How many short term order cancellation attempts (successful and failed) are allowed for an account per N blocks. |
Title | limit | usd_tnc_required | Definition |
0 | 0 | how many open short term orders are allowed per equity tier.
|
4 | 20000000 |
8 | 100000000 |
10 | 1000000000 |
100 | 10000000000 |
1000 | 100000000000 |
0 | 0 | how many open stateful orders are allowed per equity tier. |
4 | 20000000 |
8 | 100000000 |
10 | 1000000000 |
100 | 10000000000 |
200 | 100000000000 |
sequentially-generated value |
human-readable name of the market pair |
exponent of the price. e.g. if |
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 |
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:
|
0 | 20000 [0.02] | 600000 [0.6] | 1000000000000 [1,000,000 USDC] | 500 USDC / IM | 10000000000 [10,000 USDC] |
1 | 100000 [0.1] | 500000 [0.5] | 250000000000 [250,000 USDC] | 500 USDC / IM | 5000000000 [5,000 USDC] |
2 | 200000 [0.2] | 500000 [0.5] | 100000000000 [100,000 USDC] | 2,500 USDC / IM | 2500000000 [2,500 USDC] |
3 | 1000000 [1] | 200000 [0.02] | 1000000000 [1,000 USDC] | 2,500 USDC / IM | 2500000000 [2,500 USDC] |
4 | Isolated | 50000 [0.05] | 600000 [0.6] | 0 | 2,500 USDC / IM | 2500000000 [2,500 USDC] |
5 | Mid-Cap | 50000 [0.05] | 600000 [0.6] | 0 | 500 USDC / IM | 5000000000 [5,000 USDC] |
6 | FX | 10000 [0.01] | 500000 [0.5] | 500000000000 [500,000 USDC] | 2,500 USDC / IM | 2500000000 [2,500 USDC] |
Perpetual contracts, unlike traditional futures contracts, lack an expiry date and use funding rates to encourage the perpetual price to align with the underlying asset's price. The Funding Rate is determined algorithmically based on the Index Price and Mid-Market Prices, prompts long traders to pay shorts when the perpetual trades at a premium and vice versa.
These payments are proportional to traders' positions and are exchanged directly between traders, not involving the exchange. The goal of the Funding Rate is to maintain the perpetual market's price close to the Index Price by incentivizing trading actions that bring it in line with the underlying asset's value.
Funding rate and premium payments are credited or debited at a fixed interval based on the Epoch Information parameters. These parameters define the funding rate interval and premium sampling interval:
Next Tick: when the next epoch starts in seconds.
Duration: duration of the epoch in seconds.
Is Initialized: whether the epoch has been initialized.
Fast Forward Next Tick: specifies whether next_tick
.
should be fast-forwarded to be greater than the current block time.
Title
Value
Definition
6000000 [6%]
Used for clamping 8-hour Funding Rates according to the equation: funding_rate_clamp_factor * (initial margin - maintenance margin)
.
60000000 [60%]
Used for clamping 8-hour Premium Votes according to the equation: premium_vote_clamp_factor * (initial margin - maintenance margin)
.
15
Minimum number of premium votes per premium sample.
Name
Next Tick
Duration
(seconds)
Current Epoch
Current Epoch Start Block
Is Initialized
Fast Forward Next Tick
30
60
0
0
False
True
0
3600
0
0
False
True
0
3600
0
0
False
True