Creation of DAO for true decentralized governance

[olahouze]

Protocol Change Proposal

Summary

Modification of the governance to have a real decentralized democracy

Problem Definition

Currently each proposal of modification of the Protocol requires :

• To have a certain number of tokens (512 at the beginning but the limit was lowered in a request of evolution)
• To have the hand on a validator (https://docs.cosmos.network/master/modules/gov/03_messages.html)

This comes back to the existing systems in the real life with the election of ministers/representatives, and thus to the possible drifts that we know

Proposal

The proposal would be to create a DAO which would allow each person having token to be able to make requests of evolution even if it does not have a node of validation

Note : this is the same as the RFC system which is the basis of the internet construction

The operation would be as follows:

1. Creation of a DAO for COSMOS
2. Each person who stacks tokens on a validator (delegation or not) is assigned the same amount of "governance" tokens in the DAO
   For this need, possibility to create a DATOM token (for DAO ATOM) which has no financial value, just a governance weight
3. Each person with DATOM will be able to propose evolutions by submitting proposals in the DAO
4. Each person will be able to vote in the DAO and the weight of a DAO member will be relative to the number of DATOM he/she owns
5. If the request is validated (80% of OK) in the DAO, a validator will be designated to create the "evolution request" in the current classic system (deposit of ATOMs as surety + creation of the proposal message)

In this way

• The important participants in the network will have a stronger weight than the others (because many DATOM)
• A user with a low number of ATOMs will be able to propose evolutions all the same

Management of blank votes
In case of lack of voters we can consider that validators to whom ATOMs have been delegated can have proxy on them in the DAO

Example :
Period 1 (14 days)
Validator 1 : 10 clean tokens => OK
User 11 : 10 tokens => OK
User 12: 10 tokens => KO
User 13: 10 tokens => No vote
User 14: 10 tokens => No vote

Validator 2: 10 clean chips => OK
User 21: 10 tokens => OK
User 22: 10 tokens => KO
User 23: 10 tokens => No vote
User 24: 10 tokens => No vote

In this example, we have 100 tokens and only 40 OK and 20 KO (we do not have the 80% to validate or invalidate the request)
The validators use their proxy for the second period

Period 2 (14 days)
Validator 1 : 10 clean tokens => OK
User 11: 10 tokens => OK
User 12: 10 tokens => KO
User 13: 10 tokens => No vote => Becomes OK
User 14: 10 tokens => No vote => Becomes OK

Validator 2: 10 clean chips => OK
User 21: 10 tokens => OK
User 22: 10 tokens => KO
User 23: 10 tokens => No vote => Becomes OK
User 24: 10 tokens => No vote => Becomes OK

In this example, we have 100 tokens and only 80 OK and 20 KO We do not have the 80% to validate the request

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned