CIP-56: Snapshot setting changes

Governance
, ,
1 
CIP-Draft: Snapshot settings updates
Authors: c3rnst, middleway.eth
Status: Draft
Created: originally 2024-11-1 (separated from Delegate CIP)

Simple summary

This posts summarises a number of Snapshot setting changes that have been discussed on the Forum for a number of weeks and decouples this from the proposal on delegation.

The following changes are proposed to be approved with the passing of this CIP:

I CIP Template Revision:

It is recommended to include transactional data to a CIP (the tenderly simulation is optional). This way, there is time for experts, community and voters to review the transaction and to comment.

The CIP draft must also include a text description of what the transaction should achieve.
Moving forward, CoW DAO will emphasize the need for verification of the proposed transaction on Snapshot: the transaction posted on Snapshot is the relevant one as that transaction that will execute when the proposal is successful.

Hence, the CIP template will be amended to add a bold line, mandatory to be included in the CIP text and then on Snapshot: “Transactions will be executed on CoW DAO’s Safe using the oSnap plugin, contingent upon successful passing of this CIP. When voting on Snapshot, participants are encouraged to verify the content, cross-check Tenderly simulations, and confirm alignment with the CIP’s intent.”

II oSnap plugin update

This CIP proposes to introduce a new version 3 of the oSnap Snapshot plugin. This updated plugin will automatically include a Tenderly simulation of the proposed transaction on the Snapshot page - for the convenience of verifying it.

III Governance processes & delay period on oSnap

This CIP proposes to increase the delay period on oSnap from a currently implemented two days to three days.

To not extend the total governance period, Forum time is reduced to 6 days (instead of 7 days).

In summary:

  • Forum discussion: a min of 6 days
  • Snapshot voting (as before): 7 days
  • Execution delay period: 3 days

Do note, that recently a proposal passed for slashing proposals to have a forum requirement of only three days (as a known and approved exception to the rule).

IV Update to the new CoW DAO logo
Long time waited visual update!

Proposed transactions

