Governance & Community Pool thoughts

[clockworkgr]

This is a list of thoughts/considerations I believe will be beneficial to the design of AtomOne:

• Adopt Decentralists DAO governance suggestions: https://github.com/decentralists/DAO/tree/main/governance

Some have already been adopted by the hub. The most important one in my view is the separation of staking and governance. Extending on that, and because direct voting suffers from voter apathy to an extent. I think a staker should be able to delegate to an account for voting on proposals the same way they delegate to validators. It is already possible via authz but I think a specific module/redesign of the mechanism would be better.

In a slightly more extended system, proposals could be "tagged" as pertaining to a specific domain: e.g. marketing or architecture etc. and a staker could have the option of setting different accounts he delegates to for different tags.

The reasoning behind this design is that as mentioned in the Decentralists DAO roadmap, validators should not be politicians. Validators should be solely chosen based on their performance, security considerations and technical know-how.

The reasoning for the afore-mentioned tagging system is that it's very hard for a staker to follow everything that might be happening within the chain and wider ecosystem or have the necessary know-how to evaluate/judge a proposal.

Over time, certain accounts will become recognized in the community for their expertise in specific domains. Allowing stakers to delegate decision-making to these trusted accounts will foster broader, though indirect, participation in governance.

The crux of it is that as a staker, I want to be able to codify that:

1. I trust person X to run a secure and reliable validator
2. I trust person Y to know his stuff when it comes to marketing
3. I trust person Z to make architecture decisions

etc.

• Community Pool overhaul

The community pool is a very powerful tool for growing a chain and ecosystem that has been severely abused and misused in the past due to the existing governance system and certain aspects of its design. Based on my observations and the discussion here: https://github.com/atomone-hub/genesis/issues/32 I would propose the following:

1. Limit funding per proposal This can be a hard-limit in $ or a perc-of-pool limit. Changeable by governance within bounds

2. Funding proposals should have a start-date and end-date thus allowing for a total funding limit at any given time.

3. Proposals should be denominated in $ (or other fiat equivalent) until such time where token volatility is sufficiently low to not have to. For approved funding requests, a faux-stable/USD-pegged token could be minted for the amount requested which could be redeemed in part or in full at any time between start/end dates for the actual community pool funds based on an (oracle-provided) exchange rate.

4. Building on the above, release of funds could be gradual/vested over the start/end period for most proposals. Lump sum release could be requested but would require a higher majority approval.

5. With a gradual/vested release, a proposal could be contested in the future and with appropriate majority approval rescinded to stop the release of funds. This would be appropriate in scenarios such as the one currently in progress with Notional and Proposal 104 of the hub

I will add to this topic based on discussion and subsequent ideas

[jaekwon]

Adopt Decentralists DAO governance suggestions

Yes I think we should copy over the governance suggestions into this repo, basically migrate it here for now.

proposals could be "tagged" as pertaining to a specific domain

I love that you brought up tags. I believe like you said, that we should support liquid-democracy-type delegation to people, for ideally more or less orthogonal tags or concerns. If a proposal should be associated with a blend of concerns, then arguably it need to pass each independently.

We need to make sure the tags are good, but we can probably help by pre-defining a few important tags in the constitution as required to support.

Developing this should be a long-term goal but we can define in the Constitution the steps to roll it out safely.

Community Pool overhaul

Perfect, thank you for taking the lead on this. I like the way you think.

How do you feel about turning this into an issue dedicated to this tags idea, and breaking out "Community Pool overhaul" into a separate issue?

I suggest that you create two separate files in a PR, HYPERDELEGATION.md (or whatever it is called, for a long-term plan to support this experiment safely, with tags, and how to manage the tags), as well as "COMMUNITYPOOL.md" where all the community pool relevant (constitutional) laws are; and then we can be codeowners for these aspects, and we can invite anyone else if (AND ONLY IF) we trust their judgement based on their contributions to ISSUES discussions for the relevant files (like tags :) ).

[0xFDg]

@clockworkgr the ideas are very nice! I love the distinction about validators, marketing and architecture decisions!

In a slightly more extended system, proposals could be "tagged" as pertaining to a specific domain: e.g. marketing or architecture etc. and a staker could have the option of setting different accounts he delegates to for different tags.

I would also add the possibility of using a module, perhaps something like ShadowJS SDK, or a related SCRT technology to ensure privacy when an address chooses accounts to delegate voting to and maybe also for the vote, only the Decentralist has to prove and justify the vote.

[giunatale]

Extending on that, and because direct voting suffers from voter apathy to an extent. I think a staker should be able to delegate to an account for voting on proposals the same way they delegate to validators. It is already possible via authz but I think a specific module/redesign of the mechanism would be better.

Authz is a slippery slope, how would you prevent "nesting"? I think a flat 1 delegation-delegate level is enough. I may be wrong but authz I don't think is enough by itself to prevent nesting.

As I also wrote here maybe we might want to look at how Optimism works, because they also use this delegates system.

[clockworkgr]

Extending on that, and because direct voting suffers from voter apathy to an extent. I think a staker should be able to delegate to an account for voting on proposals the same way they delegate to validators. It is already possible via authz but I think a specific module/redesign of the mechanism would be better.

Authz is a slippery slope, how would you prevent "nesting"? I think a flat 1 delegation-delegate level is enough. I may be wrong but authz I don't think is enough by itself to prevent nesting.

As I also wrote here maybe we might want to look also at how Optimism works, because they also use this delegates system.

I agree. I said it was kinda possible through authz but should best have it's own first class module baked in