# Main Features

| Feature | Value | Remark |
|----|----|----|
| **Eligibility** | NFT holders | |
| **Census Creation** | Automatic | From Ethereum state |
| **Voting Options**| *yes*, *no*, *abstain* | Can be changed (but hardcoded in SC) |
| **Voting Steps** | 1 | If relay service is not used, vote submission requires one additional step |
| **Multisig Support** | Partial | Through delegation; improved support could be explored in future stages (see [Further Work](/L6oniVQNRh2eT2nLjOfKLA)) |
| **NFT Smart Contract Upgrade** | Not Required | |

# Summary of user experience

Nouns holders will be able to cast votes for the NFTs they own or that have been delegated to them. Delegation and un-delegation will be done as now. The voting process can be summarised as follows

* Creation of new voting process:
* Obtain public encryption key from the Time-Lapse Cryptography Service.
* Create new vote by submitting details to the smart contract, like voting period, description of vote, and encryption key.
* During the voting period:
* Users connect to a UI and vote, which results in the generation of one of more vote packages (depending on the number of NFTs they hold or have been delegated to).
* Optionally, users can choose to immediately submit these votes to the Delay-Relayer for later anonymous submission to the Ethereum contract.
* Users can also choose to store their vote packages and later submit it to the smart contract themselves, or to submit it to the Delay-Relayer via other means, e.g. Tor.
* Users can check if their vote is submitted to the smart contract (must have stored a hash at submission time) .
* After the voting period:
* The private key for ballot decryption is disclosed.
* Anyone can decrypt the ballots and compute the result of the vote and the corresponding proof (open source software).
* Anyone can send the result+proof to the contract.

# Formal Properties

Technically speaking the requirements of the call are captured by the following formal properties, in alphabetical order.

| Property | Definition | Nouns | This proposal| How |
| -------- | -------- | -------- | -------- | -------- |
| ***Ballot secrecy*** | It is impossible to link a voter with a choice | | **Yes** | ZK Census membership proof **+** opt-in delay-relayer |
| ***Eligibility*** | Only legitimate voters can vote | Only NFT holders / Delegates can vote | **Yes** | The voting smart contract only accepts valid census membership proof to cast a ballot **+** the census is automatically generated from the Ethereum state |
| ***Eligibility verifiability*** | Anyone can verify that each vote in the set of all cast votes was cast by an eligible voter | | **Yes** | Same as *Elegibility* |
| ***Fairness*** | No early results can be obtained which could influence the remaining voters | | **Configurable**[^1] | Ballots are encrypted and decryption key is not released until the end of the voing period **+** opt-in time-lock encryption |
| ***Individual verifiability (IV)*** | A voter can verify that her vote is included in the set of all cast votes | | **Yes** | Via nullifier |
| ***Proxy vote*** | An eligible voter may delegate their voting power to a representative | One delegation per NFT | **Yes** | Via Nouns smart contract delegation system |
| ***Robustness*** | The system should be robust to a certain degree of malfunction or corruption and still deliver correct results | | **Yes** | Same security assumptions as in Ethereum, except for private key publication |
| ***Unconditional privacy*** | Nobody should be able to learn any additional information even several centuries after the voting process | | **yes** | Same security assumptions as in Ethereum |
| ***Universal verifiability (UV)*** | Anyone can check that the election outcome corresponds to the ballots published on the bulletin board. | | **Yes** | Via open source software
| ***Uniqueness*** | No voter should be able to vote more than one time | One vote per NFT at most | **Yes** | The voting smart contract only accepts ballots from census proofs whose nullifier is not in a list of nullifiers that has already voted; when a ballot is accepted, the corresponding nullfier is added to the list |
| ***Weighted voting*** | votes inherently vary in strength depending on the voter. | | **Yes** | Voting power: one vote per NFTs, all votes have the same weight |

[^1]: *Configurable*: Not preestablished. Up to the voting process creator, voter, etc.

