[1IP]: Migrate from Reality to oSnap for Snapshot Execution

2.1 General Proposals
1

Simple Summary

This proposal suggests implementing oSnap within 1inch’s current SafeSnap setup to replace the Reality oracle with the UMA oracle for the execution of governance decisions by 1inch token holders.

https://docs.uma.xyz/developers/osnap

Abstract

The 1inch DAO currently utilizes SafeSnap for the execution of governance decisions, which involves the Reality oracle. This proposal suggests transitioning from Reality to oSnap, while staying within the SafeSnap framework, for improved security and monitoring, better user experience, and access to future product features.

Motivation

The implementation of oSnap aims to streamline the execution of governance decisions, bringing a new layer of efficiency and reliability to 1inch DAO while requiring minimal integration effort and no disruption to existing DAO governance systems.

Specification

UMA’s oSnap is a tool for executing on-chain transactions based on off-chain voting decisions.

Since 1inch already uses SafeSnap, the integration would only take three steps:

  1. Add the Zodiac app to the 1inch Safe.
  2. Deploy the oSnap module through the Zodiac app, setting the challenge window, bond requirements, and minimum voting period and quorum on Snapshot.
  3. Set the module address as the umaAddress in the SafeSnap configuration file.

After integration of oSnap, the execution flow proceeds as follows:

  • After a Snapshot vote completes, anyone can click a button to propose the associated transactions on-chain.
  • If no dispute arises about the proposal’s accuracy during the challenge window, anyone can execute the transactions.
  • In case of a dispute, the transactions are not executed and need to be re-submitted. UMA token holders will then determine who was correct in the dispute, with the correct party rewarded from the opposing party’s bond.

The implementation of oSnap within 1inch’s existing SafeSnap setup is expected to be swift and efficient, requiring minimal engineering resources. oSnap is fully compatible with 1inch’s current governance structure as it replaces the Reality oracle but does not alter the fundamental mechanisms of the Snapshot voting system, the SafeSnap plug-in, or the Safe wallet infrastructure.

The oSnap contracts have been audited by Open Zeppelin. oSnap is currently being used by ShapeShift, BarnBridge, and Across to manage their treasuries in a decentralized way.

Rationale

oSnap is integrated with SafeSnap but uses the UMA oracle rather than the Reality oracle as the verification method. There are a few big advantages to oSnap.

  1. Stronger security and monitoring. With Reality.eth, you are responsible for monitoring your deployment and catching bad proposals. Theoretically third parties have a financial incentive to monitor proposals but in practice that is unlikely to happen. With oSnap, proposals go to the same closely monitored oracle systems as Polymarket, Sherlock, Cozy, and other oracle requests. Your DAO proposals will populate in the oracle dapp (https://oracle.uma.xyz/) that makes it easy for people to identify and dispute bad proposals. In practice, questionable Polymarket proposals tend to be disputed within 30 minutes, and those proposals are harder to evaluate than oSnap proposals. Your proposals will also be pulled into bot monitoring systems members of our competitive validator network have set up, and you can use our open source code (https://docs.uma.xyz/developers/osnap/monitoring-bot-setup) to set up Slack, Discord, and PagerDuty alerts. The Risk Labs engineering team is continuously improving our monitoring and is currently developing a bot that will not only alert on proposals but could automatically dispute if an obviously bad proposal is identified.
  2. **Simpler and clearer dispute resolution. **Reality.eth has a multi-step escalation game where proposers and disputers post progressively larger bonds until someone, hopefully the malicious party, gives up. oSnap disputes are routed to UMA’s data verification mechanism, where UMA stakers resolve the bonds based on whether or not the proposal was valid. The full weight of staked UMA tokens is worth tens of millions of dollars, providing strong incentives to get it right. Meanwhile, you can re-propose before DVM resolution if the proposal was valid, so you don’t need to wait for the vote to resolve.
  3. **Continuous development and improvement. **Risk Labs (the team behind UMA and Across) is very focused on adding new features and improvements to oSnap. Some of these will automatically be available to SafeSnap users with Reality execution; for example, improvements to the general Snapshot interface or transaction builder. Many of the improvements will only be available to oSnap users, though, because the oSnap implementation is quite different from the Reality.eth implementation and lives in separate files in Snapshot’s repo. Any monitoring or bot improvements will also only be helpful to oSnap users. The Risk Labs team is highly effective and respected in the industry and is putting significant effort towards oSnap in the coming months. There is no comparable development effort working on the Reality system or any other Snapshot execution method.

For all of these reasons, it makes sense to migrate from Reality to oSnap if you’re already a SafeSnap user.

Considerations

While oSnap has been audited by Open Zeppelin, as with any system, there may be unforeseen vulnerabilities. However, the Risk Labs team is continuously improving open source monitoring infrastructure for oSnap, and oSnap proposals are routed to UMA’s robust and active oracle network.

1 Like
2

@RoundElephant do you have any more thoughts on the proposal, now that it’s in phase two?

3

We talked about this proposal, and your previous discussion thread, on the June 22nd governance call.

While I am a strong believer in iterative improvements to our DAO’s governance infrastructure, and very much appreciate the effort your team put in here, I find myself unable to support the current proposal to replace the Reality oracle with the UMA oracle through oSnap within 1inch’s SafeSnap setup.

Firstly, the Reality oracle has been time-tested and proven to be reliable to date. It is one of the key components of our DAO’s governance system and has not shown any significant issues or vulnerabilities to date. We have multiple parties and tools monitoring the reality.eth module, and have 72-hours to respond to malicious proposals (plus a 72-hour cooldown period before those proposals can be executed).

Furthermore, there is an inherent complexity to blockchain technology, especially when the technology relies on an Oracle. It has taken a considerable amount of time for the core team and, I’m sure, for many other members of our community, to gain a comprehensive understanding of how our current Gnosis Safe + Snapshot + SafeSnap solution functions under the hood. Implementing oSnap would require a new learning curve for members of the DAO.

“If it isn’t broken, don’t fix it.” The Reality oracle isn’t perfect, no system is, but it has served its purpose well so far. While the proposal to migrate to oSnap and the UMA oracle may offer certain benefits, I believe the time, effort, and potential risk involved in this transition do not justify the proposed change.

Of course, I am open to discussing this further and hearing counter-arguments. The beauty of a DAO is that it’s a collaborative space where all perspectives are welcome. However, based on the current information, my vote is to retain the Reality oracle and continue with our current SafeSnap setup.

4

Hi @RoundElephant! Thanks for the comments. We still believe that oSnap is a much better choice than the Reality oracle but understand if the 1inch community is not interested in reviewing a new governance component at this time.

We know of DAOs that have had their treasuries attacked—both successfully and unsuccessfully—due to Reality’s lack in built-in monitoring. This actually spurred one of our partner DAOs to make the switch.

Since you already have your own monitoring, moving to oSnap would only improve that, since you would have your monitors reinforced by third-party monitors in a very active network. For comparison, Polymarket presents much more complicated questions but only a two-hour challenge window, and consistently gets disputes of any questionable proposals.

Risk Labs is also building a bot that will not only monitor oSnap proposals but will automatically dispute when a bad proposal is made on-chain. The bot will be open source, so your team and third party disputers can easily run it in parallel. That will bring the expected dispute time for bad proposals to a minute or two, while still retaining a conservative 72-hour challenge window.

We will continue to add improvements to oSnap and have a dedicated team of engineers and product folks working on it. We want it to be a no-brainer to make the switch and know we have to earn it.