Intro
During recent events in the Boom DAO SNS, there was a critical proposal 653 for minting SNS tokens which was executed almost immediately, triggered by only 2 neurons that voted.
This raised some concerns in the community that there could be a technical bug in the SNS framework.
In this post, we refute this hypothesis. The fact that only 2 neurons could vote is
a consequence of a sequence of proposals that changed the SNS parameters. In addition to laying out the facts, we also draw some learnings.
How could it be that 2 neurons got 100% of the voting power?
Each SNS DAO can customize the detailed governance rules and tokenomics in the nervous system parameters (learn more here).
One parameter relevant for this case is called neuron_minimum_dissolve_delay_to_vote_seconds and defines the minimum dissolve delay (i.e., staking period) that neurons need to be eligible to participate in voting. When a proposal is submitted, the governance takes a snapshot of which neurons have a dissolve delay that is no less than this value and those are the neurons that can vote on the proposal.
The following plot shows all recent Boom DAO proposals that changed nervous system parameters and what they set the minimum dissolve delay to. Note that the execution time (the right end of each proposal) is relevant to understand which value the minimum dissolve delay had at each point in time.
Let’s zoom in a little bit to the time when proposal 653 was adopted.
We can draw the following conclusions from the data.
- There were only 2 eligible neurons on the minting proposal (653) because all other neurons had a dissolve delay below neuron_minimum_dissolve_delay_to_vote_seconds at the time when proposal 653 was created. Therefore, these 2 neurons comprised 100% of the eligible voting power and could adopt the proposal quickly.
- The value of neuron_minimum_dissolve_delay_to_vote_seconds had been dramatically increased from 48 hours to over 54 years by proposal 617 (shown by the red line)
- Proposal 617 was inside a stream of many proposals setting the neuron_minimum_dissolve_delay_to_vote_seconds to 48 hours.
- In particular, proposal 620 (shown in purple) was the first of those to be executed after 617, resetting neuron_minimum_dissolve_delay_to_vote_seconds from 54 years back to 48 hours.
- The window during which neuron_minimum_dissolve_delay_to_vote_seconds was very high (54 years) was just over 20 minutes (as shown by the arrows), but that was enough for the two neurons to set their dissolve delay to 83 years and be the only eligible neurons during this period.
- All other neurons (apart from these two) could have participated and potentially voted against the minting proposal 653 if they also increased their dissolve delay to a value over 54 years after the execution of proposal 617 and before the creation of the minting proposal 653 - thus within a very short time frame.
Takeaways
Proposal 653 was not adopted due to a technical bug in the code, but due to a series of proposals with arguably confusing or unexpected effects for some users. For this reason, we conclude with two takeaways.
- To make it harder to change nervous system parameters in the future, the NNS released a new SNS governance version that makes the topic “DAO community settings” that includes changes to the parameters critical (forum post, proposal). This means that going forward a proposal to change the parameters can only be adopted under stricter conditions (see documentation for the detailed rules for critical proposals).
- In the Boom DAO case, if proposal 617 were critical it would not have been approved (the condition that â…” of the cast votes are in favor was not met as there were 36.8% yes and 30% no votes of the overall voting power).
- In general, it is always possible that few parties get a majority of the voting power by buying enough tokens if there are enough SNS DAO members willing to sell their tokens. Making proposals critical does not prevent this - it merely shifts the line of how much voting power is needed to dominate voting in the given topic.
- In a lot of the voting frontends it is hard for human voters to read the proposals that change the SNS parameters and spot the exact change of each proposal. We plan to look into updating the NNS dapp to
- Make it more visible which parameter would be changed in a given proposal.
- Make the parameters easier to read (e.g., not only show the dissolve delay in seconds, but in a more readable format).
