Vote Proposal Buffer is the amount of time that must pass between each subsequent vote. This parameter will determine the number of votes that can take place within a period of time and whether or not we can have votes run concurrently.
What is important to consider?
If we look at the edge cases, a very high setting would greatly limit the number of votes we can have over a period of time. For example, if set to 90 days, there would be a maximum of 4 votes allowed per 12-month period. Depending on the Vote Duration parameter, this may also prevent concurrent votes, if that is a desired outcome. A very low setting would allow for many votes over a period of time and, depending on the Vote Duration parameters, could allow votes to run concurrently. For example, if set to 1 day, a new vote may take place every day.
So what do we need to talk about in this forum post?
What are the advantages and disadvantages of having a very high Vote Proposal Buffer and a very low Vote Proposal Buffer.
What considerations should we take into account in determining this parameter?
In the function that creates new votes there are these lines:
// Get the start block of the previous vote (if it’s the first vote will be 0)
uint64 previousVoteStartBlock = votes[voteId - 1].startBlock;
// Here we ensure that the next vote created starts at least bufferBlocks blocks after the previous vote start block
uint64 earliestStartBlock = previousVoteStartBlock == 0 ? 0 : previousVoteStartBlock.add(bufferBlocks);
// Get the actual start block of the next vote created (if the bufferBlocks duration has already passes then get the current block number)
uint64 startBlock = earliestStartBlock < getBlockNumber64() ? getBlockNumber64() : earliestStartBlock;
// Get the block from where the vote will be able to be executed in case it passes
uint64 executionBlock = startBlock.add(durationBlocks).add(executionDelayBlocks);
!dish praise to @lkngtn for describing to me the real reason for the vote proposal buffer in Dandelion Voting:
The vote proposal buffer’s main purpose is to make it so that the rage quit mechanism works well in a specific scenario…
Imagine if a proposal comes out to send 100 wxDai to the Token Engineering Academy and I vote yes on it right after it comes out.
Then a second proposal comes out 3 minutes later that asks for 10,000 wxDai to fire bomb a house… and for some crazy reason this gathers support.
Well I voted yes on the first proposal, but i want to rageQuit before the second proposal passes.
I cannot rage quit until that first vote is executed… and there was only 3 minutes between the vote proposals so there will be 3 minutes between the vote execution…
As you can see… 3 minutes is not enough time really… so this variable was included to protect against this scenario.
There seems to be a lot of questions about this one… confusing Ragequit Delay with Vote Proposal Buffer
The vote proposal buffer is a rate limiter for proposals… as in, it slows the number of newly created milestones. if that is set to 10 days, it means only 1 vote can happen every 10 days…
For example… If:
Vote Proposal Buffer is 10 days
Vote Duration is 1 day
Ragequit Delay is 1 hour
Then if Vote A is proposed, the next vote cannot be PROPOSED for 10 days
BUT!
Every vote will pass or fail within 24 hours and be executable 1 hour later.
The 2 params that address the ability for people to Ragequit before a proposal is executed are:
**- Vote Duration ** - Ragequit Delay
Ragequit Delay being the primary one, targeted exactly for that purpose.
What is the Vote Proposal Buffer (hours)?
The Vote Proposal Buffer is the amount of time that must pass between the start of subsequent votes.
Implications & Parameter Options
The Vote Proposal Buffer is measured in hours, and you will have the option to set this parameter between 0 and ∞.
The Vote Proposal Buffer is being implemented in order to limit rapid proposal creation within the DAO which delays the execution of prior proposals. The Vote Proposal Buffer also allows token holders adequate time to exercise their ragequit rights for a specific proposal before the voting period ends. If we set a high Vote Proposal Buffer, we can limit the number of votes we can have over a period of time. If we set a low Vote Proposal Buffer we would allow for many votes to occur over a period of time and, depending on the Vote Duration parameters, could allow votes to run concurrently.
Suggested Range
The Vote Proposal Buffer is important for providing the community the ability to make proposals, and also to prevent spam from occurring that delays voting on proposals. We suggest a range between 4-12 hours.
Related Parameters to consider when defining the Vote Proposal Buffer (hours):
Vote Duration (days)
Tollgate Fee (wxDai)