P-36: Implementing oSnap for Optimistic Governance

👩🏽‍⚖️ Proposals
1

Abstract: This proposal aims to integrate oSnap 2, an optimistic governance tool developed by UMA, into Developer DAO’s governance system. By leveraging oSnap, Developer DAO can execute the results of Snapshot votes on-chain, eliminating reliance on multi-signature wallets and promoting a more decentralized and efficient execution process.

Author Description: I am the Head of Growth at UMA. At UMA, I’ve led insurance, prediction market, and KPI option integrations. Prior to UMA, I am the head of Partnerships for Developer Dao and still an active steward for Developer Dao.

Team Description: The proposal is backed by Risk Labs, the dynamic and experienced team behind the development of the UMA and Across protocols. We are doxxed, well funded, and have a high bar for all of our code. Our oracle smart contracts have been audited by Open Zeppelin and secure over $100 million in value.

Motivation: The motivation for this proposal is to enhance Developer DAO’s governance system by making it more efficient, secure, and decentralized. Current DAO governance models often rely on multi-signature wallets for the execution of proposals, which can lead to delays and potential security vulnerabilities. Implementing oSnap, which allows for on-chain execution of off-chain votes, would eliminate the dependency on multi-sig wallets and the associated issues. Furthermore, oSnap’s dispute mechanism and incentives for correct submissions help maintain the integrity and accuracy of the decision-making process. By adopting oSnap, Developer DAO can streamline its governance process and empower its token holders, thereby upholding the true spirit of decentralization.

I’ve started chat around oSnap with @Kempsterrrr but I would love feedback from the larger community. As Developer DAO charts the course for its future governance, and all eyes are on elections and the governance process, I thought this was a good time to bring oSnap to the broader community for feedback.

Rationale: The integration of oSnap into Developer DAO’s governance aligns with the DAO’s mission of decentralization and community involvement. Implementing oSnap will not only streamline the governance process but also eliminate the need for reliance on multi-signature wallets, thereby promoting more direct community control.

This approach aligns with the DAO’s guiding value of decentralization by reducing the need for intermediaries and giving more power to the token holders. Moreover, oSnap’s dispute mechanism provides an extra layer of security, ensuring that the outcomes of governance votes accurately reflect what was approved on Snapshot and that the transaction payload matches what was described in plain English. Finally, the integration of oSnap is free and easy, making it a practical choice for enhancing Developer DAO’s governance.

Since its launch earlier this year, oSnap has been adopted by Across, BarnBridge, and ShapeShift to control their on-chain treasuries, securing over $40 million in value. oSnap is also being used by Lossless Protocol to secure their next generation of wrapped tokens. There are a few other deployments that haven’t been announced yet.

Key Terms:

  1. oSnap: A tool developed by UMA that allows for on-chain execution of off-chain votes, streamlining the governance process of DAOs.
  2. Optimistic Governance: A governance method where anyone can submit transactions to implement a proposal. If no dispute about the proposal’s accuracy arises during a dispute window, the transactions will go through.
  3. On-chain Execution: The process of implementing the results of governance votes directly on the blockchain, enhancing transparency and efficiency.
  4. Off-chain Votes: Votes on Snapshot that occur outside the blockchain but whose results can be implemented on-chain.
  5. Multi-signature Wallets: Digital wallets that require multiple signatures to execute a transaction, often used in DAOs for executing proposals, raising centralization risks.
  6. Dispute Mechanism: A system within UMA that allows for disputes over the accuracy of a proposal. In the event of a dispute, the transactions are not executed and need to be re-proposed. UMA’s voting system identifies the correct party in the dispute (the proposer or the disputer) and rewards them with the losing party’s bond.
  7. Optimistic Oracle: A decentralized on-chain oracle for resolving flexible data requests. UMA’s optimistic oracle can handle natural language questions, like whether a set of transactions were approved on Snapshot and match what was described in the Snapshot vote.

Specifications:

