Project title: Sputnik Improvements Proposal
One-liner: A collection of minor improvements for more creative and flexible governance systems.
Project DAO: Voyager DAO
Challenge area or bounty: “ Better DAO frameworks on NEAR”
Slides: Introduction | Voyager
Repo: ~https://github.com/cmwaters/voyager~
Project members
- Callum Waters (cmwaters.near)
Project summary
The Sputnik DAO contract provides a solid foundation for the governance of organizations on NEAR. This proposal lists a collection of ideas with the aim of exploring more creative and flexible governance systems and extending the current Sputnik framework. This proposal is part of the Open Web Governance Challenge.
-
Non binary voting choices - Currently, all proposals are based on a binary yes/no voting system (with the addition of a veto vote against spam proposals). While this covers a broad set of use cases, there may be some proposals that benefit from the ability to express more nuanced preferences. An apt example is the creation of bounties. A proposer could allow the members to vote on the amount they think the reward should be and the end result is the weighted medium of everyone’s preferences. Non-binary voting choices could also consist of proposals that want to use multi-choice or ranking of preferences. This would be implemented via modifying the
VotePolicy. - Pluggable voting mechanisms or tally functions - This ties partly with the aforementioned idea insofar that in some cases we can’t simply add all the choices together. However, even with binary proposals we may want to experiment with a different form of tallying the votes. One good example is quadratic voting where the the square root of the weight is added.
- Better Support for Weight Based Groups - Sputnik uses roles to differentiate between different members in a DAO. This is effective for having permissioned sub groups but doesn’t align so well with the notion of a group of token holders (each with varying wealth). From looking at the codebase, there seems to be some attempt to create more intuitive DAOs using token weights. I would propose to extend this by abstracting out roles from weights; thus members with the same role could conceivably have different weights. In addition, weights should be allowed to be changed and thus follow the contributions (and withdrawals) from the members within the DAO (or based on some other potentially arbitrary metric).
- Multi-Message Proposals - This is a somewhat self-explanatory suggestion. Sputnik currently allows only one “action” to occur as a result of a proposal i.e. one transfer or one change of policy or a membership change. In some cases it may be sensible to group together multiple actions in a single proposal.
-
Quorum - The Sputnik framework requires a minimum participation equal to the threshold of the
VotePolicyi.e. if the threshold is 50% then at least 50% of the group must vote yes. A quorum is a variable which sets the minimum amount of participation. In large groups we might be content if only 40% vote (of which at least 50% must approve to pass the proposal). In small groups we may want a 50% threshold but demand that at least 75% vote. By having both a quorum and threshold variables we allow for greater flexibility. - Flexible Defaults - It is implicit in the design of the system that if a member doesn’t vote at all for a proposal that it effectively counts as a “reject” vote. This is sometimes not the desired behavior. In fact, amongst many groups, holding a vote is more a last resort when trying to decide upon something. From this notion, it may be favourable if some kinds of proposals defaulted to “approve”. Thereby most people don’t have to submit their consent, it is automatically assumed and instead only those wishing to “reject” the proposal need to vote.
- Withdraw and Amend Proposal - This last proposal allows for some simple UX improvements. In the case of submitting a proposal, it’s possible that the proposer may include a mistake in the description or other elements of the proposal that should be allowed to be amended. It is likely that no ammendments can be made that change the underlying semantics of the proposal but are just for cosmetic changes. Similarly, it may be beneficial to introduce a period at the start of the proposal lifespan where the proposer can quickly withdraw it.
These ideas probably offer varying levels of value with some being more experimental and others more practical. There are also varying tradeoffs when it comes to implementing these changes. However, most of these changes can be made independent from one another so it may also be feasible to just accept a subset of these ideas.
I also acknowledge that this was submitted after the deadline but felt that it was better to submit something late than nothing at all.