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.
This parameter establishes whether transfers for any tokens are enabled at Genesis. Transfers will be enabled.
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.
These parameters establish punishments for detrimental behavior by validators.
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.
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.
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.
.avif)