[Draft] Implementing oSnap for Optimistic Governance

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.


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.

1 Like

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:


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.

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.