Nouns Fork is a minority protection mechanism that allows Nouners to exit Nouns DAO (aka OG DAO), into a fresh copy of Nouns DAO, reusing their token IDs and art, and the Nouns governance system, and taking with them their fair share of OG DAO’s treasury into the fork DAO treasury. Nouners need to band together to meet the fork threshold to be able to fork. We launched V1 of Nouns Fork with a known griefing vector, which we’d like to better explore and explain, and ultimately decide if there’s a worthwhile solution we should build.

While arbitrage remains the top concerns many Nouners have with regards to the Fork, we won’t be covering that here. On the arbitrage problem, we are happy to explore further if we get a strong signal from the DAO, similar to how we made Fork V1 our most urgent priority after receiving a strong signal on a Snapshot vote.

In this post we will stay focused on the known griefing attack Fork V1 has, and potential mitigations we’re considering.

An attacker with a voting majority can force an honest minority to fork and then disband their fork DAO by forcing them to ragequit.

Let’s walk through it step by step:

1. The attacker buys a majority share of votes (by owning Nouns or bribing others).

2. The attacker then either puts up a malicious proposal, or holds the DAO hostage by shooting down all proposals.

3. The minority, e.g. all other Nouners, initiate a fork.

4. The attacker joins their fork and has majority votes in the fork DAO as well.

5. The attacker puts up a malicious proposal in the fork DAO.

6. The minority has no choice but to ragequit.

The griefing attack stems from the fact that any Noun can join any fork, so if there’s a malicious majority, they can force the minority into forking and then simply join their fork DAO. The mitigation we currently have is allowing fork DAO Nouners to ragequit at any time without needing to band together, so people get away with their fair share and leave the malicious Nouner with little-to-no profit.

This griefing is problematic despite having ragequit because one of Fork’s aspirations is to keep forkers together as DAO members; while the honest minority can choose to regroup into a new DAO after they ragequit, it might still be a significant hit to the project’s momentum.

You might wonder: why would anyone perform this attack? We think the most likely motivation is to hurt or ruin Nouns.

We have a couple of ideas, both are variations of the same principle: somehow limiting which Nouns can or cannot join a fork. The first idea is based on forking on a specific proposal, and blacklisting Nouns that voted and got what they wanted (e.g. voted For and the proposal succeeded). The second idea is allowing Nouners who initiate a fork to set a blacklist (or whitelist) of which Nouns can join. Let’s explore how each idea might work in more detail.

A fork is created on a specific proposal, as part of the proposal’s timeline. Once a proposal reaches the Successful / Defeated / Vetoed state, an Escrow Period starts giving Nouners time to escrow to meet fork threshold, and if threshold is met the fork is executed and others can join, same as today. The key difference is: if the proposal is Successful, Nouns that voted For cannot fork, and if the proposal is Defeated, Nouns that voted Against cannot fork. Vote-based conditions will only be possible with the upcoming Noun Governor’s NFT-based voting.

For example say a majority group passes a proposal to take all treasury funds, other Nouns can fork off knowing that at least the Nouns that voted for the proposal can’t fork with them; the attacker might have extra Nouns that didn’t vote to fork with, but likely not a significant amount to pose an immediate threat.

One problem can arise when a Nouner’s delegate votes in favor of an attack or a proposal the Nouner deeply opposes (intentionally or accidentally); this would result in the Nouner not being able to fork, while they ought to be included. This problem can be mitigated by expecting Nouners to keep track of all proposals and change their delegation before voting on a malicious proposal begins. Another possible mitigation is adding a “delegate override” ability for Nouners to override their delegates’ votes.

As we’ve seen onchain this year, forks can often happen due to political polarization. In such times Nouners want to make sure they fork or stay with others they feel aligned with. In this design Nouners can be left behind when they vote differently from others they feel allied with, and if their Nouner friends choose to fork on a proposal where they voted differently, the Nouner in question is unable to join. We imagine this leading to voting anxiety and more “copy-paste” voting rather than voting as Nouners truly think. The easiest mitigation in our view is to keep Fork V1’s existing forking mechanism, such that a group of Nouners can fork together without these exclusion risks.

