NMDP #3: Add oSnap to the Nexus Mutual Snapshot space

Governance Discussions Nexus Mutual DAO Proposals
1

Status: Open for Voting
Voting Period: 20–27 February
Submitted: Feb 5th, 2024
Author: Bobbay @ UMA

References
RFC: Adding oSnap to the Nexus Mutual Snapshot space

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 $300M 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 $700M 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:

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.

Additional Resources

Proposed Settings

  • 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 security can be further improved by modifying other settings on the Snapshot space. The below is an option that is not specific to oSnap but a general setting the DAO 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. A proposed would need at least 1,000 NXM to submit a Snapshot proposal.

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 15 days before moving to a Snapshot vote

Now that the review period has passed, this NMDP has been transitioned to a DAO Snapshot vote. Voting will be open from 20 February at 3pm UTC until 27 February at 3pm UTC.

Be sure to review the proposal and participate in the Snapshot vote!

Edit: @BraveNewDeFi edited this post to update with the details of the DAO Snapshot vote.

2 Likes
3
4

I’m in support of this proposal. oSnap will be a great addition to the Mutual’s existing DAO governance process.

I’m also looking forward to talking with the UMA team on Thursday on Twitter Spaces to go over this proposal in more detail and share more information about oSnap with members.

2 Likes
5

Support from me as well. This will help the DAO Treasury operationally.

1 Like
6

Hello,

It is great to see an effort to reduce dependency on trusted components within Nexus Mutual’s governance process by removing the reliance on a multisig for execution.

While the solution removes one central party dependency (a trusted multisig) it introduces two other trusted players external to the DAO, namely:

  1. You rely on the servers of a centralized off-chain signaling platform - Snapshot
  2. You rely on UMA token holders for all future Nexus Mutual disputes.

While both Snapshot and UMA are highly reputable, the proposed design is handing over the ability to influence onchain execution to parties external to Nexus Mutual. Doesn’t this compromise the autonomous part of the DAO?

Perhaps the schema could work quite well for high-velocity, low-stakes decisions, but considering how central governance is to the functioning of Nexus Mutual, it would be important to consider other alternatives:

  • Build a dispute mechanism reliant on NXM instead of UMA tokens to preserve/enhance the autonomy of Nexus Mutual (handing over control to, in essence, the token holders of another project has been a hurdle for the adoption of subjective oracle systems such as Kleros and Aragon, and seems to be an unresolved challenge here)
  • Implement a direct onchain governance mechanism that will provide a trustless and secure onchain execution. Several teams, including Moloch, Tally, and Aragon, are building such solutions with extensive track records. While the added security and true autonomy of onchain governance comes at a cost, considering there were 11 proposals in the past year and most votes are placed by wallets with $100k+ worth of NXM that cost is relatively not that high in relative terms and it can be further mitigated using cross-chain voting solutions.

Please pardon me if I am wrong with some of the argumentation, and I am looking forward to hearing what the original proposer and other members think.

1 Like
7

Also, as a follow-up question, does the introduction of oSnap mean that the multisig will be removed, or will that trusted component remain in addition to the two new ones being introduced?

1 Like
8

Worth clarifying here that this isn’t for protocol governance. This is for governance related to the DAO treasury. Protocol governance is role-based and requires on-chain voting.

These are two separate functions.

While both Snapshot and UMA are highly reputable, the proposed design is handing over the ability to influence onchain execution to parties external to Nexus Mutual. Doesn’t this compromise the autonomous part of the DAO?

This would rely on UMA’s optimistic oracle, which has security measures in place that penalize people who vote dishonestly. It would be far more expensive to attack UMA’s optimistic oracle than any value that could be gained through a malicious DAO governance proposal.

I would argue relying on multisig signers isn’t autonomous and oSnap is a closer step toward permissionless execution.

1 Like
9

oSnap is built on top of Safe, so the multisig would remain, but proposals with transaction payloads would be executed permissionlessly if a vote is approved by members.

1 Like
10

Hey @Smol Thanks for the questions!

@BraveNewDeFi provided some great replies. I’ve added some additional context below.

I would like to highlight that Nexus Mutual DAO already uses Snapshot for NMDPs so this is not an introduction of a new player to the governance process. Instead of relying on the manual multisig and essentially trusting the multisig signers to enact the request, oSnap ensures that the transaction will be executed after a successful snapshot vote reducing the trust assumption on the manual signers.

On your point that UMA is able to influence onchain execution for Nexus, oSnap can only execute transactions for valid Snapshot proposals and was intentionally designed so that UMA only resolves the bond values between the proposer and disputer on disputes, not determine which transactions Nexus Mutual is able to execute. If UMA incorrectly resolved an oSnap dispute, the financial consequences would be an inaccurate allocation of the 2 WETH bond between the proposer and disputer, not executing the proposed transactions. This would also have a significant impact for UMA’s reputation and holders since integrations would lose trust in the oracle and oSnap.

UMA holders main role is to be the arbitrator for the optimistic oracle and incentivize honest behavior. UMA inflationary rewards go to UMA holders that are staked and voters that vote against the majority or do not vote are penalized which incentives voter participation and valid dispute resolution. We have implemented bots and a verification program to verify each proposal, developed a Voter dapp (https://vote.uma.xyz/) to simplify the voter UX, and implemented bots and a verification program to ensure inaccurate proposals are disputed.

NXM holders are only used to voting on the snapshot and on-chain votes, and with voter apathy being a large issue, introducing another voting mechanism could not only be a deterrent, but NXM holders are also not used to the consistency of voting as much as UMA holders.

On your 2nd point of using an onchain solution, as you mentioned yourself, there is a cost here. The beauty of offchain voting is that everyone can vote along as they hold NXM tokens. The gas cost to cast an onchain vote is burdensome over time and it would deter smaller holders or those with less capital from casting votes. This could lead to a more centralized voting cohort of those participating in onchain votes, and this is something that DAOs should avoid.

As Brave mentioned, the multisig will remain in place and is not removed!

11

It’s great to see the important discussion happening in this thread. I’m looking forward to seeing more proposals from teams, such as UMA, that are focused on building solutions for efficient governance operations.

12

Hey @BraveNewDeFi and @Bobbay, I appreciate the responses and clarification as team members of Nexus Mutual and UMA, respectively.

As I hinted and @BraveNewDeFi confirmed in low stakes environment, indeed, an offchain solution could be more suitable.

  • that sounds great! How are those numbers compared with the $21M in the treasury safe?
  • Thank you, that clarifies things. So if a legitimate proposal is disputed and settled in favour of the disputer, can the proposal still go to execution?
  • I think the convenience of “outsourcing governance” to a different community makes sense with little value at stake, however this could be a “broken window” moment and result in sustained disengagement.

As both of you point out voter apathy is already quite prevailant in the NXM community with only 5-6 addresses having voted over the past year. And the current solution doesn’t change the situation meaningfully so it won’t improve enegagment and participation. Wouldn’t an optimistic solution relying on NXM holders to veto provide a more sovereign (or autonomous if you willl) alternative by not relying on UMA holders or Snapshot servers.

An optimistic setup where a multisig proposes actions that NXM holders can veto only if disagreeing. If no veto happens within a dedicated time window actions get executed:

  • In reality most proposals in Snapshot are created by @BraveNewDeFi so having a multisig instead of one operator is more decentralised.
  • It reduces the need for voting altogether so apathy is not such a big problem. At the same time tokenholders maintain the ultimate control over the treasury
  • No reliance on third parties
  • Delegation can be layered on this if gas cost of onchain veto is a concern for small hodlers
  • Perhaps some inflation incentive can be directed towards active NXM holders to “stay vigilant” in a model similar to UMA [not sure if this is even necessary, but it could be an addition]

Thank you once again for your responses!

13

Hey @Smol,

This vote has ended and NMDP #3 did pass, with 107k NXM voting in favour and no votes opposing. I’m happy to go through and answer your questions, as I think it’s important to clarify how oSnap works, how to ensure it’s secure, and what measures the DAO team, as the manager of the Nexus Mutual Space, can take to prevent malicious votes from going through.

I’ll go through and answer the questions you’ve asked:

Over the last 30 votes through UMA’s optimistic oracle, the lowest amount of UMA that participate in a vote was 10,521,909.03, which is currently valued at $43,876,360.66 . The largest amount of UMA that participated in the last 30 days was 16,414,278.91, which is valued at $68,447,543.05.

UMA stakers who vote fraudulently will have their stake burned, as outlined in the UMA docs. Important to note this only applies for disputed votes that go through a full Snapshot voting period.

UMA stakers can’t vote on what to do with DAO treasury funds themselves, and they don’t vote to approve a vote. Most statements go undisputed because they are true statements.

This still applies to the above, where there’s a strong financial inventive within UMA not to vote fraudulently because you’ll have a portion of your UMA slashed as a result.

When you say “legitimate proposal,” are you saying a non-malicious proposal? UMA can’t decide how to allocate funds. They can only vote to validate or invalidate a decision, which would be configured in the transaction payload for an NMDP.

Again, this isn’t outsourcing governance. You still need NXM voters to participate in a vote and if quorum isn’t acheived, the vote is automatically denied. oSnap just allows for for execution after the dispute window closes. If there is a dispute, UMA stakers would review the data and vote to validate or invalidate the decision based on the available data.

Again, oSnap doesn’t have anything to do with voter apathy. It removes the need for 4 of 7 signers on the DAO treasury multisig to execute a transaction after a vote is approved.

If voter apathy is low, I don’t think creating a solution that relies on NXM voters makes much sense here. That would be a case of reinventing the wheel, when UMA’s oSnap provides an existing solution that is securing substantially more in value elsewhere.

At the end of the day, we can prevent malicious proposals from getting to the execution phase using the admin functions on the DAO Snapshot space.

I’ll let @Bobbay provide more background on UMA and their security/incentive model, but I think you’re not quite understanding the role oSnap plays in the DAO governance process.

NXM voters still need to participate in a vote. If a vote doesn’t achieve quorum, it won’t pass by default. That quorum is now 50,000 NXM.

If someone were to try and pass a malicious proposal through the DAO Snapshot space, they would have to be a KYC’d member that has enough NXM to push a malicious proposal through, which would be a least 50,000 NXM and likely more as there would be a baseline of 100k NXM voting against.

Currently, there are only 16 addresses that only 50,000 NXM or more, and of that:

  • One address is the arNXM vault run by Ease
  • One address is the DAO treasury itself
  • One address is the NXM token controller proxy
  • One address is the wNXM contract

The other 12 addresses are likely to be long-term aligned investors.

In the case that oSnap is used, you would need someone to acquire enough NXM to attack the process and enough UMA to attack the UMA voting process, which wouldn’t be profitable.

Trying to create an UMA-like process within the DAO wouldn’t make much sense, as it would be less secure than using oSnap. At the end of the day, NMDP could have been voted down and we could have just relied on multisig signers instead of trying to create something for NXM voters to do beyond voting on governance proposals.

1 Like
14

@BraveNewDeFi thanks for answering the questions above and I am excited about the vote passing!

Just a few general comments:

  • To be part of UMA’s dispute resolution process, it is required to stake UMA and there is a cool-down period of 7 days after unstaking. This waiting period makes it costly for an attacker as the UMA they need to acquire to manipulate votes is going to be worth a lot less if trust in UMA is lost.
  • An attack becomes more impractical given the relatively small economic value (2 WETH) UMA’s vote is deciding with oSnap disputes. In no circumstances can UMA determine if transactions can be executed by the DAO.
  • UMA has no role in Nexus Mutual’s governance process except for resolving the bond values between the proposer and the disputer when a dispute occurs.
  • Disputes can also be made by anyone (not just UMA tokenholders). So even if an attacker acquired the significant amount of UMA required to corrupt UMA’s DVM, they would still need to prevent anyone from disputing proposals. With challenge periods between 1-3 days, DAOs have plenty of time to simply disable the oSnap module if UMA is falsely resolving disputes.
  • Here is a dashboard of all oSnap integrations. The current TVS is over $500 million: https://dune.com/risk_labs/osnap-total-value-secured
1 Like
15

Thank you, I appreciate the clarifications!

1 Like