Thisis more than an exact replica of Prop #354, which passed with near-unanimous approval only to be unexpectedly canceled by its owner before execution. This prop is a statement of resilience, a pledge that will not be broken or canceled.
Finalized with meticulous care between January and February, V3's design stands unchanged. The community, blindsided by the spontaneous cancellation despite comprehensive legal opinions and exhaustive audits, remains united and vigilant. Claims of a "crypto-economic issue" find no echo among the community, auditors, Cayman Foundation's law firm, or the CT community at large. Yet, we should all stand ready for open discourse within the five days before this prop goes live. This prop will not be canceled. The community alone will decide, again.
This proposal symbolizes something profound. It is the very test of whether Nouns is controlled by the collective strength and wisdom of the community/token holders or controlled by a select few known as the Nounders/multisig holders. This is a moment that challenges us to prove our shared principles and uphold true decentralization while leading the ecosystm forward into a new more resilient future.
------------------------- Below should be identical to the last prop. Please Verify -------------------------
This proposal upgrades the Nouns DAO logic contract to V3. This version introduces the following changes:
Proposal editing: adding a new initial state to the proposal lifecycle: “Updatable”, during which proposers can update their proposal's transactions and text description. This feature will be disabled at first and will require a separate proposal to configure the period of the Updatable state. Propose by signatures: 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. This feature will be activated once this proposal executes. Objection-only period: a conditional voting period that gets activated upon a “last-minute” proposal swing from defeated to successful, affording voters more reaction time. Only against votes are possible during the objection period. This feature will be disabled at first and will require a separate proposal to enable it and configure its parameters. 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). Currently the vote snapshot block is the proposal creation block. Nouns Fork: allowing Nouners to exit the DAO by forking to a new DAO. Current threshold is set at 20%. For more details please read the tech spec and this post. An updated version of nouns.wtf will be deployed to add support for these features.
Audit 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:
0 critical risk severity issues 2 high risk severity issues 18 medium risk severity issues 22 low risk severity issues For more info: the full Spearbit audit report.
code4rena found:
1 high risk finding 3 medium risk findings 8 low risk findings For more info: the full code4rena audit report.
Won’t Fix Issues 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.
Setting a new fork escrow contract might lead to lost tokens Proposals can move from Expired state back to Queued when timelock’s Grace Period changes Changes in detail Proposal editing 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.
Propose by signatures 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.
Objection-only period 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 days lastMinuteWindowInBlocks: what is considered “last minute”? e.g. 2 hours Both parameters start with values of zero, effectively making this feature disabled. A separate proposal will follow turning on this feature with suggested parameters.
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.
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.
Nouns Fork Further details can be found here in the tech spec and this post.
New treasury 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:
Transferring ETH, stETH, wstETH, rETH & USDC Changing ownership of the auction house, auction house proxy admin, nouns token & nouns descriptor contracts Change ownership of TokenBuyer and Payer to allow treasury v2 to perform ETH/USDC swaps Approve the treasury v2 to transfer lil nouns from treasury v1 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.
Important heads up 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.
Proposal #1 Transactions (this proposal): Send 2,500 ETH to new treasury contract The rest of the ETH will be transferred in a followup proposal. We can’t tell in advance how much ETH the treasury will have at the moment this proposal executes so we are sending a first chunk now. Upgrade the DAO contract logic to V3 Set the fork params: a. forkEscrow: the escrow contract b. forkDeployer: the contract which deploys new forked DAOs c. erc20TokensToIncludeInFork: addresses of erc20 tokens which will be included in the treasury fork, specifically: stETH, wstETH, rETH and USDC d. forkPeriod: the period during which token holders can join a fork after it has been executed, 7 days e. forkThresholdBPS: the % of nouns required to surpass in order to activate a fork, 2,000 bps = 20% Set the proposal id at which the vote snapshot will be changed to be after voting delay a. Sets it to the next proposal after the current one Transfer ownership of the auction house proxy contract Send stETH to the new treasury, leaving 5,000 stETH for proposals that may be queued Change ownership of the Nouns token contract Change ownership of the Nouns descriptor contract Transfer ownership of the auction house proxy admin Set treasury V2 as the new treasury of the DAO contract, and set treasury v1 to be available to reference for proposeOnTimelockV1 Proposal #2 Transactions: This 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.
Move leftover ETH from treasury v1 to treasury v2 Approve treasury v2 to transfer lil nouns from treasury v1 Transfer ownership of TokenBuyer to treasury v2 Transfer ownership of Payer to treasury v2 Approve unlimited stETH to be transferred by the ERC20Transferer contract Invoke ERC20Transferer to send remaining stETH to the new treasury Transfer all wstETH to treasury v2 Transfer all rETH to treasury v2 Transfer all USDC to treasury v2 Can be viewed in more detail here.
Proposal #3 Transactions: Set ENS reverse lookup on treasury V2 to resolve to nouns.eth Proposal execution notes Proposals #1 and #2 will be executed on treasury v1, while proposal #3 is executed on treasury v2. Prior to executing proposal #3, the accounts that control nouns.eth will set nouns.eth to point to treasury v2.
Thisis more than an exact replica of Prop #354, which passed with near-unanimous approval only to be unexpectedly canceled by its owner before execution. This prop is a statement of resilience, a pledge that will not be broken or canceled.
Finalized with meticulous care between January and February, V3's design stands unchanged. The community, blindsided by the spontaneous cancellation despite comprehensive legal opinions and exhaustive audits, remains united and vigilant. Claims of a "crypto-economic issue" find no echo among the community, auditors, Cayman Foundation's law firm, or the CT community at large. Yet, we should all stand ready for open discourse within the five days before this prop goes live. This prop will not be canceled. The community alone will decide, again.
This proposal symbolizes something profound. It is the very test of whether Nouns is controlled by the collective strength and wisdom of the community/token holders or controlled by a select few known as the Nounders/multisig holders. This is a moment that challenges us to prove our shared principles and uphold true decentralization while leading the ecosystm forward into a new more resilient future.
------------------------- Below should be identical to the last prop. Please Verify -------------------------
This proposal upgrades the Nouns DAO logic contract to V3. This version introduces the following changes:
Proposal editing: adding a new initial state to the proposal lifecycle: “Updatable”, during which proposers can update their proposal's transactions and text description. This feature will be disabled at first and will require a separate proposal to configure the period of the Updatable state. Propose by signatures: 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. This feature will be activated once this proposal executes. Objection-only period: a conditional voting period that gets activated upon a “last-minute” proposal swing from defeated to successful, affording voters more reaction time. Only against votes are possible during the objection period. This feature will be disabled at first and will require a separate proposal to enable it and configure its parameters. 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). Currently the vote snapshot block is the proposal creation block. Nouns Fork: allowing Nouners to exit the DAO by forking to a new DAO. Current threshold is set at 20%. For more details please read the tech spec and this post. An updated version of nouns.wtf will be deployed to add support for these features.
Audit 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:
0 critical risk severity issues 2 high risk severity issues 18 medium risk severity issues 22 low risk severity issues For more info: the full Spearbit audit report.
code4rena found:
1 high risk finding 3 medium risk findings 8 low risk findings For more info: the full code4rena audit report.
Won’t Fix Issues 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.
Setting a new fork escrow contract might lead to lost tokens Proposals can move from Expired state back to Queued when timelock’s Grace Period changes Changes in detail Proposal editing 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.
Propose by signatures 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.
Objection-only period 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 days lastMinuteWindowInBlocks: what is considered “last minute”? e.g. 2 hours Both parameters start with values of zero, effectively making this feature disabled. A separate proposal will follow turning on this feature with suggested parameters.
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.
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.
Nouns Fork Further details can be found here in the tech spec and this post.
New treasury 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:
Transferring ETH, stETH, wstETH, rETH & USDC Changing ownership of the auction house, auction house proxy admin, nouns token & nouns descriptor contracts Change ownership of TokenBuyer and Payer to allow treasury v2 to perform ETH/USDC swaps Approve the treasury v2 to transfer lil nouns from treasury v1 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.
Important heads up 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.
Proposal #1 Transactions (this proposal): Send 2,500 ETH to new treasury contract The rest of the ETH will be transferred in a followup proposal. We can’t tell in advance how much ETH the treasury will have at the moment this proposal executes so we are sending a first chunk now. Upgrade the DAO contract logic to V3 Set the fork params: a. forkEscrow: the escrow contract b. forkDeployer: the contract which deploys new forked DAOs c. erc20TokensToIncludeInFork: addresses of erc20 tokens which will be included in the treasury fork, specifically: stETH, wstETH, rETH and USDC d. forkPeriod: the period during which token holders can join a fork after it has been executed, 7 days e. forkThresholdBPS: the % of nouns required to surpass in order to activate a fork, 2,000 bps = 20% Set the proposal id at which the vote snapshot will be changed to be after voting delay a. Sets it to the next proposal after the current one Transfer ownership of the auction house proxy contract Send stETH to the new treasury, leaving 5,000 stETH for proposals that may be queued Change ownership of the Nouns token contract Change ownership of the Nouns descriptor contract Transfer ownership of the auction house proxy admin Set treasury V2 as the new treasury of the DAO contract, and set treasury v1 to be available to reference for proposeOnTimelockV1 Proposal #2 Transactions: This 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.
Move leftover ETH from treasury v1 to treasury v2 Approve treasury v2 to transfer lil nouns from treasury v1 Transfer ownership of TokenBuyer to treasury v2 Transfer ownership of Payer to treasury v2 Approve unlimited stETH to be transferred by the ERC20Transferer contract Invoke ERC20Transferer to send remaining stETH to the new treasury Transfer all wstETH to treasury v2 Transfer all rETH to treasury v2 Transfer all USDC to treasury v2 Can be viewed in more detail here.
Proposal #3 Transactions: Set ENS reverse lookup on treasury V2 to resolve to nouns.eth Proposal execution notes Proposals #1 and #2 will be executed on treasury v1, while proposal #3 is executed on treasury v2. Prior to executing proposal #3, the accounts that control nouns.eth will set nouns.eth to point to treasury v2.
I support the V3 upgrade that includes a fork, provided that future forks aren't guaranteed. If an arbitrage opportunity exists, it will be pursued. Nouns should be resilient to arbitrage, instead of being vulnerable to it or treating it adversarially. While I’m personally not a fan of arbitrage, it will always exist, and should be addressed in the DAO’s design. The best way to address this is in two ways: increasing spending and increasing uncertainty.
noun40 makes many thoughtful points here, especially on spending. As noun40 points out, spending makes arbitrage less profitable. Ensuring that Nouns does not hold a significant treasury, but instead spends its revenue relatively quickly, would ensure that arbitrage opportunities are minimal. There is no reason that Nouns should sit on a substantial treasury. It's arguably better to inject ETH into the market now, given the scarcity of funding, than to hoard it and spend reluctantly. Nouns has the opportunity to keep builders and artists in the ecosystem and to make it viable for them to participate for the long-term.
Nouns should spend more, it should spend quickly, and it should take into account that funding deployed now is more valuable to the ecosystem than funding deployed later. Given the time value of money, spending now yields the greatest impact. While it is of course important to spend well, and ensure that funds go to the right places, there are many good actors ready to absorb the $50M of liquidity that Nouns holds. If a portion of that is misused, it is still less expensive than the costs of enforcement. Enforcement around spending, or not spending at all, is very likely more costly in terms of impact than spending misuse. If $49M goes to good actors and $1M is wasted, that is better than barely spending at all. Cherry picked examples of waste will always be touted on Twitter, but the alternatives are worse.
In addition to spending, Nouns has another mechanism that it should leverage: uncertainty. Right now, it’s possible to estimate how many days Nouns has until arbitragers have a majority of votes. (There will be ambiguity here from groups that don’t vote, but it’s relatively easy to estimate a range here.) If Nouns are below “book value”, then arbitrage is nearly guaranteed. Nouns can raise these costs, however, by adding uncertainty. As I write this, the odds of a fork are very close to guaranteed. If someone is buying Nouns for an arbitrage opportunity and there is a 90+% chance of a fork, arbitrage looks very appealing. By reducing the certainty of a fork, we can raise the costs of arbitrage.
Nouns has an excellent mechanism for injecting uncertainty: the Nouns Foundation veto. The veto is relatively open-ended, and specifically mentions the possibility of a veto for using the Nouns treasury for personal gain. Announcing that the veto will be considered for future forks, without committing to a particular path, will reduce the expected value of any arbitrage. This can be dialed in based on messaging — stronger statements will hold more sway, as well statements with greater specificity. We can inject uncertainty without resorting to more desperate measures, like burning or slashing. Simply announcing the possibility of a veto and letting the arbitragers incorporate that uncertainty will reduce the expected value of the arbitrage.
Nouns should spend more, but it should also ensure that future forks are seen as far from guaranteed. This is a path to a DAO focused on public goods that does not reduce the flexibility that Nouns has or commit to a particular path. I am in favor of the V3 upgrade + the fork, but I encourage Nouns (in particular, the Nouns Foundation) to become more aggressive about arbitrage and reduce its expected value. That will ensure that arbitrage is not guaranteed and make it a less appealing target.
P.S. A brief note on procedural objections: I understand the procedural concerns of bundling multiple proposals together, but with the many cancelations of prior V3 upgrade proposals, there was ample opportunity to split these out into separate votes before now. I also understand the concerns about the preamble, which I am not a fan of, but the transaction data is what matters. The preamble is less relevant here, where all of the work to date on V3 speaks for itself.
To start, I really do not think I am educated enough, nor qualified enough to vote in favor or against this Prop. As someone who is primarily an outsider, this prop seems to be all over the place.
It also gives off a very divisive aura that as an outsider (delegate) feels insanely unappealing.
Outsiders (people who aren't spending time voting on Nouns DAO proposals) will be left with a sour taste in their mouths if there isn't better communication between all parties: Nouns, crypto-community as a whole, etc. Maybe I'm not looking in the right direction? That's a valid point. However, I don't even know where to start.
All in all, I do think this proposal should pass, but for now, I would like to abstain. sent from voter.wtf
DAO's are about onchain governance and coordination. If you don't respect that or try and threaten that governance sub rosa, you're not interested in DAOs, you're just dissembling.
FOR - 5 VOTES
kwikgamedev | "Put a fork in it, see if the DAO is done!"
AGAINST - 30 VOTES
brettdrawsstuff | "copy pasta props = no"
robotfishgirl | "as much as I want this to go through, the issue pointed out by the nounders is too significant to ignore. Even if there's no better solution, would like to see more discussion before a resubmit like this"
benbodhi | "low effort duplicate prop to the one I already voted against."
ABSTAINS - 7 VOTES
Copying my reason from the previous prop:
Thank you Noun 40 for all the context that you've authored and shared! As a newer participant in the game of Nouns, it helped me inherit a nuanced and optimistic perspective on this proposal. I'm sure it was super helpful to those who have been embedded in the community as well. 💖🙏
as we venture forward, let curiosity be our compass and innovation our guide.
sent from voter.wtf
I'm FOR upgrading to V3 but not with this preamble. Lets stay classy and professional with the things that will live permanently on Ethereum. Especially with decisions of this magnitude.
We oppose this proposal due to the evident abuse of agenda-setting power during the “Nouns Fork“. It is operating under a facade of procedural justice. The current voting outcomes are a result of this abuse. We do not recognize the legitimacy of all previous community votes related to the Fork feature, as they violate procedural rules and only lead to increased uncertainty, division, and a breakdown of trust within NounsDAO.
This abuse manifests on two levels:
1.Proposal 356 bundles multiple proposals together. Proposals 353, 354, and 356 combine two distinctly different topics and levels of importance. This raises the question: Should we, during significant constitutional reforms, bundle distinct and important proposals together for community discussion?
Treating the Fork and V3 other features as two separate proposals is essential. The Fork proposal is a constitutional-level reform, the focal point of community disagreements, as its outcome will directly alter Nouns' foundational incentive mechanisms and organizational structure. On the other hand, the V3 feature upgrade will change the interaction flow for governance participants.
Two proposals with distinctly different objectives are bundled together. One addresses fundamental changes to the underlying incentive system, fraught with significant contradictions; the other optimizes governance processes, which seems beneficial. Combining these two muddles the discourse around Proposal 356, preventing a clear and rational discussion of its pros and cons. For governance researchers, such mixed proposals are extremely frustrating. Garbage in, garbage out. This is one consequence of the abuse of agenda-setting power.
2.More crucially, the NounsDAO Fork proposal bypassed the regular procedure and should not have been proposed by just one team. From its inception to its implementation, the Fork feature was emotionally driven, sidestepping the intended process. After Proposal 248's Rage Quit, a utopian voice emerged in the community, envisioning an infinitely forked NounsDAO future. Two emotional currents hastily pushed out the NounsDAO Fork feature, bypassing the regular procedure.
Now, it's evident that the hastily introduced mechanism has significant issues. It has attracted arbitrageurs, undermining foundational governance. On-chain data clearly supports this perspective. Since May, the number of Nouns holders has stagnated: 392 holders on May 1st and 392 on August 21st. Most Nouns in the past four months have been snagged by arbitrageurs.
The current NounsDAO is under attack. It's evident that the Fork mechanism has serious issues, a fact supported by clear data, rather than sensationalized stories.
Until a credible-neutrality solution emerges, terms like "decentralization," "adventurous spirit," "culture," and "global public goods movement" are just marketing narratives. We need to pause, revert the NounsDAO Fork feature to the research phase.
The right process should resemble Proposal 216: "Mandated Round: Private Voting Research Sprint". Engage multiple teams, foster innovation, and present diverse forking solutions. Instead, the Verb team, already overwhelmed, was pushed by community anxiety to offer an over-engineered Fork solution that arbitrageurs are now exploiting.
We are being forced to accept a flawed proposal and then debate and take sides. This is another consequence of agenda-setting power abuse.
Now, pro-fork arbitrageurs might have more than 100 votes, which is very risky. We strongly urge all independent Nouners, not swayed by vested interests, to vote against Proposal 356 and follow these steps:
(noun40 voting via agora)
I personally don't think the new attack vector raised (keep accumulating nouns with "no risk" post 20% threshold while blocking spending) is viable attack vector. my reasoning below.
the threshold to capture the dao (theoretically 51% but in practice likely closer to 40-50% since there's likely votes you can never galvanize in any circumstance) is unchanged.
let's assume the arber has accumulated the needed 20% to fork but decides to continue. let's look at two scenarios of what they could now do.
scenario 1: they try to block spending as much as they can with their voting weight as argued.
in this case they face immense risk. they have to actively use their tokens to vote to block props so their actions become visible and identifiable. if they are unsuccessful in blocking spending and important props are still getting through (which was our case this time around; as much as sentiment is struggling, the dao still passed a ton of props this year including the last two months) then the dao might just let it slide. but if it truly becomes successful at meaningfully interrupting substantially all funding activity, then the flood gates of defense mechanisms open up.
we could vote to continuously send excess eth to a time locked smart contract to erase the arb profit as charlie suggested in his blog post. we could attempt mutual destruction buy purchasing a high priced nft or even choosing to burn the eth. we could even do something more akin to "slashing" by identifying the portion of the dao that has substantially voted against all recent props and passing a prop to send the entire treasury eth to a fork dao and assigning ownership of all the identified attacker tokens IDs in the fork dao to the treasury (deleting attacker ownership). that would mean not only the arb profit gone but the entire principal involved in the attack to be zeroed and actually just become a donation to the dao. the world would also not be very confused in figuring out what the legitimate dao is in that case so we'll just continue onward with our provenance.
the moral of the story is that you're absolutely not safe until you actually completely capture the dao. even if you're 1% less than that target the super frustrated dao could totally retaliate and you don't have a way of stopping spending without frustrating the dao.
scenario 2: you silently continue to accumulate without any attempt to block or reduce spending.
in this case you're arb profits are still absolutely at risk. any prop that spends eth is reducing the book value of all nouns thus reducing your per noun arb profit (percentage return on capital invested in the arb).
one could argue that well, while they lose on percentage returns, they could still be interested in increasing their absolute eth profit and continue for that reason. well note that as your position grows, the portion of dao treasury expenses that you're financing (in reduced total arb profit) also grows linearly.
let's actually just do some rough back of napkin style math. this year our monthly eth spend has been roughly the same as the monthly auction revenue (treasury eth amount has been roughly flat; source: https://dune.com/hildobby/nouns). for easy round numbers let's say nouns are sold every day at 30 ETH and the book value is 35 ETH. our monthly spend in this case is 900 ETH (assuming monthly spend = monthly auction revenue). if you hold 20% of the supply then you're paying for 20% (180 ETH) of that 900 ETH expense. in other words every day that you continue the arb you have a chance at making 5 ETH more (gap between book value and auction price) but you're on average losing 6 ETH per day (180 ETH / 30 days).
thus it's not economically rationale to continue in both percentage of return terms AND absolute total profit terms unless you can meaningfully reduce spending (but note that spending this year didn't really stop even with the arbers trying and we analyzed in scenario #1 the added risks arbers would be facing such as slashing by further frustrating the dao).
for these reasons I don't think the new attack vector raised is really viable and doesn't change my view on v3 being the right path forward.
P.S. just one last note on the dao capture situation. this attack vector is already alive and well without the fork and I would argue our options are worse without the fork. if someone has 40%+ voting power then while they can't unilaterally pass any prop b/c of veto, they can absolutely reject every prop. we have no recourse here. they can ask for their "share" of the treasury. they could ask for more. we have no other recourse than to accept their terms or else the dao is permanently bricked. imo it's naive to assume to that in the current mode only economically irrational actors would attack the dao. it can be absolutely rational to capture the dao even without the fork if you can get a low enough cost basis since you can take the entire treasury hostage and negotiate with the dao for a profit. the only real defense here is something like the fork that limits the damages to their "share" of the treasury and ultimately not having auction prices dip too far below the book value (which the fork mechanism contributes to as well). in a way there's a viewpoint one can have that creating market competition amongst arbers through something like the fork mechanism ensures that the cost of such a capture attack remains reasonably high at all times.
Verifiably the exact same prop as the one that passed almost unanimously.
this proposal passed already, the cancellation based only on the last-minute opinion of one individual despite the 214 votes in favor was very unfair.
anyway, the "crypto-economic issue" is something so remote and theorical and that needs so many unpredictable factors to be perfectly aligned to make it happen (like a steep discount to bv for a very long period of time and the complete absence of other arbers etc.), that it's not an issue at all.
what are the 2 most important assets for a Dao? the treasury and the community. And BOTH THESE ARE NOT AT RISK in the case of the theorized attack, thanks to the vanilla rq feature of the forked dao.
it's false that if someone gets 20% of the supply can block the dao from spending and it's even more false that going from 20% to ~40% is "risk free", such an attack would be extremely expensive and a crazy bad r/r to even try it.
it's also insane to think that an attacker would join the forked dao just to grief it, simply because THERE ARE NO ECONOMIC INCENTIVES TO DO SO, thanks again to the vanilla rq feature.
so throwing away $200k that we paid for the audit, $900k/year for the dev team, and months of intensive discussions, just for this is very stupid especially because this can always be fixed at a later time in many ways e.g. set a reserve price for the auctions.
additional views on the topic that I suggest reading: https://twitter.com/noun40__/status/1691252232808017920, https://twitter.com/noun12LFG/status/1691180505520123904
I agree with the V3 upgrade except for Nouns Fork; I believe the Nouns Fork feature is unnecessary given the original purpose of Nouns DAO as it provides an economic attack incentive to the abitlagers.
If Nouns Fork were to be adopted, it would need to be adjusted by adding a cost to Fork.
Old friends, and worse, future ones, excited and curious, are not exit liquidity. Completely Heartbreaking.