# Framework update for the next elections v 0.1

## **Introduction**

Published version (v1) without comments available at https://hackmd.io/8YBpAi47QN2ceqPLjG68Iw
You can keep commenting the design here - coments will be duly noted

### **Purpose**

The purpose of this document is to define the functional and non-functional requirements for the NDC Voting framework. It serves as a reference for all stakeholders involved in the development, implementation, maintenance and usage of the IT system.

### Motivation

The motivation for the upgrade of the NDC Voting framework

- Voting power needs to depend on staked tokens to assure commitment
- Current setup does not reward active community contributors with voting power
- Current framework did not consider scalability issues that may arise upon further decentralization

### Proposed Solution

To account for staked tokens we use stake-weighted voting. However high Gini coefficient will lead to a plutocracy with straightforward stake-weighted voting. To implement more fair distribution of the voting power throughout the community we implement quadratic weighted voting with threshold.

To incentivize community members to actively participate in the development of the NEAR ecosystem we implement reward system based on transaction history of an account.

We use scalable decentralized data sources to prevent scalability issues.

### Rationale for voting power calculation parameters

To ensure fair votes distribution we set activity rewards to generate voting power a little bit less then staking rewards. This will bring us to quadratic formula threshold to 1000 and activity reward to 20 per month

### Voting power calculation

We setup threshold at 1000 NEAR tokens. Rationale behind the threshold elaborated below.

Exact formula to calculate the voting power through quadratic voting:

Voting power = Case 
when stake <= 1000 then floor(stake) 
when stake > 1000 then floor(sqrt(stake-1000))+ 1000
END

We are additionally rewarding accounts for continuous activity. This will ensure that community members who contribute to the ecosystem has the impact of their voice increased. We add 20 votes for each month account has at least one transaction. This will roughly add 16.5M votes to the overall amount of 34.4M which we consider a proportionally fair additional reward for active users.
Full data per user segment below:
|Segment| Staking voting power| Activity reward| Total power |Users| Power per user| User, %|
|-----|---------|-------------|-------|------|-----|---|
|0-1| 9410| 7844022 |7853432| 59925| 131| 47.54%|
1-10| 94670| 2157842 |2252512 |16485 |137| 13.08%|
10-100| 1330000| 3137216| 4467216| 23967| 186 |19.01%|
100-1000| 8080000| 2401050| 10481050| 18343| 571| 14.55%|
1000-10000| 5515550| 685902| 6201452| 5240| 1183| 4.16%|
10000+| 2886694 |273968| 3160662| 2093| 1510| 1.66%|

### Oracle design

Proposed solution requires an Oracle to provide data necessary for the voting power calculation.

We implement pseudo-trustless optimistic oracle to capture data required for voting power calculations using snapshots of Near blockchain data with custom Merkle proofs. We may reduce requirement of creating a Merkle proof to a post on NEAR governance forum for the sake of simplicity.

Crucial part of the proposed solution is the oracle that provides data for voting power calculation. Oracle consists of 3 parts :

***Indexer (Snapshotter)***

Indexer is responsible for collecting all the data for the snapshot.

- Based on the configuration it index all blocks to get all required data. Indexer process each block till configured parameters meet requirements - check block timestamp and block confirmations count.
- As soon as we have reached the condition specified in the configuration (block timestamp and block confirmations), the indexing stops and the collected data set is our snapshot.
- Snapshot can be published in IPFS and this data will be used by Data Processing Script.

**Input**: Indexer configuration.

**Output**: Snapshot.

***Data processing script***

Responsible for processing all data collected by the indexer.

- Chunk processing: parse accounts data: NEAR balance, staking NEAR amount, tx count and account age.
- Build Merkle tree using this data, get Merkle root.
- Provide ability to verify Merkle proof.
- Prepare accounts data for Oracle smart-contract to have it available on-chain.

**Input**: Snapshot.

**Output**: Merkle root, accounts data, ability to verify Merkle proof.

***ORACLE SMART-CONTRACT***

Responsible for storage required data of each account with ability to challenge snapshot.

- Ability to add accounts data in batches.
- Ability to read data for each account.
- Ability to challenge snapshot.

**Input**: Merkle root, accounts data.

**Output**: View method that provide data by individual account for voting smart-contract.

To achieve strong trust model we use optimistic oracle approach. Anyone can deposit NEAR tokens and challenge Merkle proof provided by the oracle. If deposit reaches 1000 NEAR token threshold we halt the voting process.
Oracle development may be outsourced to community members with relevant portfolio (e.g. Pikespeak)

### Voting workflow update

For the workflow update following changes are considered for the next elections:

