Ideas for Snapshot voting integration with Defender Admin

We have heard from several teams that they are using Snapshot for collecting votes on proposals from their community, and then executing them through team multisig wallets via Defender Admin. With this in mind, we have been in touch with the dev behind Snapshot, and have been brainstorming a few ideas about integrating the two systems. So we wanted to open up the discussion to the community!

Let’s start with the strengths of each system. Snapshot focus is on creating proposals for the community to vote on, making it easy to plug in different voting strategies. Defender focus is on simplifying the creation, review, and execution of administrative transactions, by making it easy to run upgrades or call protected functions via multisigs (and soon timelocks!).

Regarding integration points, Snapshot is unopinionated, but has a nice plugin architecture that we can leverage. A limitation is that proposals are stored in IPFS and are hence immutable. On the Defender side, we have a bit more freedom on what we want to do :wink:

Given all the above, this is a possible flow we have in mind:

Create proposal in Admin

As a project team member, you create a new proposal in Admin for a transaction that would enforce a change in the contracts, such as an upgrade. This is Defender’s bread and butter, making it easy to craft a transaction for an admin action out of a few inputs.

Making the proposal public

Once the proposal in Admin is created, you can make it publicly accessible via a unique URL. We can push this even further and turn it into a “Publish to IPFS” option!

Creating the equivalent proposal in Snapshot

Here’s where the magic happens. Using a Defender plugin in Snapshot, during proposal creation, you can link the Snapshot proposal to the Defender one, using the public URL generated in the previous step. This gets stored in the Snapshot proposal metadata on IPFS.

Viewing Snapshot info in Defender

With both proposals linked, we can now show you Snapshot voting information within Defender Admin, so you can know how your community has voted on a proposal before activating it. We can even add further restrictions and prevent you from executing if the vote hasn’t passed - or at least give you a very stern warning.

Screenshot from 2021-03-11 19-27-27

Viewing Defender info in Snapshot

And now your community can also see exactly what transaction will be executed associated to the proposal they are voting on, giving them further transparency on the process. And since the Defender Admin proposal is publicly accessible, we can also link to Defender so they can see all the decoded transaction info.


So what do you think? Does this align with your usage of Snapshot at the moment? Please share your feedback!

3 Likes

Looks great.
I have a side idea. It would great to be able to push results of off-chain voting into a smart-contract using Defender Relay. Currently, this is done manually by a multi-sig but there should be a way to automate it.

2 Likes

Certainly! I’m thinking we could use a Sentinel that watches for ExecutionSuccess events emitted from the Safe, triggers an Autotasks, and it fires a tx through a Relayer to log the results in a contract.

2 Likes

Hi! Here is Fabien from Snapshot, i love these ideas :slight_smile:

I see many similarities in Defender and Snapshot UI layouts, i can see these integration would fit very well. That will give much more context for the users on both apps.

We can imagine in future having a way to publish a proposal to Defender within Snapshot or publish a proposal to Snapshot within Defender so the author of the proposal don’t need to cross post. Or even further, having a way to vote within Defender, or execute a transaction within Snapshot, but let’s start simple :slight_smile:

On Snapshot we have plugins where parameters can be set at the proposal level you can try here with the Aragon plugin if you click on the sparkles icon https://snapshot.org/#/dai-rinkeby/create . We can have a Defender plugin where the author of the proposal can input the Defender proposal url / id.

I’m curious about Defender Relay and how you see it work. Would Defender Relay act as an oracle and post the results (not the votes) of the proposal on-chain? And then this info will be used to prevent doing action that was not approved?

3 Likes

Thanks for the comments here, Fabien!!

We thought about both, but given we’re constantly adding new options for building txs within Defender (the “pause action” being the most recent ones), and Snapshot is also constantly adding new stuff (plus the plugins!), we wanted to avoid having to duplicate efforts in terms of keeping the create UIs in sync between both projects.

Sounds great! One thing I had in mind to reduce the pains of cross-posting: would it be possible from the plugin pre-populate title and description of the proposal, by pulling them from the Defender one? So user opens the Defender plugin, inputs the Defender proposal ID, and they automatically have the title and description pre-filled in Snapshot with the contents from Defender - though they can still edit them to add further info.

Interesting! We haven’t though about adding Defender Relay in the mix here, but it’s definitely doable. We can use an Autotask to collect the results of the Snapshot votes, and then have a Relayer push them on-chain. Is there an event or anything emitted by Snapshot when a voting closes, that we could rely on? Otherwise, we can just poll the proposal every few minutes, and once we see it closed, we push that on-chain. It should be pretty simple!

1 Like

Just to clarify. Current the problem is that Snapshot is off-chain voting so people have to manually submit result of voting on-chain. Usually multi-sig is used. I was thinking that Defender could bridge that gap by combining Relayer, Autotasks and Admin. Not sure exactly how though. Pretty sure Gnosis Safe working on something like this.

2 Likes

Nice!

One thing I had in mind to reduce the pains of cross-posting: would it be possible from the plugin pre-populate title and description of the proposal, by pulling them from the Defender one?

Yes that’s a good idea, it’s not possible atm but that’s something we could implement.

Is there an event or anything emitted by Snapshot when a voting closes, that we could rely on?

There isn’t, we have a webhook server that send callback on each new vote or proposal but not when a proposal end.

I was thinking that Defender could bridge that gap by combining Relayer, Autotasks and Admin. Not sure exactly how though. Pretty sure Gnosis Safe working on something like this.

That would be neat, we are working with few projects including Gnosis to enable such onchain settlement solution, we could explore this with Defender.

1 Like

Some thoughts from The Graph team:

  • The cross viewing / linking of the snapshots and admin function calls in defender is useful.
  • To me, the most useful part is being able to show the community voting on snapshot the actual function calls that will happen in Defender, and having them clearly explained (rather than just a block of bytes). I believe defender already does this, which is great
  • We have 2 snapshot votes. One by the community that is non-binding in execution, and another one by the council that is binding in execution. So for the council vote, having the ability to make the snapshot result in the onchain upgrade would be great, or vis-versa.
2 Likes

Thanks @David_Kajpust!

I take it this bit is to be able to collect all the signatures from all council members, right?

1 Like

Yeah, if we could take all those signatures and forward that to a relayer for execution, that would be useful.

3 Likes