We can avoid these automatic blacklisting problems in one fell swoop, by taking a different approach: manual blacklisting (or whitelisting).

In the manual design, any Nouner can initiate a fork and set a blacklist of Noun IDs, thereby preventing the attacker from joining their fork.

Using this design with a high fork threshold seems problematic. One problem is that if a real threat arises and such a selective fork is used, some honest Nouners might get left behind for unfortunate reasons, either by the fork initiator making a mistake, or leaving them out on purpose. This problem exists in the automatic design as well, but to a much lesser degree since the fork initiator has no control over the blacklist.

Lowering fork threshold has its risks as well, as discussed during the initial Fork design period. We’d like to restart some of those discussions and see if a very low threshold is viable.

If the DAO decides to use a low threshold, this design can lead to many forks one after the other. Therefore, if we were to disable proposal execution during each fork’s forking period, the DAO might be unable to execute proposals for a long time; this could be exploited as a way of griefing the DAO.

To mitigate this concern we think these kinds of forks should not block proposal execution; instead, the fork initiator needs to manually set the forking period expiration timestamp, and if they are trying to exit prior to a specific proposal’s execution they would need to make sure that timestamp precedes when said proposal can be executed.

Worth noting that in the future an attacker might have ways to swap out their Nouns, either with treasury Nouns or some other liquidity pool, and they might use a swap to circumvent a fork blacklist. The minority can mitigate this risk by blacklisting all treasury (or liquidity pool) Nouns.

The manual approach combined with a lower fork threshold seems better than the automatic approach; the rules for when one can fork and which forks one can join are easier to grok. Specifically Nouners are less likely to be left behind in the OG DAO for unfortunate reasons.

Whether we can use a much lower fork threshold requires further inquiry with the DAO and the foundation.

As always, we are asking for your thoughts and feedback; should we solve this griefing problem? or just leave it open? Are there any Fork design changes you think we should explore further?

Special thanks to wag, for coming back to Nouns with gusto, and engaging with us on these challenging design questions and adding ideas like the manual fork admin direction.

Thanks everyone and looking forward to your feedback,
verbs team ⌐◨-◨

Nouns Fork is a minority protection mechanism that allows Nouners to exit Nouns DAO (aka OG DAO), into a fresh copy of Nouns DAO, reusing their token IDs and art, and the Nouns governance system, and taking with them their fair share of OG DAO’s treasury into the fork DAO treasury. Nouners need to band together to meet the fork threshold to be able to fork. We launched V1 of Nouns Fork with a known griefing vector, which we’d like to better explore and explain, and ultimately decide if there’s a worthwhile solution we should build.

While arbitrage remains the top concerns many Nouners have with regards to the Fork, we won’t be covering that here. On the arbitrage problem, we are happy to explore further if we get a strong signal from the DAO, similar to how we made Fork V1 our most urgent priority after receiving a strong signal on a Snapshot vote.

In this post we will stay focused on the known griefing attack Fork V1 has, and potential mitigations we’re considering.

An attacker with a voting majority can force an honest minority to fork and then disband their fork DAO by forcing them to ragequit.

Let’s walk through it step by step:

1. The attacker buys a majority share of votes (by owning Nouns or bribing others).

2. The attacker then either puts up a malicious proposal, or holds the DAO hostage by shooting down all proposals.

3. The minority, e.g. all other Nouners, initiate a fork.

4. The attacker joins their fork and has majority votes in the fork DAO as well.

5. The attacker puts up a malicious proposal in the fork DAO.

6. The minority has no choice but to ragequit.

The griefing attack stems from the fact that any Noun can join any fork, so if there’s a malicious majority, they can force the minority into forking and then simply join their fork DAO. The mitigation we currently have is allowing fork DAO Nouners to ragequit at any time without needing to band together, so people get away with their fair share and leave the malicious Nouner with little-to-no profit.

This griefing is problematic despite having ragequit because one of Fork’s aspirations is to keep forkers together as DAO members; while the honest minority can choose to regroup into a new DAO after they ragequit, it might still be a significant hit to the project’s momentum.

You might wonder: why would anyone perform this attack? We think the most likely motivation is to hurt or ruin Nouns.