- For plural proposals users must have ability to cast their vote multiple times during the voting period. User can change their vote for any parts of the proposal untill the deadline. This is standard voting system design to disincentivize bribery as user is not able to proove that he casted vote according to the briber request.
- To increase privacy votes will be casted anonymously through a zk solution or a private shard. Exact design of the privacy solution TBD.
- Option to challenge the Merkle proof provided by oracle is available for the users.

### Snapshot specification

To have a single source of data for all of the calculations required for the voting power calculation we will make a NEAR blockchain snapshot with following properties:

1. All of the data gathered for specific block height. We take the last block that receives 103 confirmations before the 00:00 PST on the 17.12.2023.
2. To prevent gaming of the system through the stake delegation snapshot will have all accounts with stakes at that height. We will parse lockup accounts to retrieve tokens staked through non-native mechanisms whenever technically possible.
3. To have a single source for the snapshot data it will be published on IPFS with link published on-chain.
4. To provide community the ability to check the snapshot it will have a custom Merkle proof proving the integrity of following data points:
- Amount of staked NEAR tokens (including tokens staked through pools and other non-native staking mechanisms)
- Amount of transactions
- Transactions date
- Height of the block at which snapshot was taken
- Date of the elections start
5. Merkle proof in p.4 constructed by a centralized service developed by the OPS team in an open-source manner. Decentralization achieved through providing community the ability to challenge constructed proofs.
### Sybil resistance approach

By introducing rewards for activity and quadratic reduction mechanisms we adding incentives for multi-accounting i.e. Sybil attacks. As attack on quadratic reduction and on activity rewards has conceptual differences we split analysis on the 2 parts.

***Quadratic formula gaming***

While quadratic formula applied over a snapshot is resistant to multi-accounting per se it is vulnerable to groups who are already cooperative. For the sake of this framework we can define cooperative groups as account that share same incentives in the NEAR ecosystem for every voting subject - it may be accounts controlled from the same center as well as different shareholders of a single entity. We consider following for the quadratic formula gaming

- Attacker has control over group of accounts with more then 1000 NEAR token held on at least one of the accounts (depends on the threshold)
- Attacker can only be a member of already cooperative group and needs to distribute stake prior the snapshot predicting moving of the voting to quadratic formula or similar reduction mechanisms
- Attacker can not optimally distribute his stake among controlled accounts without knowing the exact threshold. Optimal will be distribution on equal chunks close to the threshold as we consider acquiring of every account has non-zero cost. Stake needs to be distributed before the snapshot date hence prior the threshold publication (and actual agreement on the threshold)
- Splitting of big accounts into smaller chunks increases security of the system reducing bottlenecks
- Multi-accounting is a violation of [NDC Fair Voting Policy](https://bafkreidwdxocdkfsv6srynw7ipnogfuw76fzncmxd5jv7furbsn5cp4bz4.ipfs.nftstorage.link/). Users do need to acknowledge compliance with policy. We are not implementing technical solutions to enforce it at this point though

Conjunction of factors should bring attacks impact to low comparing to the overall voting power.

***Activity rewards gaming***

Since activity reward is capped additional voting power can be gained through multi-accounting

To gain additional voting power optimally attacker needs to add bots or affiliated accounts that will stake NEAR tokens and perform transaction every month. Considering that there is no much bots (accounts with a lot of transactions and staked tokens at the same time) the maximum voting power is capped roughly by 5% of overall voting power which is offset further as a lot of the bots bring considerable value for the ecosystem (e.g. arbitrage bots do decrease slippage)

Voting through bots is a violation of [NDC Fair Voting Policy](https://bafkreidwdxocdkfsv6srynw7ipnogfuw76fzncmxd5jv7furbsn5cp4bz4.ipfs.nftstorage.link/) which can be enforced the same way as in the previous election

### Election timeline

Elections are conducted during 6 weeks. Every week starts on Monday midnight PST and ends on Sunday midnight PST.

Below are the list of critical points on the election timeline:

- **Week 1** - Start of the week
- Snapshot taken and published on-chain.
- Start of candidacy submission.
- Start of challenge period for the Merkle proof.
- Publication of the challenge details for the community on the governance forum.
- **Week 2** - End of the week
- End of challenge period for the Merkle proof. Confirmation published on-chain.
- **Week 4** - End of the week
- Close of candidacy submission.
- **Week 5** - Start of the week
- Election starts.
- **Week 5** - End of the week
- Election ends.
- **Week 6** - Start of the week
- Begining of the onboarding period (2 weeks) for newly elected cadency\Restart of the election in case of quorum mismatch or other failure.