This CIP shall trigger the following transactions once moved to Snapshot:

  1. Update to version 3 of the oSnap module: Update settings.json to new oSnap plugin by cmagan · Pull Request #10 · cowprotocol/snapshot-settings · GitHub (in review; compatibility with v2 is being checked also)
  2. Including 3 day oSnap delay
    (WIP)
  3. Include the new CoW DAO logo for its Snapshot space: Update settings.json with new avatar (#9) · cowprotocol/snapshot-settings@3e68719 · GitHub

When moving to Snapshot, the new Github state will be put on IPFS and CoW DAO will point to that IPFS.

Transactions will be executed on CoW DAO’s Safe using the oSnap plugin, contingent upon successful passing of this CIP. When voting on Snapshot, participants are encouraged to verify the content, cross-check Tenderly simulations, and confirm alignment with the CIP’s intent.

2

Moving to a 3 day delay on execution is a solid method for reduce attack surfaces over a weekend. :+1:

2 Likes
3

This has moved to Snapshot: https://snapshot.box/#/s:cow.eth/proposal/0xf923f716d6eb13564d810b9c6fc505d27c60c2fc8812460eaa6c3b6d75de0aee

with the following text and tenderly simulations:

CIP-56: CoW DAO Snapshot settings updates
Authors: c3rnst, middleway.eth
Status: Active
Created: originally 2024-11-1

Simple summary

This CIP includes a number of snapshot setting changes that have been discussed on the Forum for a number of weeks.
The following changes are proposed to be approved with the passing of this CIP (re-ordered):

I oSnap plugin update (Snapshot setting update)

This CIP proposes to introduce a new version 3 of the oSnap Snapshot plugin. This updated plugin will automatically include a Tenderly simulation of the proposed transaction on the Snapshot page - for the convenience of verifying it.

II Update to the new CoW DAO logo (Snapshot setting update)
Long time waited visual update!

III Governance processes & delay period on oSnap (Uma setting update)

This CIP proposes to increase the challenge period on oSnap from a currently implemented two days to three days.

To not prolong the total governance period, Forum time is reduced to 6 days (instead of 7 days).

In summary:

  • Forum: a min of 6 days
  • Snapshot voting (as before): 7 days
  • Execution delay period: 3 days

Do note, that recently a proposal passed for slashing proposals to have a forum requirement of only three days.

IV CIP Template Revision (not a setting but formality):

It is still recommended to include transactional data to a CIP (the tenderly simulation is optional). This way, there is time for experts, community and voters to review the transaction and comment below.

The CIP draft must also include a text description of what the transaction should achieve. Moving forward, CoW DAO will emphasize the need for verification of the proposed transaction on Snapshot: the transaction posted on Snapshot is the relevant one as that transaction that will execute when the proposal is successful.

Hence, the CIP template will be amended to add a bold line, mandatory to be included in the CIP text and then on Snapshot: “Transactions will be executed on CoW DAO’s Safe using the oSnap plugin, contingent upon successful passing of this CIP. When voting on Snapshot, participants are encouraged to verify the content, cross-check Tenderly simulations, and confirm alignment with the CIP’s intent.”

Proposed transactions

  1. Update to version 3 of the oSnap module
  2. Include the new CoW DAO logo for its Snapshot space

For one and 2, the newest setting is available here:

  1. Including 3 day oSnap challenge period
  • Changes oSnap setLiveliness parameters to 259200 (3days)
  • Tenderly Dashboard
    NOTE THAT IT’S PRE-RUN (need to verify on Snapshot directly for the correct inclusion of this)

Transactions will be executed on CoW DAO’s Safe using the oSnap plugin, contingent upon successful passing of this CIP. When voting on Snapshot, participants are encouraged to verify the content, cross-check Tenderly simulations, and confirm alignment with the CIP’s intent.

4

We generally support this proposal.

  • Governance votes and the actual execution of transactions should conclude in a safe and secure manner.
  • Having transaction simulations available at the time of Snapshot submissions, which can be verified, is highly meaningful.
  • The other proposed changes also seem reasonable overall.

However, we have a few questions before the vote: @c3rnst

  • What is the reason for extending the delay period from 2 days to 3 days? While there is a comment from @mfw78, is it an accurate explanation?
  • Additionally, in such a case, what measures would be taken if a malicious governance participant successfully passes a proposal? We would like to understand how extending the delay period by one day would impact CoW DAO’s response to such a scenario.
5

Hi there. thanks for your feedback.

Indeed, if the challenge period falls on a weekend or extended public holiday, there might not be a quick enough reaction from the community to stop the automatic execution of a faulty transaction.

Additionally, in such a case, what measures would be taken if a malicious governance participant successfully passes a proposal? We would like to understand how extending the delay period by one day would impact CoW DAO’s response to such a scenario.

Well, ideally it does not get to this stage. But assuming the malicious governance attacker is going by the rule book (reached quorum and majority for-votes), then the question is if the intended execution matches the transaction (of if it’s imposed a malicious transaction, of which other voters were unaware): oSnap module would automatically execute unless the module is deactivated. In the case that the execution does not match the intention of the proposals, I’d argue that CoW DAO signers are mandated to remove the module.

If it’s meant to rightfully pass and the transaction matches the intention of the proposal and the understanding of the voters, then I would argue it’s the intention of the voting community (= CoW DAO) and should pass.

happy to hear feedback and suggestions for improvement (that you might have gathered in other DAOs)?

1 Like
6

Thank you for your explanation @c3rnst. We think the proposal itself is solid, so we plan to vote for it.

That said, we’d like to share two points that might be worth considering for the future. These are more ideas for potential future discussions rather than issues to address right here and now:

  1. Standardizing the timeline for starting Snapshot votes
  • For CIP-53, 54, 55, and 56, there seems to be no clear reason for staggering their timelines. These could have been initiated simultaneously.
  • Aligning timelines could help avoid critical periods, such as the Delay Period, from falling on weekends or holidays, ensuring smooth execution of expected functions.
  • It would also reduce the workload for governance participants, particularly delegates.

(We made a similar proposal in Lido, in which we suggested to extend the voting period to encourage broader governance participation.)

  1. Preventing incidents like Compound’s “Humpy” case

  • The Humpy case in Compound involved large token holders prioritizing personal gains over ecosystem benefits. While some proposals failed due to community pushback, others succeeded despite opposition, causing significant harm. Learn more here.

  • Unlike Compound, the longer voting periods in CoW DAO naturally make attacks like Humpy less likely. (Compound’s on-chain voting lasts only a bit longer than two days, with no restrictions on the time between forum posts and Snapshot initiation.)

  • However, CoW DAO’s voting process, like Compound’s, relies on a single vote and lacks a second stage of on-chain validation. This means that once a malicious proposal passes, there is little (if any) recourse.

    Such situations should deviate from the intention of the voting community as described by @c3rnst

We’d be happy to hear thoughts on these ideas and explore whether they resonate with others for future improvements.

1 Like
7

Yes, I kind of like this (a bit like in a direct democracy where every quarter there is voting)…
I also noticed the staggered proposals, which is a hassle for voting, generally.

When I though about it in the past, I kind of discarded it as I didn’t think CoW DAO is “big enough” to make this change:

  • So far it’s not been a big problem
  • Proposals are submitted by different teams (within the core team but also external), oftentimes with some kind of urgency or goal
  • We’ve tried to group a few of them internally for synergies, but also failed because the one “we waited for” got pushed further back - which meant everything had to wait…

All in all, I’m not against it though - we can think about it a bit more and maybe eventually the recognised delegates will form a working group around governance to address this.

On the second point:

relies on a single vote and lacks a second stage of on-chain validation

I believe the oSnap module does some checks for the on-chain execution.

But all in all, I’m in favour to reduce governance risks, so maybe we can form a working group with experts to address these. Currently, I’m OK to know that there are many people reviewing transactions, but doesn’t hurt to be more thorough :slight_smile:

1 Like