tallyVotes()to “pass” and adjust
desiredEGL, enough EGLs must participate to meet the
votingThreshold, which is defined as a % of
eglsInCirculationis calculated as the sum of EGLs at the time
tallyVotes()is called that were:
- 1.Swept by pools
- 2.Distributed and claimed (i.e. used to vote at least once) by Core Devs
- 3.Distributed and claimed (i.e. used to vote at least once) by Genesis participants
- 4.Deployed to Balancer as part of the Genesis (i.e. 750M tokens)
- 5.Calculated as Voter Rewards (i.e. when
- 6.Unlocked and sent to EGL Creators
- 7.Distributed by the EGL DAO
votingThresholdis initialized at 10% of the
eglsIncirculationfor the first 7 epochs, after which it jumps to 30% for the remaining 45 epochs (totaling 52 epochs) after the EGL launch, and then gradually increases every epoch at a rate of 10% / year to a maximum of 50%:
, if i <= 7
, if 7 < i < 52
, if i ≥ 52
i = 0 for the first epoch
votingThresholdis not met, the tally does NOT leave the
Instead, in order to incentivize voter participation, the default behavior is to gradually undo the change since EGL launch, which is very likely a negative outcome for EGL voters. Specifically, the default behavior sets the
desiredEGLto 95% of the
tallyVotesGasLimit(the gas limit of the block that the successful
tallyvote()was called in).
For example, assume:
- 1.EGL the
tallyVotesGasLimitis 15M gas.
- 2.The voted on
- 3.At some point in the future the
votingThresholdis not met.
After the vote, the new
desiredEGLwould be 14.25M (15M * 95%) since the threshold wasn't met.
The aforementioned default behavior does not take place for a grace period of 7 epochs (weeks) from smart contract launch. Thus, in the first 7 weeks, if a vote does not meet the threshold,
desiredEGLstays the same (e.g. what it was in the prior week).