I think we should connect, both on-chain and off-chain modules together,
but I’m not picky about the Snapshot space and ens, but it should be selected based on the current procedure.
I think we should connect, both on-chain and off-chain modules together,
but I’m not picky about the Snapshot space and ens, but it should be selected based on the current procedure.
How about the following approach
a) The treasury has now capability of receiving ENS domains. We let the community find their snapshot space by participation of the community members.
b) Once we have proof where the majority of the community is most active, we strengthen this decision by an on chain vote setting the respective URL in fractal’s framework
c) Once a) and b) is successfully executed we continue to build a process on top as proposed by @Baer_DAOplomats
if the community ever wants to migrate we can repeat b) in the future.
This is Tom , Project lead at Fractal. I actually +1 a lot of what has been said by @fred-bb .
for a) → It sounds like some amount of social proof is required (i.e. gauging which ENS domain ‘wins’) before it is formalised onchain. This can be really tricky so the only thought here is that I wonder if one of the earlier snapshot proposals could contain an agreement for what ‘enough participation proof’ looks like. Even this is flawed… but at least its some evidence for later.
for b) → Once you are at that stage, this leans more to my area. As @fred-bb has confirmed we have an Fractal<>Snapshot integration. Anyone can use the ‘Settings’ page (i.e. click the three dots on the home page) to propose x1 ENS to be the DAO’s designated Snapshot space and have it saved onchain. This will then proceed like any onchain vote. If the vote is passed and executed, then we save the ENS formally in our FractalKeyValuePairs contract. You will then also be able to see and vote on all Snapshot proposals right next to your onchain activity in the UI. Another onchain proposal will be required to switch this snapshot space or remove it.
The only caveats is this integration works with Snapshot ‘Single Choice Vote’, ‘Basic Vote’ and ‘Weighted vote’ as well as ‘Any’ and ‘Shielded’ privacy types (i.e. we estimate about 90% of all Snapshot proposals) . We also don’t have the functionality to create snapshot proposals in the snapshot space from our UI yet… Saying that, individual members can always default to the Snapshot space’s original UI if they personally prefer it.
For an example of Fractal<>Snapshot integration, - Ethlizards are currently running a small goerli test on our testnet site here - Fractal - → Note goerli is deprecating by Jan 31st so no guarantees this link works after that.
This feature is really important for me so communities can i) see clearly how the DAOs offchain activity interacts with onchain execution ii) confirm only x1 ENS snapshot space.
for c) if there are any additions Fractal can make to ease these next steps, please let us know in Shutter DAO Fractal Feedback Thread
I hope this is helpful as you decide
A Shutter DAO 0x36 Snapshot space is currently live: Snapshot
And Shutter DAO 0x36 owns shutterdao0x36.eth: - ENS
So if you are a community member with voting power (you delegated to yourself or someone delegated to you), then you can …
OR