dYdX logo
dYdX logodYdX icon
English
中文
日本語
한국어
русский
Türkçe
Français
Português
Español

v4 Deep Dive: Rewards and Parameters

Product
Product
Rewards and Parameters
Product
Product

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: 

  1. Self-trading should not be profitable 

  2. Any distributed rewards should be proportional to fees paid to the protocol

  3. Trading rewards should be deterministic

  4. Trading rewards should be settled and distributed every block 

  5. 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:

  1. Fees differ based on side (maker/taker)

  2. Users are eligible for lower fees based on their 30 day trading volume across sub accounts and markets

  3. 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.