We want to thank everyone contributing to this discussion, both here and on the working group call.
As it relates to an improved process, we believe it should address all cases where a full constitutional process is currently considered an overkill, whether due to relatively low risk or a proposal’s non-controversial nature. Examples of such proposals include token registrations or the currently-bundled constitutional AIP which covers three technical proposals.
An Optimistic Process
While our initial thought process led to optimistic governance as well, we believe there are several issues with that approach:
Firstly, all passed constitutional proposals currently enjoy the same broad legitimacy due to a DAO-wide consensus building and tokenholder vote. This legitimacy is something that can’t be replaced by an optimistic governance model, where proactive action of tokenholders isn’t necessary to execute a proposal, but rather stop it from executing.
- This isn’t necessarily a blocker on its own, but something that may result in downstream effects such as increased (perceived or actual) exposure for council members.
- The above, in turn, might result in increased difficulty for finding interested parties to participate in the framework.
Secondly, the composition and necessary checks on a new body and process aren’t an easily solvable problem. For example, a DAO expert position would require elections to be conducted regularly and the optimistic governance process would need to be set up and maintained independently of existing DAO processes, adding further complexity.
Thirdly, an issue with the council’s on-chain authority arises, since it will either:
- Have greatly limited on-chain decision making power by being able to only access the token registration contracts, OR
- Have broad on-chain decision making power so that it can propose maintenance upgrades as well.
The former allows for greater security, but goes against the guiding principle of introducing a process capable of covering all currently uncontroversial proposals blocked by the constitutional process. The latter introduces new risks to the system and essentially implements a secondary Security Council, on-chain function-wise.
Lastly, a risk of DOS attacks exists with the committee capable of creating a large number of proposals that would each need to be vetoed separately, thus overwhelming the tokenholders.
An Alternative Approach
As a result of the above, we’d like to propose an alternative approach to be explored. Namely, we believe that several low hanging fruits exist, with the potential to evolve further.
1. Firstly, we view proposal bundling as both a short and long term solution.
Short Term
In the short term, proposal bundling has proven to work in case of technical proposals, such as the previously-mentioned AIP or the Adopt Timeboost + Nova Fee Sweep AIP. We believe that broad consensus-building and resulting tokenholder vote is useful even in the case of non-controversial technical proposals, and would recommend for the DAO to adopt a calendar-based approach to token registration proposal bundling. By utilizing (for example) a quarterly bundled vote (both on Snapshot and in a single payload on Tally), external teams would be able to predict better when their token registration is put in front of the DAO.
Medium to Long Term
Building on the above, we’d also like to propose for the DAO to explore an on-chain solution to accommodate a bundled proposal approach. Importantly, the short term solution doesn’t account for seemingly non-controversial proposals turning out to be controversial at the Snapshot or Tally voting stage. A bundle being struck-down due solely to one of the subproposals, constitutes a significant blow to the efficiency of the DAO, which would now need to repeat the entire process.
To counter the above, as well as change the on-chain framework in a way that is beneficial beyond the problem at hand, we propose:
- Adding an on-chain way for multiple proposals to be proposed in one transaction;
- Allowing for multiple proposals to be voted on in one transaction (without requiring to sign multiple times).
Thus, a delegate could propose multiple, separate proposals (subproposals) with separate payloads in one transaction which would resultingly follow the exact same lifecycle. Similarly, voters could vote on multiple subproposals within a single transaction. By updating the existing Tally UI, they should also be able to decide on a yay/nay/abstain vote at the bundle level, as well as at the level of each subproposal, giving more granularity over decisions and eliminating the risk of a bundle being struck down due to the inclusion of a controversial subproposal.
Importantly, the contract already supports users voting on multiple proposals in the same transaction, with the limitation of requiring multiple signatures (1 per each proposal) in the process (this is not true for proposers).
Consequently, a more lightweight approach can be considered, transitioning the complexity from necessary contract changes onto the UI. It would involve having the proposing delegate propose multiple subproposals separately, the governance UI being adjusted to display them as a single bundle, and the voters voting on a bundle in one transaction (but with multiple signatures).
Ultimately, we believe that the UX can be improved significantly on the UI level, regardless of what happens on-chain. We hope to open a discussion with delegates on this, since their perspective is critical, e.g., would the ability to vote on a bundle of pre-planned token registrations already be beneficial, while still requiring multiple signatures?
2. Secondly, we should make it as easy as possible for external teams to propose token registrations.
Teams coming to the DAO requiring a token registration vote should be able to easily understand how to approach it. One improvement here is the bundled proposal calendar. Another one is the recently-introduced token registration template, which can be used by anyone to generate a payload.
While there are certainly other improvements that can be made, the immediate next step would be to add the token registration template to the Tally interface so that payloads can be drafted there directly.
We again want to thank everyone for participating in this conversation and are looking forward to the upcoming working group call where further alignment can be reached.