UMA’s oSnap is a tool for making on-chain transactions based on off-chain voting decisions. After integration of oSnap, the flow works like this:

  • A Snapshot proposal can include a transaction payload that is executable if the proposal is approved by the DAO.
  • After a vote completes, any address can post a bond and propose to execute the transactions on-chain by clicking a button on Snapshot.
  • If no dispute arises about the proposal’s accuracy during the dispute window, the transactions are executed.
  • In case of a dispute, the proposal is not executed and needs to be re-submitted. UMA token holders will determine who was correct in the dispute, with the correct party rewarded from the opposing party’s bond.

Steps to Implement:

  1. Deploy a Safe to hold Developer DAO assets.
  2. Install the Zodiac app.
  3. Deploy an oSnap module through the Zodiac app.
  4. Add oSnap to the DevDao Snapshot space through the SafeSnap plug-in.

Timeline: This process can be implemented in a single afternoon, given the straightforward nature of the setup process.

Overall Cost: There are no fees associated with the implementation of oSnap, and it does not require any additional manpower beyond the existing governance working group. There are also no fees to use UMA’s oracle to verify oSnap requests. Therefore, the overall cost of implementation is zero.

2 Likes
2

Thanks for sharing this @mannyornothing - as you stated, we’ve had a few chats about this already, and I personally support moving towards this reality, in time.

I’ve updated the title to be more specific.

Some very important things to consider as part of this proposal:

  1. Whilst it removes the need for multi-sig signers to sign budgets, which is a plus, right now, only Stewards can elevate proposals to Snapshot to the blocker still remains. I propose we explore changing this privilege back to a threshold of token holders (substantially lower that the previous 50k) and re-consider the role stewards play in Governance.

  2. We need more detail regarding disputes… the only reason I can see for disputing a vote is the DAO is asking the Foundation to break the law. What does “UMA tokens holders will determine who was correct in the dispute” practically mean? If they’re resolving the dispute but don’t understand Cayman law, nor do they have a fiduciary responsibility not to break those laws as a director, how do we reconcile that? (I understand you’re rolling this out with other DAOs who have Cayman Foundations, so imagine this isn’t the first time this question has come up)

Some initial questions/observations. I will circle back next week when I have some more time. :slight_smile:

@stewards

3

The oSnap rules are used to evaluate if transactions included in a Snapshot proposal are valid and can be executed based on certain criteria of the proposal such as meeting the minimum voting period, minimum quorum, and Snapshot not being exploited. Voters are not asked to interpret laws or the contents of the Snapshot proposal. This is the current template that is used by oSnap integrations:

I assert that this transaction proposal is valid according to the following rules: Proposals approved on Snapshot, as verified at Snapshot, are valid as long as there is a minimum quorum of {quorum_value} and a minimum voting period of {voting_period} hours and it does not appear that the Snapshot voting system is being exploited or is otherwise unavailable. The quorum and voting period are minimum requirements for a proposal to be valid. Quorum and voting period values set for a specific proposal in Snapshot should be used if they are more strict than the rules parameter. The explanation included with the on-chain proposal must be the unique IPFS identifier for the specific Snapshot proposal that was approved or a unique identifier for a proposal in an alternative voting system approved by DAO social consensus if Snapshot is being exploited or is otherwise unavailable.

4

Hey Developer DAO, my name is Alex from the UMA team and I focus on helping DAOs integrate oSnap. I am happy to answer any questions and also want to make sure the community understands how oSnap works with Snapshot and the user flow.

I deployed a test oSnap module on Goerli and set up a test space and proposal:

For simplicity, the test proposal is a simple ETH transfer and the oSnap module has a bond value of 0. In production, oSnap integrations use a bond (typically a few thousand USD) and a challenge window of 2 to 5 days to prevent malicious proposals and disputes. I proposed the transactions and anyone can execute once the challenge window is completed.

Feel free to also create your own Snapshot proposal with transactions and ask any questions as you go through the process. Please note, the safe associated with the oSnap module is 0x7aAEE1C36ddD4Dc3Ed45e8A2f7102f8C30e28DFE on goerli so you can either do an ETH transfer or send test tokens to the safe that you want to interact with.

1 Like
5

