In this post we describe an updated spec to the stream based minority protection we introduced in the previous post.

High Level Design

Nouns DAO auctions an NFT every day. Part of the auction proceeds are sent immediately to the DAO treasury and the rest are streamed over time. For the purpose of this document, we will refer to the escrow contract as StreamEscrow.

For more context please see this Nouns Foundation post and our initial post about this design.

Step by step example

• Alice wins the daily auction for 10 ETH.

• Upon auction settlement:

  • An initial amount of 2 ETH (20%) is paid immediately to the DAO.

  • The remaining 8 ETH are streamed from Alice to the DAO over 1500 days.

  • All newly vested amounts from all streams are sent to the DAO at each auction settlement.

• The stream is managed by a non-upgradeable contract, not in control of the DAO (or anyone else).

• Alice cancels her stream after 375 days (25% of the stream length), by returning her Noun and withdrawing her unstreamed funds, which come out to 6 ETH.

Stream management

All streams are managed via a single StreamEscrow contract. All the streams’ funds are deposited into this single contract. It maintains internal accounting in order to know how many funds belong to which stream, and how much has already been streamed to the DAO.

The reason for a single contract as opposed to a contract per stream, is because it is significantly more gas efficient.

In the example above, once the stream is created, 8 ETH are transferred to StreamEscrow. The Auction House contract notifies StreamEscrow every time an auction is settled and another chunk of the funds are streamed to the DAO.

Creating a stream

To create a stream for a Noun, the account creating the stream must meet two conditions at the same time:

1. Be on the StreamEscrow contract allowed accounts list, and

2. Be the owner of the Noun in question, or approved to transfer the Noun in question by its owner.

The primary use case is the Auction House contract creating streams upon auction settlement. The Auction House will be allowed by the DAO starting at the proposal that upgrades Auction House to the new streams-supporting version. Auction House is also the owner of each new Noun just before its sent to the auction winner, so it will meet these two conditions consistently.

Additional use cases might include selling treasury-owned Nouns outside the auction mechanism. In such cases we might create a helper contract that will be allowed, and the DAO will approve such a helper contract to transfer some or all of its Nouns.

The right to cancel the stream is attached to the Noun NFT, i.e. if Alice transfers her Noun to Bob, then only Bob is allowed to cancel the stream and withdraw the unstreamed funds.

Canceling a stream

In order to cancel her stream, Alice calls a function on StreamEscrow which:

• Transfers her Noun into the Nouns DAO treasury.

• Cancels her stream so that it doesn’t stream any more funds to the DAO.

• Sends unstreamed funds back to Alice.

DAO receiving streamed funds

At each tick of the StreamEscrow clock (every 24 hours or longer), all streams are advanced one step forward, and the newly vested amount is sent to the DAO immediately, as part of the same clock-forwarding transaction.

Upon every transfer of ETH to the DAO an event is emitted with the ETH amount; this is the primary means of tracking streams revenues.

The DAO can pass a proposal to change the address to which ETH should be sent; this flexibility can be used in future for example to run revenues through a tax withholding helper contract, or if the DAO chooses to move to a new treasury / executor contract.

Fast-forwarding streams

Any Noun owner whose Noun has an active stream can choose to fast-forward their stream by some amount of ticks, all the way up to sending the full value of their stream to the DAO immediately. This is helpful when a Noun owner wants to accelerate their funding of Nouns DAO. The primary downside of fast-forwarding is the reduction in minority protection.

Past Nouns

Nouns that were auctioned before this change was introduced don’t have any stream attached to them.

Nounder Nouns

Nounder Nouns will not have any refund available, since none of them are paid for and therefore will not have an escrowed stream.

Currency

Auctions and streams are all conducted in ETH.

Summary of configuration parameters

Auction House parameters

• Upgradeable and under DUNA control: Yes.

• Initial payment percentage

  • Value: 20%.

  • Can it be modified: Yes, via DAO proposal.

• Stream duration:

  • Value: 1500 ticks.

  • Can it be modified: Yes, via DAO proposal.

  • Only affects new streams. Existing streams cannot be modified.

• StreamEscrow contract address

  • Can it be modified: Yes, via a DAO proposal to upgrade the Auction House code.

StreamEscrow parameters

• Upgradeable and under DUNA control: No.

• DAO executor address, i.e. who’s the admin of this contract.

  • Value: current treasury.

  • Can it be modified: Yes, via DAO proposal.

• ETH recipient address, i.e. where vested funds are sent.

  • Value: current treasury.

  • Can it be modified: Yes, via DAO proposal.

• Nouns recipient address, i.e. where Nouns are sent when streams are canceled.

  • Value: current treasury.

  • Can it be modified: Yes, via DAO proposal.

• The list of accounts allowed to create streams

  • Value: starts with just Auction House.

  • Can it be modified: Yes, via DAO proposal.

Detailed design

Introducing refunds via escrowed streams requires the following:

1. Changing Auction House.

2. Deploying the new StreamEscrow contract.

3. Disabling the Fork.

The gist of the change is that auction proceeds are split, such that some are sent to the DAO, most remaining funds are streamed to the DAO over time. The StreamEscrow clock can be advanced every 24 hours or longer. For convenience, we are “piggybacking” on the Auction House daily settlement transaction, as Nouns’ reliable daily transaction, thus avoiding the need to otherwise automate these stream clock forwarding transactions.

The code can be found here.

Why use Auction House as the clock?

The primary consideration is that when streams vest, the recipient (DAO) should recognize revenue, and tying vesting to the auction achieves two positive things for the DAO:

1. Legibility: instead of implicit revenue that’s hard to track, it occurs as part of a transaction, where we can emit events and index them and make them easily trackable.

2. External call piggyback: to have this legibility, someone needs to initiate a transaction; instead of funding bots or humans to do this for us, we can use Nouns’ existing recurring transaction.

The “implicit” alternative seems bad to us. Without explicit transactions, say just vesting every 24 hours or every block, accounting becomes more challenging. We would have to build new tooling that would check the state of streams at specific blocks and store that information in a dedicated database in order to keep track.

Auction House Changes

The Auction House change is straightforward: upon auction settlement, instead of sending 100% of the winning bid directly to the DAO’s treasury, the new code will:

• Send 20% directly to the treasury.

• Send 80% to StreamEscrow and register a new stream, with an end time articulated in the number of ticks from today.

• Notify StreamEscrow that an auction has settled in order to advance all streams by one “tick” (i.e. one auction).

StreamEscrow Details

StreamEscrow (SE) performs its accounting using a few key variables:

• minimumTickDuration: the minimum amount of time that needs to pass between ticks; we intend to set it to 24 hours. This variable is immutable.

• ethStreamPerTick: the amount of ETH streamed to the DAO at each “tick” (i.e. every 24 or longer, when forwardAll is called; default is at auction settlement).

• currentTick: how many ticks have occurred since this contract started handling streams.

• lastForwardTimestamp: the last time a tick occurred; used to enforce the minimum tick duration.

• ethStreamEndingAtTick: a mapping from a tick to the rate of ETH vesting that should stop vesting once we reach that tick.

• streams: a mapping from noun ID to its stream information, including:

  • ethPerTick: the amount of ETH to stream at each tick for this specific stream.

  • lastTick: the tick at which this stream will end.

  • canceled: whether the Noun owner canceled the stream or not.

• allowedToCreateStream: a mapping from an address to whether or not it’s allowed to create streams.

Functions used by Auction House

forwardAllAndCreateStream(uint256 nounId, uint16 streamLengthInTicks)

1. Requires the following (reverts if not true):

   1. msg.sender must be an approved caller, i.e. its value in allowedToCreateStream is true.

   2. msg.sender must be the owner of the input Noun, or approved by its owner.

2. Calls forwardAll() to advance all active streams by one tick to the DAO (more info below).

3. Calculates when this nounId’s stream should end, i.e. at what tick value, using the input of stream length it gets from Auction House.

4. Calculates the new stream’s ethPerTick value by dividing the stream amount (received as ETH sent in this function call) by the stream length input.

5. Adds the new stream’s ethPerTick to the overall ethStreamPerTick rate of streaming per tick for all streams.

6. Adds this new stream to the streams contract-level mapping.

forwardAll()

1. Gracefully requires the following (stops execution without reverting if true, to not halt auction house execution):

   1. At least minimumTickDuration (24 hours) have elapsed since the last time all streams were forwarded.

2. Increments currentTick by one.

3. Transfers ETH to the DAO at the amount of ethStreamPerTick.

4. Emits the event ETHStreamedToDAO with the amount of ETH streamed at this tick.

5. Handles finished streams (streams whose lastTick value equals the current tick value): 3. For each such stream, decrements ethStreamPerTick by the stream’s ethPerTick.

Functions used by DAO side contracts

createStream(uint256 nounId, uint16 streamLengthInTicks)

1. Requires the following (reverts if not true):

   1. msg.sender must be enabled via setAllowedToCreateStream.

   2. msg.sender must own the given Noun, or be approved by its owner.

   3. There is no active stream for nounId.

2. Creates a new stream, without forwarding existing streams.

Functions used by Noun owners

cancelStream(uint256 nounId)

1. Requires the following (reverts if not true):

   1. msg.sender is the owner of nounId.

   2. The nounId stream hasn’t been canceled already.

   3. The nounId stream hasn’t ended yet.

2. Sends Noun with nounId from the owner to the DAO treasury.

3. Decrements ethStreamPerTick by the stream’s ethPerTick.

4. Calculates and sends msg.sender the refund amount (ethPerTick times ticks left until the stream ends).

5. Emits the event StreamCanceled with the amount of ETH sent back to the Noun owner.

Functions used by the DAO (via proposals)

setDAOExecutorAddress(address treasury)

1. Requires the following (reverts if not true):

   1. msg.sender is the DAO executor (treasury).

2. Sets the executor address to the new value.

setAllowedToCreateStream(address contract, bool allow)

1. Requires msg.sender to be the DAO executor address.

2. Enables/disables the contract to call createStream

setETHRecipient(address newAddress)

1. Requires msg.sender to be the DAO executor address.

2. Sets ethRecipient to the new address; future vested ETH gets sent to this new address.

setNounsRecipient(address newAddress)

1. Requires msg.sender to be the DAO executor address.

2. Sets nounsRecipient to the new address; future Nouns from canceled streams get sent to this new address.

Disabling the Fork

To disable the Fork, the DAO will need to pass a proposal calling the DAO logic function _setForkThresholdBPS with a new value of 10,000, such that it becomes impossible to fork.

Because of restrictions on the circumstances pursuant to which a DUNA may make distributions to its members, a key change in this transition will be redesigning the minority protection from forks to cancellable streams. This post contains an initial draft of the streams specification - the design is not yet finalized. To that end, we are sharing this information with the intention of soliciting feedback from the community. We’d love your help finding issues and improving the plan wherever possible.

In tandem with soliciting feedback from the community, we are also working closely with the Nouns Foundation’s advisors to determine how to best achieve full legal compliance for all Nouners, delegates, DUNA administrators, and community members, without sacrificing any of the core principles of the DAO.

A Potential Design: Escrowed Streams

We are contemplating changing how auction winners pay for their Noun: instead of paying the full amount to the DAO right away, a small part would be paid to the DAO upon settlement, with most of the funds instead being deposited into a non-custodial and non-upgradeable escrow contract that then autonomously streams auction funds to the DAO over a period of 4 years.

If a Nouner wishes to exit the DAO, they can send their Noun back to the DAO, which will automatically cancel the stream, and they would then receive any unstreamed funds back from the escrow contract.

The stream cancellation right is transferable and tied to the Noun NFT.

A Concrete Example

• Alice wins the auction for 10 ETH.

• Upon auction settlement:

  • An initial amount of 2 ETH is paid immediately to the DAO.

  • The remaining 8 ETH are deposited into the escrow contract and streamed to the DAO over 4 years.

• The stream is autonomously managed by a non-upgradeable contract which is not under the control of the DAO (or anyone else).

• Alice cancels her stream after one year by returning her Noun, which allows her to withdraw her unstreamed funds from the escrow contract (which comes out to 6 ETH).

• The DAO can withdraw the already streamed funds from the escrow contract (which comes out to 2 ETH, minus whatever the DAO has already withdrawn).

No Streams for Past Nouns

