Gov Overview | Cosmos SDKAn overview of the Governance module.
dYdX Chain is a proof-of-stake blockchain network and holders of DYDX can participate in governing the dYdX Chain. dYdX Chain uses the standard x/gov module in the Cosmos SDK.
The governance module empowers DYDX holders to propose and vote on proposals, directly influencing the evolution of the dYdX Chain through a democratic process. The subject matter of proposals can vary from changing a governable parameter on the dYdX Chain, spending dYdX community funds, and updating the software that dYdX Chain nodes are running, among other things.
Deposits: Unstaked DYDX tokens pledged by the proposer and potentially other DYDX holders in support of the creation of a governance proposal.
Inheritance: If a DYDX staker does not vote on a proposal, they will inherit the vote of their validator for the respective proposal.
Vote Weight: A DYDX holder's vote weight is equal to the amount of DYDX the user has actively staked (1-1). DYDX tokens that are not staked or are in the unbonding period will not count towards a DYDX holder's vote weight.
Tallying: After the voting period concludes, the TallyParams aggregate the vote results to determine if the proposal was accepted or rejected by the dYdX community.
Execution: If a proposal passes, the execution process depends on the type of proposal.
These parameters may be adjusted by the dYdX Community with an on-chain governance proposal.
All DYDX holders have the right to create a proposal. A DYDX holder can only use unstaked DYDX tokens to contribute to a given proposal deposit.
To create a proposal, a DYDX holder needs to send a msgsubmitproposal transaction and satisfy the min_initial_deposit_ratio parameter by sending a deposit transaction.
After the proposal is created, any DYDX holder can contribute to the deposit by sending a deposit transaction.
For the voting period to start, the min_deposit parameter needs to be satisfied within the max_deposit_period. Note, (1) the proposal is in an inactive proposal queue until the min_deposit is satisfied and (2) the voting_period will start as soon as the min_deposit is reached.
The deposit is kept in escrow and held by the governance ModuleAccount until the proposal is finalized (passed or rejected).
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.
Governance of the dYdX Chain includes 5 distinct types of proposals: text proposals, parameter change proposals, community spending proposals, software upgrade proposals, and new market proposals.
Text proposals are votes that occur on-chain without directly triggering any changes on the dYdX Chain. Text proposals can be used (1) to establish dYdX community consensus for an off-chain matter, such as a strategic plan, a dYdX DAO action, or a dYdX DAO commitment, or (2) as signalling for a future vote that will directly cause changes on the dYdX Chain.
Community Spending Proposals involve a request to spend DYDX from the community treasury, community pool, or any other community-controlled account. The inputs for a Community Spending Proposal are (1) the number of DYDX and (2) the recipient address.
Parameter change proposals are for changing one or more of the dYdX Chain parameters that are controlled by the governance module.
If a parameter change proposal is successful, the parameter change takes effect in the block after the voting period ends.
The upgrade module facilitates smoothly upgrading a live Cosmos chain to a new (breaking) software version. Software Upgrade Proposals need to be created with a plan. Such a 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 on how to carry out the upgrade (the latest consensus version of each module and other software).
After the dYdX community accepts a software upgrade proposal there are two important steps:
Signal - After a SoftwareUpgradeProposal is accepted, validators are expected to download and install the new version of the software while continuing to run the previous version. Once a validator has downloaded and installed the upgrade, it will start signaling to the network that it is ready to switch by including the proposal's proposalID in its precommits.
Switch - Once a block contains more than 2/3rd precommits where a common SoftwareUpgradeProposal is signaled, all the nodes (including validator nodes and full nodes) are expected to switch to the new version of the software.
The voting options for governance proposals on dYdX Chain are:
Yes
No
NoWithVeto - allows voters to express strong disagreement with a proposal to the extent that if burn_vote_veto is “True” and the veto_threshold is reached the respective deposit in the governance module account for the proposal is burned.
Abstain - allows voters to signal that they do not intend to vote in favor or against the proposal but accept the result of the vote.
A proposal can be expedited, which shortens the voting duration to 1 day and sets a higher tally threshold by default. The expedited proposal threshold is 0.75 (75%) and the quorum is 0.334 (33.4%). If the expedited proposal does not meet the threshold within the shortened voting period, it is converted to a regular proposal, and the voting restarts under standard conditions.
For example, if an expedited proposal starts on July 1st, the vote would end on July 5th if the expedited proposal fails to meet the higher tally threshold by July 3rd.
Users can set their proposal to expedited proposal by setting the expedited field in the proposal submission JSON file to true. Expedited proposals can be used for any vote type, including Text, Community Spend, Parameter Change, Adding Markets, and Software Upgrades.\
| Title | Value | Description |
|---|---|---|
Deposit Params
The parameters for deposits on governance proposals.
2000000000000000000000 adydx
2,000 DYDX
The minimum token deposit for a governance proposal to enter the voting period.
604800s
7 days
The maximum time permitted for DYDX holders to deposit enough DYDX tokens to satisfy the min_deposit for a governance proposal to enter the voting period.
0.20000
The percentage of the min_deposit that needs to be submitted by the address that creates the proposal.
Voting Params
The parameter for vote length of governance proposals.
345600s
~4 days
The duration of the voting period.
0.33400
The parameters for tallying votes on governance proposals.
0.50000
The minimum proportion of Yes votes for a proposal to pass.
*Abstain votes are not counted.
0.33400
The minimum percentage of NoWithVeto votes required to reject a proposal, regardless of the number of Yes votes.
Burnable Params
The parameters for burning or returning a proposal deposit to depositors.
True
If True, this boolean parameter will burn the proposal deposit for any proposals that are vetoed.
False
If True, this boolean parameter will burn the proposal deposit if the proposal vote does not reach quorum.
False
If True, this boolean parameter will burn the proposal deposit if the proposal does not enter the voting period.
Expedited Proposal Params
The parameters for expedited proposals
0.75000
The minimum proportion of Yes votes for an expedited proposal to pass.
*Abstain votes are not counted.
86400s ~1 day
The duration of expedited proposal's voting period.
Below, we outline the flow of dYdX Chain governance, from the idea's inception to 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. 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.
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 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.
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.
To create a DRC, dYdX community members should use .
a link to the completed , and
--node is RPC endpoint address that can be found . Remember to append :443 to the end of the RPC URI to access the endpoint properly and securely.