CIP-30: Implementing oSnap for Optimistic Governance in CoW DAO

CIP-30: Implementing oSnap for Optimistic Governance in CoW DAO
author: Alex Gaines (againes@umaproject.org), John Shutt (john@umaproject.org), Manny Narang (manny@umaproject.org)
status: active
created: 2023-07-05

Simple Summary

This proposal aims to integrate oSnap, an optimistic governance tool developed by UMA, into the CoW DAO governance system. By leveraging oSnap, CoW DAO can execute the results of Snapshot votes on-chain, eliminating reliance on multi-signature wallets and promoting a more decentralized and efficient execution process.

Motivation

The motivation for this proposal is to enhance CoW DAO’s governance system by making it more efficient, secure, and decentralized. By adopting oSnap, CoW DAO can streamline its governance process and empower its token holders, thereby upholding the true spirit of decentralization.

Specification

UMA’s oSnap is a tool for making on-chain transactions based on off-chain voting decisions. After the integration of oSnap, the flow works like this:

  • A Snapshot proposal can include a transaction payload that is executable if the proposal is approved by the DAO.
  • After a vote completes, any address can post a bond and propose to execute the transactions on-chain by clicking a button on Snapshot.
  • If no dispute arises about the proposal’s accuracy during the dispute window, the transactions are executed.
  • In case of a dispute, the proposal is not executed and needs to be re-proposed. UMA token holders will determine who was correct in the dispute, with the correct party rewarded from the opposing party’s bond.

The oSnap integration process can be completed in a single afternoon. The steps to integrate oSnap are:

  • Install the Zodiac app.
  • Deploy an oSnap module through the Zodiac app.
  • Add oSnap to the CoW DAO Snapshot space through the SafeSnap plug-in.

Overall Cost: There are no fees associated with the implementation of oSnap. There are also no fees to use UMA’s oracle to verify oSnap requests. Therefore, the overall cost of implementation is zero.

Rationale

Current DAO governance models often rely on multi-signature wallets for the execution of proposals, which can lead to delays and potential security vulnerabilities. Implementing oSnap, which allows for on-chain execution of off-chain votes, would eliminate the dependency on multi-sig wallets and the associated issues. Furthermore, oSnap’s dispute mechanism and incentives for correct submissions help maintain the integrity and accuracy of the decision-making process.

The integration of oSnap into CoW DAO’s governance aligns with the DAO’s mission of decentralization and community involvement. Implementing oSnap will not only streamline the governance process but also eliminate the need for reliance on multi-signature wallets, thereby promoting more direct community control. This approach aligns with the DAO’s guiding value of decentralization by reducing the need for intermediaries and giving more power to the token holders. Moreover, oSnap’s dispute mechanism provides an extra layer of security, ensuring that the outcomes of governance votes accurately reflect what was approved on Snapshot. Finally, the integration of oSnap is free and easy, making it a practical choice for enhancing CoW DAO’s governance.

The UMA team discussed oSnap with Chen from CoW Protocol, who brought up the importance of monitoring proposals. 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 UMA’s oracle dapp making 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 that members of our competitive disputer network have set up, and you can use our open source code 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 will automatically dispute if a faulty or malicious proposal is identified.

Since its launch earlier this year, oSnap has been adopted by Across, BarnBridge, ShapeShift, and +DAO to control their on-chain treasuries, securing over $40 million in value. oSnap is also being used by Lossless Protocol to secure their next generation of wrapped tokens.

Execution

Safe Transaction Data

The below shows the multisend call and detailed transaction data for deploying and enabling the oSnap module for the CoW DAO safe. All deployment steps can be performed through the Zodiac UI.

Multisend Call:

{
  "method": "multiSend",
  "types": [
    "bytes"
  ],
  "inputs": [
    "0x00000000000000addb49795b0f9ba5bc298cdda23600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000544f1ab873c00000000000000000000000028cebfe94a03dbca9d17143e9d2bd1155dc26d5d000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000189dc2070d900000000000000000000000000000000000000000000000000000000000004a4a4f9edbf00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000460000000000000000000000000ca771eda0c70aa7d053ab1b25004559b918fe662000000000000000000000000c02aaa39b223fe8d0a0e5c4f27ead9083c756cc20000000000000000000000000000000000000000000000001bc16d674ec8000000000000000000000000000000000000000000000000000000000000000000c04153534552545f54525554480000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002a3000000000000000000000000000000000000000000000000000000000000000376492061737365727420746861742074686973207472616e73616374696f6e2070726f706f73616c2069732076616c6964206163636f7264696e6720746f2074686520666f6c6c6f77696e672072756c65733a2050726f706f73616c7320617070726f766564206f6e20536e617073686f742c2061732076657269666965642061742068747470733a2f2f736e617073686f742e6f72672f232f636f772e6574682c206172652076616c6964206173206c6f6e672061732074686572652069732061206d696e696d756d2071756f72756d206f6620333530303030303020616e642061206d696e696d756d20766f74696e6720706572696f64206f662031363820686f75727320616e6420697420646f6573206e6f742061707065617220746861742074686520536e617073686f7420766f74696e672073797374656d206973206265696e67206578706c6f69746564206f72206973206f746865727769736520756e617661696c61626c652e205468652071756f72756d20616e6420766f74696e6720706572696f6420617265206d696e696d756d20726571756972656d656e747320666f7220612070726f706f73616c20746f2062652076616c69642e2051756f72756d20616e6420766f74696e6720706572696f642076616c7565732073657420666f7220612073706563696669632070726f706f73616c20696e20536e617073686f742073686f756c642062652075736564206966207468657920617265206d6f726520737472696374207468616e207468652072756c657320706172616d657465722e20546865206578706c616e6174696f6e20696e636c75646564207769746820746865206f6e2d636861696e2070726f706f73616c206d7573742062652074686520756e697175652049504653206964656e74696669657220666f722074686520737065636966696320536e617073686f742070726f706f73616c20746861742077617320617070726f766564206f72206120756e69717565206964656e74696669657220666f7220612070726f706f73616c20696e20616e20616c7465726e617469766520766f74696e672073797374656d20617070726f7665642062792044414f20736f6369616c20636f6e73656e73757320696620536e617073686f74206973206265696e67206578706c6f69746564206f72206973206f746865727769736520756e617661696c61626c652e000000000000000000000000000000000000000000000000000000000000000000000000000000ca771eda0c70aa7d053ab1b25004559b918fe66200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000024610b592500000000000000000000000085f520d59debd4c2902bb7f79acbc3dd4b5ab699"
  ],
  "names": [
    "transactions"
  ]
}

