DAO DAO for pre GovNo chain governance
CLHRAE opened this issue · 12 comments
My takeaway from last night's spaces was that there are plenty of decisions that need to be made before launching the GovNo chain. DAO DAO is a super powerful tool that we can use to gather No / No with Veto voters to start making those decisions.
In future if deemed helpful it can be used to hold a community fund, and we can leverage subDAOs for things like grants, retroactive compensation etc.
I recorded this DAO DAO demo in order to give an overview on how the DAO can be configured, as well as a potential solution for ensuring that DAO membership is only comprised of No or No with Veto voters (abstain and non voters can come too).
I'd like to use this issue to discuss DAO configuration, and address any concerns the community might have. Also open to other solutions.
Let's dig in...
Here is a link to the demo - https://share.descript.com/view/2OrmXbo1DfD?transcript=false
I'm down to help ! :) I'm a big fan of DAODAO
I have the export of the block pre-tally, we can gather all no-voters address, and convert them to juno.
Just how do we gonna organize people to vote from the hub ? I know Juno allow tx with $ATOM, but we might need a custom frontend or something to help people easily bridge and vote no ?
How do we address this fair comment here?
https://twitter.com/0xikaruz/status/1735371296085594532?t=xzhvFZXZMZCp4AaWTzp0dw
It's a compelling argument for why this might be not suitable after all.
EDIT: probably rushed to a conclusion without much thinking lol.
We would mint a new cw20 tokens with transfers disabled I assume? This must be something we account for when going the daodao route.
I responded to the tweet. DAO DAO recently moved from cw20s to token factory, which as I understand can be made non transferable.
Have we decided the fate for validators who weighted vote? Also, I completely agree with the usability of DAO DAO.
Fantastic, thanks for creating this issue! A non-transferable token for the purposes of GovNo sounds really efficient to me.
I can't think of any reasons why that would complicate the eventual AtomOne token release versus creating something for GovNo before that from scratch. Either in terms of any type of implementation or weighting the future final airdrop after this one, anything come to mind on anyone else's end?
I have the export of the block pre-tally, we can gather all no-voters address, and convert them to juno.
Oh awesome @albttx, could you please send me the JSONs or whatever you have for this when you get a moment? Partially so I can build the airdrop simulation (I'll make sure the parameters are easy to change as decisions are made) and just analytics for fun haha
I think DAODAO could be a decent interim solution for coordinating GovNo DAO and I had previously suggested it for use with the Decentralists over a year ago but unfortunately ignored.
However if I think if we are as imminent as I'm led to believe... at this point using DAODAO is honestly the "scenic route", and we are late. We should be building a chain to establish validator relations and to sort of signal who is in actuality ready with validator infrastructure to actually want to be a part of this movement.
The only drawback might be that we can't find consensus on what the distribution would be for for the GovNo DAO and that's literally the only advantage I can see to using DAODAO before an actual chain to use for voting. GovNo voting DAO.
I'm under the impression that we should scaffold and fork Atom using Ignite and move forward with GovNo so that's more of a tangible experience than paying for governance proposals using $juno tokens. This aspect seems very illogical, to pay for AtomOne governance using Juno.
To summarize:
- AtomOne is very imminent
- We should be building validator relations and realize who actually wants to participate in AtomOne with GovNo as a test trial.
- We should not be paying for AtomOne governance decisions using Juno tokens.. that's just awkward and far past the concept.
Happy to hear your thoughts.
Oh awesome @albttx, could you please send me the JSONs or whatever you have for this when you get a moment? Partially so I can build the airdrop simulation (I'll make sure the parameters are easy to change as decisions are made) and just analytics for fun haha
#65 adds the snapshot but it would require votes also from the subsequent block to be completely accurate. (technically, it would require to apply all state transitions from the next block, #65 (comment))
https://github.com/atomone-hub/genesis/blob/main/snapshots/README.md
props to @albttx who is also working to get a snapshot of prop 82 (for potential future use)
@Ticojohnny I can definitely get on board with that thinking too. At least some work would ideally be happening on the chain itself even if the DAO DAO route is chosen.
Does anything feel like we need voting as urgently as possible? If not we could stick to the new chain and simply prepare the weighting/proposal data for that instead of transferring it all to DAO DAO ASAP. Considering the basic voting-only functionality, hopefully not a ton if any work would need redone after GovNo when things are ready for the final token.
I think DAODAO could be a decent interim solution for coordinating GovNo DAO and I had previously suggested it for use with the Decentralists over a year ago but unfortunately ignored.
However if I think if we are as imminent as I'm led to believe... at this point using DAODAO is honestly the "scenic route", and we are late. We should be building a chain to establish validator relations and to sort of signal who is in actuality ready with validator infrastructure to actually want to be a part of this movement.
The only drawback might be that we can't find consensus on what the distribution would be for for the GovNo DAO and that's literally the only advantage I can see to using DAODAO before an actual chain to use for voting. GovNo voting DAO.
I'm under the impression that we should scaffold and fork Atom using Ignite and move forward with GovNo so that's more of a tangible experience than paying for governance proposals using $juno tokens. This aspect seems very illogical, to pay for AtomOne governance using Juno.
To summarize:
- AtomOne is very imminent
- We should be building validator relations and realize who actually wants to participate in AtomOne with GovNo as a test trial.
- We should not be paying for AtomOne governance decisions using Juno tokens.. that's just awkward and far past the concept.
Happy to hear your thoughts.
Yeah, I agree with you on most points.
To reiterate, the idea to run a pre- GovNo chain daodao dao was to help form consensus around how the GovNo chain would be configured.
I agree wholeheartedly that validator relations are very important, and the earlier we start organising the better.
As far as your comment on JUNO, I also agree with this. It's weird, but was only used as an example for the demo.
You can require Atom tokens for a deposit if needed.
Follow on thought. If GovNo's sole purpose is to supply a gov token to allow us to further organise, why not create a new GovNo DAO DAO deployment? We can start to consolidate validator interest whilst making decisions around how GovNo is configured. The tools are there and ready to use. No coding required.
I appreciate that I have a huge bias towards DAO DAO, as I'm heavily involved in the project, but as far as I've seen (please prove me wrong), DAO DAO is the most advanced governance tooling in crypto - bold claim, but I've yet to be corrected. I don't see the point in re-inventing the wheel when the ecosystem already has a solution. I hope that the community can see that my favour to DAO DAO comes from a place of wanting to help both GovNo and AtomOne.
However if I think if we are as imminent as I'm led to believe... at this point using DAODAO is honestly the "scenic route", and we are late. We should be building a chain to establish validator relations and to sort of signal who is in actuality ready with validator infrastructure to actually want to be a part of this movement.
I am 100% in agreement.
The only drawback might be that we can't find consensus on what the distribution would be for for the GovNo DAO and that's literally the only advantage I can see to using DAODAO before an actual chain to use for voting. GovNo voting DAO.
The logical Schelling point is NO+NWV voters only, with no additional reward for veto voters. The veto voters are too small in number in comparison to NO voters, that so they should be able to tolerate having no reward, while those who voted NO but not NWV can reasonably take offense at any additional reward going to NWV.
I'm under the impression that we should scaffold and fork Atom using Ignite and move forward with GovNo so that's more of a tangible experience than paying for governance proposals using $juno tokens. This aspect seems very illogical, to pay for AtomOne governance using Juno.
It would be less work and more secure to fork cosmoshub-4 and comment things out.
To summarize:
AtomOne is very imminent
Govno evern moreso
We should be building validator relations and realize who actually wants to participate in AtomOne with GovNo as a test trial.
100%
We should not be paying for AtomOne governance decisions using Juno tokens.. that's just awkward and far past the concept.
I'm more concerned about depending on another chain's/product's security. More on that...
RE security from first principles:
GovNo chain daodao dao was to help form consensus around how the GovNo chain would be configured.
That GovNo was first declared and now DAODAO is becoming suggested as a dependency is concerning.
I understand that DAODAO is already in use, but as a matter of principle I'd like to ensure that GovNo stays independent.
Risking the keys of the NO voters by any means poses an existential threat to AtomOne. We cannot promote anything that requires everyone to adopt software that we are not accustomed to or have vetted. Recently there was discovered a vulnerability in the Ledger client library, for example. What are all the ways in which voters can leak their private key? Are there any Juno/DAODAO specific clients (like a web app) that users would be led to install that encourages them to enter their privatekey/mnemonic? Even if the user had the option to use a hardware ledger, I do not support apps that offer that (WITHOUT AMPLE WARNING) as a matter of principle (because some users are inevitably led to leak their keys). We would need to support transaction signing with just the standard cli, as many of us depend on offline signers. Is it easy to export the JSON to sign using the existing gaiacli tx signing feature? Does it require or strongly incentivize installing an application or mobile app?
On another general note about governance dependencies; the disparity in participation between the two parties would cause confusion; I suspect a lot of voters will prefer not to use DAODAO due to nonzero friction. GovNo should not take DAODAO as input in its own governance because it is dangerous; this dilutes security to the lowest denominator, or worse.
For the purpose of this genesis repo, but also generally all splits, we should follow the principle of not introducing new required tooling, and only making minimal changes to the tooling that voters have already been using prior to the fork. If AtomOne wanted to use DAODAO tooling, arguably it should probably first run it under an ICS zone under its own control, and forks of that project maintained by approved AtomOne vendors (consistent with not depending on the security of other chains/projects). Then, future splits from AtomOne can use DAODAO (or the DAODAO fork) primarily to coordinate GovNo, instead of using the SDK's governance module. And these principles should be codified (well in a way they are in these comments) so that future splits can be done as securely as possible. Future splits can refer to this security principle that was started here in this repo. In short, the principle is that during the split no new optional tooling should be introduced.
DAODAO is deployed on Juno, and Juno's market cap is $53M. The damage that could result from control over Juno itself should also be considered. The Juno chain validators could exclude votes in a critical proposal. The Juno chain validators might be opposed to AtomOne itself. There is some threshold ratio between the market cap of Juno and Gaia (cosmos hub) here where this becomes a tangible concern, and it feels like it is. This can be mitigated with an agreed disclosure that nothing is binding, but in reality there is often not sufficient reminder while public sentiment is always manipulated.
GovNo DAO DAO deployment? We can start to consolidate validator interest whilst making decisions around how GovNo is configured. The tools are there and ready to use. No coding required.
The downside to this is that now we have to audit the whole DAODAO+Juno stack.
I suggest that for now, we maintain a separate DAODAO.md file, and this file linked to from the README as an optional experiment that nobody is required to (and not everyone is expected to) join, so that at least we can compile all alternatives in one place. In the future this repo should also include files for DAO systems built on other platforms too, thus making the AtomOne/genesis repo a general template for splitting chains or hubs.
If the DAODAO.md file was specific enough in its instructions, where the instructions are using existing Gaia tooling, and there is no risk of hacking or phishing, and all the knowns ways there might be concerns are iterated (such as for any mobile apps, what are all the privacy and security concerns; whether there are any gotchas where the user may even accidentally expose their private key), then I can imagine becoming convinced that this is secure enough, but the bar is pretty high. I think it makes more sense to use this as an opportunity to begin answering the above questions, for the next generation of splits that need to happen, but time will tell, and maybe the GovNo chain will.
Makes a ton of sense, even if DAO DAO was being used it's necessitate working on the new chain in tandem anyways. So especially if GovNo voting isn't needed yesterday, we can definitely go straight to setting up the voting on a new chain instead of having any type of intermediary step like DAO DAO. Makes sense that you'd not only like to separate the final chain but GovNo and initial voting itself, so that's what we'll shoot for.