--- title: NDC DAO description: Specification of the NDC Governance Framework. authors: Robert Zaremba, Noak Lindqvist --- # NDC DAO (Governance Framework) ## 1. Introduction We propose a governance framework for the NEAR Digital Collective (NDC). Our main design goal is to empower the NEAR Ecosystem to work, live an play with NEAR. In order to achieve that goal, a fully functioning overarching yet DAO-like process has to be put in place for NDC-wide decisioning and execution. An overarching NDC does not contradict nor conflict with NDC working groups, DAOs or sub DAOs. However, any kind of council deciding about the constitution is a step backwards. DAOs can be used for all working groups, but no on working group (nor constellation of working groups) can be allowed to make NDC wide decisions. **Everyone** that fills the criteria to vote should be allowed to vote. We ouline a solid, research backed framework to achieve this. ## 2. Solution Overview ### NDC Membership For the NDC Governance we propose a user-and-criteria-centric DAO framework (simply called NDC). Membership in NDC is very flexible and dynamic and assessed in real time. - Note: This is somewhat contrary to the group-centric current design of Astro DAO with users manually added or voted into group membership NDC Membership is open to everyone at all times, and defined in real time by a combination of various aspects of NEAR on-chain usage at the time a vote is cast, such as: - holding NEAR or liquid staked NEAR tokens - supporting liquidity to the system, proven by holding selected liquidity provider (LP) tokens. - membership in selected approved NEAR DAOs. As in every real world collective, working groups and other constellations (e.g. NEAR DAOs) are important units of life in the ecosystem. - NEAR _Souls_ - active users who gained approved badges, represented as Soulbound Tokens (SBT). NOTE: usually, SBTs should have expiration date. We don't want to discount active users who don't have enough wealth to hold lot of NEAR. The motivation is to empower different kinds of activity in NEAR: rather than focusing only on a NEAR token wealth, we want to incetivize the NEAR Ecosystem to build vibrant communities and protocols. Active users as well as assets provider are NDC Members. Therefore, the definition of NDC voting rights will differ in different use cases. Some NDC votes might put more emphasis on tokens and other less. Some NDC votes might require a more strict definition of aliveness or verified status as humans, while others use less. More about this below. ### Governance Scope NDC Governance will be formed through an on-chain DAO system, which will self govern its membership parameters (and thus indirectly its members), as well as adding capabilities into the ecosystem. Technically speaking, NDC should be enabled to define and enforce any on-chain changes, inclusive of changing its own parameters governing its social consensus and democracy. We define a series of parameters throughout, which we summarize in the Parameters Summary section below. This work is heavily inspired by the widely appreciated E. Glen Weyl research related to Quadratic Voting and Quadratic Funding well described in [Radical Markets: Uprooting Capitalism and Democracy for a Just Society](https://press.princeton.edu/books/paperback/9780691196060/radical-markets). Moreover, the "humanity" thesis is highly correlated with ["Decentralized Society: Finding Web3’s Soul"](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4105763) by Glen Weyl, Puja Ohlhaver and Vitalik Buterin. ### Building a Soul: Membership Criteria It's important to encode responsibility for each member and enabling social interactions. We propose to do that through a Humanity Protocol (code name: "i-am-human"). The protocol will allow humans - any human - to represent themselves throug commitments, credentials, affiliations and various flairs. More details in **Proof of Human** below. ### Voting Power Each NDC member will have a voting power related to their activity in the NEAR ecosystem measured by their activity. For example: - Holding X NEAR tokens will give X credits to the member. - Holding X `A` tokens will give `X * 0.15` voting credits to the member (each token will have it's own weight). - Being a member of DAO `D` will give `2000` voting credits to the member (each DAO membership will have a weight related to the importance to the ecosystem). To scale down over-powered members, and avoid [_tyranny of whales and superusers_](https://en.wikipedia.org/wiki/Tyranny_of_the_majority) we typically apply a square root of the voting power to get the voting credits, which are used when voting on a proposal. To broaden participation, some votes can use a cube root or any other higher `quadratic power`, which would scale down the plutocratic voting power even more. And true one-human-one-vote can also be considered in certain vote scenarios. **voting credits** are assigned to the user independently for each proposal, according to her _state_ (amount of tokens held, root power, and strength of her Soul) at the time of the vote, according to the following formula:``[Sum of voting power] exp [1 / power] * [soul strength]`` ## 3. Decision Making Process. Every NDC member can create a proposal by calling `NDC.create_proposal` method. To avoid spam, each proposal will require to a deposit. Each proposal will have max `NDC.params.deposit_period` to collect `NDC.params.deposit_amount` (+ storage cost) to activate the proposal and allow NDC Collective to vote on it. We define the following types of proposal: - gov_param_change: proposal to change the governance parameters (`NDC.params`) - treasury_spend: proposal to transfer funds from the NDC trasury - roadmap goal: binding textual proposal to add a roadmap goal, with a priority as a parameter. - add/update/remove_token_membership: proposal to qualify token holders as NDC members, with weight as a parameter. - add/update/remove_dao_membership: proposal to qualify DAO members as NDC members, with credit allocation as a parameter. - add/update/remove_sbt_membership: proposal to qualify SBT holders as NDC members, with credit allocation as a parameter. - function_call: proposal to call a remote smart contract. - message: a verbal text acting as a constitution to be executed by the working groups. In the future (depending on the ability to implement the NEAR blockchain protocol changes) we plan to enable the following proposals: - chain_upgrade: proposal to vote on the chain upgrade (new binary with set of changes) ### Plural Proposals Each proposal will have a plurality of options. Each NDC member, when voting on a proposal, will spend their credits according to Quadratic Voting mechanism. A member who wants to allocate `X` votes on the same option in a give proposal, will need to spend `X^2` credits. For example, the treasury spend proposal can propose few options: - allocate 10k for case A and 20k for case B - allocate 5k for case A and 30k for case B - allocate 5k for case A, 15k for case B and 20k for case C Now assume that a member dislikes C but has no preference between A or B. In this case, they would be best served spending an equal amount of credits on the first and the second proposal. Because if they spent all their credits on either the first proposal or second proposal then their vote would count for less against C. ### Quadratic Voting. Individuals can cast multiple votes for a single or multiple options, voicing their preference with strength of their vote. When casting a vote, voters will need to consider that their “voice” which shrink quadratically with number of vote credits they cast. This quadratic cost induces a marginal costs that increases linearly with votes purchased and thus welfare optimality if individuals’ valuation of votes is proportional to their value of changing the outcome. A variety of analysis and evidence suggests that this still-nascent mechanism has significant promise to robustly correct the failure of existing democracies to incorporate intensity of preference and knowledge. Regular democratic voting doesn’t calculate a voter’s level of interest (conviction) in a candidate or outcome. Without a way to calculate such conviction, direct democracy can be dangerous. Majoritarian cycling will exist, as will the tyranny of the majority, which the realized was just the tyranny of the poor over the rich. The beauty of quadratic voting is that the cost of casting more votes increases very rapidly which prevents all sorts of malicious behaviors. Monopolies of votes cannot exist—no matter how many vote credits one voter has, they cannot control the outcome. Voters would carefully select the outcomes they care most about, a feature standard voting lacks. Additionally, quadratic voting operates on environments in which the identities of voters is well-established which imposes all sorts of social reputation constraints. The model theoretically optimizes social welfare by allowing everyone the chance to vote equally on a proposal as well as giving the minority the opportunity to concentrate the votes on their high priority matter. Weyl perfectly describes the economical value of **Quadratic Voting** in his research: > The quadratic cost function has the unique property that people purchase votes directly proportionally to the strength of their preferences. As a result, the total number of votes for a given issue is the sum of the strength of the preferences of the people who voted. This is because the marginal cost of each additional vote increases linearly with the number of votes. If the marginal cost increases less than linearly with respect to the number of votes, then someone who values a vote twice as much will tend to purchase more than twice as many votes, and the system will be predisposed to dominance by special interest groups with strong, concentrated interests. One-dollar-one-vote is the limit of this behavior, wherein the marginal cost of a vote is constant. On the other hand, if the cost function increase more quickly than a linear rise, then the system will be predisposed to a tyranny of the majority, with the limit of this behavior being one-person-one-vote. ### Signalling proposals (TODO: need to validate usefulness of this) Every proposal will require on-chain deposit. Prior to triggering such a process, we need a weak, non binding, governance mechanism to allow users to explore a usefullness of a proposal. Signaling will work as an on-chain poll. Every member will be able to support (thumbsup), oppose (thumbsdown) or abstain (-) without any further consequences. Once created, a member will be able to share it with a broader ecosystem and ask supporters to help collecting a required deposit to make a proposal. ### Voting When a proposal collected enough deposit, any member can vote. When a member wants to cast the vote, voting credits will be calculated as a function of their _state_. Then the voter allocates the credits, which will be counted according to the quadratic voting mechanism. This applies for plural proposals as well as binary (yes/no) proposals. In the latter case, member can decide, for example, to allocate 60% yes and 40% no. (TODO: Explain why one member would vote 60/40?) Moreover, each proposal will have an extra option: **abstain** - which will be counted towards establishing the quorum but not towards the outcome. When choosing abstain, a voter will have to allocate all their credits into abstain option. ### Proposal tally Once proposal voting end, anyone can trigger proposal vote tally and proposal execution. Proposal passes when: - received at least `NDC.params.min_quorum` of votes (note, votes are calculated based on vote credit quadratic voting). - there is an option with strict majority of votes. Example. If proposal has 3 options (a, b and c), and option a received same amount of votes as option b, and more then option c, then the proposal fails. ### Conviction boost A NDC Member can express their governance conviction by bonding NDC-supported tokens in the NDC protocol for a longer period of time. In exchange, they will get more vote credits (eg 20% more by bonding for 1month). Conviction gov parameters: - conviction staking (min, max) factor and max duration. Example: when `min=1, max=2, max_duration=4months` then a member who locks their tokens for 4 months will increase amount of their bonded vote credits by 2x. (TODO) - provide more details - how to handle DAO based boost? Probably we won't handle it, because DAO membership should not be transferable. ### Dispenser NDC will have a grant allocation mechanism. Dispenser is a grant disburse mechanism, which doesn't allocate the whole grant at once. Instead, it disburses the grant in multiple stages. We will provide two mechanism: - based on predefined milestones. Each grant will have assigned committee which will evaluate progress of a project and unlock subsequent grant allocations. - time based vesting (eg 5% every month). The dispenser can be stopped any time by NDC or by an associated committee. ## 4. Proof of Human "Humanity" is a complex thing to define, and cannot be boiled down to any "single" one proof. It has to be a set of algorithms which together constitute a **"Proof of Unique and Alive Human".** The output of each such algorithm can be represented by a Soulbount Token (SBT). The algorithm can be something as simple as proof of attendence, or complex things like Face Recognition, Social Graph mining, or even a government issued ID verification (could be represented by token ownership). The goal here is to allow multiple options to represent a constantly evolving world. Humanity is comprised of a combination of for example one's fingerprint, look of their face, who their friends are and how often they meet, their accounts on social media, their passport and social security number, their phone number and address, even their attention and skill at solving fuzzy problems. We define Humanity as an algebraic expression of SBT sets (aka SBT-Class). ### i-am-human dApp We design a robust, auto-evolving mechanism, controlled by the NDC Governance. The Proof of Humanity will constantly adjust it's parameters, as well as add new requirements as new threats and new solutions arise. The project is described in further detail in the [**i-am-human**](https://docs.google.com/presentation/d/1uFzAh4eB2y159P2nLdhvmzXX0KGHSaTZTwYrXGmRkAc/edit#slide=id.p) presentation, which is a codename of the protocol we established during last few months of research. * NOTE: we may rename the project, example names: NDC Human, or OpenSociety or OpenCollective. Due to its nature it will not be possible to rely on more than one certifying protocol for uniqueness within NDC. Also, due to the complexity and labor involved, it's recommended to make the proof-of-unique-human outputs from this dApp available to all other protocols on NEAR, not just to NDC. - Note: It is however possible to have any number of issuers of aliveness credentials. ### Soulbound Tokens Soulbound Tokens (SBT) adds three important features to the NFT standard: - Non-transferrable - Important to ensure people can’t use the same credential to verify many accounts as unique - Recoverable - Important in case a user loses their private keys or their account becomes compromised in any way. - Expiration + Renewable - Important feature to ensure people come back with some frequency to be re-credentialized, for example to prevent the token to be used after a user dies or to collect annual fees With these added features, SBTs become advantageous as carriers of individual human attributes, such as uniqueness or aliveness. ### SBT-Class We define a new SBT-Class as a smart contract that can answer the question "is the owner of this account a unique and alive human" by evaluating all applicable SBTs found in a user's wallet and then output a yes/no (or weighted score). The answer will in turn determine eligibility for the account to participate in a vote at the time of the vote. This SBT-Class powered design is further explained in our proof of concept: https://devpost.com/software/i-am-human-app and in our [Proposed SBT NEP](https://github.com/near/NEPs/pull/393/) ### Finding Web3's Soul This solution is well in line with the aforementioned ["Decentralized Society: Finding Web3’s Soul"](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4105763) which we highly recommend you read. > Non-transferable “soulbound” tokens (SBTs) represent commitments, credentials, and affiliations of “Souls”. SBTs encode the trust networks of the real economy to establish provenance and reputation. More importantly, SBTs enable other applications of increasing ambition, such as community wallet recovery, sybil-resistant governance, mechanisms for decentralization, and novel markets with decomposable, shared rights. We call this richer, pluralistic ecosystem “Decentralized Society” (DeSoc)—a co-determined sociality, where Souls and communities come together bottom-up, as emergent properties of each other to co-create plural network goods and intelligences, at a range of scales. Key to this sociality is decomposable property rights and enhanced governance mechanisms—such as quadratic funding discounted by correlation scores—that reward trust and cooperation while protecting networks from capture, extraction, and domination. With such augmented sociality, web3 can eschew today’s hyper-financialization in favor of a more transformative, pluralist future of increasing returns across social distance. ## 5. Problem Analysis ### Identity forging If we can't prevent people from forging indentities, the mechanisms collapses into the token voting system. Instead of blessing only a single identity system, we propose a robust protocol, where manipulation is not worth the cost. Example: Introduce a application fee and/or a required stake when creating a new human identity. The stake will be lost if the application process is challenged and not successful. Such fees and forgone stakes could be paid out to all humans who already passed verification as a form of small Universal Basic Income. ### Collusion The only way we can eliminate vote buying is by enabling strong privacy. Unfortunately this is a very hard problem and beyond of this scope. Would require a zero knowledge based system. ### Double spend To protect the system from double spend scenarios (eg Alice has 10k NEAR, she votes on proposal A, and then sends 10k NEAR to other account to vote again with that 10k NEAR), we introduce a token locking mechanism. A member can only receive voting credits when their membership tokens (NEAR or other supported tokens) are deposited in NDC smart contract. When a member cast a vote, the deposited tokens will be locked until `max(proposal.voting_end)` for each `proposal` they voted. (TODO: Consider conviction voting instead of locking, such that the number of seconds staked matters. Alice could then unstake halfway through the voting period, send the NEAR to Bob, and then Bob can increase his vote) ## 6. Legitimating NDC The remining question is how to legitimize the constitution and the proposed NDC governance system. We propose a simple NEAR coin voting (1 NEAR = 1 vote) for expedience, as it is already supported by the existing Astro-DAO contracts. When passing, this will give the full authority to NDC. ## 7. TODO - create an implementation roadmap - integrate quadratic funding and correlation discount Research: - discuss if we evolve Astro/Sputnik to support this, or build an entirely new DAO-contract and UI for NDC - where should we entertain different weights / different quadratic powers / different SBT classes etc. for various scenarios? So create one class for each type of vote. For example (illustrative): - _voting to change NEAR protocol parameters require super majority 60% or 70% and you cant have aliveness older than 6 months and you have to be validated by 5 people and quorum is above 40% and qudratic power is 1-human-1-vote_ - _voting to release funds you have to be member of a Release-DAO and quorum has to be above 50% and quadratic power is 3_ - _voting to assign budget only requires validation by 3 people and quorum is 30% and quadratic power is 2 and aliveness can be up to 12 months_ - slashing mechanism (could be controlled by the NDC DAO) ## Parameters Summary - `deposit_period`: maximum - `deposit_amount`: minimum amount of NEAR which has to be deposited during the `proposal_creation -- proposal_creation + deposit_period` to activate proposal for voting. ## References [1] https://en.wikipedia.org/wiki/Tyranny_of_the_majority