v4 Deep Dive: Rewards and Parameters

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.

Legitimacy and Disclaimer

Crypto-assets can be highly volatile and trading crypto-assets involves risk of loss, particularly when using leverage. Investment into crypto-assets may not be regulated and may not be adequate for retail investors. Do your own research and due diligence before engaging in any activity involving crypto-assets.

dYdX is a decentralised, disintermediated and permissionless protocol, and is not available in the U.S. or to U.S. persons as well as in other restricted jurisdictions. The dYdX Foundation does not operate or participate in the operation of any component of the dYdX Chain’s infrastructure.

The dYdX Foundation’s purpose is to support the current implementation and any future implementations of the dYdX protocol and to foster community-driven growth in the dYdX ecosystem.

The dYdX Chain software is open-source software to be used or implemented by any party in accordance with the applicable license. At no time should the dYdX Chain and/or its software or related components be deemed to be a product or service provided or made available in any way by the dYdX Foundation. Interactions with the dYdX Chain software or any implementation thereof are permissionless and disintermediated, subject to the terms of the applicable licenses and code. Users who interact with the dYdX Chain software (or any implementations thereof) will not be interacting with the dYdX Foundation in any way whatsoever. The dYdX Foundation does not make any representations, warranties or covenants in connection with the dYdX Chain software (or any implementations and/or components thereof), including (without limitation) with regard to their technical properties or performance, as well as their actual or potential usefulness or suitability for any particular purpose, and users agree to rely on the dYdX Chain software (or any implementations and/or components thereof) “AS IS, WHERE IS”.

Nothing in this post should be used or considered as legal, financial, tax, or any other advice, nor as an instruction or invitation to act by anyone. Users should conduct their own research and due diligence before making any decisions. The dYdX Foundation may alter or update any information in this post in the future at its sole discretion and assumes no obligation to publicly disclose any such change. This post is solely based on the information available to the dYdX Foundation at the time it was published and should only be read and taken into consideration at the time it was published and on the basis of the circumstances that surrounded it. The dYdX Foundation makes no guarantees of future performance and is under no obligation to undertake any of the activities contemplated herein.