[SCP - 133] Ideation: Integrate UMA's oSnap module

Proposal Discussion
1

For more background and discussion, please see [Incubation] Integrate UMA’s oSnap module.

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.

Vote

For: Integrate UMA’s oSnap module

Against: Do not integrate UMA’s oSnap module

Feedback is welcome and appreciated. The UMA team also plans on joining the ShapeShift governance call on March 30th to answer any questions.

2

I would have to ask @willy 's thoughts on this. (security wise etc) but from what i understand, its a good step forward. Thanks!

3

Thanks for the response @Giantkin!

Willy has helped communicate with us on how oSnap can best support ShapeShift. We are joining the governance call tomorrow and happy to answer any questions you have around security/implementation details!

4

Thats the questions i would defer to willy, was my point :slight_smile:

5
  1. as mentioned in the incubation post, I'm in favor of implementing oSnap to improve the speed and ease at which FOX token holders can execute valid transactions on the DAO treasury without the multisig, and to help pave the road to one day remove (or significantly reduce the capabilities of) the multisig once we're confident in oSnap.

    A couple things I would like to see before we make this important change:

    Can we specify the parameters that will be set at launch? I recommend a FOX bond of 100,000 FOX (what we currently have with SafeSnap), but would appreciate any suggestions on whether that’s too low or unnecessarily high, and a 48 hour challenge period to start with. Could even include language to approve decreasing the challenge period to 24 hours in a few months if we test (or an anon tests) at least 3 invalid txs and we see that they’re all challenged in <12 hours.

  2. Really appreciate the offer for Uma to deploy an example oSnap module on testnet so the community can give it a spin, and would love to take you up on this

Another q I wanted to follow up on is whether transaction(s) need to be included in a snapshot proposal, or if it’s possible for arbitrary transactions that the community has implicitly approved via snapshot proposal to be executed via oSnap. (for example, if TMDC votes to approve a tx that is within the guidelines of their last proposal, can that tx be executed without ever being included in a snapshot proposal)

Last q for now, have any oSnap txs been proposed on mainnet yet? I was trying to find examples on https://oracle.uma.xyz/ but couldn’t find one yet

6

Hey Willy, I’ve flagged your comment for Alex and can reply to my knowledge:

It actually looks like the bond needs to be set in USDC or WETH, at least based on the UI in the demonstration video.

  1. Your challenge window suggestion matches what we have been thinking and plan to do for Across.

I’ll let Alex get your other questions. Which is to say, I wasn’t very useful here I just wanted to say hi :joy:

7

You can set the bond token to FOX easily after deployment, though! We just made USDC and WETH the defaults in the deployment UI so as to not overwhelm deployers with too many options. Any token approved as an UMA “collateral currency” can be used as a bond, and it’s pretty easy to approve new tokens if you want to use one that’s not on the list.

https://docs.uma.xyz/resources/approved-collateral-types

8

I’m going to dig deep into your other questions! Sorry for the long post, just want to get all of my thoughts down and make sure we cover all of the details and considerations.

USING FOX AS A BOND TOKEN

One downside of using FOX as a bond rather than USDC or WETH is that third-party disputers are less likely to have enough FOX on hand to dispute if they spot a bad proposal. That, along with ease of use for deployers, is why we set USDC and WETH as the default options.

There are pros and cons to using FOX as the bond token.

Pros:

— Proposers and disputers are FOX holders, showing they have “skin in the game” for ShapeShift’s DAO, specifically.

— It’s harder to grief proposals, by continuously disputing valid proposals to slow down execution, because the griefer will need to keep acquiring FOX to do so. (Regardless of what bond token you use, the griefer can only delay execution for as long as they are willing to keep losing money, but they’re at a severe disadvantage if they have to use your DAO’s own token, since DAO members can pull liquidity, raising the price.)

— It’s harder to continuously make bad proposals, for the same reason. Assume that a bad proposal is coming from a malicious actor who gathered 100,000 FOX for that purpose. If they are disputed once, they are now out of FOX and will need to get more to try again.

Cons:

— Honest third-party disputers may not have enough FOX to raise a dispute, or any FOX at all. You will need to cultivate a disputer network of FOX holders ready to dispute within the challenge window.

— If DAO members are actively monitoring proposals, and the challenge window is long enough, that might be fine. But it does mean you will probably want to have a long challenge window for safety. Imagine the scenario where you have half a dozen active disputers with enough FOX tokens to dispute a bad proposal, and a solid record of bad proposals getting disputed within an hour. That feels safe, until an attacker makes a malicious proposal on Christmas Eve and your challenge window is only 24 hours. In a Christmas Eve Attack, having WETH or USDC as your bond token gives you a larger third-party disputer network. You should design your bond token, bond amount, and challenge window in expectation of Christmas Eve Attacks.

— If you want third parties outside of your DAO to be able to easily dispute bad proposals, you might want to loan them FOX to do so, or have a standing offer to reimburse disputers for their slippage and gas costs to buy FOX on Uniswap, something like that.

BOND SIZING

100,000 FOX is about $3,400, which seems like a reasonable size. That will make proposing efficient, since you should have many DAO members with enough FOX to propose after a vote. It will also be manageable for disputers who don’t have FOX on hand and need to buy it on Uniswap to raise a dispute.

One concern you might have is that malicious proposers can also easily acquire enough FOX to attempt an attack multiple times, but our experience with Across is that when an attacker gets disputed once they tend to give up. They’re just testing to see if someone is actually online to dispute.

