# Nouns DAO V3 Spec

## TLDR

1. **Proposal editing**: allowing proposers to update their proposal’s transactions and text description, during the Updatable period only, which is the state upon proposal creation. Editing also works with signatures, assuming the proposer is able to accumulate signatures from the same signers.
2. **Propose by signature**: allowing Nouners and delegates to pool their voting power towards submitting a proposal, by submitting their signature, instead of the current approach where sponsors must delegate their votes to help a proposer achieve threshold.
3. **Objection-only Period**: a conditional voting period that gets activated upon a last-minute proposal swing from defeated to successful, affording against voters more reaction time.
4. **Votes Snapshot After Voting Delay**: moving votes snapshot up, to provide Nouners with reaction time per proposal, to get their votes ready (e.g. some might want to move their delegations around).

## Proposal editing

Proposals get voter feedback almost entirely only once they are on-chain. At the same time, proposers are reluctant to cancel and resubmit their proposals for multiple reasons, e.g. prefering to avoid restarting the proposal lifecycle and thus delay funding.

### Spec

The `proposer` account of a proposal in the `Updatable` state can call an `updateProposal` function, providing the new complete set of transactions to execute, as well as a complete new version of the proposal description text.

### UI

This change will go live with a UI update to nouns.wtf, including:
* The number of versions this proposal has had to date.
* The ability to view each version of the proposal.
* Nice-to-have: a [diff view](https://confluence.atlassian.com/fisheye/files/960155326/960155329/1/1540460169949/Crucible_2.2-Side-by-Side-Diff_Main-View-RAW-70.png) comparing any two versions.

We expect other governance clients (e.g. House of Nouns, Agora) will add support as well.

## Propose by signature

Proposal threshold is the number of votes an account must control in order to submit a proposal. As of this writing an account must control 2 Nouns to pass the threshold.

To sponsor proposals, Nouners today delegate their Nouns to proposers. This is problematic for two main reasons:

1. The sponsoring Nouner can't use their Nouns to vote until the sponsored proposal achieves a final state; if they choose to undelegate sooner, the proposal can be easily cancelled by anyone.
2. Delegates with less than 2 Nouns can't pool their votes to sponsor proposals because sub-delegation is not supported.

### Spec

#### Propose
* A proposal can be submitted with a list of signatures.
* Each signature is verified against the exact content of the proposal.
* Supports both EOA and smart contract signatures ([EIP-1271](https://eips.ethereum.org/EIPS/eip-1271)).
* Replay is prevented using signature nonces.
* The votes of all signers are summed up, and if they pass the proposal threshold test, the proposal goes on chain.

#### Cancel

Today a proposal can be cancelled if:
1. The proposer chooses to cancel, or
2. The proposer no longer has threshold votes, in which case anyone can cancel; this is to protect the DAO from spam.

In this new version a proposal can also be cancelled if:
1. One of the accounts that signed on the proposal chooses to cancel, or
2. The sum of votes of all proposers no longer exceeds threshold.

### UI

* The best UX would use a server + database, storing the proposal content and all signatures until the last signer is ready to submit the proposal.
* nouns.wtf doesn't have a database, so the spec there is still undecided.
* Other governance clients with a database can provide smooth UX with "proposal drafts" people can upload and use to gather support.

## Objection-only Period

The goal is to protect the DAO from executing proposals, that the majority would not want to execute. The classic case we have in mind is a minority trying to pass a proposal can let the proposal look like it's failing, to cultivate voter apathy, then cast many of their For votes just before voting ends, swinging to proposal from defeated to successful, leaving the majority wishing they were more vigilant.

### Spec

The conditions for activating the objection-only period:

* In a proposal's `lastMinuteWindow` (e.g. the last 2 days)
* If the proposal is Defeated (i.e. defeated if voting ended now)
* And a For vote comes in that flips the proposal from Defeated to Successful
* Then activate the objection-only period for this proposal

During the objection-only period:

* Accounts who have already voted cannot vote
* Accounts who haven't voted yet can only vote Against
* The duration of the objection-only period is a parameter to be set (e.g. 3 days)

## Votes Snapshot After Voting Delay

The current DAO implementation takes a snapshot of votes & delegation at the block a proposal is created, meaning Nouners have no lead time to put their votes in order, e.g. moving their delegations back to themselves to vote on something they really care about.

Why was this done? A proposal's quorum votes is calculated as a percentage of total supply at the moment of proposal creation; at the same time total supply grows during voting delay, giving a slight advantage to proposers who can time their proposals to minimize their quorum requirement.

More than a year after the original decision, seems better for the DAO to change this decision. The value of a useful voting delay period seems much greater than the minor quorum offset (which has become smaller with a total supply of 3 digits).

### Spec

* Quorum will continue to be calculated using total supply on proposal creation block
* Vote snapshots will use proposal voting start block, i.e. the block after voting delay, when voting starts
* Nouners will now have the duration of voting delay to transfer, buy, sell, delegate and undelegate their votes