[RFC]: Adding oSnap to the Nexus Mutual Snapshot space

Governance Discussions
1

[RFC]: Adding oSnap to the Nexus Mutual Snapshot space

Status: RFC
Submitted: Jan 15th, 2024
Author: Bobbay @ UMA

Summary

The current Nexus Mutual DAO proposal (NDMP) governance process uses offchain Snapshot voting to approve or deny Nexus Mutual DAO Proposals. The adoption of oSnap for NDMPs would eliminate the need for multisig execution by automatically executing successful Snapshot votes onchain, thus consolidating the governance process to one gasless vote on Snapshot that results in onchain execution.

Rationale

We believe decentralized governance is critical to the entire web3 ecosystem. The traction of oSnap has shown us that DAOs are increasingly committing to this as well; as such, UMA continues developing oSnap with no fees for the betterment of the industry at large.

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

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

Specification

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.

Once enabled, Snapshot proposals can include treasury distribution transaction payloads within the proposal to be automatically executed after a successful snapshot vote. There would be no changes related to proposals not related to treasury distributions, such as social votes relating to governance, removing a council member, etc.

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

  • An oSnap-enabled Snapshot proposal incorporates transaction data, to be verified and executed upon passing, with a user-friendly builder for creating and verifying token transfers.
  • NXM holders vote on the proposal like any other Safe Snapshot proposal
  • If NXM 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.

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

Proposals automatically execute once they have passed a snapshot vote and aren’t disputed, reducing the need to coordinate multi-sig signers to sign transactions for proposals related to the community fund, like the examples mentioned above.

This minimizes the operational friction within DAOs and makes the process more seamless.

Dispute process

  • Anyone can dispute by navigating to https://oracle.uma.xyz/ and finding the relevant proposal to initiate a dispute by posting a bond.
  • 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.

To date, there has only been one oSnap dispute after 60 proposals. The dispute occurred when there were Cloudflare-related issues during the challenge period and the UMA bot disputed as a precautionary action. The dispute was accurately resolved by UMA’s dispute resolution process and the proposal was re-proposed and executed.

Monitoring

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.

SafeGuards

Here are a couple of safeguards that could be incorporated into oSnap:

  • Enable moderators on the snapshot space
    • Nexus Mutual team leads could be added as moderators giving them the ability to add and remove proposals.
    • This method retains permissionless proposal creation by anyone but moderators can remove any spam proposals.
  • Author only mode
    • Nexus Mutual Team Leads can be the only users with the ability to upload a proposal on the snapshot space for Nexus Mutual.

Here is an example of how CowSwap incorporated safeguards into their Snapshot space.

Drawbacks

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

Here are the audit reports by Open Zeppelin:

Next steps

  1. We would appreciate community feedback on this and will leave this up to gather enough feedback.
  2. We will incorporate the community feedback before moving to the NDMP stage
2 Likes
2

Thanks for having us on the call. Here is some follow-up information!

1 Like
3

Thanks for the proposal @Bobbay and for being on the community call just now.

I’m tentatively supportive here. The biggest benefit is our ability to process transactions without coordinating the multi-sig signers. My only concern is around the attack like scenarios (due to automatic execution), and so I have to do a bit more work to see what settings you have and what I think makes the most sense for Nexus.

Gut feeling is that there will be something that works, I just have to spend some time on it.

2 Likes
4

The core reason the UMA bot was implemented was to automate disputes for any incorrect or malicious proposals. The bot uses strict parameters to validate Snapshot proposals and if there are any issues with proposal results or Snapshot’s API, the bot will automatically dispute.

The automation for proposing and executing transactions is optional and was the result of feedback from DAOs not wanting the team or community members to be required to post a bond after the Snapshot voting period is completed.

The bot has no special permissions and there are also third-party verifiers and a verification program each proposal goes through where participants are financially incentivized to dispute bad proposals made by the bot. The bot and monitoring code is public and we are happy to assist in Discord or Slack monitoring for your team and community:

1 Like
5

I agree with @Hugh on this. I’m supportive but want to analyze the parameters the DAO would need to put in place to prepare for a wider community discussion. Over the next week, I’ll review the oSnap documentation and come back to this discussion with some proposed parameters that could be implemented if members support the oSnap implementation.

There are significant benefits, but we just need to get the security aspect right before this transitions to an NMDP.

Looking forward to hearing thoughts from other Mutual members!

1 Like
6

Hey @BraveNewDeFi @Hugh any thoughts on the proposed parameters? Let us know if you want any further information.

1 Like
7

Hey @Bobbay,
Yes, I’ve put together some proposed params for our Snapshot space.

Proposed Parameters for Snapshot and oSnap

After reviewing the options on the oSnap Configuration Parameters docs page, I’ve put together the proposed configuration parameters for any potential implemention of oSnap, if members signal to support this iniative through the NMDP process.

Proposed Params:

  • Voting Quorum: 50,000 NXM would be required to achieve quroum for any Snapshot vote that would move funds out of the DAO Treasury.
  • Voting Period: The minimum voting period would be five (5) days.
  • Challenge Period: The challenge period would be set to 36 hours.

The above parameters should provide a suitable level of security for an oSnap implementation.

The security can be further improved by modifying other settings on the Snapshot space. The below are options that are not specific to oSnap but are general settings we can apply to the Nexus Mutual DAO Snapshot space.

  • Proposal validation. Currently, someone needs voting power of at least 10 NXM to submit a Snapshot proposal. This could be updated to a higher threshold, so, say, someone needs voting power of at least 1,000 NXM to submit a Snapshot proposal.
    • We can use the Authors only mode setting, which would only allow Admins, Moderators, or Authors (addresses listed as one of these roles on the Nexus Mutual DAO Snapshot space settings) to post Snapshot proposals. This would prevent the greatest level of security, but we would sacrifice some members’ autonomy to post proposals without going through someone on the DAO teams.

Members can review the proposed parameters for oSnap and share their thoughts. I’m also curious to hear people’s thoughts on the Proposal Validation settings for the Snapshot space.

2 Likes
8

Hey ! These are great settings for snapshot and oSnap to make your governance process more seamless and secure. I would also love to hear if other community members have thoughts on this.