Proposition for a governance minimization model
There are multiple options for voting. The following are the most common:
(a) Per-wallet based (1 user, 1 vote)
(b) Share-based (1 token, 1 vote)
(e) Alternate conviction – voting power increases each time as well as reputation (i.e. voting power will increase if, for example, you refer valuable projects, solve tasks, or contribute to the overall development)
(f) 1 user, 1 vote, but more tokens locked increases APY in a shared pool
This proposal focuses on option (e), utilizing HUMAN Protocol Reputation Oracles to adjust voting power while providing strong incentives to contribute to the HUMAN project. Apart from the baseline voting power distribution, a question remains about the voting areas within the remit of the token-based governance structure. Given that DAOs can face many challenges, the design needs to clearly define areas that are within scope for voting while protecting against abuse on the network. Currently under consideration are the following areas: dApps, features, enhancements, and HUMAN Protocol versions. As the primary operating entity, Metahuman may initially receive a portion of pool income to supplement the existing HMT treasury. Tying Metahuman to the pool ensures token holders it is aligned with the goal of strengthening the pool, and thus, HMT. One open question is whether Metahuman should be allowed to vote the HMT it holds: to avoid concentration, HUMAN-RP may explicitly block votes from certain wallet sources for a period of time.