Proposal Lifecycle
An overview of the dYdX Improvement Proposal (“DIP”) lifecycle.
Last updated
An overview of the dYdX Improvement Proposal (“DIP”) lifecycle.
Last updated
Below we outline the flow of dYdX Chain governance, from inception of the idea to the implementation. These processes are subject to change according to feedback from the dYdX community.
Anyone can sign up and set up a thread on any topic on dYdX’s governance forums hosted at https://dydx.forum/. dYdX community members are required to register using an email address or an Ethereum wallet.
dYdX Request for Comments (DRCs) creation is the first step in the governance improvement process. Anyone can participate in the dYdX governance forum, create an off-chain DRC, and discuss potential improvements to the dYdX Chain and/or dYdX ecosystem.
To create a DRC, dYdX community members should use this template.
The DRC should cover all the information of the potential final DIP.
Once posted on the dYdX governance forum, the proposer should reasonably respond to questions and incorporate constructive feedback to further improve the DRC. The DRC Discussion and Feedback step aims to establish a rough consensus before a vote starts.
While a rigid timeline is unnecessary, four days likely makes sense to ensure the dYdX community has sufficient time to review and comment on the DRC.
Before submitting a transaction to create a governance proposal, the prospective proposer must create a json file containing relevant information for the governance proposal. Depending on the type of proposal, the contents of the json file will differ.
Text Proposals: the file should contain a title, description, and deposit (in aDYDX units).
Community Spending Proposals: the file should contain the title, description, recipient, number of tokens, and deposit (in aDYDX units).
Parameter Change Proposals: the file should contain title, description, changes, subspace (module with the parameter that is being changed), key (the parameter that is being changed), value (value of the parameter that will be changed by the governance mechanism), and deposit (in aDYDX units).
Software Upgrade Proposals: the file should contain title, description, deposit and plan.
The plan outlines when the update will occur (block height), the name of the new version of the software, and the UpgradeHandler which instructs the upgrade module how to carry out the upgrade (the latest consensus version of each module and other software).
As a general rule, any information specific to a proposal (e.g., Title, description, deposit, parameters, recipient) can be placed in a json file, while information general to a transaction of any kind (e.g., chain-id, node-id, gas, fees) can remain in the CLI (the command-line interface).
Below is a template json file that can be used for a Text proposal:
The description must at least contain:
a short summary of the DRC that has been posted on the dYdX governance forum,
a link to the completed DIP template, and
a link to the forum post,
so that prospective voters have access to the full context of the DIP.
The description within the json file will be visible to the prospective voters when they:
query the proposal using the CLI,
view the proposal on their wallet dashboard (such as Keplr or Leap), or
view the proposal on a block explorer (such as Mintscan).
If you have never submitted a proposal on dYdX Chain before, it would be helpful to familiarize yourself with this technical guide.
An on-chain DIP may be submitted by a dYdX community member using the following generic command format (on the command-line interface):
Here is an example using the above command format to submit a software upgrade proposal:
If <proposal type> is left blank, the type will be a Text proposal. Otherwise, it can be set to param-change, software-upgrade, or community-treasury-spend.
dydxprotocold is the command-line interface client that is used to send transactions and query the dYdX Chain and tx gov submit-proposal software-upgrade indicates that the transaction is submitting a software upgrade proposal.
--~/upgrade_plan.json indicates the file containing the proposal information.
--from wallet-1 is the account key that pays the transaction fee and deposit amount. This account key must exist in the keychain on your device and it must be an address you control. To register an account in the keychain, you can follow the steps here.
--chain-id dydx-mainnet-1 is dYdX Chain.
--gas 500000 is the maximum amount of gas permitted to be used to process the transaction.
The more content there is in the description of your proposal, the more gas your transaction will consume.
If this number isn't high enough and there isn't enough gas to process your transaction, the transaction will fail.
The transaction will only use the amount of gas needed to process the transaction.
You can simulate the amount of gas needed to submit the proposal by adding --dry-run at the end of the CLI command above.
In practice, the simulation function isn’t always accurate, so you may want to multiply the return the gas unit by a ~1.3x multiplier. For example, with the following result, you will need to input around --gas 1100000
--fees is a flat-rate incentive for a validator to process your transaction, it is denominated in USDC (ibc/8E27BA2D5493AF5636760E354E46004562C46AB7EC0CC4C1CA14E9E20E2545B5).
The network still accepts zero fees, but many nodes will not transmit your transaction to the network without a minimum fee.
Many nodes use a minimum fee to disincentivize transaction spamming.
The number is divided by 10^18.
--node is RPC endpoint address that can be found here. Remember to append :443 to the end of the RPC URI to access the endpoint properly and securely.
To submit the proposal on-chain, the proposer will need to deposit a number of DYDX that is equal to or greater than the min_initial_deposit_ratio.
As soon as the proposal is created the max_deposit_period begins and the min_deposit must be satisfied before the max_deposit_period concludes for the vote to start.
After the proposal is created, any DYDX holder can contribute to the deposit by sending a deposit transaction.
To contribute to the deposit of a governance proposal, the prospective depositor must know the proposalID that they intend to add a deposit to. The prospective depositor can query list of proposals on dYdX Chain by entering this command on the CLI:
Once the prospective depositor knows the ID of the proposal, they can add a deposit using this command:
If a proposal fails to satisfy the min_deposit within the max_deposit_period and the burn_proposal_deposit_prevote parameter is set “False”, any DYDX holder who contributed to the respective deposit of a proposal will have their deposit refunded.
If the min_deposit is satisfied within the max_deposit_period, the vote will start and the deposit is kept in escrow and held by the governance ModuleAccount until the proposal is finalized (passed or rejected). Depositors of a proposal will have their deposit refunded, unless enough voters vote NoWithVeto and satisfy the veto_threshold.
If the min_deposit is satisfied within the max_deposit_period, the vote will start and voting will last for the voting_period.
Note, only staked DYDX tokens can vote on dYdX Chain governance proposals.
Prospective voter can vote by following the steps on the How to Vote Guide.
If a DYDX staker does not vote on a proposal, they will inherit the vote of their validator for the respective proposal.
When the voting_period ends, the TallyParams (quorum, threshold, and veto_threshold) determine whether the proposal is approved and implemented or rejected.
The execution process according to the respective vote type is as follows:
Text Proposals: will not result in any on-chain changes, but could result in an off-chain action.
Community Spending Proposals: the number of DYDX encoded in the proposal will be transferred from the from the dYdX community account to the address encoded in the proposal.
Parameter Change Proposals: the parameter will update go into effect without a hard fork.
Software Upgrade Proposals:
Signal - Validators upgrade their software to the new version and signal that they are ready for the upgrade.
Block Height: The dYdX Chain reaches the specified block height for the upgrade and pauses its operation.
Upgrade and Restart: Validators apply the upgrade and restart their nodes, which resumes the blockchain's operation with the new software.
