[RFC] Add oSnap to Euler DAO

General Proposal RFC
1

Title: [RFC] Add oSnap to Euler DAO
Author(s): @Bobbay
Submission Date: 22nd April 2024

Simple Summary
We propose adding oSnap, a governance tool developed by UMA, to the Euler Safe to allow for automatic onchain execution after successful Snapshot votes.

Abstract

oSnap secures over $700M 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 $1.4B of TVS across bridges, prediction markets and governance tools.

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

Specification/Body Text

Once enabled, Snapshot proposals related to the distribution of funds from Euler can include transaction data with the proposal. After a successful Snapshot vote, the transaction is put onchain and verified by UMA’s optimistic oracle before being executed by the Safe. There will be no changes to the Euler treasury or proposals for treasury distributions or social votes relating to governance, removing a director, etc.

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

  • An oSnap enabled Snapshot proposal is created. This process is the same as a normal Snapshot proposal with the addition of transaction data that will be verified and executed if the proposal passes. The Snapshot transaction builder is specifically designed to make it easy to create and verify transaction data for token transfers.
  • EUL holders vote on the proposal like any other Euler Snapshot proposal
  • If EUL 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 implemented 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.
  • In case of a dispute, the proposal is not executed. 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.

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

UMA created and maintains oSnap as a public good with no implementation or usage fees because we believe decentralized governance tools are critical to the entire Web3 ecosystem. Since UMA is already running robust monitoring across all of our optimistic oracle integrations and can recycle the bonds posted, the additional costs associated with these services are negligible and it is sustainable to continue providing this service for DAOs. If any changes were to be made in the future, we are committed to having existing DAOs not face any changes (aka be “grandfathered in”).

Next steps

oSnap is a module that is added to a Safe with rules on how to evaluate a Snapshot proposal. 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.

If required, the UMA Team is here to help the Snapshot admin enable oSnap.

Relevant Links

Pros and Cons of This Proposal

Benefits

The benefits of Euler adopting oSnap are:

  • oSnap enables EUL voting to govern how Euler funds are allocated and remove the reliance on the Safe multi-sig signers.
  • Transaction payloads included in proposals that are approved by voters are trustlessly and permissionlessly executed which increases transparency and decentralization.
  • Automatic transaction execution by UMA bots is faster than waiting for multi-sig signers along with the bot paying the gas costs for execution. The gas cost of the transaction execution is paid for by these bots instead of the multi-sig signers.
  • The UMA team is continuously making frontend improvements as per user feedback and improving open source monitoring infrastructure for oSnap.

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.

Drawbacks

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

  • Yes, in favour of the proposal
  • No, against the proposal
  • Modify the proposal
0 voters
1 Like
2

I just have one question.
Why then use Tally or why use oSnap if there is Tally?

3

Valid question. Both play an important role in a governance pathway and can play the same role or different roles depending on the governance process.

In Euler’s case, although a Tally has been set up, it hasn’t been used in the governance process and generally snapshot votes were seen as binding, as you can see in the snapshot history.

Snapshot + oSnap = Off-chain voting + on-chain execution
Tally = On-chain voting + on-chain execution

The major difference is voting; snapshot voting is an off-chain. Therefore, voting is free.

Tally voting is onchain, therefore placing a financial cost on the voter.

Tally is a great tool. However, voters paying on-chain gas to vote is not a great UX and can deter voters from participating, especially individuals or smaller voters. Also, EUL voters are already used to solely voting on Snapshot proposals; therefore, with oSnap, they get to enjoy further decentralization without adding further friction to participate in governance.

1 Like
4

It’s great to see a proposal for oSnap. Bringing onchain execution to Snapshot votes has the potential to reduce the overhead associated with coordinating onchain execution from the treasury.

The current proposal threshold (500 EUL) and quorum requirements (50,000 EUL) for Euler DAO may create risks for the DAO if oSnap was to be implemented. The two risks that are top of mind for me are:

  1. Incentivising proposals that are unlikely to be passed, creating an unreasonable expectation on Delegates; and
  2. Creating a honey pot for malicious proposals.

The Foundation is conscious of improving Delegate engagement to increase the resilience of the DAO. As it stands, I’m not sure the increased efficiency from implementing oSnap outweighs the risks to the DAO in its current state.

1 Like
5

Sounds good and thank you for the feedback! We will pause the proposal until Euler is ready to integrate oSnap. To respond to your above points:

  • For most DAOs that have integrated oSnap, there is a slight uptick in the number of proposals from onchain actions that were previously executed by the multisig signers. However, most DAOs set parameters in the Snapshot settings to determine who can create a proposal and/or moderators to prevent spam. Since proposals are required to meet the minimum quorum/voting period and have a majority in favor of the proposal can be proposed, any spam or malicious proposals that didn’t meet the criteria for a valid proposal and transactions were proposed would be automatically disputed and the proposer would lose their bond.
  • For the point of creating a honey pot, it is important to understand the risks of malicious proposals going undisputed. UMA has created robust monitoring in the form of a bot that automatically disputes invalid proposals and a verification team that manually checks the intent of transactions to ensure nothing malicious is voted on or proposed. The verification team has caught several errors (not necessarily malicious) and would have likely been executed if solely relying on other multisig signers to review before executing.

Thanks again for your feedback and I look forward to the opportunity to revisit in the future!

1 Like
6

What is the success rate?

1 Like