Unfortunately Nouns which pre-date this change will not have a stream attached. This is due to requirements related to the restructuring of the DAO.

Nounder Nouns

Nounder Nouns will not have any stream, since none of them are paid for.

Summary of configuration parameters

Auction House parameters

• Upgradeable and under DUNA control: Yes.

• Initial payment percentage

  • Value: 20%.

  • Can it be modified: Yes, via DAO proposal.

Escrow parameters

• Upgradeable and under DUNA control: No.

• Stream duration:

  • Value: 4 years.

  • Can it be modified: No.

• DAO treasury address

  • Value: current treasury.

  • Can it be modified: Yes, via DAO proposal.

Summary

We understand that the streams specification represents a large change to how the DAO has historically operated; however, we think that the change, as part of the DUNA migration, is necessary to enable the continued viability of the DAO. As noted above, these plans are not finalized. We are looking forward to continued discussion with the community and welcome any feedback.

Thanks,

verbs ⌐◨-◨

We were recently approached by 0xkasper from hexens, a white hat security team, who found a new attack vector based on a vulnerability we were aware of in the Nouns token contract. Nouns tech grants pod has initiated a bounty payment of 30K USDC to the team.

TLDR

• Who’s at risk? Noun owners delegating to EOA accounts (not smart contract accounts).

• What’s the damage? Noun NFTs can become non-transferrable with no voting power.

• How likely is it to happen? The probability is low if you trust your delegates and their wallet security setup; otherwise please consider changing your delegation immediately.

An example scenario

Alice owns Noun 1, and Bob owns Noun 2.Alice delegates to Bob (Alice votes: 0; Bob votes: 2).

The problem begins when Bob, whether intentionally or not, uses a faulty delegation function.

Bob uses the delegateBySig function in the Nouns token contract to delegate to address zero (0x0000…). By doing so, one voting power unit was burned and can never be recovered (Alice votes: 0; Bob votes: 1). This is because most of the code does not expect delegation to address zero to be possible, but delegateBySig allows such a delegation to pass into the voting power change code.

Continuing the story:

Bob transfers Noun 2 to a new wallet, let’s name it Bobby (Alice votes: 0; Bob votes: 0; Bobby votes: 1).

Now Alice's Noun 1 is a zombie:

• its voting power is gone forever.

• It can never be transferred out of Alice's wallet (a transfer attempt will always revert).

The reason why transfer attempts will revert is because upon each transfer the Nouns contract reduces the sender’s voting power by one, and since Bob is already at zero, that is an invalid operation (an underflow error).

The conditions under which this can happen:

• You delegate to an EOA account (only EOA accounts can use delegateBySig because it requires a signature with a private key).

• That EOA account has at least one Noun that it owns.

For more technical information see the last section of this post.

Important takeaways

The obvious case to worry about is delegating to people you do not trust, who might want to grief you. However, even if you trust your delegate’s intention, they might be subjected to a phishing attack or some other hack, and their attacker might perform these actions to grief you.

Unfortunately, the NounsToken contract is not upgradeable, so we cannot fix the bug directly, instead we must work around it. The fact that smart contract delegate accounts cannot participate in this attack is very useful.

For now, the safest bet is to delegate to smart contract accounts only. Ask your delegates to create a Gnosis Safe account and delegate to them there. Until then if you are not sure what to do, delegate back to your Noun owner account.

For the long term, there are a few design options we’re exploring for how to mitigate this attack vector with a less cumbersome user experience. We will share more information in an upcoming post.

That’s all for the high level summary. You can find additional technical information below.

Thanks,verbs ⌐◨-◨

Technical details

For those of you who made it this far and care to know exactly how this attack works, here’s a deeper dive.

The main function to understand is _moveDelegates which is called every time a noun is transferred or when a noun owner account delegates to any other account. See the function code below.

Let’s follow the story above from a more technical point of view.

When a noun is bought on auction, it is first minted to the auction house. Minting looks like a transfer from address zero to the recipient. If you follow the code you’ll notice that there’s a special condition regarding address zero that skips the voting power update code for any source or recipient that is address zero. So when a noun is minted, a new voting power unit is created and added to the auction house’s voting power balance (this happens in the _writeCheckpoint function).

When Alice and Bob bought their respective nouns, the _moveDelegates function ran again, this time deducting one vote from the auction house, and incrementing the buyer’s voting power by one vote.

When Alice delegated to Bob, this function ran again, this time writing a checkpoint for Alice saying she has zero votes, while giving Bob one more vote, for a total of two (srcRep would be Alice, dstRep would be Bob, and amount would be one, equal to the voting power Alice owns).

When Bob used delegateBySig and provided the zero address as the delegate, srcRep was Bob, and dstRep was address(0). Notice how the first part of _moveDelegates that updates srcRep votes executed, while the second part that updates dstRep votes did not execute because dstRep was address(0) – this is the key moment in the attack vector. The result of this transaction is that a vote was deducted, never to be added again. The total number of votes represented in all the latest checkpoints combined are now one short of the Nouns NFT total supply.

At this moment in time it’s not obvious that Alice should suffer from the situation. In theory, if Bob does nothing else, Alice can still pull her delegation from Bob and her noun wouldn’t become a zombie; in that case it would be Bob’s noun that becomes a zombie.

The crux of the griefing is when Bob immediately after delegating to address zero, also transfers his noun to a different wallet; in this action _moveDelegates runs again, decreasing Bob’s vote count from one to zero, and increasing Bob’s new wallet’s votes to one. This is another side of the bug; in valid delegation scenarios when Bob delegates to Charlie and Bob transfers a noun they own, a vote is deducted from Charlie’s votes, since that is in fact where Bob’s noun’s vote resides. In our address zero buggy scenario, due to how the view function delegates is implemented, address zero is a magic value that assumes an account is its own delegate, so from the code’s point of view Bob is his own delegate, not address zero, and so Bob’s vote count is decreased.

Remember, Alice is still delegating to Bob, while Bob has zero votes. If she tries to undelegate from Bob, _moveDelegates is called where srcRep is Bob and dstRep is Alice, and the line that calculates srcRepNew will revert with the underflow error you can see in the code, because it would be attempt to run the calculation 0 - 1 on an unsigned integer.

The same problem arises if Alice tries to transfer her noun to a different account. The function _beforeTokenTransfer is executed, and in it again _moveDelegates is called, moving votes from Alice’s delegate, Bob, to the recipient’s delegate, which by default is the recipient account itself. And so again the code is run with Bob as srcRep, and we hit the underflow error.

At this moment again, it’s not entirely the case that Alice’s noun has to get stuck in her wallet with no voting power. If for whatever reason Bob buys another noun, or any other noun owner delegates votes to Bob, Bob’s votes go above zero again, and Alice then has the opportunity to undelegate or transfer her noun elsewhere. The problem of the zombie noun would then transfer to whichever noun remains owned by or delegated to Bob.

Nouns Token relevant code snippets

function _moveDelegates(
    address srcRep,
    address dstRep,
    uint96 amount
) internal {
    if (srcRep != dstRep && amount > 0) {
        if (srcRep != address(0)) {
            uint32 srcRepNum = numCheckpoints[srcRep];
            uint96 srcRepOld = srcRepNum > 0 ? checkpoints[srcRep][srcRepNum - 1].votes : 0;
            uint96 srcRepNew = sub96(srcRepOld, amount, 'ERC721Checkpointable::_moveDelegates: amount underflows');
            _writeCheckpoint(srcRep, srcRepNum, srcRepOld, srcRepNew);
        }

        if (dstRep != address(0)) {
            uint32 dstRepNum = numCheckpoints[dstRep];
            uint96 dstRepOld = dstRepNum > 0 ? checkpoints[dstRep][dstRepNum - 1].votes : 0;
            uint96 dstRepNew = add96(dstRepOld, amount, 'ERC721Checkpointable::_moveDelegates: amount overflows');
            _writeCheckpoint(dstRep, dstRepNum, dstRepOld, dstRepNew);
        }
    }
}

function _writeCheckpoint(
    address delegatee,
    uint32 nCheckpoints,
    uint96 oldVotes,
    uint96 newVotes
) internal {
    uint32 blockNumber = safe32(
        block.number,
        'ERC721Checkpointable::_writeCheckpoint: block number exceeds 32 bits'
    );

    if (nCheckpoints > 0 && checkpoints[delegatee][nCheckpoints - 1].fromBlock == blockNumber) {
        checkpoints[delegatee][nCheckpoints - 1].votes = newVotes;
    } else {
        checkpoints[delegatee][nCheckpoints] = Checkpoint(blockNumber, newVotes);
        numCheckpoints[delegatee] = nCheckpoints + 1;
    }

    emit DelegateVotesChanged(delegatee, oldVotes, newVotes);
}

function _beforeTokenTransfer(
    address from,
    address to,
    uint256 tokenId
) internal override {
    super._beforeTokenTransfer(from, to, tokenId);

    /// @notice Differs from `_transferTokens()` to use `delegates` override method to simulate auto-delegation
    _moveDelegates(delegates(from), delegates(to), 1);
}

function delegates(address delegator) public view returns (address) {
    address current = _delegates[delegator];
    return current == address(0) ? delegator : current;
}

Since our last update on Nouns Governor we’ve been working on speccing and implementing the design described as “Approach 1: Delegation NFTs”. While working on the proposed design for $nouns and soliciting feedback from Nouners (thanks 9999!) we discovered a flaw in the Nouns Gov design we were working towards.

The flaw enables an attacker to use the voting power of swappable Nouns sitting idle in a contract. We describe it in detail below.

All the solutions we could come up with to mitigate this attack require the Nouner to deposit their Noun(s) in a new contract, which is a requirement we were hoping to avoid.

If we choose to accept this requirement, then we think there’s a simpler design which enables granular delegation, without switching to an NFT based voting approach. We will describe it in a followup post.

Removing checkpoints

When switching to NFT based voting we decided to not use the voting power checkpointing system used today. Voting by NFT eliminates the ability to double vote with the same token because we record each time an NFT is used to vote.

Unfortunately, removing the checkpoints also opens up a new attack vector.

The attack

Setting up the stage:

• A contract (pool) holds 20 Nouns and enables permissionless swapping.

• This could be the case with the proposed $nouns contract for example.

• A Nouns proposal is up for voting.

Attack steps:

1. The attacker has one Noun; they vote with their Noun.

2. They swap their Noun with a Noun from the pool; they use the pool Noun to vote as well.

3. Repeat for all the Nouns available for swapping in the pool.

This enables the attacker to use the voting power of the Nouns in the pool as their own. This attack is not possible today because the Nouns contract keeps checkpoints of the voting power of each account at each block. Unless the attacker buys more Nouns, their swapping with the pool can only give them a single vote, because they can only hold a single Noun per block.
Unfortunately, the Nouns contract does not keep track of which account controlled which Noun in its checkpointing system, and the contract is not upgradeable, so the most straightforward solution - having said tracking native to Nouns token - is not possible. We detail below the alternatives we’ve come up with so far.

Possible mitigations

Checkpointing NDT ownership

One of the ideas we were exploring as a mitigation to this attack was to have checkpoints for Noun Delegation Tokens (NDTs). NDTs are one-to-one NFTs which a Nouner can mint to delegate their voting power of that Noun to someone else. Any time an NDT changes ownership, we would record the block. This would allows us to answer the following question in the contract: was this user the owner of this NDT when this proposal’s voting started?

Unfortunately this does not solve the problem. One could perform a similar sequence to the one above, just before a proposal’s voting starts:

1. Swap their Noun with a Noun from the pool.

2. Mint themselves an NDT.

3. Repeat for all the Nouns in the pool.

This ensures that they will be the owner of all the NDTs at the proposal’s snapshot block. The only scenario in which this wouldn’t be the case is if another attacker backruns them and does the same thing. In any case, the problem remains.

The root of the problem is that we can’t hook into Nouns transfers. And since the Nouns token contract is not upgradeable, we can’t add those hooks either.

Storage proofs

We could use storage proofs to prove that a Noun was owned by a specific account at a specific block; federation.wtf does something similar. Besides the additional complexity of requiring users to generate these proofs, it would probably also require relying on a third party to have access to historic block hashes. This level of complexity is not a good fit for the core governance contracts.

Depositing Nouns in custody

We could keep track of Nouns transfers if we require users to deposit their Nouns into a custody contract. This would allow us to keep ownership info checkpoints at the Noun level, and not just the NDT. For example, we could create a “WrappedNoun” contract (similar to wrapped punks). In this WrappedNoun contract, we could keep track of the owner per block.

The main drawback here is that Nouners would have to deposit their Nouns into a new contract, which is something we were hoping to avoid.

In the solution space of depositing Nouns in custody there’s another possible solution we’re currently exploring. We could have a delegator contract which keeps each of your Nouns in a separate custody wallet. This would allow you to delegate each Noun to a different address. One advantage of this solution is that it doesn’t require any changes in the current governor contracts. We’ll publish another post describing this solution in detail soon.

Next steps

We aren’t happy with any of the solutions we came up with so far. We think this issue is risky enough to be a showstopper for the Nouns Governor design. We will soon publish a design for granular delegation that works with the current governor contract. If you think differently, or if you have other solutions in mind, we’d love to hear from you.

We will start a conversation about this in the new nouns-protocol channel on farcaster. We are experimenting with using rounds.wtf to incentivize and reward good ideas & feedback.

Client Incentives is a new mechanism for Nouns to pay clients (frontends) for interactions they facilitate between users and the Nouns protocol.

For more details please read our blog post about it.

As of today, the rewards have no been activated yet. They will be once another DAO proposal goes through to configure and enable them.

I have a frontend for Nouns, how do I join?

1. Register a clientId

Call the registerClient function of the Rewards contract.

This function expects these parameters:

• name: what is the name of your client? e.g. camp

• descriptor: a short description of your client, ideally a URL

After calling this function, a new Nouns Client Token NFT will be minted to you. The ID of that NFT is your clientId. You will need to send your clientId in order to get attribution and get rewards.

Currently you can use it in the following functions:

• NounsAuctionHouse: createBid(nounId, clientId)

• NounsDAO:

  • castRefundableVote(proposalId, support, clientId)

  • castRefundableVoteWithReason(proposalId, support, reason, clientId)

  • propose(targets, values, signatures, calldatas, description, clientId)

  • proposeBySigs(proposerSignatures, targets, values, signatures, calldatas, description, clientId)

The NFT also gives you permission to:

• Call updateClientMetadata to update the name & description of your client.

• Call withdrawClientBalance to withdraw your rewards.

2. Collect rewards

If your clientId was used in any of the functions mentioned above, then you may be eligible for rewards.

In order to reduce gas costs on the DAO functions, rewards are only updated when someone calls the following functions on the Rewards contract:

• updateRewardsForAuctions

• updateRewardsForProposalWritingAndVoting

Gas is refunded for these calls as long as the contract is holding enough WETH.

You can check your balance to see if you have any rewards to withdraw by calling clientBalance with your clientId.

3. Enable withdrawals on your clientId

To withdraw your rewards, your clientId needs to be approved for withdrawals. We added this step to reduce the risk of bad actors trying to abuse the system.

Clients can be approved only via DAO proposals. To get your clientId approved, create a proposal in which the DAO invokes the Rewards contract with the following function:

• setClientApproval(clientId, true)

4. Withdraw rewards

Once your clientId has been approved for withdrawals, call the withdrawClientBalance(clientId, to, amount) function to withdraw your rewards.

If you have any questions, feel free to reach out to us on farcaster: @el4d & @davidbr

Client Incentives is a new mechanism for Nouns to pay clients (frontends) for interactions they facilitate between users and the Nouns protocol. In our previous post we described the goals and direction we’re exploring with client incentives. If you haven’t read it, please do. In this post, we’ll describe the scope for the first version we plan to release.

A short recap of the goals of client incentives:

• Incentivize the existence of multiple frontends for the nouns protocol

• Create a clear compensation structure for building and maintaining a frontend

• Allow sunsetting nouns.wtf’s protocol interactions without disruption

The Client Incentives mechanism measures a client’s contribution only based on generated calls to the Nouns smart contracts. We don’t think it’s a complete way to measure contribution, but good enough for some automatic compensation. We think Nouns should keep funding/retro-funding clients for other contributions and innovations as they happen.

Interactions rewarded in V1

In V1 the following interactions will be rewarded:

1. Creating proposals

2. Voting on proposals

3. Bidding on auctions

We chose not to include the following interactions in V1:

• Forking: since it’s a pretty rare event, compensating based on usage is probably not the right way to guarantee support. We suggest that for the time being, the foundation maintains forking support on nouns.wtf and the DAO allocates budget for maintenance as needed.

• Delegation: it’s less obvious how to prevent gaming with delegation so we decided to postpone it for now.

• Settling auctions: there are currently other incentives for settling auctions, mostly for picking specific traits for the next minted noun (e.g. FOMO, nounscout.wtf).

• Updating proposals: we expect clients that build tools for creating proposals will also be expected to support updating proposals.

• Proposal candidates: candidates are rewarded once they become proposals via `proposeBySigs`. We think that may be sufficient for V1.

Reward structure

At first we wanted to use a pay-per-use reward structure. Meaning, for every time a smart contract was called via a client, the client would get rewarded. The main benefit of this approach was simplicity, both conceptually, and technically.

Thanks to feedback we received on our previous post, we decided to change the rewards to all be defined as a percentage of auction revenues; this has two benefits:

• Incentive alignment between clients and the DAO for auction revenue to increase

• Easier to budget a % of income than pay-per-use which is less predictable

For auctions, the client which facilitated the winning bid will be entitled to a percentage of that auction’s bid.

For creating & voting on proposals the process is slightly more involved; Proposals are rewarded periodically. A percentage of all auction revenue in that period is used as the reward pool which is split between clients based on usage of proposal creation and voting. Proposals are only eligible for rewards if a minimum % of voting supply voted For the proposal. This is meant as an anti-spam measure.

The DAO has the following main parameters to configure:

1. percentRewardAuctions: % of auction revenue rewarding auction bidding

2. percentRewardProposals: % of auction revenue for rewarding writing proposals

3. percentRewardProposalVotes: % of auction revenue for rewarding votes

For more detailed description, please review the spec.

Who can participate?

We want to start permissionless, meaning that anyone can register themselves as a client. We hope this will lower the friction for building a client and being rewarded. Any developer can build a client, register themselves, and immediately start getting paid if they get usage, without the need to put a proposal for funding.

If we see there’s abuse of the system, e.g. trying to get rewards for yourself or using rewards to pay users to use a specific client, we will change the system to either be permissioned or have some ability to punish misbehaving clients.

L1 vs L2

We’ve considered implementing this contract on an L2 to reduce gas costs. Specifically we’ve explored Axiom’s ZK Coprocessor as a way to read mainnet storage state from an L2. While Axiom’s platform is very powerful, at the moment it seems to not yet be a good fit for our needs. Specifically, the limitation on the number of datapoints that can be verified in a single call forces the solution to be more complex than we’d like. There’s a lot more technical details here to explain which we’ll consider expanding on in a separate post if there’s demand for it. The main reasons we chose to stick to mainnet for this version are:

• The L2 solution is significantly more complex resulting in longer shipping time as well as technical dependencies.

• Axiom’s V2 is not live yet on mainnet and L2s.

• The associated costs with using Axiom were not trivial to calculate given the complexity of the required solution.

We’re hoping that by the time we’re working on the next version of client incentives it will be on an L2, but for now we’re staying on mainnet.

Next steps

If you have any questions, please check the spec for more details. If you still have questions, feedback or suggestions, please reach out!

In the meantime, we’re developing the contracts based on the spec mentioned above. Besides the side contract used for rewards, we will need to upgrade core contracts:

• AuctionHouse: will be upgraded to record historic prices as well as the winning bid clientId.

• DAOLogic: will be upgraded to record the clientId used for proposals & votes.

We will do an audit for these changes and propose the upgrade to the DAO.

Once deployed, the DAO will need to fund the side contract, and decide on what percentage of the auction’s revenue to dedicate to each of the rewards.

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.

The griefing attack

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.

Potential solutions

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.

Automatic vote-based blacklisting

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.

New problems and possible solutions

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.

Manual blacklisting

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.

New problems and possible solutions

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.

Conclusion

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 ⌐◨-◨

We messed up but got lucky, and we worry this might happen in other projects. We wanted to share a short retrospective and some mitigation ideas, hoping to help others avoid such mistakes in future.

The issue in detail

If you’re not interested in the technical details of the issues, feel free to skip this section.

A bit of context to help understand the issue:

• A key change in this project added a minority protection mechanism to Nouns DAO, which lets a minority group fork off to a new instance of Nouns DAO; let’s call those fork DAOs.

• Forks DAOs come with a classic ragequit mechanism, allowing a token holder to quit by giving up their token(s), and receiving their fair share of the fork DAO’s treasury.

• One’s fair share of the treasury can include ETH as well as ERC20 tokens. The ERC20 tokens sent upon quit are set in a whitelist configured by the DAO.

Now we can talk about the original medium issue Spearbit found (issue 5.2.16). The gist is:

• If there is a malicious majority of token holders in the fork DAO.

• Then they can pass a proposal to change the whitelist of ERC20s, to include faulty addresses, such that the quit function always reverts.

• Thereby disabling the quit function for all other fork DAO members.

We followed the auditors’ recommendation and submitted a change that allows token holders to specify a subset of ERC20s to receive when they quit. The change was approved during the mitigation review process.

The critical issue we accidentally introduced, and was caught by code4rena (issue H-01), allows fork DAO members who quit to steal tokens by submitting duplicate ERC20 contract addresses to the modified quit function.

How did this happen?

The flaws in our approach

We felt under significant pressure to ship fast; many DAO members were impatient to have this version live. Since our north star is serving the needs of the DAO, we took that pressure to heart, perhaps more than we should have. We were rushing this version forward way more than we would have without that pressure.

This rushing sentiment played a key role in other aspects mentioned below.

Mitigation review

Spearbit’s audit process included a two-week fix period during which the audit team is available for up to two business days, to review fixes we submitted for issues they found. It was during this period that we introduced the critical issue that was missed.

In hindsight, we relied too heavily on the mitigation review. We advise protocol teams to carefully consider every fix, and to not regard time-limited mitigation reviews with the same trust as the primary audit period.

We would like to invite Spearbit to share their learnings with us and the broader community; what could have been done differently?

Signal to noise in issues found

One of our assumptions going into an audit with a reputable org like Spearbit is that we won’t need to review & respond to many minor issues. However, this wasn’t the case.

A lot of our time was spent discussing why we think certain issues are not interesting to us.

Specifically, there were multiple occasions where medium-severity issues assumed that a DAO could pass visibly malicious proposals. Quoting from the report:

While the governance process gives an opportunity to detect and block such malicious proposals, the assumption is that a malicious majority can force through any proposal, even a visibly malicious one. Also, it is not certain that all governance proposals undergo thorough scrutiny of security properties and their impacts. Token holders need to actively monitor all proposals for malicious updates to create, execute, and join a fork before such a proposal takes effect.

While we agree with the general statement, this is an issue with DAOs at large, and the forking feature introduced is actually a way to help mitigate this risk.

These kinds of issues are labeled as medium-severity due to Spearbit’s risk classification matrix:

Low likelihood x High impact = Medium severity.

Because the lowest likelihood level is low, any high-impact issue, no matter how unlikely, is classified at Medium severity.

We recommend adding another level of likelihood below “low” such that: very low likelihood x High impact = Low severity.

Another reason we chose to fix certain issues was so they wouldn’t get flagged during the subsequent code4rena audit. In hindsight, it would’ve been better to leave them as is and mark them as “known issues” for the second audit.

Fixing medium severity issues might not be worth the risk

Making changes to critical areas of the protocol at such a late stage of the development cycle, especially while trying to meet deadlines, might not be worth the risk.

Fixes introduced at this stage will probably not get the same level of testing and attention they require. Knowing that, it may be better to leave some fixes for a future version.

For this reason, we decided to leave some of the issues found in the code4rena audit unfixed for now.

What can we do to improve?

Protocol teams, do your best to allocate ample time for audits, and help your devs feel safe to optimize for quality and less for deadlines. Mistakes during this period can be very costly. And don’t feel like you have to fix every issue; if it’s not a must, err on the side of letting it go for now.

The labeling of issues by severity is useful for understanding which issues should be fixed, but it does not provide the whole picture. When deciding whether an issue should be fixed, the complexity of the potential fix is an important consideration. For example, a medium-severity  issue, with a trivial fix, should probably be fixed. On the other hand, if a non-trivial fix is recommended, more careful assessment is required on whether the fix is worthwhile, and what kind of review or follow-up audit should be done.

We think that auditors could provide more guidance on which issues they recommend fixing. For example:

Issue: Some issue with proposal creations
Severity: Medium
Potential Fix: Change the rules for how a proposal can be created
Recommendation: Don’t fix in this version due to high complexity. Consider fixing in future protocol versions with additional audits.

Perhaps auditing teams can check in with their clients during the audit and ask if they are happy with the signal-to-noise ratio. If the clients are experiencing fatigue, it seems very important to pause and discuss how to improve; the mid-audit client experience seems underrated.

Specifically for DAO audits, audits can be much better if there’s early alignment on how to treat all issues that start with a malicious majority assumption; we suspect most protocol teams will prefer to spend very little time on those issues.

Above all, let’s have more public conversations about the auditing experience from both sides and continue iterating on making it awesome.

Thanks for reading,

verbs ⌐◨-◨

This activity is problematic for Nouns because it blocks long-term-aligned participants from acquiring Nouns and contributing their energy, capital, and perspective to the project. Additionally, this process ‘leaks’ a portion of the DAO treasury to arbitrageurs at the expense of future proposers.

In this post we’d like to show how specific DAO parameter changes and activities can affect arbitrage in Nouns DAO auctions and help us get back to a place where we can attract one new long term member every day.

First, some quick definitions:

Fork Threshold

The % of the circulating (not including DAO-owned Nouns) Noun supply that’s required to exit to a new instance of Nouns DAO.

Book Value

The amount of ETH (and other assets) that a Noun NFT would bring with it upon forking to its own instance of Nouns DAO.

Arbitrageur (arber)

While not arbitrage in the purest sense of the word, Nouns DAO arbitrageurs are attempting to buy Noun NFTs in the daily auctions and exit them to their own instance of Nouns DAO with their pro-rata share of the treasury. Once in control of their own instance of Nouns DAO, they will withdraw the treasury ETH, hopefully earning more than they bid in the primary DAO auctions.

Natural Demand

The prices long-term Nouners are willing to bid to win Nouns auctions. At the time of this writing natural demand almost always loses auctions to arbers.

How an Arber Might Think

Arbers bid to make a profit. To do so, they attempt to predict the eBV (expected book value) at the time the next fork event will occur and win Nouns auctions below their eBV, leaving them with a profit margin.

To decide if and how much to bid, arbers ask themselves (1) when will the next fork happen, and (2) what will BV be at fork time (eBV).

When the next fork happens is affected by variables like: the fork threshold and adjusted total supply, which together tell us how many nouns must escrow to initiate a fork; and how many nouns are already held by arbers who intend to fork.

What will BV be at fork time is affected by variables like: auction revenues; predicted spend rate; and predicted DAO-owned nouns distribution.

We have a simplified spreadsheet model you can clone and play with, to better develop your arb intuitions.

With this understanding of how an arber might think, we can switch to the Nouner perspective, explore how Nouners can affect the arb game, and what Nouners might want to do to best serve the project.

How Nouners Can Change the Arb Game

The main problem we’re hoping to solve: not enough auctions are won by long-term players.

As long as eBV is greater than natural demand, arbers will continue to dominate auctions. We expect eBV to reach natural demand one way or another, and then we expect to see a growing portion of auctions won by long-termers.

Yes, eBV (and BV) is trending in the direction we think solves the problem. However, we think it’s too slow and too much value is leaking to arbers until we get there.

Nouners can change the arb game for the better. Let’s look at a few key variables and how they affect the arb. After that we discuss possible directions and their potential implications.

Spend the treasury

As long as Nouns DAO controls funds that sum up to BV being greater than natural demand, we expect arbers to continue their efforts to extract ETH from the treasury, either through forking or through malicious proposals.

Various poison pills like buying a Punk or sending funds to a timelock smart contract can certainly hurt the arb via forking; however we advise against such tactics as they grow the incentive to mount a majority attack.

The only way out is through. Spending on proposals is the safest most effective anti-arb strategy. Worth noting Nouners have been successful at decreasing BV through proposal spending ever since the last bull market ended.

Arbers are tracking the DAO’s spend rate. If they believe Nouners intend to accelerate spending, we expect lower auction bids due to a lower eBV.

Distribute Nouns

BV is the treasury value divided by the number of nouns in circulation, i.e. not owned by the DAO. Therefore distributing DAO-owned Nouns to any recipient other than the DAO dilutes BV. If arbers see more nouns distributed, they will predict a lower eBV and therefore bid lower.

At the time of this writing, adjusted (circulating) supply is 370, while the DAO owns 532 Nouns (303 treasury + 229 escrow). If the DAO were to distribute all its Nouns today, BV would immediately shrink by a factor of ~2.4x.

However, we don’t think this is a meaningful lever to impact the arb because realistic distribution rates seem to have a negligible effect. For reference, since fork 0 ended on September 15th, 12 nouns were distributed (including 3 to the PropHouse round) in 53 days, making the rate 0.226 nouns per day.

Change fork threshold

In the context of the arb game, it’s most useful to translate fork threshold into the number of auctions or days until the next fork becomes possible or likely.

We think this is the most interesting parameter to discuss, since it’s a simple configuration change that can have dramatic effects. To further develop intuitions on Fork Threshold, let’s discuss what might happen with a high vs zero threshold.

What might happen if Fork Threshold is much higher?

A longer time to fork makes eBV harder to predict, so arbers will bid lower to account for the added risk. Nouners can use higher threshold values to push arber bids down as a way of getting closer to natural demand.

A greater threshold leads to arbers holding a larger number of votes they will likely use to vote against most spending proposals, as we’ve seen before fork 0, in an attempt to preserve BV. It’s not all bad as it gives good reason for dormant voters to engage or delegate.

If Fork Threshold is raised and we continue to see arbers accumulating nouns, it might need to be raised again until we’re convinced eBV has met natural demand.

After a few months BV should catch up with eBV and natural demand, making it safe to lower Fork Threshold again to provide better minority protection.

And what if Fork Threshold is much lower?

A very low threshold provides arbers with high predictability and little time delay, making it rational for arbers to compete with each other up to a small profit margin. In other words, you should expect auctions to settle just short of BV at auction time.

A positive aspect is that per auction the treasury value leak becomes minimal, meaning Nouners can feel a lesser sense of urgency to spend BV down (some urgency should remain in order to meet natural demand).

The main downside is arbers are likely to continue dominating the auctions a while longer, until other factors like spending on proposals push BV down to where natural demand is able to compete with arbers.

Another concern is DAO potentially spending significant amounts of time in forking periods, unable to execute proposals. We may need to consider introducing a short cool down period between forks to ensure the DAO has time to execute proposals.

Example model tinkering

Let’s look at four configurations with different Fork Threshold and daily spending values.

Notice the big difference in time to fork between Fork Threshold at 10% vs 30%; this results in the big eBV difference we see between spending 30 ETH vs 90 ETH daily.

Let’s run a similar comparison, varying Fork Threshold and daily nouns distribution values.

Nouns distribution makes little difference to eBV at 10% Fork Threshold, while at 30% threshold it’s a bit more interesting. Still we maintain this lever isn’t cost-effective as a means of lowering eBV; it’s still an interesting activity for other reasons like growing Nouns’ network value.

A visual model

At some point we dreamed this post would be an exciting interactive page like the famous NYTimes infographic articles. Instead we have the simplified sheet above, as well as a more visual and interactive model below. We might post improved models if this version isn’t useful enough.

In this visual model we chose Fork Threshold for the X axis, as it seems like the most interesting parameter for Nouners. The Y axis is eBV, the variable Nouners probably want to push down to let natural demand win Nouns auctions.

The model lets you change the values of all other parameters and see their direct impact on the relationship between Fork Threshold and eBV. For example, try increasing spend rate and see how eBV declines much faster, or increase the number of Nouns already intending to fork, and see how eBV increases.

Conclusion

Right now 90%+ of auctions are won by arbitrageurs. As long as the ability to fork is a feature of the DAO, we would not expect arbitrage activity to ever reach zero.

So what can Nouners do?

• Iterate on high fork threshold values until eBV meets natural demand; run frequent reassessments until successful or a new approach is discovered.

• Lower fork threshold to zero (w/ upgrade) and let arbers compete on smaller margins, taking longer to spend BV down and accepting the reality of almost zero new long-term players joining via auctions.

• Change nothing. The current spend rate might be sufficient; a daily/monthly spending Dune dashboard is a critical missing tool to continue the conversation.

• Disable the fork, but we won’t elaborate on this option.

We believe that a good near-term milestone is seeing 50%+ of auctions won by long-term Nouners. The best way we have thought of so far is the high fork threshold coupled with fast-enough spending and ongoing analysis.

Please let us know if this breakdown was helpful, if any additional questions arise, and how might we make it better.

Thanks!
the verbs ⌐◨-◨

Like any other protocol, Nouns DAO relies on clients (webapps / mobile) to interact with its smart contracts. There are many reasons for the DAO to benefit from having multiple clients available, to name a few:

• Redundancy of clients reduces risk of technical issues limiting access

• The ability to sunset or stop developing nouns.wtf which is currently being maintained by Nounders

• Gives space for new clients to emerge, including specialized clients like a proposal builder

Currently nouns.wtf is in an awkward place where it’s still probably the most popular client, but at the same time it’s not being actively maintained. It’s also not entirely clear how decisions are made on what can be added to the site.

We want to propose a model where clients get paid by the DAO based on usage. By usage we mean interactions with the smart contracts such as bidding on auctions, creating proposals, and voting. This is similar to the way Liquity incentivizes frontends with “kickbacks”.

We hope this will create the following incentives:

1. Incentivize clients to provide great UX (and do some minimum marketing) to drive more usage to their apps.

2. Incentivizes clients to solve for all the interactions the DAO pays for (and we can pay more for interactions with insufficient coverage).

3. Incentivizes clients to keep up with DAO upgrades, so they remain functional and continue to be used.

The simplest way this can work is by adding a client parameter to the function calls, e.g.:

castVote(proposalId, support, reason, client) where client is the wallet address of the client that facilitated this transaction.

Diving deeper

Let’s discuss the key interactions we think are worth paying for, how they could be paid, and how to make sure they can’t be gamed.

Bidding on auctions

How to mitigate gaming?

We don’t want to pay for every createBid call because that can be easily gamed by making many low value bids. One way to get around it is to only pay for the interaction of the winning bid.

Options for calculating payouts

• Fixed percentage of the auction settlement amount.

• Fixed ETH amount.

• Other options you think make sense? Please let us know

Creating proposals

Having great proposal creation tools is important, supporting good previews, different transaction types, etc.

How to mitigate gaming?

We don’t want to pay for every proposal creation because it may incentivize people to create spam proposals just to get the payment.

A few options on how to avoid it:

• Only pay for successful proposals that get executed.

• Only pay for proposals that pass quorum.

• Let us know if you have more ideas.

Options for calculating payouts

• Fixed ETH amount per proposal.

• Fixed percentage of the amount of funding asked in the proposal. This is problematic because it creates weird incentives, and not all proposals are directly asking for funding.

• Allocate a percentage of the DAO’s income to pay for proposals created, e.g. X% of auction revenue per month is used to pay governance clients for new valid proposals (valid meaning passed anti-gaming filters mentioned above).

• Pay out disproportionately to top clients (e.g. 1st place gets 2x more than 2nd place).

Voting

How to mitigate gaming?

In order to prevent spam proposals created just for voting payments, we can use the same method as mentioned above, i.e. only count votes made on “valid” proposals.

Options for calculating payouts

• Fixed ETH amount per vote transaction.

• Fixed ETH amount per vote, i.e. if voting with 2 nouns, client gets paid double.

• Fixed ETH amount per proposal: e.g. if 1 ETH is paid out per proposal, and a proposal had 100 votes, then for each vote, the originating client gets 0.01 ETH.

Other interactions

We think the interactions listed above are the key interactions the DAO should pay for and those should be in the scope of the first iteration of this model.

Other interactions and possible payment options:

• Proposal updates (updateProposal)

  • We don’t want to incentivize updating proposals for payouts because that’s easily gamed by doing no-op updates. Perhaps it makes sense to pay the client which originated the most recent version of a proposal. If a proposal was updated, we would update the originating client for that proposal. It makes sense for clients to support both functionalities.

• Proposal candidates

  • All the interactions related to candidates have the goal of eventually turning the candidate into a Proposal via proposeBySigs.

  • Payouts for proposal creation provide incentive for clients to support all the functionality of proposal candidates.

  • Assuming this is enough incentive, perhaps the specific candidate interactions (creating, updating, signing, feedback) don’t need payouts.

• Delegation

  • Don’t have a good idea on how to prevent spam delegations for payouts. Open to suggestions!

• Forking

  • Probably makes sense for fork-related interactions to be paid for by both OG DAO and the fork DAO.

  • Probably makes sense to pay per forking Noun, whether put in escrow or joining after fork DAO creation; this allows multiple clients to contribute to a single fork event and be fairly compensated.

  • How much should be paid per forking Noun? Should it be a nominal amount, e.g. 0.01 ETH? Or should it be a percentage of BV? Any other ideas?

Avoiding fake clients

A more general way to try to game the system, is to pretend to be a client by putting your own wallet address when interacting with the DAO contracts. This gets worse if people actually use clients, but swap the client address with their own when posting transactions.

One way to mitigate this risk is for the DAO to maintain a list of approved clients that can be paid. Whenever a new client wants to be added to this list, they can put up a proposal. It also serves as a way to advertise that this client exists.

Alternatively there could be some algorithmic way to determine that a client is likely not fake, e.g. condition payout on a minimum number of interactions, from different wallets, etc.

We’d like your feedback here. Do you think it’s better to keep a list of approved clients or rather take the permissionless route of codifying some rules to identify “real” clients? If the latter, what rules do you think will work well?

Budget

How much would the DAO need to pay to make it worthwhile for teams to develop clients?

We invite existing client teams to share some stats of their development and maintenance costs. Based on these numbers the DAO can pick some reasonable amounts to set as payouts.

Technical considerations

We wanted to share some interim thoughts we had on how to implement this, and we welcome any feedback.

These are the requirements we had in mind so far:

1. Changing the amounts and formulas for payouts should not require an audit, i.e. should be outside the core DAO contracts

2. It should be possible to delegate the ability to change the payout scheme to a trusted multisig, e.g. Tech Grants Pod.

3. Small (ideally zero) additional gas cost for interacting with contracts.

In order to meet requirements (1) & (2), we imagine the payout being outside of the core DAO contracts. The DAO would explicitly fund this side contract via proposals.

The core DAO contracts would introduce a new client parameter in the relevant functions, which would be either an ID or a wallet address to which to send payouts.

Regarding gas costs, we considered some methods that wouldn’t require writing to storage during the interactions:

1. Send a message to an L2 with the client id and interaction details; write it to storage on L2; payout calculation and disbursement on L2.

2. Use storage-proofs to provide evidence of the client ids to a contract on mainnet or an L2.

Both of these options add a certain degree of complexity and dependency on third parties.At the moment we’re leaning towards keeping everything on mainnet if it’s not too gas intensive.

For those interested, see a rough estimate for gas costs at the bottom of this post.

What’s next?

Please share your thoughts and feedback with us. Any ideas on better economics or technical solutions are very welcome.

We’re currently leaning towards implementing everything on mainnet for simplicity. Let us know if you think there’s a better way.

We want to hear your feedback before we move on to implementation:

• Do you think our ideas to mitigate gaming are good? Should the DAO keep a list of approved clients? Do you have better ideas?

• We plan to deploy everything on mainnet. Do you think we should use an L2 instead?

• We want to focus on proposals, voting & auction bids at first. Do you think the V1 scope should be different?

• What do you think would be the best payouts schemes?

• How much would the DAO need to pay to make it worthwhile for teams to develop and maintain clients?

Appendix: gas costs

What would be the minimum gas footprint to keep everything on mainnet?

A rough estimate of the additional gas cost based on the pseudocode below:

1. AuctionHouse.createBid

   1. One expensive SSTORE* per auction (setting a zeroed storage slot). By default that would be done by the first bidder, but we could also move it to be done by the settleCurrentAndCreateNewAuction function.

   2. Subsequent bids have minimal extra gas cost

2. DAO.propose

   1. One expensive SSTORE per proposal to store the client address.

   2. The current storage layout of proposals is not optimized so we can probably “squeeze-in” the client parameter without incurring extra gas cost.

3. DAO.castVote

   1. One expensive SSTORE per client per proposal: the first vote cast from a client.

   2. This can be reimbursed as part of vote refunds, so the cost is shifted to the DAO.

*expensive SSTORE: storage write of a non-zero value into a zero slot; about 20K gas, which at 100 gwei gas price and ETH at $1600 would be ~$3.2.

Below is some rough pseudocode of the changes required in the DAO’s core contracts to save the necessary data onchain:

createBid(uint nounId, address client) {
  biddingClient[nounId] = client;
  // regular bid code continues...
}

propose(targets, values, signatures, calldatas, description, address client) {
  clientProposals[proposalId] = client;
  // regular propose code continues...
}

castVoteWithReason(uint proposalId, uint support, string reason, address client) {
  // record how many votes were cast per client, per proposal
  clientVotes[proposalId][client].votes += votes;
  // record how many voting txs were made per client, per proposal
  clientVotes[proposalId][client].txs += 1;

  // regular voting code continues...
}

Example pseudocode of a payout contract:

payoutForWinningBid(uint nounId) {
  require(!payoutDone[nounId], ‘already paid’);
  require(auctionHouse.auction().nounId > nounId, ‘auction not settled’);

  payoutDone[nounId] = true;

  // send fixed amount as payout
  // to send a % of auction settlement price, we need to store the history of auction prices, which we plan to do in the next version of auction-house
  sendETH(auctionHouse.biddingClient[nounId], PAYOUT_FOR_BIDDING);
}

payoutForProposal(uint proposalId) {
  require(!payoutForProposalPaid[proposalId], ‘already paid’);
  require(dao.state(proposalId) == EXECUTED);
  payoutForProposalPaid[proposalId] = true;

  // send fixed amount to the client
  sendETH(dao.clientProposals[proposalId], PAYOUT_FOR_PROPOSAL);
}

payoutForVotes(uint proposalId, address client) {
  require(!payoutForVotesPaid[proposalId], ‘already paid’);
  require(state(proposalId) == EXECUTED);
  payoutForVotesPaid[proposalId] = true;

  Proposal proposal = dao.proposals(proposalId);
  uint totalVotes = proposal.forVotes + proposal.againstVotes + proposal.abstainVotes;

  sendETH(client, (dao.clientVotes[proposalId][client] / totalVotes) * PAYOUT_FOR_VOTES_PER_PROPOSAL);
}

This time we’d like to share three different design directions we have in mind, with some high level details on how each direction might work. Our hope is the same as last time: to receive feedback from the community; do you have a preferred design direction? Do you think none of them are good enough?

The current focus is on how delegation information is encoded and presented. The current delegation system stores wallets and their voting power balance; in an NFT-based governor we need to store delegation information per NFT.

Other requirements and design details seem more straightforward, and we’re happy to elaborate on them in future posts.

A couple of new concepts

These are new ideas that are mentioned below in the details of the different approaches. Here’s a quick intro to what they mean to help you better imagine the alternatives at the heart of this post. Assume they are applicable no matter the approach we end up choosing.

Delegation Admin

Nouners can set a “delegation admin” wallet, giving it full control over delegation decisions; delegation admins can transfer this role to any other wallet; Nouners can revoke this role at any time.

The primary use case is holding Nouns in cold storage while managing delegations using a hot wallet.

It seems useful to also allow the delegation admin to vote with any of the owner’s Nouns that haven’t been specifically delegated. We’d love your feedback on this design dilemma.

Subdelegation

We think additional degrees of freedom could be great for the community, yet still unsure how open it should be.

We’re confident the Nouner should be able to revoke delegation rights at any time, making themselves the only valid voter. We’re still debating how delegation transfers should work.

The simplest approach is to let a Noun’s current delegate transfer their rights to anyone else.

More complex designs might include: limiting subdelegation to only one degree (Nouner -> delegate -> subdelegate); or an infinite delegation chain where any preceding delegate can revoke delegation down the line.

We’re leaning towards keeping the base design simple, while affording more advanced requirements through composition with other projects like Agora’s Alligator.

We’re excited to get lots of community feedback on this one.

Approach 1: Delegation NFTs

This approach uses a new NFT, where each token represents the right to vote and propose with the Noun bearing the same token ID. More details below.

Delegation NFT details

• It’s a new ERC721 enumerable token.

• Nouners (inc. their delegation admin wallet) can mint delegation tokens with the same IDs as the Nouns they own, and transfer them to other wallets, thereby delegating voting rights of those Nouns to those wallets.

• Nouners (and their delegation admin wallet) can burn delegation tokens, reverting back to the default state that only the Noun-owning wallet can vote.

• Nouners can transfer delegation tokens mirroring their Nouns from their delegates to any other wallet at any time; it’s akin to them have ERC721 approval from their delegates on their delegate tokens.

• Subdelegation would be simply a delegate transfering their delegation tokens to any other wallet. We could complicate the design with extra permissions if needed, as discussed in the above subdelegation section.

Stale tokens

This design is the only one that has the stale tokens property. To better understand what stale tokens are, let's explore how it works, starting with the use case of selling a Noun to someone else.

Alice selling to Bob

1. Alice delegates Noun 142 to Diva, by transfering delegation NFT 142 to her wallet.

2. Then Alice sells Noun 142 to Bob; the delegation NFT is still in Diva's wallet.

3. Diva continues to vote and propose with Noun 142 until Bob delegates it to someone else (or burns the delegation NFT).

Stale tokens can also benefit Nouners, specifically when transferring Nouns among their own wallets.

Alice transferring to a new wallet

1. Alice delegates Noun 142 to Diva.

2. Alice transfers Noun 142 to her new hardware wallet, wanting the delegation to Diva to persist.

3. Diva continues to vote with Noun 142, and Alice simply does nothing.

In today's design, and potentially the WrappedNouns design (described below), we automatically delegate upon transfer. When transferring to a new wallet, Alice would then need to submit another transaction to delegate from her new hardware wallet to Diva.

In summary, in most cases this property adds an explicit delegation step after transfers between different people, and removes a step after transfers among wallets of the same person.

How to determine a Noun's current delegate

• If a delegation NFT exists, its owner is the current delegate.

• If it doesn't exist, the Nouner wallet is the current delegate.

We're still unsure whether stale tokens should be allowed to vote or not (leaning towards yes).

Open Questions

• How should we treat stale delegation NFTs? Should the owner of that delegation NFT be allowed to continue voting until the new owner transfers or burns the delegation token? or should it be considered invalid immediately after the Noun transfer?

• How should we solve for forked Nouns?

  • They are owned by the DAO treasury and should not be participating in governance.

  • Potential solution: have explicit logic that prevents voting with treasury-owned Nouns, and allow anyone to burn treasury-owned delegation NFTs.

• How should we solve for burned Nouns?

  • Probably the same treatment as forked Nouns.

Approach 2: track delegation in Governor state

This approach is the minimalistic one, moving delegation functions from the NounsToken contract to Nouns Governor contract, and keeping track in governor contract storage state. It meets all the original motivations of NFT-based voting, without the added legibility and fun UX the delegation NFTs approach adds.

The governor contract manages delegation state, using a delegates mapping from owner wallet to tokenId to a Delegation struct; the Delegation struct stores a delegate and subdelegate addresses.

How to determine a Noun's current delegate

• Get the Noun’s current owner from the token contract.

• Check the delegates mapping of the owner per voting tokenId, if it’s not address zero - that’s the current delegate.

• Otherwise, the current delegate (or subdelegate) is the token owner.

Approach 3: Wrapped Nouns

This approach asks Nouners to wrap their Nouns in a new NFT, so that the new NFT can help meet the requirements the current immutable Nouns contract doesn’t support.

This approach can employ either of the previous two in storing and determining a Noun's current delegate wallet. It is different in that it aims to replace the current NounsToken contract in most usage, so that we gain new upgradeable hooks pre and post transfer events, to optimize user experience.

The key improvement is the ability to auto-update delegations upon transfers.

WrappedNouns details

Compatibility:

• Original Nouns are transferred to WrappedNouns, and a WrappedNoun is minted to the owner of that original Noun. There is a reverse redeem function that burns the WrappedNoun and sends the original Noun to the WrappedNoun’s owner.

• WrappedNoun art reflects the original Noun’s art.

• Nouns auction still sells OG Nouns.

• To maintain backwards compatibility with the current Governor contract, the owner can delegated their deposited Nouns to an wallet of their choice.

Delegation:

• Nouns can set a “default delegate” wallet, to which any new WrappedNoun they receive is automatically delegated.

• The rules of who can delegate and subdelegate would be very similar to approach 1; meaning we would keep track for each WrappedNoun which wallet is its delegate or subdelegate.

• The technical details of how we keep this state can vary:

  • It could be simple storage mappings in the WrappedNouns contract, or

  • It could be delegation NFTs similar to approach 1, slightly improved because we have hooks on WrappedNouns transfers; for example, upon a transfer of a WrappedNoun we could auto-transfer the relevant delegation NFT to the new Nouner's default delegate wallet.

Hooks:

• This is a technical point we haven't fully explored yet: this design allows us to deploy new upgradeable and configurable code that could run before or after each WrappedNoun transfer.

• The obvious use case is mentioned above, an improved UX when selling Nouns: to auto-delegate Nouns upon transfer per some recipient configuration, e.g. delegate all newly received Nouns to a specific wallet.

• We're hoping to hear more exciting ideas from the community.

How to determine a Noun's current delegate

• If a WrappedNoun does not exist for that Noun, the owner is the only account that can vote.

• If a WrappedNoun exists, we can take either direction:

  • Like approach 2, except the delegation mapping would be stored in the WrappedNoun contract rather that the governor contract, or

  • Like approach 1, except the WrappedNoun contract would determine the current delegate rather than the governor contract.

Open Questions

• How do we treat WrappedNouns where their backing ON Noun has been burned?

  • Probably similar to delegation NFTs, with specific logic in the governor contract to prevent voting and proposing, and allowing anyone to burn such WrappedNouns.

Noteworthy differences

• Delegation NFTs is the only design that has the stale tokens property, as discussed in detail above.

• Delegation NFTs might also be the coolest, as the only design that puts NFTs in delegates' wallets. It seems like the most composable design; for example, crypto wallets that support NFT transfers will then support delegation and subdelegation out of the box; and delegates can know which Nouns they can vote with just by looking at the NFTs in their wallet. Delegation NFT art is another open design space.

