ProposalsProposal 353
ProposalsProposal 353
This proposal upgrades the Nouns DAO logic contract to V3. This version introduces the following changes:
An updated version of nouns.wtf will be deployed to add support for these features.
The DAO funded two audits for this version, first with Spearbit and then with code4rena.
Below is a summary of the results with links to the reports.
Please reach out to us (verbs team) if you have any questions regarding the findings.
Spearbit found:
For more info: the full Spearbit audit report.
code4rena found:
For more info: the full code4rena audit report.
There were some issues we chose to not fix despite agreeing they were good findings, because we wanted to avoid adding further risk or time delays. We’re listing those here explicitly for the sake of max transparency. There were other issues we did not fix because we disagreed with the auditors’ analysis, and those are not listed here.
Proposals get voter feedback almost entirely only once they are onchain. 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.
There have been cases where proposers made promises offchain, e.g. to return part of the funds, but that is not captured onchain, and not visible to the entire voter base.
This feature introduces a new state into the proposal lifecycle:
Updatable (new) → Pending → Active …
During the Updatable state, a proposer can update their proposal’s description and/or transactions. Following the Updatable state, there’s a Pending state during which updates are no longer available before voting starts during the Active state.
The length of the Updatable state is configurable by the DAO, and starts at zero. This effectively keeps the feature disabled. A separate proposal will follow with proposed periods for the state, for example: Updatable: 5 days, Pending: 1 day
There’s also an onchain method of providing feedback to proposals while they are in the Updatable state.
Proposal threshold is the number of votes an account must control in order to submit a proposal. As of this writing an account must have at least 2 votes to pass the threshold.
Current methods of sponsoring a proposal and their problems:
Nouners today either delegate their Nouns to proposers or submit the proposal on their behalf.
Delegating is limited to Nouners, since delegates can re-delegate their vote to another account.
When a Nouner delegates, they can’t use their voting power for the length of the proposal lifecycle which is very inconvenient.
If a Nouner/delegate chooses to submit a proposal on behalf of the proposer, we lose the meaning of who is the actual proposer and also the process itself can be cumbersome where the delegate needs to make sure the proposal looks good and pay gas for it.
This upgrade introduces a new function to the DAO contract: proposeBySigs.
This allows anyone to submit a proposal and a set of signatures. The signatures are provided by voters and need to match the proposal content. If the sum of votes from all the signers surpasses proposal threshold, the proposal can be submitted.
The goal is to open another channel through which proposers can submit proposals, without necessarily finding a sponsor through private channels.
Voters can only be signers if they don’t currently have an active proposal, either as a proposer or signer. Signers of a proposal can cancel it at any time, and the same is true for proposers; proposers should choose their signers carefully.
This allows both Nouners and delegates to “sign-off” on a proposal, while the proposer address remains the actual proposer and without the need to change delegations.
It also allows pooling voting power, e.g. two delegates with 1 vote each can sign a proposal in order for it to pass the proposal threshold, currently at 2 votes.
It also opens the door to raising the proposal threshold since it’s easier to collect voting power.
As part of this update we are adding support for “proposal candidates” to nouns.wtf, where proposers can submit their proposals and request signatures. In order to prevent spam, creating a candidate proposal requires either holding 1 vote or sending 0.1 ETH (the ETH recipient and the amount are configurable by the DAO).
The candidate proposals data are submitted to a side contract to make this data publicly available for any frontend to interact with.
The goal is to protect the DAO from executing proposals that the majority would not want to execute. The threat is one where 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 the proposal from defeated to successful, leaving the majority wishing they were more vigilant.
This upgrade introduces a new state in the proposal lifecycle: ObjectionPeriod.
… Active (regular voting period) → ObjectionPeriod (conditional) → Succeeded / Defeated \
ObjectionPeriod gets turned on only if a proposal turns from not passing to passing close enough to the end of the voting period.
During the ObjectionPeriod state, only voters who haven’t voted yet are allowed to vote, but only against the proposal.
Q: Why not allow voting For a proposal during this extra voting period?
A: Similar to the attack scenario described above, it would still allow voters to keep their votes to themselves and vote only at the last minute. In this case it would be right before the ObjectionPeriod ends.
More broadly speaking, the risk that a proposal passes when it shouldn’t, is much higher than the risk of a proposal not passing when it should.
A proposal can be re-proposed, but a proposal that passes can’t be reversed.
DAO configurable parameters:
objectionPeriodDurationInBlocks: how long the objection period lasts, e.g. 2 dayslastMinuteWindowInBlocks: what is considered “last minute”? e.g. 2 hoursBoth parameters start with values of zero, effectively making this feature disabled. A separate proposal will follow turning on this feature with suggested parameters.
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.
This upgrade changes the snapshot to be after the voting delay, i.e. once voting starts. Nouners will now have the duration of voting delay to transfer, buy, sell, delegate and undelegate their votes.
Because the nouns supply grows during the voting delay, nouns that are minted during the voting delay also participate in voting. Originally the snapshot was taken during proposal creation in order to align the total supply and the quorum and proposal calculations, which are performed at proposal creation time. Now that the supply has grown, this inconsistency is insignificant.
Further details can be found here in the tech spec and this post.
The DAO fork feature requires switching to a new treasury contract which allows the DAO to transfer ETH and ERC20 tokens when a fork executes. The current treasury (treasury v1) contract is not upgradable, so it requires a migration to a new one. The new treasury (treasury v2), deployed at 0xb1a32FC9F9D8b2cf86C068Cae13108809547ef71, adds the new functions to the existing contract, and is upgradable to avoid the need for migrations in the future.
The migration includes:
Other assets in treasury v1 can be moved or approved to be moved in follow up proposals. Only assets in treasury v2 are included in the treasury forking in case of a fork.
DAO proposals are limited to 10 transactions, therefore we are doing the migration in two steps. There will be a follow up proposal with the second part of the migration. The follow up proposal will go onchain once this one executes.
The DAO will still have access to the original treasury (treasury v1), by proposing proposals via the proposeOnTimelockV1 function.
Existing streams created by the DAO will remain controlled by treasury v1. If the DAO chooses to cancel them, the proposeOnTimelockV1 function will need to be used.
Proposals that are queued but not yet executed before this proposal executes will need to be executed using the executeOnTimelockV1 function. The regular execute function will attempt to execute via treasury v2 and will fail.
proposeOnTimelockV1This proposal will be submitted only after the first one executes, since only then we will know the final amount of ETH in treasury V1 to transfer as part of this proposal.
Can be viewed in more detail here.
This proposal upgrades the Nouns DAO logic contract to V3. This version introduces the following changes:
An updated version of nouns.wtf will be deployed to add support for these features.
The DAO funded two audits for this version, first with Spearbit and then with code4rena.
Below is a summary of the results with links to the reports.
Please reach out to us (verbs team) if you have any questions regarding the findings.
Spearbit found:
For more info: the full Spearbit audit report.
code4rena found:
For more info: the full code4rena audit report.
There were some issues we chose to not fix despite agreeing they were good findings, because we wanted to avoid adding further risk or time delays. We’re listing those here explicitly for the sake of max transparency. There were other issues we did not fix because we disagreed with the auditors’ analysis, and those are not listed here.
Proposals get voter feedback almost entirely only once they are onchain. 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.
There have been cases where proposers made promises offchain, e.g. to return part of the funds, but that is not captured onchain, and not visible to the entire voter base.
This feature introduces a new state into the proposal lifecycle:
Updatable (new) → Pending → Active …
During the Updatable state, a proposer can update their proposal’s description and/or transactions. Following the Updatable state, there’s a Pending state during which updates are no longer available before voting starts during the Active state.
The length of the Updatable state is configurable by the DAO, and starts at zero. This effectively keeps the feature disabled. A separate proposal will follow with proposed periods for the state, for example: Updatable: 5 days, Pending: 1 day
There’s also an onchain method of providing feedback to proposals while they are in the Updatable state.
Proposal threshold is the number of votes an account must control in order to submit a proposal. As of this writing an account must have at least 2 votes to pass the threshold.
Current methods of sponsoring a proposal and their problems:
Nouners today either delegate their Nouns to proposers or submit the proposal on their behalf.
Delegating is limited to Nouners, since delegates can re-delegate their vote to another account.
When a Nouner delegates, they can’t use their voting power for the length of the proposal lifecycle which is very inconvenient.
If a Nouner/delegate chooses to submit a proposal on behalf of the proposer, we lose the meaning of who is the actual proposer and also the process itself can be cumbersome where the delegate needs to make sure the proposal looks good and pay gas for it.
This upgrade introduces a new function to the DAO contract: proposeBySigs.
This allows anyone to submit a proposal and a set of signatures. The signatures are provided by voters and need to match the proposal content. If the sum of votes from all the signers surpasses proposal threshold, the proposal can be submitted.
The goal is to open another channel through which proposers can submit proposals, without necessarily finding a sponsor through private channels.
Voters can only be signers if they don’t currently have an active proposal, either as a proposer or signer. Signers of a proposal can cancel it at any time, and the same is true for proposers; proposers should choose their signers carefully.
This allows both Nouners and delegates to “sign-off” on a proposal, while the proposer address remains the actual proposer and without the need to change delegations.
It also allows pooling voting power, e.g. two delegates with 1 vote each can sign a proposal in order for it to pass the proposal threshold, currently at 2 votes.
It also opens the door to raising the proposal threshold since it’s easier to collect voting power.
As part of this update we are adding support for “proposal candidates” to nouns.wtf, where proposers can submit their proposals and request signatures. In order to prevent spam, creating a candidate proposal requires either holding 1 vote or sending 0.1 ETH (the ETH recipient and the amount are configurable by the DAO).
The candidate proposals data are submitted to a side contract to make this data publicly available for any frontend to interact with.
The goal is to protect the DAO from executing proposals that the majority would not want to execute. The threat is one where 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 the proposal from defeated to successful, leaving the majority wishing they were more vigilant.
This upgrade introduces a new state in the proposal lifecycle: ObjectionPeriod.
… Active (regular voting period) → ObjectionPeriod (conditional) → Succeeded / Defeated \
ObjectionPeriod gets turned on only if a proposal turns from not passing to passing close enough to the end of the voting period.
During the ObjectionPeriod state, only voters who haven’t voted yet are allowed to vote, but only against the proposal.
Q: Why not allow voting For a proposal during this extra voting period?
A: Similar to the attack scenario described above, it would still allow voters to keep their votes to themselves and vote only at the last minute. In this case it would be right before the ObjectionPeriod ends.
More broadly speaking, the risk that a proposal passes when it shouldn’t, is much higher than the risk of a proposal not passing when it should.
A proposal can be re-proposed, but a proposal that passes can’t be reversed.
DAO configurable parameters:
objectionPeriodDurationInBlocks: how long the objection period lasts, e.g. 2 dayslastMinuteWindowInBlocks: what is considered “last minute”? e.g. 2 hoursBoth parameters start with values of zero, effectively making this feature disabled. A separate proposal will follow turning on this feature with suggested parameters.
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.
This upgrade changes the snapshot to be after the voting delay, i.e. once voting starts. Nouners will now have the duration of voting delay to transfer, buy, sell, delegate and undelegate their votes.
Because the nouns supply grows during the voting delay, nouns that are minted during the voting delay also participate in voting. Originally the snapshot was taken during proposal creation in order to align the total supply and the quorum and proposal calculations, which are performed at proposal creation time. Now that the supply has grown, this inconsistency is insignificant.
Further details can be found here in the tech spec and this post.
The DAO fork feature requires switching to a new treasury contract which allows the DAO to transfer ETH and ERC20 tokens when a fork executes. The current treasury (treasury v1) contract is not upgradable, so it requires a migration to a new one. The new treasury (treasury v2), deployed at 0xb1a32FC9F9D8b2cf86C068Cae13108809547ef71, adds the new functions to the existing contract, and is upgradable to avoid the need for migrations in the future.
The migration includes:
Other assets in treasury v1 can be moved or approved to be moved in follow up proposals. Only assets in treasury v2 are included in the treasury forking in case of a fork.
DAO proposals are limited to 10 transactions, therefore we are doing the migration in two steps. There will be a follow up proposal with the second part of the migration. The follow up proposal will go onchain once this one executes.
The DAO will still have access to the original treasury (treasury v1), by proposing proposals via the proposeOnTimelockV1 function.
Existing streams created by the DAO will remain controlled by treasury v1. If the DAO chooses to cancel them, the proposeOnTimelockV1 function will need to be used.
Proposals that are queued but not yet executed before this proposal executes will need to be executed using the executeOnTimelockV1 function. The regular execute function will attempt to execute via treasury v2 and will fail.
proposeOnTimelockV1This proposal will be submitted only after the first one executes, since only then we will know the final amount of ETH in treasury V1 to transfer as part of this proposal.
Can be viewed in more detail here.