Update settings.json to new oSnap plugin

[cmagan]

Description

Update settings.json to migrate from legacy safeSnap to new oSnap plugin

Changes

oSnap docs include a step by step guide for doing this change though the Snapshot interface.

Unfortunately there's no explicit explanation for updating settings.json, so I had to reverse engineer it.
But the change is straight forward and the new oSnap plugin does not take any parameters.

How to test

1. Deploy a test space with the new settings
2. go to the space interface and check the settings
3. see the setup similar to how a successful setup looks like in the step by step guide on the oSnap docs
   

[mfw78]

Before activating or approving anything here, we need to have a source of truth. Therefore we need to have the settings.json documented showing that there is no additional properties for the oSnap plugin.

[abg4]

My name is Alex and I am from the UMA team. I just wanted to leave a comment that the update looks good to switch from the SafeSnap plugin to oSnap.

What helped my review was a testnet space I set up for a team a few months ago. It's not a production space but I created this snapshot text record and made the update with this proposal. I also made some changes to the space and made another proposal to check the changes were accurately reflected in the Snapshot space and it matched the update in your PR.

The other requirement for the oSnap plugin is to have the Safe address used with oSnap included in treasuries which you already have set.

Let me know if you have any questions.

[mfw78]

@cmagan FYI, I've reviewed the above, but cannot merge as no longer a contributor on this repository.

[fedgiac]

I've been asked to review this change but it's hard for me to understand its impact so I'd like some clarifications if possible.

My understanding is that this change won't have any direct on-chain impact (we'd still be using the current OptimisticGovernor) except for an ENS record change, but it's about social consensus on who should be executing the transaction.
What we're doing here would be telling UMA's oSnap plugin to "please automatically execute transactions on the behalf of the DAO if the proposal passes." It's not clear what changed between safeSnap and oSnap and why this requires an on-chain acknowledgment (why isn't it just a flag umaAutomaticExecutionRequest: true?). It's also unclear why we can forgo specifying the module address in the settings. But maybe it's explicit in each Snapshot proposal, or implicit in the fact that the safe that sets the ENS record has some OptimisticGovernor-like contract that can be used for this?

In general, I very much feel the need for much more documentation in what is the impact of this settings file. (Note that I still find it better than just blindly relying on doing what the web interface just tells me to do.)

[cmagan]

Thanks @fedgiac for reviewing!
The change is mainly because we want to use the latest version of the osnap snapshot plugin.
It has a bunch of new features including tenderly simulations.

The only onchain change needed, is to update cow.eth snapshot settings

[fedgiac]

It makes sense, but I don't see exactly what the plug-in change entails apart from an interface change.

I understand there can be legitimate reasons: for example, the format used by a proposal could have changed, and with this we tell Snapshot that we're aware of it and our proposal will now match that. However, I don't see any indication of a reason like that, and things like "include a Tenderly simulation" are great but in principle are just a front-end change and don't need any obvious acknowledgment on our part.

To me, understanding this is key to understand if switching plugins can have unintended consequences. (I very much doubt that, but automated transaction execution on a DAO is critical enough that's good to double check anyway.)

[cmagan]

I 100% agree!

This is also my understanding, CoW DAO is required to make the settings changes onchain, but the result is just a UI improvement of CoW DAO's snapshot space.

[fedgiac]

After looking a bit more into it, I believe this is indeed mostly a UI change and I don't think there are negative repercussions. In particular, the execution mechanism remains the same.