---
title: NDC Gov Ultimate
description: Specification of the NDC Governance Framework.
---

# NDC Voting Framework - the ultimate version
###### tags: `NDC`

## 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 outline a solid, research backed framework to achieve this.

## Solution Overview

### NDC Membership

For the NDC we propose a user-and-criteria-centric governance 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 AstroDAO 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 like 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 through commitments, credentials, affiliations and various flairs.

More details in the [Proof of Personhood](#Proof-of-Personhood) section.

### 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]`

## 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 treasury
- 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 a 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.

### Plural Delegations

We define _plural delegation_ an ability to delegate voting power to multiple delegatees. It's derived from liquid democracy (vote delegations) and plural mechanism (ability to have multiple options).

In it's basic form, _liquid democracy_ is a principle of making collective decision by letting agents transitively delegate their votes. For example: A and B delegate to C, and C can delegate to D (so at the end C will vote for himself, C, B and A).
Main weakness of liquid democracy is that small subset of agents may gain massive influence. Such agents are called _super voters_. The issue was widely researched and proven in various setups (including blockchain delegated PoS). We solve the issue using the following mechanisms:

1. Delegator `A` with voting power `w_A` can delegate to many delegatees `d_A_1 ... d_A_n` and assign a delagation power `w_A_1 ... w_A_n` such that `sum(w_A_i) = w_A` and `∀ w_A_i > 0`. This mechanism is called Fluid Liquid Democracy, and it's proven by P. Golz, A. Kahng, S. Mackkenzie, A. D. Procaccia in "The Fluid Mechanics of Liquid Democracy".
2. We remove the transitivity of liquid democracy by allowing only one level of delegations. If `A` delegates to `B` and later `B` delegates to `C` then all `A` delegation will be automatically cancelled with appropriate event. This is to establish direct feedback loop and connection between delegator and delegatee.
3. Finally, every delegator can cast a vote himself without doing a prior undelegation. So, if `A` delegates to `B` and `B` casts his vote, then `A` can cast himself, by changing `B` power vote, and providing his own vote (as it's implemented in the Cosmos SDK `x/gov` module.

Implementation issues:
1. Circular delegation: this is not possible because we limit the delegation relation to be not transitive.

### Quadratic Voting

Quadratic voting allows for decisions to be made for the greatest number of people.
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 idea is it allows people to express how important things are to them, and not just which direction they feel about it

In an effort to block a small number of the financially elite to buy up a large portion of tokens to obtain more vote credits and in turn disproportionately affect outcomes. Getting 1,000 votes would require obtaining 1,000,000 credits, which should prevent that from happening.

> 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.

### Quadratic Voting + Prular Delegation

The idea is to sum sqr roots of delegations (with delegation reduction), rather than firstly sum and then square root them.
**Example**. Let's assume 20% delegation reduction. Bob and Charlie delegate 100 credits to Alice. Alice executes the vote for MrX, her vote power will be `2*sqrt(100*0.8) = 17.89`. If Bob and Charlie don't delegate, and instead both vote for MrX independently, then the combined vote power will be: `2*sqrt(100) = 20`.
With 10 delegations: `10*sqrt(100*0.8) = 89.44` vs `100*sqrt(100) = 100`

### 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 usefulness 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.

## Proof of Personhood

"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 attendance, 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 defined by an algebraic expression of SBT sets (aka SBT-Class). It can be expressed by 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.

### 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 socially, 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 society, web3 can eschew today’s hyper-financialization in favor of a more transformative, pluralist future of increasing returns across social distance.

### i-am-human dApp

NOTE: we may rename the project, example names: NDC Human, or OpenSociety or OpenCollective.

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.

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. It is however possible to have any number of issuers of aliveness credentials.

- 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.
- SBT based Proof of Humanity provides the most flexibility while being future proof. Protocol can handle public SBT tokens as well as privacy SBT tokens, and constantly evolve to support new proofs.

## Problem Analysis

### Vote Buying

When few people participate, projects are less decentralized, raising several interrelated concerns. Less participation:

+ makes it cheaper for adversaries to execute governance attacks;
+ raises regulatory and legal questions related to securities laws; and
+ erodes the democratic legitimacy of the organization

Rewarding people for participation in governance can create social and political issues.

Morea about possible solution:
https://a16zcrypto.com/posts/article/paying-people-to-participate-in-governance/

### Identity forging

If we can't prevent people from forging identities, 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)

### Performance

At the large scale, a single shard won't be enough to support the NDC.
Considering 200tps / shard, and each voting transaction would require 2 callback, we end up with 63 tps. That give us `5.4m` tx per day. Clearly not enough to handle efficiently 10m voters.

We plan for having a solid and usable solution earlier than later. In the meantime we hope that more tools will emerge to setup layer-2 solution in the future (for example, something based on Calimero)

### Privacy

In the current design we focus more on transparency and verifiability. The latter could be achieved with ZKP, but in the first version we want to have a stable system working. Loosely form of privacy could be achieved through the standard blockchain pseudoanonymity.
It's worth to note that lack of privacy may enable some bribery attacks.

## 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 AstroDAO contracts. We think that NEAR ownership, today, is the most obvious way legitimate the Governance framework. Voters will need to lock their NEAR tokens for a specified time (eg `min(voting_time, 3 weeks)`) to participate in the process. This is required to avoid double voting and will also incur an opportunity cost limiting the gameability of the protocol.

When passing, this will give the full authority to NDC.

## 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)

## Parameters Summary

- `deposit_period`: maximum amount of time when a proposal will await for required deposit to reach a voting stage. Each proposal can have multiple sponsors who will need to provide early support for a proposal to get into wider attention.
- `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
[2] [Cosmos Governance](https://v1.cosmos.network/resources/whitepaper), [documentation](https://hub.cosmos.network/main/governance/).
[3] [Gov2: Polkadot’s Next Generation of Decentralised Governance](https://polkadot.network/blog/gov2-polkadots-next-generation-of-decentralised-governance/)

## Copyright

[Creative Commons Attribution 4.0 International Public License (CC BY 4.0)](https://creativecommons.org/licenses/by/4.0/)