Detailed Transaction Data:

{
  "version": "1.0",
  "chainId": "1",
  "createdAt": 1691615486406,
  "meta": {
    "name": "Transactions Batch",
    "description": "",
    "txBuilderVersion": "1.16.1",
    "createdFromSafeAddress": "0xcA771eda0c70aA7d053aB1B25004559B918FE662",
    "createdFromOwnerAddress": "",
    "checksum": "0x1807bca7bc7dcea4d50fc7b8e4b680ca00513a9547b7e039f81484602c4d032d"
  },
  "transactions": [
    {
      "to": "0x000000000000aDdB49795b0f9bA5BC298cDda236",
      "value": "0",
      "data": null,
      "contractMethod": {
        "inputs": [
          {
            "name": "masterCopy",
            "type": "address",
            "internalType": "address"
          },
          {
            "name": "initializer",
            "type": "bytes",
            "internalType": "bytes"
          },
          {
            "name": "saltNonce",
            "type": "uint256",
            "internalType": "uint256"
          }
        ],
        "name": "deployModule",
        "payable": false
      },
      "contractInputsValues": {
        "masterCopy": "0x28CeBFE94a03DbCA9d17143e9d2Bd1155DC26D5d",
        "initializer": "0xa4f9edbf00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000460000000000000000000000000ca771eda0c70aa7d053ab1b25004559b918fe662000000000000000000000000c02aaa39b223fe8d0a0e5c4f27ead9083c756cc20000000000000000000000000000000000000000000000001bc16d674ec8000000000000000000000000000000000000000000000000000000000000000000c04153534552545f54525554480000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002a3000000000000000000000000000000000000000000000000000000000000000376492061737365727420746861742074686973207472616e73616374696f6e2070726f706f73616c2069732076616c6964206163636f7264696e6720746f2074686520666f6c6c6f77696e672072756c65733a2050726f706f73616c7320617070726f766564206f6e20536e617073686f742c2061732076657269666965642061742068747470733a2f2f736e617073686f742e6f72672f232f636f772e6574682c206172652076616c6964206173206c6f6e672061732074686572652069732061206d696e696d756d2071756f72756d206f6620333530303030303020616e642061206d696e696d756d20766f74696e6720706572696f64206f662031363820686f75727320616e6420697420646f6573206e6f742061707065617220746861742074686520536e617073686f7420766f74696e672073797374656d206973206265696e67206578706c6f69746564206f72206973206f746865727769736520756e617661696c61626c652e205468652071756f72756d20616e6420766f74696e6720706572696f6420617265206d696e696d756d20726571756972656d656e747320666f7220612070726f706f73616c20746f2062652076616c69642e2051756f72756d20616e6420766f74696e6720706572696f642076616c7565732073657420666f7220612073706563696669632070726f706f73616c20696e20536e617073686f742073686f756c642062652075736564206966207468657920617265206d6f726520737472696374207468616e207468652072756c657320706172616d657465722e20546865206578706c616e6174696f6e20696e636c75646564207769746820746865206f6e2d636861696e2070726f706f73616c206d7573742062652074686520756e697175652049504653206964656e74696669657220666f722074686520737065636966696320536e617073686f742070726f706f73616c20746861742077617320617070726f766564206f72206120756e69717565206964656e74696669657220666f7220612070726f706f73616c20696e20616e20616c7465726e617469766520766f74696e672073797374656d20617070726f7665642062792044414f20736f6369616c20636f6e73656e73757320696620536e617073686f74206973206265696e67206578706c6f69746564206f72206973206f746865727769736520756e617661696c61626c652e00000000000000000000",
        "saltNonce": "1691615260889"
      }
    },
    {
      "to": "0xcA771eda0c70aA7d053aB1B25004559B918FE662",
      "value": "0",
      "data": null,
      "contractMethod": {
        "inputs": [
          {
            "internalType": "address",
            "name": "module",
            "type": "address"
          }
        ],
        "name": "enableModule",
        "payable": false
      },
      "contractInputsValues": {
        "module": "0x85f520D59deBD4c2902BB7f79ACbc3Dd4b5AB699"
      }
    }
  ]
}

Tenderly Simulation

1 Like

Thanks Alex, John and Manny for the detailed proposal.

This is the main reason that I think this proposal is positive for CoW DAO, and I’m personally in support of it.

I would like to make sure the new technical flow for CoW DAO to propose and execute governance proposals is clear and the new security assumptions and risks are well understood.