We have a couple of ideas, both are variations of the same principle: somehow limiting which Nouns can or cannot join a fork. The first idea is based on forking on a specific proposal, and blacklisting Nouns that voted and got what they wanted (e.g. voted For and the proposal succeeded). The second idea is allowing Nouners who initiate a fork to set a blacklist (or whitelist) of which Nouns can join. Let’s explore how each idea might work in more detail.

A fork is created on a specific proposal, as part of the proposal’s timeline. Once a proposal reaches the Successful / Defeated / Vetoed state, an Escrow Period starts giving Nouners time to escrow to meet fork threshold, and if threshold is met the fork is executed and others can join, same as today. The key difference is: if the proposal is Successful, Nouns that voted For cannot fork, and if the proposal is Defeated, Nouns that voted Against cannot fork. Vote-based conditions will only be possible with the upcoming Noun Governor’s NFT-based voting.

For example say a majority group passes a proposal to take all treasury funds, other Nouns can fork off knowing that at least the Nouns that voted for the proposal can’t fork with them; the attacker might have extra Nouns that didn’t vote to fork with, but likely not a significant amount to pose an immediate threat.

One problem can arise when a Nouner’s delegate votes in favor of an attack or a proposal the Nouner deeply opposes (intentionally or accidentally); this would result in the Nouner not being able to fork, while they ought to be included. This problem can be mitigated by expecting Nouners to keep track of all proposals and change their delegation before voting on a malicious proposal begins. Another possible mitigation is adding a “delegate override” ability for Nouners to override their delegates’ votes.

As we’ve seen onchain this year, forks can often happen due to political polarization. In such times Nouners want to make sure they fork or stay with others they feel aligned with. In this design Nouners can be left behind when they vote differently from others they feel allied with, and if their Nouner friends choose to fork on a proposal where they voted differently, the Nouner in question is unable to join. We imagine this leading to voting anxiety and more “copy-paste” voting rather than voting as Nouners truly think. The easiest mitigation in our view is to keep Fork V1’s existing forking mechanism, such that a group of Nouners can fork together without these exclusion risks.

We can avoid these automatic blacklisting problems in one fell swoop, by taking a different approach: manual blacklisting (or whitelisting).

In the manual design, any Nouner can initiate a fork and set a blacklist of Noun IDs, thereby preventing the attacker from joining their fork.

Using this design with a high fork threshold seems problematic. One problem is that if a real threat arises and such a selective fork is used, some honest Nouners might get left behind for unfortunate reasons, either by the fork initiator making a mistake, or leaving them out on purpose. This problem exists in the automatic design as well, but to a much lesser degree since the fork initiator has no control over the blacklist.

Lowering fork threshold has its risks as well, as discussed during the initial Fork design period. We’d like to restart some of those discussions and see if a very low threshold is viable.

If the DAO decides to use a low threshold, this design can lead to many forks one after the other. Therefore, if we were to disable proposal execution during each fork’s forking period, the DAO might be unable to execute proposals for a long time; this could be exploited as a way of griefing the DAO.

To mitigate this concern we think these kinds of forks should not block proposal execution; instead, the fork initiator needs to manually set the forking period expiration timestamp, and if they are trying to exit prior to a specific proposal’s execution they would need to make sure that timestamp precedes when said proposal can be executed.

Worth noting that in the future an attacker might have ways to swap out their Nouns, either with treasury Nouns or some other liquidity pool, and they might use a swap to circumvent a fork blacklist. The minority can mitigate this risk by blacklisting all treasury (or liquidity pool) Nouns.

The manual approach combined with a lower fork threshold seems better than the automatic approach; the rules for when one can fork and which forks one can join are easier to grok. Specifically Nouners are less likely to be left behind in the OG DAO for unfortunate reasons.

Whether we can use a much lower fork threshold requires further inquiry with the DAO and the foundation.

As always, we are asking for your thoughts and feedback; should we solve this griefing problem? or just leave it open? Are there any Fork design changes you think we should explore further?

Special thanks to wag, for coming back to Nouns with gusto, and engaging with us on these challenging design questions and adding ideas like the manual fork admin direction.

Thanks everyone and looking forward to your feedback,
verbs team ⌐◨-◨