Hey Developer DAO! The UMA team (@mannyornothing, John, and I) had a great call with @kempsterrrr earlier today. We focused on security concerns and how these are mitigated with the oSnap design. Here are the main talking points to keep everyone on the same page and we are also happy to answer any unanswered questions from the community.

How does oSnap handle transactions that propose the DAO engage in illegal activities?

The first aspect to keep in mind is that for anything to be executed through oSnap it must pass through the Developer DAO governance process first. This means that a Snapshot proposal must receive a majority of the votes in favor of the proposal and both the minimum voting period and quorum were met. Transactions that do not meet this criteria and include a unique IPFS identifier pointing to a valid Snapshot proposal are disputed.

It is highly unlikely for something illegal to pass through the DAO with a majority of the DAO in favor of it. However, if this were to happen the DAO still has the option to do an emergency disconnect by having the multi-sig signers disable oSnap. This allows the DAO to pause transactions from being executed and talk through the situation. oSnap can easily be reenabled when ready.

Another concern we talked through is the 2 WETH bond required to be posted for valid Snapshot proposals

This is a common concern as it will be difficult to encourage DAO members and communities to post the bond for a 1-3 day challenge period for transactions to be executed. Therefore, UMA has implemented a bot that verifies Snapshot proposals and, if valid, automates the execution by posting the bond that anyone in the world can dispute if wrong. The same bot also monitors all proposals and automatically disputes malicious proposals. The bot also pays the execution costs for transactions going through oSnap making the governance process essentially free for DAOs.

UMA takes monitoring efforts seriously and each oSnap proposal is also manually verified by a decentralized network of verifiers in the UMA Discord. Not only are the Snapshot proposal params checked (results, quorum, voting period), but also elements of the proposal that are difficult to automate such as the intent of the proposal matching the transaction payload, the Safe is not interacting with a malicious contract, etc. The bot combined with manual verification would prevent situations such as what happened with Gitcoin sending a transfer to the contract address from happening.

1 Like
6

bumping this - thanks for answering the questions above! With Uma covering the bond and an ability to more cleanly “veto” in extreme cases, I only really see upside in this and support updating this proposal and putting it to the community for a vote.

7

Updated Proposal

[Draft] Implementing oSnap for Optimistic Governance

Authors: Bobbay, Manny & Alex @ UMA

Summary

The adoption of oSnap for Developer DAO would eliminate the need for multisig execution by automatically executing successful Snapshot votes onchain, thus consolidating the governance process to one gasless vote on Snapshot that results in onchain execution.

Motivation

We believe decentralized governance is critical to the entire web3 ecosystem. The traction of oSnap has shown us that DAOs are increasingly committing to this as well; as such, UMA continues developing oSnap with no fees for the betterment of the industry at large.

Adding oSnap streamlines the execution of governance decisions, brings a new layer of efficiency and reliability to Developer DAO. This requires minimal effort and no disruption to existing DAO governance processes. UMA even covers the onchain execution costs for every oSnap proposal.

oSnap secures over $300M for treasuries including CoW Protocol, Across, Connext and Shapeshift. A dashboard of all oSnap users can be viewed here. oSnap was built by UMA, an experienced leader in optimistic verification. UMA’s optimistic oracle currently secures $700M of TVS across bridges, prediction markets and governance tools.

Scope of Work

oSnap Safe app lets you add oSnap to your Snapshot space and Safe in a few minutes with no developer time required. A video demonstration of the oSnap Safe App can be viewed here.

Once enabled, Snapshot proposals can optionally enable oSnap and include transaction payloads within the proposal to be automatically executed after a successful snapshot vote. Learn how to upload a proposal with oSnap here.