First, the existing multisig signers will still have full access and control of CoW DAO’s Safe. This means they can effectively veto any pending execution, by disconnecting the oSanp module (at a worst case scenario), and/or enforce execution of a falsely disputed proposal if need be.
This represents a progressive decentralization approach where incremental steps can be taken to reduce admin control and empower CoW token holders and community.
In normal mode operation, multisig signer involvement will not be required for governance proposal execution anymore, but they can intervene in emergencies.
Down the line, multisig signer power could be reduced to only have veto right or even remove their access altogether.

RISKS
The default mode will become that any passed proposal can be executed. This raises few risks that should be acknowledged:

  • Attackers can try to pass a proposal without the community noticing and being able to vote against it. This is low risk that is present in any DAO. If a proposal passes quorum it should be executed. It is the community responsibility to prevent unwanted proposals from gathering quorum.
  • Attackers can try to execute a failed proposal by posting a bond. In this case there is clear financial incentive to dispute the execution, the main risk IMO is just nobody noticing but this is very unlikely with UMA’s setup and monitoring tools are available for the community to get additional protections.
  • A proposal execution could never be forced because a dispute cancels execution regardless of the arbitration outcome.
  • This poses another minor risk of attackers blocking legitimate proposals from executing by disputing them. For this reason a large enough bond should be required, which will represent a big financial cost to carry a continued denial of service attack.
  • Multisig signers can still decide to execute a falsely disputed proposal, out of the oSnap context if critically needed.

To sum it up, in my opinion any potential risk is well mitigated, so the benefits outweigh the risks.
Being able to run a bot that can watch snapshot, post bond for executing any passed proposal, post bond for disputing any failed proposal execution, and alert in any case to discord, slack and TG would help to mitigate any remaining concerns.

I’m signalling my support of this proposal :cow:

2 Likes

I agree that the benefits outweigh the risks. Continued decentralization is an excellent reason why we should pursue this proposal. I am signalling my support.

1 Like

Progressive movement towards decentralising the CowDAO safe definitely has my support. In regards to the implementation of this though, and with oSnap being permissionless with execution (pending a bond) - I think there are two main points that need to be dealt with as part of this proposal:

  1. Is there a UI for a user to execute the proposal (with posting a bond)?
  2. If the answer to (1) is Yes, this must be documented thoroughly in a CowDAO Governance SOP.
1 Like

Thanks for the questions. Yes, the UI for proposing and executing transactions is included in the Snapshot proposal. We are happy to help with the documentation and have existing documentation that can be leveraged (oSnap - UMA Protocol).

Here is the flow after the Snapshot voting period has ended:

Proposing transactions
A button is shown in the transactions container that allows anyone to post a bond and propose the transactions:

If clicked, a modal informs the user of the required proposal bond and challenge window. If everything looks good, the user can sign the transaction to propose the transactions:

Challenge Window
The proposal then goes through the challenge period. The UI shows a link to the UMA oracle UI (https://oracle.uma.xyz/) that can be used to dispute invalid proposals. The UI also informs users when the proposal can be executed based on the end of the challenge window:

Executing Transactions
If the proposal successfully goes through the challenge period, a button enables the transactions to be executed:

2 Likes

@moderators the oSnap proposal has been on the forum for 9 days. Can we move the proposal to phase 2? Let me know if there is anything we need to address before going to Snapshot. Thanks!

1 Like

Apologies for the delays!
This proposal is indeed eligible for moving to the voting phase.

I think there is an important discussion to have about oSnap deployment parameters.
The defaults proposed in the above payload:
10K USDC bond
2 day liveliness period

@againes are there any other important deployment parameters to discuss?
My personal suggestion is to change the bond amount to 2ETH.
This way we use ETH instead of USDC and we reduce a bit the bond value (at least until ETH=5k :sweat_smile:)

For the liveness period, it is a simple tradeoff between safety and prolonged governance process. I suggest to keep the 2 day default.

1 Like

Thanks for your questions @middleway.eth. Yes, updating the bond to use 2 WETH and a 2 day challenge period makes sense.

The bond and challenge period can be easily updated after deployment and we are happy to assist with the deployment process to confirm everything is accurately configured. We also have a proposal bot that we are implementing that will automate proposing and executing transactions after validating a Snapshot proposal. In order for proposals to be eligible, the bond needs to be 1 WETH with a 3 day challenge period.

The only other parameters for consideration are based on your Snapshot Voting settings (Voting Period/Quorum) and Snapshot Space URL. The Voting parameters are minimum values for a Snapshot proposal to be considered valid and should match the Snapshot settings to prevent anyone from accidentally proposing transactions through the Snapshot UI if these minimum values are not met:

  • Voting Period: 7 days
  • Quorum: 35M
  • Space URL: Snapshot

Lastly, I want to emphasize that we will support the integration throughout the process (deployment, monitoring, and assisting with admin changes, if necessary). Let me know if you have any other questions.

2 Likes

After further discussion, CoW DAO wants to use a bond of 2 WETH with a challenge window of 48 hours. The below includes an updated Tenderly simulation, multisend call, and detailed transaction data for the change:

Tenderly Simulation

Multisend Call:

{
  "method": "multiSend",
  "types": [
    "bytes"
  ],
  "inputs": [
    "0x00000000000000addb49795b0f9ba5bc298cdda23600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000544f1ab873c00000000000000000000000028cebfe94a03dbca9d17143e9d2bd1155dc26d5d000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000189dc2070d900000000000000000000000000000000000000000000000000000000000004a4a4f9edbf00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000460000000000000000000000000ca771eda0c70aa7d053ab1b25004559b918fe662000000000000000000000000c02aaa39b223fe8d0a0e5c4f27ead9083c756cc20000000000000000000000000000000000000000000000001bc16d674ec8000000000000000000000000000000000000000000000000000000000000000000c04153534552545f54525554480000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002a3000000000000000000000000000000000000000000000000000000000000000376492061737365727420746861742074686973207472616e73616374696f6e2070726f706f73616c2069732076616c6964206163636f7264696e6720746f2074686520666f6c6c6f77696e672072756c65733a2050726f706f73616c7320617070726f766564206f6e20536e617073686f742c2061732076657269666965642061742068747470733a2f2f736e617073686f742e6f72672f232f636f772e6574682c206172652076616c6964206173206c6f6e672061732074686572652069732061206d696e696d756d2071756f72756d206f6620333530303030303020616e642061206d696e696d756d20766f74696e6720706572696f64206f662031363820686f75727320616e6420697420646f6573206e6f742061707065617220746861742074686520536e617073686f7420766f74696e672073797374656d206973206265696e67206578706c6f69746564206f72206973206f746865727769736520756e617661696c61626c652e205468652071756f72756d20616e6420766f74696e6720706572696f6420617265206d696e696d756d20726571756972656d656e747320666f7220612070726f706f73616c20746f2062652076616c69642e2051756f72756d20616e6420766f74696e6720706572696f642076616c7565732073657420666f7220612073706563696669632070726f706f73616c20696e20536e617073686f742073686f756c642062652075736564206966207468657920617265206d6f726520737472696374207468616e207468652072756c657320706172616d657465722e20546865206578706c616e6174696f6e20696e636c75646564207769746820746865206f6e2d636861696e2070726f706f73616c206d7573742062652074686520756e697175652049504653206964656e74696669657220666f722074686520737065636966696320536e617073686f742070726f706f73616c20746861742077617320617070726f766564206f72206120756e69717565206964656e74696669657220666f7220612070726f706f73616c20696e20616e20616c7465726e617469766520766f74696e672073797374656d20617070726f7665642062792044414f20736f6369616c20636f6e73656e73757320696620536e617073686f74206973206265696e67206578706c6f69746564206f72206973206f746865727769736520756e617661696c61626c652e000000000000000000000000000000000000000000000000000000000000000000000000000000ca771eda0c70aa7d053ab1b25004559b918fe66200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000024610b592500000000000000000000000085f520d59debd4c2902bb7f79acbc3dd4b5ab699"
  ],
  "names": [
    "transactions"
  ]
}

Detailed Transaction Data:

{
  "version": "1.0",
  "chainId": "1",
  "createdAt": 1691615486406,
  "meta": {
    "name": "Transactions Batch",
    "description": "",
    "txBuilderVersion": "1.16.1",
    "createdFromSafeAddress": "0xcA771eda0c70aA7d053aB1B25004559B918FE662",
    "createdFromOwnerAddress": "",
    "checksum": "0x1807bca7bc7dcea4d50fc7b8e4b680ca00513a9547b7e039f81484602c4d032d"
  },
  "transactions": [
    {
      "to": "0x000000000000aDdB49795b0f9bA5BC298cDda236",
      "value": "0",
      "data": null,
      "contractMethod": {
        "inputs": [
          {
            "name": "masterCopy",
            "type": "address",
            "internalType": "address"
          },
          {
            "name": "initializer",
            "type": "bytes",
            "internalType": "bytes"
          },
          {
            "name": "saltNonce",
            "type": "uint256",
            "internalType": "uint256"
          }
        ],
        "name": "deployModule",
        "payable": false
      },
      "contractInputsValues": {
        "masterCopy": "0x28CeBFE94a03DbCA9d17143e9d2Bd1155DC26D5d",
        "initializer": "0xa4f9edbf00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000460000000000000000000000000ca771eda0c70aa7d053ab1b25004559b918fe662000000000000000000000000c02aaa39b223fe8d0a0e5c4f27ead9083c756cc20000000000000000000000000000000000000000000000001bc16d674ec8000000000000000000000000000000000000000000000000000000000000000000c04153534552545f54525554480000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002a3000000000000000000000000000000000000000000000000000000000000000376492061737365727420746861742074686973207472616e73616374696f6e2070726f706f73616c2069732076616c6964206163636f7264696e6720746f2074686520666f6c6c6f77696e672072756c65733a2050726f706f73616c7320617070726f766564206f6e20536e617073686f742c2061732076657269666965642061742068747470733a2f2f736e617073686f742e6f72672f232f636f772e6574682c206172652076616c6964206173206c6f6e672061732074686572652069732061206d696e696d756d2071756f72756d206f6620333530303030303020616e642061206d696e696d756d20766f74696e6720706572696f64206f662031363820686f75727320616e6420697420646f6573206e6f742061707065617220746861742074686520536e617073686f7420766f74696e672073797374656d206973206265696e67206578706c6f69746564206f72206973206f746865727769736520756e617661696c61626c652e205468652071756f72756d20616e6420766f74696e6720706572696f6420617265206d696e696d756d20726571756972656d656e747320666f7220612070726f706f73616c20746f2062652076616c69642e2051756f72756d20616e6420766f74696e6720706572696f642076616c7565732073657420666f7220612073706563696669632070726f706f73616c20696e20536e617073686f742073686f756c642062652075736564206966207468657920617265206d6f726520737472696374207468616e207468652072756c657320706172616d657465722e20546865206578706c616e6174696f6e20696e636c75646564207769746820746865206f6e2d636861696e2070726f706f73616c206d7573742062652074686520756e697175652049504653206964656e74696669657220666f722074686520737065636966696320536e617073686f742070726f706f73616c20746861742077617320617070726f766564206f72206120756e69717565206964656e74696669657220666f7220612070726f706f73616c20696e20616e20616c7465726e617469766520766f74696e672073797374656d20617070726f7665642062792044414f20736f6369616c20636f6e73656e73757320696620536e617073686f74206973206265696e67206578706c6f69746564206f72206973206f746865727769736520756e617661696c61626c652e00000000000000000000",
        "saltNonce": "1691615260889"
      }
    },
    {
      "to": "0xcA771eda0c70aA7d053aB1B25004559B918FE662",
      "value": "0",
      "data": null,
      "contractMethod": {
        "inputs": [
          {
            "internalType": "address",
            "name": "module",
            "type": "address"
          }
        ],
        "name": "enableModule",
        "payable": false
      },
      "contractInputsValues": {
        "module": "0x85f520D59deBD4c2902BB7f79ACbc3Dd4b5AB699"
      }
    }
  ]
}

1 Like

Hey folks!

I’m very much in favor of this proposal. I have previously reviewed the optimistic governor module and am confident that it will function as advertised.

I have reviewed the proposed transactions for this proposal. All of the parameters appear to be correct.

Although I’m not totally satisfied with the rules statement.

It is currently set as this:

I assert that this transaction proposal is valid according to the following rules: Proposals approved on Snapshot, as verified at Snapshot, are valid as long as there is a minimum quorum of 35000000 and a minimum voting period of 168 hours and it does not appear that the Snapshot voting system is being exploited or is otherwise unavailable. The quorum and voting period are minimum requirements for a proposal to be valid. Quorum and voting period values set for a specific proposal in Snapshot should be used if they are more strict than the rules parameter. The explanation included with the on-chain proposal must be the unique IPFS identifier for the specific Snapshot proposal that was approved or a unique identifier for a proposal in an alternative voting system approved by DAO social consensus if Snapshot is being exploited or is otherwise unavailable.

I think I would prefer something like this:

I assert that this transaction proposal is valid according to the following rules:

  • the voting period for the proposal lasted at least 168 hours and has now ended.
  • the number of votes FOR is greater than the number of votes against AGAINST.
  • a quorum of at least 35000000 COW voted FOR or ABSTAIN on this proposal.
  • the proposal was initiated as Snapshot proposal in the cow.eth Snapshot space.
  • there were no significant service outages or availability issues that could have reasonably restricted participants from casting their votes in the proposal.
  • the module transaction hash is the keccak hash of the concatenation of the individual EIP-712 hashes of the module transactions defined in the Snapshot proposal.
  • the plain description of the transactions, and their intended result, in the proposal is complete and accurate.
  • the voting period did not occur during, in, or as a result of any unauthorized or malicious changes to the cow.eth Snapshot space.
  • the proposal was not filtered from the default view in the cow.eth Snapshot space during the voting period.
  • the explanation included with the on-chain proposal is the unique IPFS identifier for the specific Snapshot proposal that was approved
1 Like

After chatting with the UMA team about the formatting of the rules, I think we’re safe to proceed with the current version. Turns out that consistency in the rule sets between deployments is somewhat important for tooling purposes.

1 Like

Thanks for all the feedback!
The proposal is now up for voting
https://snapshot.org/#/cow.eth/proposal/0xbb52a603325a81e2f4e2cb0bb17d6626d8929737f2511d18e184cdeb94f7f3de

Hello, this is Juan from the Kleros team.

I totally support the idea of adding an extra layer of security and decentralization by integrating a subjective oracle on your governance process :handshake:.

But, before moving forward with a decision, I think it’s important to be aware about the available alternatives; Kleros, in collaboration with Reality has developed the Reality Module, a subjective oracle that operates optimistically, akin to UMA. However, I believe this might be a more suitable solution for COW Dao.

Why?

Firstly, considering the Lindy effect:
Kleros’ arbitration system has been operational since 2018, and has much more cases solved, Ether distributed to jurors and $ settled, while UMA was launched in 2021 and hasn’t yet reached the performance metrics of Kleros. (167 M pnk staked on courts, 399 Ether paid to jurors, more than 750 active jurors and over 1600 disputes.

(To see more stats, of all cases and courts, please visit [Klerosboard]

This is also one of the reasons behind why leaders in the DeFi space such as 1inch choose Reality as their oracle for the off-chain voting on Snapshot and uses Kleros for the final arbitration.

Below, you can see the main differences of Kleros vs UMA, but I recommend this article comparing both mechanisms.

Some takeaways:

UMA → One round resolution:

  • More Predictable and faster (in average).all cases take roughly the same amount of time to resolve
  • Less secure: Less secure: In order for the platform to be secure a large percentage of all token holders must vote in each question so that an attacker cannot sneak through a malicious outcome in a low-turnout vote.

Kleros → Appeal system (a group of randomly-chosen jurors vote on a decision the contract can be triggered to draw a larger panel of randomly-chosen jurors who reconsider the case.)

  • Non duplication of effort and more secure
    “Since only a few randomly selected jurors will have to spend the human effort to evaluate a case in a given round. Nonetheless, as jurors know that their rewards and penalties depend on whether they agree with the outcome of any possible future appeals, they are incentivized to try to vote in a way that is representative of the broader pool of staked PNK holders. Then, one only needs to require many jurors to spend the effort required to evaluate a given case if the case is appealed enough times.”
  • Less predictable regarding time:
    As each appeal round results in the new jurors being given time to consider the case, there is some variability in how long a case will take to resolve depending on how many times it is appealed.

Arguments and evidence
UMA has no explicit process for gathering evidence and arguments, though in practice voters tend to discuss cases in the UMA Discord, while in Kleros anyone can submit evidence and jurors are incentivized to provide their reasoning in voting in a given way.

The blogpost goes much deeper so please check it out if you are interested!

Hey everyone, I just want to post a comment on oSnap monitoring since we have added several features since the proposal was originally posted and I want to make sure it’s clear what is done from the UMA side for monitoring and optional steps that can be done by CoW DAO and the community.

The following monitoring is included automatically when an oSnap module is deployed:

  • Our internal monitoring utilizes Slack and Pager Duty notifications when transactions are proposed, executed, and disputed. We are also notified when there are any admin changes to the oSnap module (rules, collateral, owner, etc).
  • An automated proposal bot uses strict parameters to verify Snapshot proposals. The bot automates:
    • Disputing proposals that do not meet the validation criteria.
    • For Snapshot proposals that have passed verification, the bot automates the on-chain proposal and execution steps to save DAOs gas costs and avoid the DAO needing to post a bond for the challenge period.
  • 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, other oSnap integrations).
  • When transactions are proposed, a Discord ticket is automatically created where a verification program made up of the UMA community completes a multi-step verification process that consists of:
    • Verifying the Snapshot proposal passed and follows the oSnap rules
    • The proposed transaction payload matches the Snapshot transaction payload included in the proposal
    • The intent of the transactions matches what is proposed (not interacting with a malicious contract, transaction payload values match the proposal, etc).

Further actions that can be taken by CoW or the community:

  • Our monitoring bots can be run independently to be notified when transactions are proposed, executed, or any admin functions are changed. Here is documentation that walks through the setup: Monitoring Bot Setup - UMA Protocol
  • To minimize reliance on UMA tools, you could also use Hal alerts to monitor when Snapshot proposals are ending (HAL Notifications - snapshot) combined with on-chain notification alerts to check when transactions are proposed on the oSnap module.

Hi Juan, we appreciate feedback on our system but I feel obligated to correct a number of points here that are not accurate.

Kleros’ arbitration system has been operational since 2018, and has much more cases solved, Ether distributed to jurors and $ settled, while UMA was launched in 2021 and hasn’t yet reached the performance metrics of Kleros. (167 M pnk staked on courts, 399 Ether paid to jurors, more than 750 active jurors and over 1600 disputes.

UMA was actually launched in 2020 and has secured hundreds of millions of dollars in locked value across governance, derivatives, prediction markets, synthetic assets, insurance protocols, and cross-chain bridges. For the last one, we have secured over $2 billion in volume with Across with no incidents, where bridges are one of the largest targets of attack. Regarding PNK staked in courts, I believe the fully diluted valuation of PNK is around $16 million (https://www.coingecko.com/en/coins/kleros) which is considerably less than the value of UMA (please correct me if I’m wrong here!), which is tied to the economic security of an arbitration system.

For other statistics, I would point to the dozen or so prediction markets settled each day through UMA with Polymarket and the hundreds of bridging actions per hour secured through Across. In terms of live governance deployments, we have launched with ShapeShift (which migrated from the Reality oracle), BarnBridge, Across, Premia, Layer2DAO, and +DAO, with more in the works.

  • Less secure: Less secure: In order for the platform to be secure a large percentage of all token holders must vote in each question so that an attacker cannot sneak through a malicious outcome in a low-turnout vote.

The percentage of token holders that show up to resolve disputes have staked greater value than the total valuation of PNK and we are always striving to increase participation through tokens staked. There are penalties for not showing up to vote that are equivalent to voting incorrectly, so staked voters participate at an over 90% rate.

In any case, this is not as relevant to the oSnap case, since an UMA vote can not actually execute a proposal. We designed oSnap so that disputed proposals are discarded and must be re-proposed, to mitigate the attack surface. Even if someone somehow corrupted the majority of the UMA voting power, the worst they can do is misallocate the proposer/disputer bonds. If you’re interested in learning how oSnap actually works to better develop a critique, I’m happy to explain!

UMA has no explicit process for gathering evidence and arguments, though in practice voters tend to discuss cases in the UMA Discord, while in Kleros anyone can submit evidence and jurors are incentivized to provide their reasoning in voting in a given way.

This is not accurate. Every proposal to the oracle has a published methodology approved by governance and linked from the voting interface. Discussions on Discord are extremely active for contentious Polymarket votes and easy to review through the voting interface. There is an incentivized community validation network that looks at every proposal and receives rewards for raising concerns, in addition to the built-in rewards for disputing an inaccurate proposal. For questionable Polymarket proposals, disputes tend to come in within 30 minutes. For questionable Across proposals, disputes tend to come in within two minutes, since it is easily bot-driven. oSnap is closer to Across, since it is simple for bots to see if a proposal was actually approved on Snapshot or not.

I consider Kleros a friendly competitor and love optimistic mechanisms for resolving truth onchain! I understand the drive to present your products here but hope that in the future you’ll ask questions and do more research before posting something like this.

Thanks for the answer, and corrections!

Most of my answers are based on our prior blog post “UMA vs Kleros” I attached before, since my main goal here was to introduce other options before votation ends (since it was ending in a couple of hours) and not to sound aggressive.

I used the date of this post for as reference:

Here I was trying to make emphasis on the court and disputes stats (so if there is any stats page to portray past cases, I would appreciate it)

Correct, PNK price (as well as UMAs) is key for the economic security of the system.

The main difference is that UMA also relies (afaik) on having a high % of token holders voting (against the appeal system with it’s pro and cons) and the implications of paying token holders with UMA tokens (the photo is the summary of the explanation on the article, but if I am wrong here please let me know)

Anyways ; You are right, and I should have reached previously to make a full due diligence on my side of the whole infrastructure behind oSnap + UMA. But as I mentioned previously, since we have a supplementary product | Reality <> oSnap), with clear differences and there were only hours left, my main goal to give the possibility to Cow voters to know and consider other options.

There are still a few days left to vote, so there should be time to consider everything. Ironically, I think that an oSnap deployment would make a future Reality + Kleros deployment easier, since you’re just swapping modules. You would lose the oSnap monitoring and automation and some new Safe app features we’re developing, but those are all part of the detailed trade-offs.

You’re correct that we have a high percentage of token holders voting, and we want to increase that. We haven’t seen that to be a burden for our voters, since the vast majority of proposals are correct and go undisputed. I would guess we have about ten votes a month, off-hand. Some of them, like Across disputes, are very straightforward and technical. Others, like Polymarket disputes about wording of a prediction market, require more thought and are actually kind of philosophically interesting and fun to consider. The inflation rate, plus the slashing mechanism, has worked well to ensure that voters actually show up to vote and vote correctly. UMA is a work token at the end of the day and attracts people who want to actually use it to vote. If we started getting voter fatigue (hundreds of votes a month?) the solution would likely be to increase the proposer/disputer bonds for whatever integration is generating so many disputes. Higher bonds cap the complexity of proposals and reduce disputes and votes, since no one wants to risk a proposal bond if it’s not a sure thing.

Next: Long digression about tokenomics and fee models, feel free to skip :sweat_smile:

I would note for the diagram that UMA’s protocol-level fee model is a work in progress. Our current thinking is that integrations will be interested in paying for efficiency, which is why we’re so focused on the proposer/disputer layer. What kinds of protocols could you create if you could safely drop the challenge window to just a few minutes, with proof that validators are online and have reviewed every proposal? That’s the future we want to work towards and something integrations would probably be happy to pay for. oSnap is unusual in that the challenge windows last for days (as opposed to two hours for Polymarket, and eventually thirty minutes for Across). We don’t have any plans to charge fees for the types of integrations we currently have running.

Pragmatically, RIsk Labs has deep pockets to pay the team—and grow the team—for years, without selling any UMA tokens, while we work towards the endgame fee model. The UMA DAO has even greater resources, though mostly UMA tokens. We haven’t seen the inflation rate directly influence the token price, even though you would expect that. The inflation rate’s effect seems to be dominated by the effect of sentiment towards the protocol, macro conditions, and the absence of persistent sell pressure since the team has plenty of non-UMA resources available to pay the bills.

Since we have plenty of runway, our focus has been on adoption and technical improvements, especially around the proposer/disputer layer. Personally, if we were to tinker with the tokenomics, I think it would be interesting to boost the inflation rate for a short period to try to draw more of the tokens into the staking system to be put to work. But that’s just my personal view and I don’t think about it much. Generally, we just want to improve oSnap and our other integrations to be as good as they can be.

1 Like

Great points on both sides, but UMA vs Kleros / Reality isn’t a debate.

UMA is a blue chip security solution. We’re one of the best staffed, best funded teams in DeFi.

We’re throwing our whole weight behind oSnap and building the most secure, best UX DAO tool out there.

UMA has secured billions and will do it again. There’s never been a successful attack on UMA and there’s no profitable way of pulling one off.

We can spend hours creating false equivalencies but the facts are the facts.

In general I am happy to support this proposal and Cherry Crypto has voted in favour on Snapshot.

However this is after a considerable amount of time diving into the discussions here and other related documentation to better understand the module and the potential risks involved. This effort was likely higher than other participants’ thresholds for well-informed participation, some of whom may be silently voicing abstain due to the lack of familiarity with oSnap or how UMA oracles currently work.


A first thought, for @middleway.eth, is whether we should outline a more formal proposal framework when proposing changes that will impact the governance process. Given the high stakes involved—governance being the highest authority of a DAO and its treasury—some more formal structure around describing the change, rationale, intended benefits, potential risks, (see next section) etc. would put this information more up front.

The framework should end with a requirement for the master governance / process doc (afaik for CowDAO it is this forum post) to be updated if the proposal is passed.


Second, for @againes, appreciate the proposal and your detailed follow-up posts. However, it would have been helpful if additional material for oSnap (one pager, small deck, demo recording, etc) was originally attached to illustrate and go over examples. In particular I would have liked to have seen more info on the risks that @middleway.eth described, as well as (non-exhaustive and complementary/duplicative to @middleway.eth’s post):

  • Happy flow
  • Happy flow in case of any infrastructure failing
  • Happy flow in case of a good proposal whose tx reverts
  • “Forced flow” in case the multisig is required to intervene and force an action through
  • Dispute flow, for bad proposal
  • Dispute flow, for good proposal
  • Attacks related to spam (eg. trying to pass invalid or malicious proposal, fatiguing UMA voters, etc) or DOS (continually burning bond, forcing revotes, etc)
    • Related, I did not understand definitively what happens in the case of a correct proposal that becomes disputed. Assuming the multisig is not called into action, would this entail a re-vote on Snapshot?

And then on the UMA side, a bit more on:

  • How the proposal bot works (what does it look at and compare, how does it detect good/bad proposals)
  • How community members could participate in running such services if they wanted to, as fallback (or competitive) infrastructure
  • How UMA voters collect evidence and determine truth (are they running a similar bot, etc)
    • Curiously, why is Auryn’s proposal for the rules statement not valid? In my opinion it is better formulated and easier to understand than the original and other UMIPs suggest very arbitrary wording is possible?

I apologize this feedback is coming in relatively late given the advanced notifications around this discussion in the forum. Hopefully late is better than never as this is intended to help future processes and discussion, and on UMA’s side, should create re-usable material for future users.

1 Like

These are great notes on how we could enhance our docs. Below is a draft that we will work into our docs:

Happy flow
Snapshot proposal is created, and approved by the DAO. Transactions are automatically proposed by a bot, and automatically executed after the challenge period.

Happy flow in case of any infrastructure failing
If bots are down, a user can manually propose and/or execute through the Snapshot interface.

Happy flow in case of a good proposal whose tx reverts
The execution bot tries a static call before submitting the transaction. So if that would revert, the bot would only log that the proposal would fail. This would repeat on the subsequent runs until the revert goes away (e.g. Safe gets funded). If someone manually tries to execute and the transaction reverts, the bot will keep trying to execute until it (or someone else) executes it successfully.

“Forced flow” in case the multisig is required to intervene and force an action through
Signers can disable the oSnap module and detach it from the Safe. They can then initiate the proposal transaction(s) through Safe, collect signatures, and execute. After execution, a new oSnap module can be deployed and enabled that doesn’t have the data for the proposal that was griefed by a malicious disputer. Deploying a new module protects against the proposal being executed a second time through the module after it was already executed by the multi-sig. This flow (disable module, execute proposal through the fallback method, deploy new module) applies to all fallback methods, not just multi-sigs.

Dispute flow, for bad proposal
The bot automatically disputes an invalid proposal, after checking the Snapshot details. If done by a human, they dispute manually through the oracle interface (https://oracle.uma.xyz) during the challenge window. You can also dispute through Etherscan, from the command line, with an alternative bot system, etc.

The disputed proposal goes up to the UMA DVM for review, and the disputer will get half of the proposer’s bond. The other half goes to the UMA protocol itself so that people can’t make a “free” malicious proposal and then dispute themselves and get their whole bond back if they get caught.

Dispute flow, for good proposal
Someone mistakenly disputes a good proposal through the oracle interface, or the bot makes a mistake. The disputed proposal escalates to the UMA DVM for review, and the proposer will get 100% of the mistaken disputer’s bond. The good proposal can be re-proposed immediately after the dispute, by a bot or by a human, so that execution is not delayed any further.

Attacks related to spam (eg. trying to pass the invalid or malicious proposal, fatiguing UMA voters, etc) or DOS (continually burning bond, forcing revotes, etc)
Malicious proposals will get automatically disputed by the bots, or if everyone’s bots are down simultaneously, they will be disputed by a human. At least three human reviewers check every proposal that goes up. CoW DAO members can also see live proposals in the oracle interface and raise disputes if something is wrong, and monitoring can alert CoW to new proposals.

The bond is 2 WETH, so it is expensive to create malicious proposals. Creating enough malicious proposals to fatigue UMA voters would be very expensive, and thus unlikely. The reward/slashing mechanism for UMA staking has ensured a high level of voter participation for every vote since its release earlier this year.

Related, I did not understand definitively what happens in the case of a correct proposal that becomes disputed. Assuming the multisig is not called into action, would this entail a re-vote on Snapshot?
No, since the proposal was already approved on Snapshot it can be re-proposed again immediately after a dispute. That makes it expensive to grief a proposal with a false dispute. The false disputer would need to post and lose a bond repeatedly. If they keep it up, the multi-sig can step in.

How the proposal bot works (what does it look at and compare, how does it detect good/bad proposals)
The proposal bot verifies:

  • on-chain transactions being proposed match what was approved in the Snapshot proposal
  • the Snapshot proposal passed with the minimum parameters specified (high enough voting period and quorum)
  • the proposal follows the strategy specified in the Snapshot space

In the case of a good proposal, the bot posts a bond to propose transactions and automatically executes transactions that have not been disputed during the challenge window. In the case of a bad proposal, the bot automatically detects and disputes. The bot pays the gas for all steps in the process.

How community members could participate in running such services if they wanted to, as fallback (or competitive) infrastructure
The bot code will be open source and we’re writing docs on how other people can run it. It will be great to have fallback infrastructure.

How UMA voters collect evidence and determine truth (are they running a similar bot, etc)
UMA voters and verifiers can run bots but they are also responsible for manually reviewing the proposal according to the methodology and not just trusting the bot’s output. There are human reviewers who also verify each proposal, including those initiated by the bots.

Curiously, why is Auryn’s proposal for the rules statement not valid? In my opinion it is better formulated and easier to understand than the original and other UMIPs suggest very arbitrary wording is possible?
The bot infrastructure and human verifier training are based on standard rulesets to make sure everything is consistent and nothing slips through the cracks. Custom rules could result in confusion or a miss by human verifiers, and would require changes to the bot code for automatic verification. We’re talking with Auryn about his suggested changes so that we could incorporate them in future standard rulesets that we could suggest to every DAO.

1 Like