v4 Rewards and Parameters Deep Dive
As we continue to release open-source software for the dYdX Chain mainnet, we want to provide a peek into what the dYdX team is building. This post discusses characteristics of the open-source software and the related governance token.
Please note that each of the topics discussed below is subject to change by the applicable governance community (the “Governance Community”). This blog post is merely intended to provide transparency into the characteristics of the open-source software that has been developed by dYdX.
Trading Rewards
Trading rewards contemplated in the initial software will be subject to adjustments by the applicable Governance Community.
The software will allow the network to fund and utilize trading rewards.
In addition to incentivizing trading on the protocol, the general goals of trading rewards include:
Self-trading should not be profitable
Any distributed rewards should be proportional to fees paid to the protocol
Trading rewards should be deterministic
Trading rewards should be settled and distributed every block
Trading rewards should limit the protocol overspending on trading activity
How will trading rewards work from a user perspective?
Traders will be rewarded after each successful trade made on the protocol.
Immediately after each fill, a user will be sent a certain amount of trading rewards directly to their dYdX Chain address, based on the formulas described below. Prior to each trade, the UI will also show the maximum amount of rewards a trade of that size could receive.
Users can earn trading rewards up to, but not exceeding, 90% of a fill’s net-trading-fees, paid in the governance token of the network.
How do trading rewards affect potential inflation of the governance token?
Trading rewards distributed by the protocol, each block, are capped at the dollar equivalent of the total net trading fees generated by the protocol that block. Thus, trading rewards distributed can fluctuate on a block by block basis.
This can result in a large amount of “savings” by the protocol (via reduced inflation) by not overspending to incentivize trading activity.
What formula for trading rewards will exist within the open source software?
The software will reflect a Rewards Treasury of tokens that are available to be distributed to traders. Call the size of this Rewards Treasury T. Each block, new tokens are transferred into this T from the vesting contract and rewards are then distributed. Each block, T can grow or shrink based on protocol activity.
Let A represent the amount of rewards that are distributed from this T to traders in a given block.
We define a trader X’s “rewards score” in a given block as:
Let S be the sum of all the rewards scores across all traders for a given block. S is given by:
Every block, the amount A of the native token that is distributed to traders is defined as:
Where C is a constant configurable by the applicable Governance Community. The open source software is configured for the constant to be initially set at 0.
The amount remaining (T - A) is retained in the Rewards Treasury and new tokens are emitted into the Rewards Treasury the following block.
A is calculated and distributed to all the takers who traded in the block and T - A is rolled over and retained in the Rewards Treasury for the next block.
The rewards distributed, A, are allocated proportional to each trader’s score.
Once the Vesting Contract is funded, trading rewards will continue to run and settle automatically, every block.
See below for a visual that summarizes trading rewards architecture.
Fee Schedule
The fee schedule contemplated in the initial software on v4 will be subject to adjustments by the applicable Governance Community
The basic structure for fees have been developed to reflect the following characteristics:
Fees differ based on side (maker/taker)
Users are eligible for lower fees based on their 30 day trading volume across sub accounts and markets
Fees are uniform across all markets
Initially, traders’ maker rebates will be developed to reflect -1.1bps. This initial setting can be adjusted by the applicable Governance Community. The open-source software contemplates that after the 120-day period has concluded, the dYdX Chain would automatically revert to the other fee schedule shown in the schedule above.
The initial software code will contemplate fees accruing to validators, which then may be shared with stakers that provide staking services to validators. Like most other settings, this can be adjusted by the applicable Governance Community.
Parameters
Below is a summary of various notable parameters and what they mean for any chain utilizing the open source software. Parameters will be subject to adjustments by the applicable Governance Community and can be set to different values at Genesis by any deployer.
Bank Parameters
This parameter establishes whether transfers for any tokens are enabled at Genesis. Transfers will be enabled.
State Parameters
The open source software will not pre-populate any bank-state on the network. Validators who participate in Genesis have the ability to determine the network’s initialized state.
Slashing Parameters
These parameters establish punishments for detrimental behavior by validators.
Signed Blocks Window | Min Signed Per Window | Downtime Jail Duration | Slash Fraction Doublesign | Slash Fraction Downtime | |
|---|---|---|---|---|---|
Slashing Params | 8192(~3 hrs) | 20% | 7200s | 0% | 0% |
SignedBlocksWindow: Together with MinSignedPerWindow, specifies the number of blocks a validator must sign within a sliding window. Failure to maintain MinSignedPerWindow leads to validator being jailed (removed from active validator set).
SlashFractionDownTime: Defines the slashing-penalty for downtime
DownTimeJailDuration: How long before the validator can unjail themselves after being jailed for downtime.
Double-signing by a validator is considered a severe violation as it can cause instability and unpredictability in the network. When a validator double-signs, they are slashed for SlashFractionDoubleSign, jailed (removed from validator set) and tombstoned (cannot rejoin validator set).
Distribution Parameters
These parameters handle the distribution of gas and trading fees generated by the network to validators.
Community Tax | WithdrawAddrEnabled | |
|---|---|---|
Distribution Params | 0% | True |
CommunityTax: Fraction of fees that goes to the community treasury. The software will initially reflect a 0% community tax.
WithdrawAddrEnabled: Whether a delegator can set a different withdrawal address (other than their delegator address) for their rewards.
Staking Parameters
These parameters define how staking works on the protocol and norms around staking.
*MaxValidators and UnbondingTime are particularly subject to change based on public testnet data and feedback.
| BondDenom | MaxValidators | MinCommissionRate | UnbondingTime |
|---|---|---|---|---|
Staking Params | Decided at Genesis, by validators | 60 | 5% | 30 days |
MaxValidators: Every block, the top MaxValidators validators by stake weight are included in the active validator set.
UnbondingTime: Specifies the duration of the unbonding process, during which tokens are in a locked state and cannot be transferred or delegated (the tokens are still “at stake”).
MinCommissionRate: The chain-wide minimum commission rate that a validator can charge their delegators. The default commission rate will be 100%.
Governance Parameters
These parameters define how governance proposals can be submitted and executed. For more information on the governance module and its associated parameters, head to the official Cosmos SDK docs.
| Min Deposit | MinInitialDepositRatio | Max Deposit Period | Voting Period | Quorum | Threshold | Veto | Burn Proposal Deposit Prevote | Burn Vote Quorum | Burn Vote Veto |
|---|---|---|---|---|---|---|---|---|---|---|
Gov Params | 10,000 governance token | 20% | 1 Days | 4 Days | 33.4% | 50% | 33.4% | False | False | True |
About dYdX
Here at dYdX, our mission is to democratize access to financial opportunity. We believe that v4 software will represent notable progress in service of that mission. The events in the global economy that have transpired over the last year have only reinforced the need for open, transparent, and permissionless financial products. We’re excited for v4 to better meet those needs.
If building the future of a decentralized exchange and open finance is something you’re interested in, check out what it’s like to work at dYdX and our open roles!
To ask additional questions, join the discussion on Discord, participate in the dYdX community, or follow us on Twitter. We’re excited to continue building the dYdX Chain and will continue to release updates over the coming months.
This post is subject to the dYdX Terms of Use and v4 Terms of Use. The dYdX interface is not available to persons or entities who reside in, are located in, are incorporated in, or have registered offices in the United States or Canada ("Blocked Persons"), or other Restricted Persons (as defined in the dYdX Terms of Use). dYdX products and services are not intended for, and should not be used by, Blocked Persons or Restricted Persons.