The updated Snapshot flow for proposals that include transaction payloads would be:

  • An oSnap-enabled Snapshot proposal incorporates transaction data, to be verified and executed upon passing, with a user-friendly builder for creating and verifying token transfers.
  • CODE holders vote on the proposal like any other Safe Snapshot proposal
  • If CODE holders approve the proposal by vote, any address can post a bond (2 WETH) for a challenge period (1 to 3 days) and propose to execute the transactions onchain. UMA has imple
  • mented a bot that validates proposals (vote passed, meets min voting period/quorum) and posts the bond for DAOs along with covering gas costs for execution (there are no fees to use oSnap).
  • If no dispute arises about the proposal’s accuracy during the challenge period, the transactions can then be executed. This is also executed by UMA’s bots
  • In case of a dispute, the proposal is not executed.

Here are examples of where oSnap would have streamlined the process:

Dispute process

  • Anyone can dispute by navigating to https://oracle.uma.xyz/ and finding the relevant proposal to initiate a dispute by posting a bond.
  • UMA token holders vote to resolve the dispute, with the correct party rewarded from the opposing party’s bond. This bonding and dispute mechanism punishes incorrect proposers and disputers and incentivizes honest disputes.
  • Any proposal that was incorrectly disputed can be re-proposed to the oracle for execution without requiring revoting. It is important to note, the dispute resolution decided by UMA token holder votes are not deciding if the transactions can be executed or not, only the bond allocation between the proposer and disputer…

Monitoring

UMA has also focused significant resources on monitoring efforts:

  • The same bot that proposes and executes transactions also automatically disputes inaccurate proposals if the following criteria are not met:
    • The proposed onchain transactions match the transactions that were approved in the Snapshot proposal
    • The Snapshot proposal passed with the minimum parameters specified (majority in favor, meets minimum voting period and quorum)
    • The proposal follows the strategy specified in the Snapshot space.
  • Proposals are included in the UMA Oracle UI (https://oracle.uma.xyz/) which is the same interface used by disputers verifying and disputing for other third-party integrations (Polymarket, Sherlock, Cozy, and other oSnap integrations).
  • UMA sponsors a verification program, that pays UMA community members to verify all optimistic oracle assertions so when any transactions are proposed through oSnap, a Discord ticket is automatically created and an experienced verifier from the UMA community completes a multi-step verification process that focuses on areas such as the transaction payload matching the intent of the proposal, verifies transactions do not include interactions with malicious contracts, etc.

SafeGuards

DAOs can take it a step further by adding the Roles modifier via the Zodiac module to specify which addresses can call the relevant functions in the Delay modifier to veto transactions. In this oSnap deployment, the Developer DAO Multisig will have permission to veto transactions.

There is still an important trust consideration: If the holder of the veto power is malicious or makes a mistake, they can disrupt the execution of a proposal without having to post a disputer bond.

Drawbacks

While oSnap has been audited by Open Zeppelin, as with any system, there may be unforeseen vulnerabilities.

Here are the audit reports by Open Zeppelin:

1 Like
8

thanks for shipping this updated proposal @Bobbay - I’d love us to have a community call about implementing this, are you/others in oSnap up for that?

The only thing I feel needs discussion here is where the veto power resides and who holds the keys. I suggest the veto power resides with the Stewards on a majority vote and the keys are linked to the devdao.eth EOA that myself and @wolovim have the keys too.

once these are defined I fully support this proposal, reducing the need for signers helps reduce the load on the @stewards, decentralises the DAO and Uma covering gas is great.

9

Yep, we will reach out to find a suitable time to have a community call!

I agree with your logic on who should have the veto power. We can discuss it further on the community call to get other peoples ideas too

1 Like
10

Confirmed 5pm tomorrow (Thursday 25th) with @alexuma

Luma RSVP For calendar invite - Governance Call: Implementing oSnap for Optimistic Governance · Luma

Call will be hosted on developers-voice in discord

1 Like
11

Video for the community call today discussing this proposal.

TLDR - sentiment from the call was very positive and as a steward I support elevating the proposal to snapshot with an initial challenge period of 3 days.

Reasoning:

  1. Removes reliance on multi-sig signers
  2. Improves decentralisation by removing the reliance on the signers
  3. Saves on gas fee’s executing transactions from the Treasury

After listening to @alexuma and @mannyornothing I don’t see the need to implement the Zodiac module, curious if this can be easily added at a later date if the DAO decided it wanted this in place?

1 Like