CHALLENGE WINDOWS

I like the plan to launch with a 48-hour challenge window at first and lowering the challenge window after testing that the dispute system is resilient. In the spirit of maximum paranoia, you might want to time those tests to line up with scenarios where an attacker might expect disputers to be offline—for example, during a major holiday, during a crypto conference where ShapeShift is a sponsor, during an Infura outage, etc.

TESTNET MODULE AND MAINNET PROPOSALS

  1. I’ll get these ready for you! We’re actually rolling out some oSnap updates over the next few days:

    Updating the oSnap module contract (the OptimisticGovernor) to use our latest oracle contract (OptimisticOracleV3). We should have our final audit feedback today and then we will update the master copy of the contract in Zodiac.

  2. Automatically delete disputed proposals, so that they can be easily re-proposed if they were valid. With the old version of the contract (and Snapshot integration) you would need to manually delete the old proposal to create a new one.
  3. Use the ASSERT_TRUTH identifier rather than the ZODIAC identifier.
  4. Some additional quality of life improvements to the Snapshot interface.

I’ll post in this thread once the testnet module and mainnet example proposal are available; I just want to make sure they’re using the latest features and contract version.

UNDEFINED TRANSACTIONS THAT WERE IMPLICITLY APPROVED

It’s certainly possible to submit proposals on-chain through oSnap to execute transactions that were described in a Snapshot vote but not strictly defined. In that scenario, though, you want to make sure your challenge window is long enough for disputers to read the proposal and study the transactions being submitted to make sure that they’re okay. This is more of a human-driven, manual process, and harder for validators to monitor in an automated way. You have to study the proposal and the transactions and apply human reasoning.

It’s also a good idea to make sure the transactions being described are very simple and straightforward, and that it can be 100% clear that the on-chain transaction proposal matches what was written in English in the Snapshot proposal. For example, “We vote to pay willy 1 ETH per month for the next six months,” is a good proposal. “We agree to pay the marketing committee whatever funds they need for reasonable expenses,” would be a bad proposal, since it’s ambiguous.

Side note: For transactions that were implicitly approved, those would need to be proposed on-chain directly (through Etherscan, for instance) since you won’t have any way to propose them through the Snapshot interface. The manual proposal should include the IPFS identifier of the Snapshot vote in the “explanation” field, though, just like a proposal with explicitly defined transactions.

9

Thanks so much for the detailed response @jdshutt

So glad to hear that txs not explicitly defined in proposals are possible, that’s huge. Maybe one day we can create a nice UI for it.

Personally I still think using FOX is the way to go, but not opposed to using ETH instead. Curious to hear other community member’s thoughts on that.

Excited to hear about these latest improvements and look forward to testing oSnap out!

10

48hrs to me is a must. (that xmas eve factor) if i saw it on xmas eve, it might be ok, but if i missed it, and now its xmas day, and i checked 10m too late…

11

We’re paying close attention to what DAOs are requesting so we can add new UI features, too. :slight_smile:

One feature request that’s come up a few times is being able to vote on a Snapshot proposal that includes multiple transaction bundles that are executed at different times, like the monthly payouts I included as an example. It would be nice to be able to do that natively within the Snapshot interface but would definitely take some work.

Edit: One more thing to add about transaction approvals. There are also flows where you update your rules to grant general permissions to certain addresses, rather than approving specific transactions. As an example, you might approve a treasury management strategy that allows the swap of USDC for ETH in certain circumstances, and a list of treasury management addresses that are allowed to execute those swaps. If that is added as a general rule, you don’t need to have a Snapshot vote on each swap. Remember that the on-chain rules string can be changed to reflect any new rules or permissions you might add.

12

By the way, @alexuma set up a demo space and shared the link in the governance call thread. This test vote has closed but nobody has proposed the transactions yet, so if anyone wants to propose and execute, you can do that! It’s on Goerli, so you’ll need a little bit of Goerli ETH.

https://demo.snapshot.org/#/shapeshift-osnap.eth/proposal/0xa14fb93a427144683a606e36dbd25d16a07891deb5e8ced3e5d9d01375efac3a

13

Also, heads-up that we’re releasing some new features for oSnap over the next week and a half, using an updated contract targeting the latest UMA oracle contract, OptimisticOracleV3. There are some details in this Twitter thread:

https://twitter.com/jdshutt/status/1642939777510146048?s=20

Let me know if you’re doing any testnet deployments in the near term (next ~10 days) so I can help! There are a few moving pieces—Snapshot release, Zodiac release, oracle dapp release—that may come out on different days, so it will have more manual steps than usual.

14

@Giantkin @raja1968 @Fireb0mb1 @willy

I see that you all voted to move forward with amendments/changes and I wanted to make sure I incorporate those changes before advancing to the Voting phase. What would you like to see in the proposal?

15

thanks @jdshutt! only changes I wanted to see was specification in the proposal for both the bond amount (100k FOX) and initial challenge period (48 hours). I also think it would be great to proactively approve decreasing the challenge period to 24 hours if we (or an anon) tests 3 invalid txs and we see they’re all challenged in <12 hours, but up to you on whether or not to include that

16

Thanks @willy! I’ll put up a Snapshot proposal this week.

17

It seams a great step forward. While i didnt know about UMA from what i see seems great!

18

s is a great investment deal. Visit https://timebrookinvestment.com/u/sign_up?r=bobbey and navigate to select your preferred package. Click the link beneath to join the group of investors now t.me/+L_3GDbXlz904MDg0Mgg