• Wrapped Nouns is the only design that can give us hooks on transfers (it's not complete because some Nouns might never wrap). Such hooks allow us to auto-delegate newly received Wrapped Nouns similar to today's token design; hooks might also be a new opportunity for great ideas and teams we haven't seen yet.

Our take

WrappedNouns feel too complex. Tracking delegation in the Governor's state feels like a missed opportunity.

Delegation NFTs feel the most exciting, as a tangible UX upgrade for Nouners, delegates and even just curious fans. This approach still has its issues, but our current gut feeling says going down this path will be worth it.

Assuming sufficient conviction in the delegation NFTs approach, we would flesh out all the open issues and share a detailed design post with everyone, to make sure the juice is indeed worth the squeeze.

What’s next?

We want your feedback. Do you have a preferred design direction? Do you think none of them are good enough? How should we approach subdelegation? What additional detail should we add to help you form your opinion?

In the meantime we’re working on additional posts, including:

• Fork V2 additional details.

• Gas comparison of the current state vs these design alternatives.

• And possibly a few more, ending with an update on final decisions.

Thank you for your attention,

the verbs ⌐◨-◨

This is the first post in a series in which we’re trying something new: to design a new Nouns DAO version in public, in collaboration with the community.

The new Nouns Governor will be our first break away from Compound Governor Bravo we’ve been relying on since day one. At its core, Nouns Governor is about NFTs voting, rather than wallets. Let’s dive into the problems NFT voting can solve, and explore the opportunities it may open up.

A bit of personal history

We started working on Nouns contracts in the spring of 2022, and in the early days of studying the code, we noticed things worked different from what we intuitively expected in an NFT DAO. The first example was that Nouners couldn’t delegate individual Nouns; to do so they have to transfer a Noun to a separate wallet and then delegate. Another example was that Nouners couldn’t override how their delegates voted, and while it didn’t seem urgent it did feel important since we knew bribe markets (e.g. Federation’s governance pools) were inevitable.

In those early days we were managed directly by the Tech Grants Pod, and shipped the new art contracts, and DAO V2 with dynamic quorum and voting gas refunds. Shortly after we started managing our backlog, and with community help decided to ship other improvements that ultimately became DAO V3, including propose by sigs and the renowned (reNouned!) Fork mechanism. The NFT voting design was on our minds, but never made it to the top of the list, until now.

Why build Nouns Governor?

So why now? Why build it at all? What changed?

The main thing is the Fork; the spark has always been minority protection from a majority attack, and say in the case of a majority passing a malicious proposal, the minority should be able to fork without the malicious majority following them into the new DAO. However we hit a technical limitation: the Nouns token contract does not store per Noun which account can vote with it in each snapshot block, so we can’t discern which Nouns should be allowed to fork and which should be blocked. Our plan is to ship NFT voting and then ship an improved Fork V2. More details on Fork V2 will come in a future post.

A much older reason is the aforementioned delegate override problem: we think token holders should be able to override their delegates’ votes, primarily from a security perspective. Governance pools make attacks potentially much cheaper than the alternative of buying Nouns. The limitation mentioned above, not knowing how each Noun voted or even who delegated to whom, is why we haven’t implemented the override to date.

For personal security, we don’t like the current constraint that Nouners must use their Noun-owning wallets to update delegations; they should be able to update delegations from their hot wallets, to minimize the risk of losing their assets.

Beyond security, there are several user experience annoyances and confusions NFT voting can improve upon. Let’s run through them.

New Nouners who buy a Noun on auction are often disappointed to discover they can’t vote on current proposals; wouldn’t it be way more delightful to allow them to participate immediately?

Snapshots are confusing for Nouns veterans as well; we’ve seen many messages expressing confusion after transfers or delegations, not being sure which wallet to use or how many votes their wallet has for a given proposal. It can and should be much easier.

We’ve also seen a proposal getting cancelled because the proposer delegated their Nouns and went below proposal threshold; we’re partially solving this with propose by sigs, because Nouners won’t have to delegate just to sponsor a proposer, but with NFT voting Nouners can propose and delegate and not have to go below threshold.

We also hope to solve several problems related to granularity: subDAOs should be able to easily split their votes (e.g. if subDAO vote on a prop is 50/50, let them split their Noun votes both ways); a whale should be able to delegate at a single-Noun granularity without transferring to individual wallets; and a whale with many times proposal threshold’s worth Nouns balance should be able to submit multiple proposals from the same wallet.

Subdelegation is another use case we’d like to enable; in many cases in Nouns there is high trust in delegation relationships, such that the token holder is happy to let their delegate further delegate their votes, whether for a specific proposal with domain expertise, or just because the delegate is going on a long offline vacation. Fun experiments are also made possible, e.g. Nouncil can have a primary wallet for all their delegations, then periodically vote to subdelegate some of their votes to individual members.

Finally, a bit on legibility. In the current state it’s hard to read onchain, e.g. with Etherscan, which account can vote with which Nouns at any given time, or how a certain Noun voted on a specific proposal. This information is available using indexers and webapps; however we think it’s even better if it’s legible with nothing but Etherscan.

But aren’t these annoying checkpoints important?

The Nounders’ decision to use Compound Bravo with snapshots was great! It allowed them to ship the project with high security and low cost. We would have done the same thing. And for ERC20 DAOs checkpoints make perfect sense, since they don’t have the non-fungibility property we can rely on.

Checkpoints were added to Compound to solve two major problems:

1. Double voting: otherwise you could easily vote, transfer your tokens to another wallet, and vote again.

2. Flashloan voting: a sequence done in a single block that costs near-zero: borrow gov tokens or borrow money and buy gov tokens on Uniswap, vote, repay the loan with a small fee.

Checkpoints prevent double voting simply by looking at a single point in time; and flashloan voting is prevented by making sure voters vote at least one block after their latest snapshot.

In NFT voting we prevent double voting easily, by storing which NFTs already voted. And we prevent flashloan voting with a minimal version of snapshots, allowing an NFT to vote only if at least one block passed since its latest transfer block.

What about other solutions?

Some of the problems we’ve outlined have been solved in different approaches, while some are more specific to NFTs and Nouns in particular. Some solutions we’re aware of:

• ScopeLift’s flexible voting, which allows a wallet holding ERC20 governance tokens submit a vote with data indicating how to split the vote, e.g. 60% For and 40% against.

• Franchiser, which allows holders of COMP-style voting tokens to selectively delegate portions of their voting power to third parties, and allows delegates to further sub-delegate.

• ZK storage proofs, can allow users to submit a proof to the DAO showing who delegated to whom at a certain block. There are several concerns with storage proofs, such as the time and compute resources to generate proofs and the gas costs of verifying proofs; however we’re curious to explore this direction down the line.

Worth noting we’re also taking time to explore other DAO projects like Llama, OpenZeppelin, Aave and others.

New possibilities

This is another less tangible reason we're excited to ship Nouns Governor; we believe the Nouns community will find unexpected ways to build cool things with it.

One example from a recent chat is that proposers could bake into their props temporary art modifications based on how Nouns vote on their prop; e.g. red.org could add custom noggles to all Nouns that vote For their proposal if it passes, and then send them a physical copy of those custom noggles.

Please reach out if you have other cool ideas!

What’s next?

We want your feedback. Do you find this direction interesting? What are we missing?

In the meantime we’re working on additional posts, including:

• NFT voting designs: should we have a delegation NFT? should we wrap Nouns in a new token? or keep it super simple?

• Gas comparison of the current state vs the potential designs.

• Fork V2 additional details.

• And possibly a few more, ending with an update on final decisions.

Thank you for your attention,
the verbs ⌐◨-◨

This is a quick analysis we composed with the help of community members, to try and make more tangible sense of wag’s original post, and feedback on twitter these past few weeks.

Our hope is this analysis will help voters in their decision making and discussions.

We’re available for any feedback, and especially to any corrections or additions community members think we should make. Find us on twitter @davidbrai and @eladmallel.

TLDR

• Different calculation approaches boil down to the analogy of dilutive purchase of shares at current valuation on auction (see below).

• Implementation feels feasible, no need to agree on the exact approach now (gut leans towards explicitly allocating shares on auction settlement to make it super explicit).

• To do this well the DAO would need to value all its assets in ETH, requiring oracles for every asset it holds or wants to hold - adds complexity to new assets, which might incentivize the DAO to hold fewer assets and avoid NFTs.

• Nounder rewards: give those nouns zero shares or allocate them shares per some average (see more below); it's a political decision, technically not hard.

• Splits voting and financial shares, creating new incentive risks that require further research.

• Feels legally concerning at initial gut reaction; legal advice needed.

Step-by-step example

• Assume the treasury currently has 990 ETH.

• New auction is settled, Alice bought a noun for 10 eth; Treasury now has 1000 ETH.

• At this exact moment, if Alice ragequits, she should get 10 ETH.

• Then say the DAO spends 10% of its funds, and now has 900 ETH; all nouners’ redeemable value should be reduced by 10%. Alice’s redeemable amount is now 9 ETH, so she maintained her 1% redeemable value.

• Then say Bob buys a Noun on auction for 10 ETH; Treasury now has 910 ETH.

• Bob’s redeemable value is 10 ETH, which is 1.0989011%.

• Alice’s redeemable value should still be 9 ETH, which is now 0.989011%.

Analogy to acquisition of shares at current valuation

• Another way to model this, is that each time a noun is sold on auction, it’s like a fund raise at current valuation.

• Let’s imagine Nouns have shares, call them NS (Nouns shares).

• Whenever someone buys a Noun on auction, new shares are allocated to that Noun, proportional to its auction’s ETH contribution to the treasury.

• So if the treasury currently has 990 ETH and there are a total of 1M NS created, and Alice buys a new Noun for 10 ETH, Alice would get 10101.01010101 NS.

• Alice’s share of NS determines what % of the treasury she can redeem.

• Somewhat similar to tokenized vaults (EIP-4626).

Key problem: valuing all assets in a unified denomination

• If the DAO has assets other than ETH, as is currently the case with stETH and soon rETH, we need a conversion rate oracle to know what the value of the treasury denominated in ETH.

• If the DAO buys an NFT, it also needs to be able to be valued in order to determine the new ETH contribution to treasury value.

• In other words, if we want to evaluate the ETH contribution from an auction we need to be able to value all the DAO assets in ETH.

Exploring wag’s recursive idea

Disclaimer: our understanding of wag’s idea has not been verified with wag; we’ll update this post if we learn we misunderstood.

Is there a different approach with the recursion formula from wag’s post?

• The formula: rd(day+1) = rd(day) * nc(day+1) + rd(day), where

  • “days” are settlement-delineated

  • nc = % Change to Treasury from post settlement balance to EOD

  • rd(day0) = Noun Auction Price

  • daymin (first calculation)= Noun Auction settlement day + 1

  • daymax (last calculation)= ‘current’ day - 1

• For a particular Noun, at the moment it was purchased from auction, the redeemable value (rd) is equal to the amount of ETH it was purchased for.

• Then to calculate the value of the next day, you need to calculate `nc`, which is the % change in treasury value during that day. It’s a way to decrease or increase `rd` proportionately to the change in treasury value.

• Seems like auction sales are not considered change in treasury value.

• Seems like there’s no real reason to do this recursively; a simpler way would be:

  • T0 = Time of acquiring a Noun

  • TRQ = Time of doing ragequit

  • rd(TRQ) = nounAuctionPrice * (TreasuryValue(TRQ) / TreasuryValue(T0))

• In words: a Noun’s redeemable value is equal to that Noun’s acquisition price, multiplied by the relative change in the DAO’s treasury assets value between day of acquisition and day of ragequit.

• In this case we still have the problem of needing to be able to evaluate the treasury assets in ETH, i.e. `TreasuryValue` returns a value denominated in ETH.

While this approach avoids explicit allocation of shares, redeemable value ends up being the same as the fund raise at current valuation described above.

Additional problems

Nounder rewards

How are nounder reward nouns valued?

1. They could be valued at zero. Meaning that they get 0 if they ragequit. This can be a problem for those who purchased them on secondary, and is discussed below.

2. They could be assigned an “average value”. If we use the idea of shares, it could be:

   1. Average shares per Noun across the board:

      1. If there are 1M shares outstanding, assigned to 100 nouns. So each noun has 10,000 shares on average.

      2. A nounder reward is minted, it gets assigned 10,000 new shares.

   2. Average shares per recent auctions, making it more responsive to the market:

      1. Take the last N auctioned Nouns and the shares they acquired (e.g. last 7 auctions)

      2. Give the newly minted Nouner reward Noun a share count equal to the average of those last N auctions

Secondary market valuation

Existing nouns will suddenly have different value on secondary markets. Owners who bought nouns that were acquired for relatively low values will object to this change.

We could assign all existing nouns the same number “shares” as a way to bootstrap this.

DAO-owned NFT oracles

What if the DAO holds NFTs that don’t have oracles to assign value to them?

• It means that if someone joins the DAO when the DAO is holding that NFT, they get assigned shares as if that NFT doesn’t exist.

• Later, if the DAO sells that NFT, the new member of the DAO will have a high % ownership of that Noun because it will be considered like income.

• If there’s enough value locked in an NFT, it will attract actors that will want to join the DAO, sell the NFT and then ragequit with the revenue from that asset.

Economic incentives

• Economic and voting shares are split.

• Anyone can buy as many economic shares as they want at any time, diluting everyone else.

• Anyone expecting Nouns to receive an influx of non-auction revenue in the near future can steal as much of it for themselves as they have capital.

• Those with cheaper voting shares will be incentivized to pass proposals for their own benefit, rather than for Nouns' collective interest, or at least will have less risk of spending.

Interim conclusion

The main challenge is to value all the DAO assets in a single denominator (e.g. ETH). This would require having oracles for all assets. Even if there are oracles, they could be potentially manipulated.

Another concern is that treating Nouns this way could significantly increase regulatory risks (this is a dev gut feeling, legal advice is needed).

The economic incentives seem worrisome and require further thinking to potentially mitigate new risks.

Reference material

• Wag’s original post on discourse.

• Capital Accounts in LLCs and Partnerships, a doc wag linked on twitter.

• A definition of capital accounts.

  • “At the most elemental level, then, each owner’s capital account reflects how much the owner has a right to receive from firm equity”

  • “They [capital accounts] usually reflect a mix of hard cash entries and entries that involve estimates of the value assigned to assets or, on occasion, to services.”

To date, there has been no DAO version of forking, but it is needed. How can we protect a minority against a tyrannical majority? Or, in less extreme cases, how can groups amicably part ways on a conflict of visions? Ragequit has been used in some cases, allowing individuals to leave with a pro rata share of the treasury, but it comes with a variety of legal and incentive risks, e.g. overemphasis on individuals.

Today we’re excited to share a solution Nouns has been working on: Nouns Fork. In our model, any token holder can signal to fork (exit) in response to a governance proposal. If a quorum of 20% of tokens signals to exit, the fork will succeed. We discuss further below.

We encourage Nouners and delegates to familiarize themselves with Nouns Fork in anticipation of the upcoming upgrade proposal once the feature is complete and audited. Please reach out with questions and feedback, so we can make sure to fix any bugs in the design or how it’s communicated. We’ve been careful to minimize the scope of this initial version for the sake of shipping fast; there’s ample room for improvement in future versions.

How Nouns Fork Works

Nouns Fork introduces a new forking user flow. This flow enables Nouners to start a fork as soon as the Fork Threshold is reached. The feature operates in one of two states: (1) Escrow Period and (2) Forking Period.

Escrow Period

During the Escrow Period:

• Any Nouner can put their tokens in escrow, contributing towards reaching the fork threshold.

• Nouners can provide context why they are forking by providing proposal IDs that led to their forking, as well as a free text reason.

• Nouners can withdraw their tokens from escrow as long as the forking period hasn't started.

• The forking period commences when the number of escrowed tokens meets the fork threshold, and someone calls the fork DAO function.

• Nouners cannot vote nor propose with tokens in escrow.

Forking Period

The Forking Period:

• Begins when the fork function is called; the fork function deploys a new Nouns DAO.

• Lasts for several days (e.g. 7 days), allowing additional token holders to send their Nouns to the DAO and join the newly forked DAO.

• During this period original DAO proposals can't be executed, to prevent race conditions between the forking flow and any malicious proposals.

• Once forking starts it cannot be canceled.

• New DAOs are deployed with vanilla ragequit in place, allowing any token holder to quit on their own at any time. Otherwise it's possible for a new DAO majority to collude to hurt a minority, and the minority wouldn't have any last resort if they can't reach the forking threshold; furthermore bullies/attackers can recursively chase minorities into fork DAOs in an undesired attrition war.

• Funds (ETH & ERC20 tokens) are sent from the original DAO to the new DAO.

• Forking Nouners claim new DAO tokens with the same IDs and same art as the Nouns they returned to the original DAO.

Fork DAO Initial Configuration

Before diving into the fork initial configuration, it's important to highlight all fork DAO contracts are upgradable, giving its token holders full freedom to adjust code and parameters through proposals. For more technical details you're invited to read this spec.

Governor

• Basis: Nouns DAO V1 (no dynamic quorum, no voting gas refunds).

• Vetoer: not set.

• Delayed Governance: waits for all escrowed Nouners to claim their new tokens or until the delay expiration timestamp (e.g., 30 days after creation) is reached; to prevent abuse by quick claimers targeting those who need more time.

• Vanilla ragequit: fork DAOs have vanilla ragequit instead of forking; otherwise it's possible for a majority to collude to hurt a minority, and the minority wouldn't have any last resort if they can't reach the fork threshold; furthermore bullies/attackers can recursively chase minorities into fork DAOs in an undesired attrition war.

Token

• Art & Descriptor: the same as current Nouns.

• Token IDs: forkers get new tokens with the same IDs of the tokens they had in current Nouns.

• Founders Reward: removed.

Auction

• Paused: token holders need to pass a proposal to kick it off, giving them time to reconfigure.

• Start ID: set to the last ID on current Nouns auction.

UI

• This release will not include a dedicated UI for fork DAOs.

• For governance forks can use existing tools like Agora, HouseOfNous, Tally, etc.

• For a complete solution forks can deploy a modified version of nouns.wtf.

FAQs

Q: What happens to the tokens that were escrowed?

A: Once the fork happens, the DAO can transfer them to any account it chooses to, including an auction contract, individuals' accounts, etc. Tokens held in the escrow contract or in the treasury contract are excluded from total-supply-dependent calculations, e.g. proposal threshold and quorum.

Q: What about NFTs in the treasury, e.g. LilNouns?

A: They are kept in the original DAO's treasury. Future versions may introduce some fair forking mechanism, e.g. random permutations.

Q: Why the big change from the previous design? Why do owners fork and not delegates, and why can't we tie a fork decision to a vote?

A: We had a wrong assumption. Nouns token delegation doesn't store which Nouns are delegated to each account, so we can't identify which Nouns participated in each vote. Moreover, the action of forking seems more appropriate for owners, as it involves transferring their Nouns.

Another challenge: an attacker could create multiple malicious proposals, making it hard for honest actors to establish a clear shelling point for everyone to fork on. We belive this type of attack is easily mitigated by having a dedicated track for forking.

Q: Why allow vanilla ragequit in fork DAOs, versus deploying them with the same forking mechanism as the OG DAO?

A: Forking would allow an attacker to follow forkers into their new DAO in a recursive attrition war. While we have ideas on how to dilute the attacker, they introduce undesired UX complexities. Additionally, a fork design might lead to token distributions in the new DAO where a majority can bully a minority that doesn't have enough tokens to meet the fork threshold (e.g., 140 Nouns fork, 130 collude to bully the other 10).

Q: Why add a 'no proposal execution' constraint instead of making sure the forking flow ends in time?

A: We considered an alternative where the fork creator would set an end timestamp. However, this approach might result in forking ending too early or too late. Ending too early could prevent enough people from joining, while ending too late might enable a malicious proposal to execute ahead of the fork. The timestamp approach could also lead to situations where people participate in two parallel forks and move from one to another. Overall, this UX seems risky.

Q: Can an attacker follow into the new forked DAO?

A: Yes, this griefing vector is a known issue. It stems from a NounsToken contract limitation where we can't easily know which Noun IDs are part of each vote; this limitation means we can't prevent an attacker from joining the fork where Nouners are trying to run away from an attack. In this version your final recourse would be to quit the forked DAO on your own, using the simple quit mechanism built into fork DAOs.

This could be fixed in future versions; a couple of technical directions like storage proofs or moving to NFT-based voting, could let us query in smart contract code per Noun how it voted, and therefore block an attacker from joining a fork (e.g. you can't fork on a proposal if you voted for it).

We're choosing to compromise in this version for the sake of shipping to mainnet quickly.

Q: Why base fork DAOs on V1 and not V2/V3?

A: V3 is not ready yet, and V2 is at Ethereum's contract size limit, and would require a lot of refactoring to allow any new code to be added. Any fork that wants can pretty easily upgrade their governor, hopefully to a stable V3.

Q: Why the 20% fork threshold? And why not just vanilla ragequit?

A: It's important that forking happen rarely, and by a large group of Nouners, to prevent potential financial abuse.

What’s Next

• There’s still time for feedback! Please let us know if you identify any problems or if you have better ideas.

• We're already coding this design and are in touch with auditors; next we're planning to run a bunch of tests, get it audited, and finally submit a proposal to upgrade the DAO to this new version.

Special Thanks

We’re grateful for the support we’ve been getting from several Nouns community members: solimander, will price, digital oil, 4156, Noun 40, vapeape and Chris.

verbs ⌐◨-◨ @davidbrai & @eladmallel

TLDR

• Dynamic quorum is an upcoming governance change that reduces the tradeoff space between friction and security, making proposals harder to pass the more Nouners vote against them.

• This is an important step towards turning off the foundation’s right to veto.

• This change has been reviewed internally and is currently being audited on code4rena.

• The final parameters decision will be made closer to deployment time.

Introduction

The primary attack Nouns DAO is worried about is someone passing a proposal to drain the treasury (currently at ~26K ETH). The last line of defense is the Nouns Foundation’s right to veto any proposal. The Nounders and Nouners (DAO members) seem aligned on the goal of turning this veto right off.

Dialectic wrote two great posts about this attack and potential mitigations, and from those ideas dynamic quorum bubbled up as the safest one to try first (credit to wag for first sharing the idea). Dynamic quorum is not meant to solve the biggest of attacks (e.g. malicious owner of 51% proposes to drain the treasury), but smaller versions which target voter apathy.

We wanted to share how the upcoming dynamic quorum upgrade works, the parameters the DAO needs to decide on, and a bit on what’s next.

Dynamic quorum

Quorum is the minimal number of For votes a proposal must have to pass, currently set to 10% of total supply, e.g. as of August 22 2022 there are 417 Nouns, meaning a proposal created today would need at least 41 For votes to pass.

Dynamic quorum determines a proposal’s quorum as a function of its contentiousness; simply put: more against votes → higher quorum.

This will ensure a reasonable degree of agility on the DAO governance, where uncontested proposals will require a low quorum whereas highly contentious ones will require a higher quorum.

This proposal is a reasonable improvement overall compared to the fixed quorum in terms of scalability since it reduces the tradeoff space between friction and security. However, it’s still ineffective against a great dishonest majority voting power.

(Quotes from Dialectic’s 2nd post).

In its simplest form: every against vote increases quorum votes by one (we’ll complicate things later). Using the numbers above, a proposal with no against votes needs 41 for votes to pass; if it receives one against vote it would need 42 for votes, and if receives 10 against votes it would need 51 for votes to pass.

Launching dynamic quorum requires setting a few important parameters. We will start with briefly defining them, diving deeper later in this post.

• Minimum quorum votes BPs: similar to v1’s “quorum votes BPs” which is set to 10%, this parameter determines the quorum votes required for a proposal to pass even with zero against votes.

• Maximum quorum votes BPs: determines the upper bound value of quorum BPs, e.g. when set to 2,000 quorum votes cannot exceed 20% of total supply.

• Coefficient: determines how many quorum votes each against vote adds (until maximum is reached).

The final values of these three parameters will be further discussed among DAO members, and will be visible as part of the proposal to upgrade the DAO contract. You’re invited to duplicate the simulation spreadsheet and tinker with the inputs, and see their impact on past proposals.

Next we’ll present some tinkering to help cultivate intuitions ahead of the on-chain configuration proposal.

Gaining a deeper intuition

Imagine you’ve submitted a Nouns DAO proposal and you want to advocate for it to be successful; you might consider the question “how many against votes are needed to defeat my proposal?”

In v1 (the current DAO logic) it looks like this:

As long as you’re below quorum, your proposal is defeated; once you have quorum (currently set to 10%) then for votes must exceed against votes for the proposal to succeed. In all the graphs in this section: above the line means defeated and below the line means successful.

v1 versus v2 baseline

We’ll now review v1 versus v2, tinkering with one parameter at a time to better understand their impact. We’ll start with a baseline configuration:

coefficient = 1; minimum quorum BPs = 1,000; maximum quorum BPs = 2,000

This graph helps visualize three distinct parts:

1. Before hitting minimum quorum BPs: v1 & v2 behave the same, i.e. the proposal is defeated without any against votes due to quorum (we complicate this a bit later).

2. Between minimum quorum BPs and maximum quorum BPs: this is dynamic quorum in action, making proposals easier to defeat with less against votes (they raise quorum).

3. After maximum quorum BPs: dynamic quorum is capped and we default to the most intuitive behavior where for votes must exceed against votes for the proposal to succeed.

We’ll attempt to further explain dynamic quorum parameters through their impact on this graph’s shape.

Minimum quorum BPs

Two charts with different minimum BPs values:

Increasing the value of minimum quorum BPs grows that space in the middle of the graph where proposals would be defeated in v2 despite being successful in v1, making it much easier to defeat proposals until the maximum quorum BPs point where v1 and v2 are both decided by simple majority. Decreasing minimum quorum BPs creates this cool new graph shape, where below v1 quorum (10%) it’s actually harder to defeat a proposal in v2.

Probably an initial value of 10% (1,000 BPs) will be acceptable to the DAO, as its preserving the current minimal quorum.

Maximum quorum BPs

Two charts with different maximum BPs values:

Increasing maximum quorum BPs delays that point the graph where v2 reverts back to simple majority, prolonging that middle area where it’s easier to defeat proposals. Perhaps a useful question in setting this parameter is “when do we want to revert from dynamic quorum to simple majority?”

Important to note that the sum of both axis is the total participation rate, which has recently ranged between 14% and 38%. In the higher setting graph for example, we only revert back to simple majority at 30%+ against votes, meaning against votes are extra powerful until we hit a 60%+ participation rate, which is probably too high given current rates.

Say we’re targeting at 36% participation rate, it might make sense to set maximum quorum BPs to 18% (1800 bps). max quorum BPs = participation rate / 2.

Coefficient

Two charts with different coefficient values:

Different coefficient change the shape of that famous middle section, with an obtuse triangle at 0.5, a parallelogram at 1, and an obtuse trapezoid at 2. Notice it pushes the v2 line down, making each against vote stronger, so less are required to defeat a proposal.

Probably setting coefficient around 1 is the easiest place to start, since it’s easiest to predict intuitively, because each against vote adds one quorum vote (up to the maximum limit).

Recap and potential guiding questions

Referring back to thinking in 3 parts:

1. Before hitting minimum quorum BPs: minimal for votes to pass a proposal with no opposition.

2. Between minimum quorum BPs and maximum quorum BPs: dynamic quorum in action, making proposals easier to defeat with less against votes.

3. After maximum quorum BPs: simple majority.

Perhaps start by estimating a highest-realistic participation rate; maximum quorum BPs should probably be less than half that rate with a bit of a margin, otherwise with higher values the risk is minority holders stalling DAO decisions. Similarly consider by what participation rate should simple majority determine the outcome rather than the rising quorum.

Next perhaps consider whether a proposal with no against votes should be easier or harder to pass compared to today with v1. It might also be useful to think of minimum quorum BPs as a reflection of whether the DAO leans more towards yes or more towards no given a proposal that has passed the proposal threshold, which is currently configured to 25 BPs or one vote.

The coefficient parameter seems most intuitively understood as how many quorum votes should each against vote add. The value one seems intuitive as it’s easiest to predict without a spreadsheet, however it’s worth considering further, perhaps by asking how much power do you think should a minority have to deter proposals. Important to highlight that the coefficient can be set to odd values like 1.3 or 0.75.

Ultimately, our hope is to achieve a higher rate of consensus on successful proposals.

What are other DAOs doing

We are aware of other governance systems that employ dynamic inputs:

• Celo’s quorum (“participation”) is set using an exponential moving average of final participation in previous proposals.

• Maker DAO uses continuous approval voting, where active proposals compete for the same pool of votes.

As far as we’re aware, this is the first implementation of dynamic quorum as a function of contentiousness. If this experiment is successful for Nouns, we believe it could become a public good useful for other DAOs.

What’s next

In the next few weeks the code4rena audit results will come in, and we will address any bugs or other issues we might have missed. Once we’ve handled the contest feedback and received the final audit report, we’ll update the DAO with plans to deploy this change to mainnet.

Beyond dynamic quorum, we will continue doing research on the path to disabling veto, including ideas like defending against last-minute vote swings, making malicious proposal more expensive, and more to come.

We’re excited to continue exploring this design space of DAO resilience!

Deploying Nouns forks is used to be expensive

One of the key features of Nouns is that their art is stored completely on-chain. Since storing data on Ethereum is expensive, the Nouns protocol uses a run-length encoding (RLE) compression algorithm to compactly store all the pixel information required to render Nouns. You can read how it works here (a bit outdated, but still helpful).

Even after encoding the art, it cost 67.3M gas to deploy the descriptor contract and add the art data to it. That is ~3.7 ETH at the gas prices in August 2021 (55 gwei).

This cost can be a source of friction for projects who want to deploy forks of Nouns. Nouns DAO wants to see Nouns proliferate and used as much as possible, so reducing this cost is a great way to reduce friction.

Nouns DAO has recently upgraded to a new version of its descriptor contract, the contract in charge of the art. This contract cost 15.9M gas to deploy, including storing all the art on-chain.

In this post we will walk you through the recent changes in the way the Nouns art is stored on chain and how we achieved a reduction from ~67M gas to ~16M gas needed to deploy it.

Methods used to reduce storage cost

There were 3 methods we used to improve upon the original Nouns protocol:

1. Multiline RLE: improve the RLE encoding by supporting multiline runs

2. SSTORE2: store data using CREATE instead of SSTORE to reduce gas cost

3. DEFLATE: use general purpose compression to reduce the size of the data

1. Multiline RLE

RLE works by encoding each consecutive “run” of pixels with the same color into a tuple of (color, length). For example, the array of pixels: R R R R R R B B B (R is red, B is blue) would be encoded as: (R, 6) (B, 3).

The initial RLE algorithm used by Nouns was encoding each row of pixels separately. For example, for an image with these pixels:

R R B B
B B B B

the encoding would be: (R, 2) (B, 2) (B, 4).

This was improved by encoding this 2-D array in its flattened form:

R R B B B B B B would be encoded as (R, 2) (B, 6).

This improvement reduced the amount of image data needed to be stored from ~60KB to ~52KB, and the gas required to deploy from ~67M to ~60M (10% reduction).

The updated encoder can be found here and the decoder here.

2. SSTORE2

SSTORE2 is a solidity library to “Read and write to persistent storage at a fraction of the cost”.

Instead of using the SSTORE op-code to store data in contract storage slots, it uses the CREATE op-code, which is usually used to deploy contract code, to store arbitrary data. You can see a comparison of the gas cost of using SSTORE vs SSTORE2 in the library’s README.

SSTORE2 becomes cheaper when using it to write bigger chunks of data, so instead of write each image individually, we decided to batch all the images of a trait together.

When batching the images together, we need to know where one image ends and the next one starts. For convenience we used ABI encoding to encode the data as a bytes[] which can be easily decoded in solidity using abi.decode. It’s very likely that there are more efficient ways of encoding the array of images, but we decided to use the convenience of ABI encoding.

This improvement reduces the gas cost to deploy the art from ~60M to ~28M (53% reduction).

You can see the usage of SSTORE2 in the NounsArt contract.

3. DEFLATE

As part of looking for ways to compress the data more, we were searching for general purpose compression algorithms implemented in solidity.

Thankfully we found the inflate-sol library by @adlerjohn which implements a decompression algorithm of DEFLATE, which is the common compression algorithm use in zlib/gzip.

Our plan was to compress the batched data as describe in (2) and write it using SSTORE2. When accessing the data, the data would be read using SSTORE2, decompressed using inflate-sol, and finally decode using abi.decode.

The concern we had here is that inflate-sol is quite gas intensive when decompressing data. Theoretically that wouldn’t be a concern since it would be used in read-only functions of the contracts, and not as a part of a transaction. Practically it is an issue because when performing an eth_call, Ethereum nodes often have a gas limit on it. Specifically the nodes used by NFT marketplaces (e.g opensea, looksrare) have gas limits when calling tokenURI on the NFT contract.

These gas limits are not documented anywhere that we could find. In order to find the limits we deployed an NFT contract where each consecutive NFT consumes 1M addition gas in its’ tokenURI method. For our experiments, we saw that NFT marketplaces and popular node providers (infura, alchemy) can handle at least ~400M gas.

With a few low-hanging gas optimizations, we were able to get the tokenURI method to about 110M gas which felt safe to use.

We deployed the inflate-sol library as a standalone contract to enable anyone to access without needing to redeploy it.

This improvement reduces the gas cost to deploy the art from ~28M to ~14M (50% reduction).

Hope you enjoyed reading. If you have any feedback or question, drop by the Nouns discord at #54-tech-grants.