# Requirement Checklist
[Call requirements](https://hackmd.io/SVyDLBq7QSWNl0LaYIuqHA)
## Musts
> Privacy is preserved forever; e.g. designs where voter identity is exposed when counting votes, or at any point post vote casting are not acceptable.

:heavy_check_mark: Fully fulfilled.

The ZKPs that eligible voters would have to generate and vote with is designed to prove their eligibility without revealing their identities.

:::info
**Note:** For optimal privacy, voters should obfuscate their IP addresses when using the relay service.
:::

> At no point should the number of votes a voter has be connected to an on-chain vote; e.g. if one’s balance (voting power) is exposed on any on-chain tx, it becomes very easy to identify whale accounts.

:heavy_check_mark: Fully fulfilled.

One vote per NFT. An optional relay service allows to break time correlation by submitting votes at a radom time (within a range).

> Should be impossible to tally a proposal’s votes before the voting period ends; the reason is that if tallying is possible, whale votes become easily identifiable.

:heavy_check_mark: Fully fulfilled.

Votes are encrypted until the end of the process

>Should support delegates as well as token owners.

:heavy_check_mark: Fully fulfilled.

Using Nouns' delegation system.

>Double voting must not be possible.

:heavy_check_mark: Fully fulfilled.

Using nullifiers.

> Support multisig contract wallets; many Nouns are held in Gnosis Safes and other smart contracts and we’d like to preserve their privacy as well.

:white_check_mark: Partially fulfilled.

Only through delegation. Improved support will be explored in future stages (see [Further Work](/L6oniVQNRh2eT2nLjOfKLA)).

> Support hardware wallets.

:heavy_check_mark: Fully fulfilled.

> Avoid centralized dependencies; any off-chain computation should run open source code and allow multiple parties to participate, to optimize for censorship resistance and redundancy.

:heavy_check_mark: Open source code: fully fulfilled.

:white_check_mark: Avoid centralized dependencies: partially fulfilled.

We will start with minimal working versions of the time-lapse service for encryption keys generation and relay service, and explore methods to descentralise such components in future stages.

> Should not require a trusted setup / ceremony for every prop (voting round).

:heavy_check_mark: Fully fulfilled.

> Should be scalable, allowing for growth in the number of voters from roughly 100 today to 10K in the future.

:heavy_check_mark: Fully fulfilled.

Can be improved to reduce gas costs:

1. For accounts with multiple tokens add proofs for fixed amounts of tokens
2. Add a batching feature in the relay service to agreggate votes (benfiting from 1).

> Not every token holder should be required to vote, and if a voter registration round is required, not every registered voter should be required to show up to vote.

:heavy_check_mark: Fully fulfilled.

No registration round is required.

> Should not require an admin to trigger steps in the voting process.

:heavy_check_mark: Fully fulfilled.

Anyone can create a voting process, and one a process is set up is unstoppable.

> Should not require voters to deposit collateral to be allowed to vote.

:heavy_check_mark: Fully fulfilled.

> The output must be the vote tally of each proposal: # for votes, # against votes and # abstain votes, with abstain being nice-to-have. The final decision whether a proposal passes or fails should be left to the DAO’s smart contract.

:heavy_check_mark: Fully fulfilled.

## Nice to Have

> Voters should not have to transfer their voting power (e.g. Nouns) from their wallets to a 3rd party smart contract.

:heavy_check_mark: Fully fulfilled.

The census corresponds to the actual Ethereum state.

> Voters should not have to bridge their Nouns to a rollup or another chain.

:heavy_check_mark: Fully fulfilled.

> Voters should be able to vote with a single submission of an Ethereum tx / message signature / proof; more steps voters must take render suggested designs less attractive.

:heavy_check_mark: Fully fulfilled (if relayer is used)

> Voters should not be required to perform additional pre-voting steps.

:heavy_check_mark: Fully fulfilled.

> Support some voters choosing to vote publicly.

:heavy_check_mark: Fully fulfilled.

A voter can prove the owership of a proof of a tx containing a vote.

> Voting (proof submission) should occur on Ethereum mainnet.

:heavy_check_mark: Fully fulfilled.

The voter can always submit directly to mainnet. However we also provide a relay service to prevent time correllation attacks and enable gas payment by third parties.

> Should rely solely on proofs, and not include a dispute period to achieve finality.

:heavy_check_mark: Fully fulfilled.

## Additional Technical Specs

> We’re fine with a multi-day delay between vote end and when votes are tallied.

Multi-day delay is not required in our implementation.

There will be some delay between the end of the voting period and the uncovering of the secret key for decrypting and tallying ballots, which is not epected to exceed one day.

> We’re unsure whether voters should be able to prove how they voted to others or not; we’d love your help exploring the pros and cons of such a feature.

The current proposal does not restrict voters from proving their voting preferences to others.

We reckon that the capacity to reveal the vote is commonly considered an undesirable feature as it enables coercion, including vote-buying. This is particularly critical in electronic systems due to their capcity for attacks at scale.

The mitigation of such would be to achieve *Receipt-freeness (RF): a voter cannot produce a proof of her vote to a third party*. It is a common feature in physical electoral systems achieved by e.g. requiring votes to be casted in private voting booths and folded.

However, building a receipt-freeness e-voting systems is very challenging, especially without trading off any of the above fulfillments e.g. avoiding trusted \/ centralised dependencies. Hence we are leaving it outside of the scope of this 3-month project.