[Incubation] Integrate UMA's oSnap module

ShapeShift DAO
1

Summary

This proposal suggests the integration of UMA’s oSnap module by ShapeShift to decentralize and improve the on-chain execution of ShapeShift governance decisions.

Abstract

This proposal recommends integrating UMA’s oSnap module into the ShapeShift ecosystem to optimize and decentralize the on-chain execution of governance decisions. oSnap streamlines on-chain voting outcomes and allows DAO members to propose and execute Snapshot vote results, validated by UMA’s oracle. The incorporation of oSnap will provide the ShapeShift community with a transparent, decentralized governance process, while its language-based rules offer flexibility for custom rules and upgrades.

Motivation

oSnap provides a way for DAOs to decrease reliance on multi-sigs and provide communities an increased role in governance and execution of governance outcomes.

Specification

If this proposal passes, the integration of UMA’s oSnap module involves the following steps:

  1. Add the oSnap module to the ShapeShift Safe through Zodiac.
  2. Determine oSnap parameter values for the proposal bond and challenge period.
  3. Deploy and configure the oSnap module to the ShapeShift Snapshot Space using the SafeSnap plugin.
  4. Snapshot proposals can now use Snapshot’s transaction builder to include transaction data that can be proposed and executed on-chain when the Snapshot voting period ends.

A test oSnap module on the Goerli network can be deployed by UMA for community members to evaluate its functionality. Additional information and a video walkthrough on oSnap deployment can be found in the UMA docs: https://docs.uma.xyz/developers/osnap/osnap-quick-start

Benefits

By integrating UMA’s oSnap module:

  1. ShapeShift inherits UMA’s network of validators who are financially incentivized to monitor and dispute invalid proposals.
  2. oSnap can prevent common DAO-related issues like treasury mismanagement and delays as it optimizes for transparency and efficiency.
  3. oSnap reduces reliance on core teams by handing control over to the community. Only one person needs to raise a dispute to stop a transaction that was not approved by the DAO from being executed.

Adding oSnap to an existing Snapshot Space and Safe is fast and free. The contract has been audited

  1. by Open Zeppelin.

Drawbacks

Potential drawbacks of integrating UMA’s oSnap module into ShapeShift may include:

  1. Depending on the length of the challenge period set on deployment of the oSnap module, this may cause a delay in transaction execution. UMA recommends a challenge period of at least 12 to 24 hours, although some DAOs may choose to make their challenge period longer.
  2. The current ShapeShift proposal process does not always strictly define the transactions to execute in advance, but a typical oSnap flow would be to create a bundle of transactions through Snapshot’s transaction builder, include them in the Snapshot proposal, and then simply execute the transaction bundle by clicking a button on Snapshot after they are approved. If the exact transactions for a Snapshot proposal are not defined in advance, or can not be executed all at once, this may require a more complex flow where the transactions are described in natural language and voted on, and then only after the vote concludes are the specific transactions created, proposed and executed through oSnap outside of the Snapshot interface. This might require extra work and testing to ensure that no additional risks are introduced. However, it is very similar to the current flow where transactions are usually created and executed by the ShapeShift multi-sig after a Snapshot vote.

Despite these potential drawbacks, we believe the benefits of integrating UMA’s oSnap module into ShapeShift outweigh any challenges, ultimately providing users with an enhanced governance experience that is significantly more decentralized and trustless than using a multi-sig.

2

Thanks for building oSnap and making this proposal @alexuma & Uma team!

Very excited about the prospect of implementing oSnap to both give the community the ability to execute transactions quickly while also paving the way to one day remove the multisig.

To minimize the risk of malicious transactions going unchallenged, we could even start with a challenge period of 48 hours, and then decrease the wait once we feel comfortable.

I know it just launched, but are there any examples of DAOs using oSnap yet @alexuma?

3

Hey @willy, thank you for your comment!

Starting with a challenge period of 48 hours is a good idea, as the wait time can be updated later once the team feels comfortable by calling setLiveness on the oSnap module.

The Snapshot integration was recently completed and we are in discussions with several teams. Across DAO will likely be the first integration, and the team is currently finalizing contract parameters. You can read more about the Across integration of oSnap in their blog post under the “Optimistic Governance” section: https://medium.com/across-protocol/across-bold-moves-ahead-ccb5bad91886.

Let me know if you have any other questions!

4

wow

6

@basket random It is a good idea to begin with a challenge period of 48 hours because the wait time may be modified later once the team feels comfortable by calling setLiveness on the oSnap module. Starting with a challenge term of 48 hours is a smart idea.