Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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 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.
The following strategies that can be updated by governance exist to prevent spam on the orderbook and prevent the blockchain state from getting too large:
Block rate limit defines the block rate limits for CLOB specific operations.
Title
Limit
Num_blocks
Definition
200
1
How many short term order attempts (successful and failed) are allowed for an account per N blocks.
2
20
1
100
How many stateful order attempts (successful and failed) are allowed for an account per N blocks.
200
1
How many short term order cancellation attempts (successful and failed) are allowed for an account per N blocks.
Equity tier limit defines the set of equity tiers to limit how many open orders a subaccount is allowed to have.
Title
limit
usd_tnc_required
Definition
0
0
how many open short term orders are allowed per equity tier.
4
20000000
8
100000000
10
1000000000
100
10000000000
1000
100000000000
0
0
how many open stateful orders are allowed per equity tier.
4
20000000
8
100000000
10
1000000000
100
10000000000
200
100000000000
Perpetual contracts, unlike traditional futures contracts, lack an expiry date and use funding rates to encourage the perpetual price to align with the underlying asset's price. The Funding Rate is determined algorithmically based on the Index Price and Mid-Market Prices, prompts long traders to pay shorts when the perpetual trades at a premium and vice versa.
These payments are proportional to traders' positions and are exchanged directly between traders, not involving the exchange. The goal of the Funding Rate is to maintain the perpetual market's price close to the Index Price by incentivizing trading actions that bring it in line with the underlying asset's value.
Title
Value
Definition
6000000 [6%]
Used for clamping 8-hour Funding Rates according to the equation: funding_rate_clamp_factor * (initial margin - maintenance margin).
60000000 [60%]
Used for clamping 8-hour Premium Votes according to the equation: premium_vote_clamp_factor * (initial margin - maintenance margin).
15
Minimum number of premium votes per premium sample.
Funding rate and premium payments are credited or debited at a fixed interval based on the Epoch Information parameters. These parameters define the funding rate interval and premium sampling interval:
Next Tick: when the next epoch starts in seconds.
Duration: duration of the epoch in seconds.
Is Initialized: whether the epoch has been initialized.
Fast Forward Next Tick: specifies whether next_tick.
should be fast-forwarded to be greater than the current block time.
Name
Next Tick
Duration
(seconds)
Current Epoch
Current Epoch Start Block
Is Initialized
Fast Forward Next Tick
30
60
0
0
False
True
0
3600
0
0
False
True
0
3600
0
0
False
True
The insurance fund (`dydx1c7ptc87hkd54e3r7zjy92q29xkq7t79w64slrq`) is the first backstop to maintain the solvency of the system when an account has a negative balance. The account will be liquidated, and the insurance fund will take on the loss when it occurs. This insurance fund will be used before any deleveraging occurs.
If the insurance fund is depleted, positions with the highest profit and leverage may be used to offset negative-balance accounts, ensuring system stability. This process, known as deleveraging, is a last-resort feature in perpetual contracts.
It works similarly to "auto-deleveraging" in other markets, requiring profitable traders to contribute profits to offset underwater accounts. Deleveraging is used only when the insurance fund is depleted and prioritizes high-profit, high-leverage accounts. This approach reduces uncertainty for traders at lower risk levels compared to a socialized loss mechanism. The most highly leveraged offsetting accounts are deleveraged first.
Assume an initial margin requirement of 10% and a maintenance margin requirement of 7.5%.
Trader A deposits 1000 USDC, then opens a long position of 1 BTC at a price of 2000 USDC. Their account balance is -1000 USDC, +1 BTC. During a period of intense and prolonged volatility, the index price reaches 1080 USDC. Trader A is in a risky position, but not yet liquidatable. The price then rapidly drops further, and before A can be liquidated, the index price reaches 900 USDC, making the nominal value of A’s account -100 USDC.
The insurance fund is already depleted due to recent price swings, so deleveraging kicks in. Trader B, whose current balance is 10000 USDC, -9 BTC, is selected as the counterparty, on the basis of B’s profit and leverage, and the fact that B’s short position can offset A’s long position.
Trader B receives A’s entire balance, leaving A with zero balance, and bringing B’s total balance to 9000 USDC, -8 BTC. Trader B’s nominal loss due to deleveraging is 100 USDC, at an index price of 900 USDC. Trader B’s margin percentage increased (and leverage decreased) as a result of deleveraging, from 23.46% to 25%.
When accounts fall below the maintenance margin requirement, the liquidation engine can automatically close their positions at the specified liquidation price. The insurance fund absorbs any profits or losses resulting from these liquidations.
Markets of similar risk are categorized into Liquidity Tiers based on standardized risk parameters. These tiers define the margin requirements for each market and should be determined according to the depth of the relative market's book and the market capitalization of the token.
Initial_margin_ppm = the margin fraction needed to open a position.
Maintenance_fraction_ppm = the fraction of the initial-margin that the maintenance-margin is.
Base_position_notional = the maximum position size at which the margin requirements are not increased over the default values.
Impact_notional = the impact notional amount (in quote quantums) is used to determine impact bid/ask prices and its recommended value is 500 USDC / initial margin fraction.
There are two market types on dYdX:
Cross Margin: Cross-margined markets share the same collateral pool and insurance fund, contributing to the overall risk properties across the entire protocol.
Isolated Margin: Isolated markets have segregated pools of collateral and their own insurance fund. Each isolated market, then, has its own individual risk properties. This enables a protocol to more safely support a much greater range of market types.
At least two oracle sources with > $1M USD in trading volume each.
At least two oracle sources with > $150K depth within 2% of the mid-price.
A minimum of four total oracle sources.
Availability of at least 30 days of historical data.
An overview of parameters that are not covered in other sections of the governance documentation and are adjustable through a dYdX Chain governance Parameter Change Proposals.
This documentation is divided into the following subsections:
represents a Perpetual, Spot or a given product in the state. Each clob pair has the following parameters:
The current size of the insurance fund can be viewed .
On dYdX Chain, each has a set of parameters that can be adjusted by governance, the parameters are as follows:
The following criteria are recommended to determine compatibility with cross-margining, hence allowing dYdX community to propose an isolated market to cross:
The current on dYdX Chain was developed to stimulate liquidity, incentivize traders with substantial volume and contribute to the platform's overall growth and competitiveness.
This fee tier was at block height 6,912,000.
: this section covers the trading statistics look-back window.
: this section covers the tiers of fees and discounts for each trader on dYdX Chain, based on their taker and maker volume.
: this section covers the core aspects of trading, namely insurance fund and liquidations config. The insurance fund acts as the first backstop to maintain systemic solvency when an account has a negative balance. The liquidations config defines the mechanism to close an account’s position when it falls below the margin requirements.
: this section covers the Prices module (x/prices) parameters on dYdX Chain as well as the liquidity tier of each market based on standardized risk parameters.
: this section covers the Perpetual module (x/perpetuals) parameters on dYdX Chain, such as funding rate and epoch information. The perpetual funding rate enables the perpetual price to align with the underlying asset's price. Epoch information is a fixed interval where funding is credited or debited to each account.
: this section covers the Clob module (x/clob) that configures the order creation, placement, and cancellations on dYdX Chain.
: this section explains the message required to update a live market on dYdX Chain.
: this section explains the safety parameters on dYdX Chain, namely the spam mitigation that is related to order creation and cancellation using the Clob module.
2592000s
30 days
The desired number of seconds in the look-back window.
Title
Definitions
id
ID of the orderbook that stores all resting liquidity for this CLOB.
status
Status of the CLOB, which could be any of the following:
STATUS_UNSPECIFIED: Default value. This value is invalid and unused.
STATUS_ACTIVE: this represents an active clob pair.
STATUS_PAUSED: this represents a clob pair that is paused until further notice.
STATUS_CANCEL_ONLY: clob pairs in this state only accept cancellations.
STATUS_POST_ONLY: clob pairs in this state only accept orders which are post-only.
STATUS_INITIALIZING: this represents a newly-added clob pair. Clob pairs in this state only accept orders which are both short-term and post-only.
perpetual_clob_metadata
Product-specific metadata.
step_base_quantums
Minimum increment in the size of orders on the CLOB, in base quantums.
subticks_per_tick
This parameter defines the tick size of the orderbook by defining how many subticks are in one tick, i.e. the subticks of any valid order must be a multiple of this value.
quantum_conversion_exponent
10^Exponent gives the number of QuoteQuantums traded per BaseQuantum per Subtick.
Title
Value
Definition
15000 [0.015%]
When an account is liquidated, up to the entire value of the account may be taken as penalty and transferred to the Insurance Fund. The liquidation engine will attempt to leave funds in accounts of positive value where possible after they have paid the maximum liquidation fee.
Contains the following parameter values:
The minimum (in notional value) and maximum (in parts per million) amount of how much a single position can be liquidated within one block.
1000000000
100000 [0.1%]
Contains the following parameter values:
The maximum amount of how much a single subaccount can be liquidated within a single block in notional value.
100000000000
1000000000000
The maximum number of quote quantums (exclusive) that the Insurance Fund can have for deleverages to be enabled.
Contains the following parameter values:
Configuration regarding how the fillable-price spread from the oracle price increases based on the adjusted bankruptcy rating of the subaccount.
1000000 [1%]
1500000 [1.5%]
sequentially-generated value
human-readable name of the market pair
exponent of the price.
e.g. if Exponent == -5 then a Value of 1,000,000,000 represents $10,000. Therefore 10 ^ Exponent represents the smallest price step (in dollars) that can be recorded.
the minimum number of exchanges that should be reporting a live price for a price update to be considered valid.
the minimum allowable change in price value that would cause a price update on the network. Measured as 1e-6 (parts per million).
A string of json that encodes the configuration for resolving the price of this market on various exchanges, otherwise also known as “oracle”.
On dYdX Chain, oracles are used for the following:
Ensuring that each account is well-collateralized after each trade,
Determining when an account should be liquidated.
0
20000 [0.02]
600000 [0.6]
1000000000000 [1,000,000 USDC]
500 USDC / IM
10000000000 [10,000 USDC]
1
100000 [0.1]
500000 [0.5]
250000000000 [250,000 USDC]
500 USDC / IM
5000000000 [5,000 USDC]
2
200000 [0.2]
500000 [0.5]
100000000000 [100,000 USDC]
1,000 USDC / IM
2500000000 [2,500 USDC]
3
1000000 [1]
200000 [0.02]
1000000000 [1,000 USDC]
1,000 USDC / IM
2500000000 [2,500 USDC]
4
Isolated
50000 [0.05]
600000 [0.6]
0
1,000 USDC / IM
2500000000 [2,500 USDC]
5
Mid-Cap
50000 [0.05]
600000 [0.6]
0
500 USDC / IM
5000000000 [5,000 USDC]
6
FX
10000 [0.01]
500000 [0.5]
500000000000 [500,000 USDC]
1,000 USDC / IM
2500000000 [2,500 USDC]
Tier
Absolute_volume_requirement
[30 day Trailing Volume]
Total_volume_share_requirement_ppm
[Exchange Market Share]
Maker_volume_share_requirement_ppm
[Maker Market Share]
maker_fee_ppm
[Maker Fee (bps)]
Taker_fee_ppm
[Taker Fee (bps)]
0 [< $1M]
0 [-]
0 [-]
100 [1.0]
500 [5.0]
1000000000000 [≥ $1M]
0 [-]
0 [-]
100 [1.0]
450 [4.5]
5000000000000 [≥ $5M]
0 [-]
0 [-]
50 [0.5]
400 [4.0]
25000000000000 [≥ $25M]
0 [-]
0 [-]
0 [-]
350 [3.5]
125000000000000 [≥ $125M]
0 [-]
0 [-]
0 [-]
300 [3.0]
125000000000000 [≥ $125M]
5000 [≥ 0.5%]
0 [-]
-50 [-0.5]
250 [2.5]
125000000000000 [≥ $125M]
5000 [≥ 0.5%]
10000 [≥ 1%]
-70 [-0.7]
250 [2.5]
125000000000000 [≥ $125M]
5000 [≥ 0.5%]
20000 [≥ 2%]
-90 [-0.9]
250 [2.5]
125000000000000 [≥ $125M]
5000 [≥ 0.5%]
40000 [≥ 4%]
-110 [-1.1]
250 [2.5]
This functionality allows the community to update parameters of a live market, which can be composed of 5 parts:
Liquidity Tier is updatable through MsgSetLiquidityTier.
The Prices module (x/prices) is updatable through MsgUpdateMarketParam.
The Perpetual module (x/perpetuals) is updatable through MsgUpdatePerpetual.
The Clob module (x/clob) is updatable through MsgUpdateClobPair.
Isolated-margin markets can be upgraded to cross-margin through UpgradeIsolatedPerpetualToCross.
An overview of the Governance module.
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.
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.
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.\
The following are Instant Market Listings Deposit parameters (ListingVaultDepositParams) adjustable by dYdX governance:
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 in the Cosmos SDK.
Tallying: After the voting period concludes, the aggregate the vote results to determine if the proposal was accepted or rejected by the dYdX community.
The 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).
allow users to list a perpetual market on dYdX immediately, without governance or third-party approvals. Funds are locked in a sub-vault to ensure initial market liquidity.
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.
Title
Value
Definitions
10000000000 [10,000 USDC]
The amount of funds that will be added to the new sub-vault.
0 [0 USDC]
The amount of funds that will be added to the main vault (MegaVault).
30 * 24 * 3600 [2,592,000 blocks or approximately 30 days based on 1 second block time]
The number of blocks for how long the funds will be locked or cannot be removed from the sub-vault.
