BIP - on chain execution of Snapshot outcomes

Status: BIP Author(s): 21xHR#6726, defi jesus#2761 Discussions-to: [Create a new thread on https://commonwealth.im/buzzed-bear-hideout and drop the link here] Created: 14 July 2022 Requires: [BIP number(s)] Implementation: [Added if BIP passes] ‌

Buzzed Summary To implement on-chain execution of Honeypot transactions based on Snapshot decisions to remove the need of multi signers. To include built-in Snapshot vote delegation.

Abstract If the BIP is implemented, the Zodiac Reality Module will be added and configured both on Gnosis and Snapshot. As a consequence, it will be possible to configure a Snapshot so that the outcome of the vote will trigger an on-chain transaction.

Motivation ‌

Motivation 1 To further decentralize the BBH DAO and fully decentralize the Honeypot.

Motivation 2 Address doubts about founders controlling funds.

Motivation 3 Address problems regarding multi signers availability.

Motivation 4 To clarify the Honeypot management system

Motivation 5 To further protect the funds

Motivation 6 To improve the speed of the transaction and hence the distribution of funds towards the committee and their respective multisig POD wallets

Motivation 7 To incentivize the effective implementation of the committees and associated multisig wallets.

Specification Overview

Here are the specification of the Zodiac Reality module: A Snapshot vote can be tied to one or more transactions that automatically execute depending on the vote outcome. Multisig and signatures are only needed to verify that transactions are not malicious and meet the DAO policies. One of the highest levels of decentralization for portfolio management. Money moves itself after the vote. Everyone has a panic button and can contradict a proposal.

The process has as much delay as we want. We chose a multi-sig as a safeguard option meaning that all transactions will be executed via the Snapshot module but multisig owners AK the security council will have the ability to veto malicious actions or act quickly in the case of an emergency. It should be emphasized that the multisig owners will only have the ability to veto transactions and won’t be able to directly make transactions.

The process is as follow: A Snapshot is set up with an associated transaction. The holders can see the details of the associated transaction. The holders vote on an outcome.
The Snapshot has an outcome. Execution request by any voter associated with a required bond (see technical specifications). Timeout period. *Any voter can dispute the execution by putting twice the initial bond. *If no one disputes the transaction, the process continues. Outcome finalized. Cooldown period. Transaction executed.

Snapshot delegation compatible This module is entirely compatible with the Snapshot vote delegation system.

Rationale ‌ There have been concerns about the lack of decentralization of the honeypot and about the founders still having their hands on the funds. Moreover, some community members previously on the Gnosis removed themselves from their signer role. As a consequence, it is clear that a proposal should be made to review the Honeypot management.
Besides the lack of decentralization, concerns have been raised regarding accountability and speed when taking action on behalf of the community. Regarding the lack of decentralization and accountability: this system allows the community itself to decide how the funds will be used and will provide the transparency needed to address these concerns. Regarding the lack of speed: This module allows setting up a time after which the transaction should be executed (see specifications). To further protect the Honeypot, moving its funds should be a simple yet slow paced task. As a consequence this proposal will push the implementation of the committees and the related multisig wallets within which the funds will move faster. There seems to be a consensus around the fact that the community shall have its hands on the funds and that these funds and the related transactions should be overseen, unbiased and managed in a transparent manner. Many objections from decisions come from the ideas of the founders keeping their hands on the Honeypot and this solution allows for a full decentralization of the Honeypot management hence wiping out these concerns by allowing the community itself to have full power over its highest level of funds, the Honeypot. Also, the low engagement on Snapshot vote which is a common problem in many DAOs reduces the speed of execution. This will easily be addressed with the ability to delegate his voting power which is quite common in the DAO framework and has also been requested in the past.

Technical Specifications

Implementation The Zodiac Reality Module will be added and configured both on Gnosis and Snapshot by defi jesus#2761 who will personally cover the associated gas transaction fees.
The documentation and all the steps required to set this module up can be found here: https://gnosis.github.io/zodiac/docs/tutorial-module-reality/get-started Another article covering the combination of Snapshot and Gnosis can be found here: https://blog.gnosis.pm/introducing-safesnap-the-first-in-a-decentralized-governance-tool-suite-for-the-gnosis-safe-ea67eb95c34f

Following the approval of this proposal, A dedicated “#security council” channel will be created within the BBH Discord A Discord announcement will be made to invite holders to self nominate specifying the requirements (see below) Within the dedicated Discord channel, each volunteer will post the following information and only these using this template: Username: Ethereum address: A brief Crypto/NFT experience and knowledge: A short text on what makes them a good candidate to be on the security council A #small-announcement will be made each day over a five days period following the approval of the proposal to remind the ability to apply as a security council member.

Setting up parameters https://imgur.com/a/8Nr2hrQ Timeout: period between the first execution request regarding a specific outcome and the cooldown period ⇒ 48 hours Cooldown: Duration required before the transaction can be executed (after the timeout has expired). ⇒ 48 hours Expiration: Duration that a transaction is valid. ⇒ 168 hours (7 days) Bond: Minimum bond required for the execution request to be accepted. New answers must be submitted with double the previous bond. ⇒ 20 BBH tokens To be noted: The following parameters imply the minimum duration for the whole process will be 5 days, 3 days Snapshot vote + 2 days Cooldown if the execution is made instantly after the end of the Snapshot voting period.

If there is a dispute over the execution of a transaction Any voter can contest an execution by putting in double the amount of the initial bound. Anyone can then counter this contestation and this can go as long as there will be someone with enough funds to contradict the decision. If no one contradicts the dispute, the transaction won’t be executed.

In terms of security This module has proved to be effective in multiple established DAO such as Aragon DAO, DAOHaus & Moloch DAO.

Snapshot built-in delegation system Upon approval of this proposal the Snapshot built-in delegation system will be activated by defi jesus#2761 and regular announcement will be made to invite holders to use that function while explaining its perks.

Copyright Copyright and related rights waived via CC0.