5. (On-chain) DIP Voting
After an On-Chain DIP is created, the proposal enters a
pending state for a period defined by the Voting Delay, which is currently configured to 6570 blocks or approximately 1 day (assuming 13 seconds per block). In other words, user snapshots are recorded 1 day after the DIP is created, at which point the proposal transitions to an active state.After the Voting Delay, the Voting Period is activated. The voting period length depends on the proposal type.
The following chart shows a DIP state flowchart:
Lifecycle of a DIP
After a DIP is created on-chain it is subject to a Voting Delay, Voting Period, Minimum Quorum, and a minimum Vote Differential. The initial parameters are as follows:
Parameter | Description | Short Timelock Executor | Merkle-Pauser Executor | Long Timelock Executor | Starkware Executor |
|---|---|---|---|---|---|
Voting Delay | Number of Ethereum blocks to wait before voting on a proposal may begin after a proposal is submitted | 6,570 blocks | 6,570 blocks | 6,570 blocks | 6,570 blocks |
Voting Period | Length of time for which proposals are available to be voted upon | 4 days | 2 days | 10 days | 4 days |
Minimum Quorum | Minimum yes votes for a DIP proposal to pass | 2% of total supply | 1% of total supply | 10% of total supply | 2% of total supply |
Vote Differential | Required yes-no gap for a DIP proposal to pass | 0.5% of total supply | 0.5% of total supply | 10% of total supply | 0.5% of total supply |
Only the voting delay can be modified by governance, and it can only be changed to values in between (inclusive) the minimum and maximum delay. The voting period, minimum quorum, and vote differential can't be changed.
Last modified 1yr ago