we build smart contracts for Nouns. we're on twitter @davidbrai and @eladmallel.
Share Dialog
Share Dialog
we build smart contracts for Nouns. we're on twitter @davidbrai and @eladmallel.
Subscribe to verbs
Subscribe to verbs
>400 subscribers
>400 subscribers
Welcome to the second post in the Nouns Governor series; Please check out the first post for more context.
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.
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.
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.
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.
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.
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.
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 delegates Noun 142 to Diva, by transfering delegation NFT 142 to her wallet.
Then Alice sells Noun 142 to Bob; the delegation NFT is still in Diva's wallet.
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 delegates Noun 142 to Diva.
Alice transfers Noun 142 to her new hardware wallet, wanting the delegation to Diva to persist.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 ⌐◨-◨
Welcome to the second post in the Nouns Governor series; Please check out the first post for more context.
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.
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.
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.
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.
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.
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.
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 delegates Noun 142 to Diva, by transfering delegation NFT 142 to her wallet.
Then Alice sells Noun 142 to Bob; the delegation NFT is still in Diva's wallet.
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 delegates Noun 142 to Diva.
Alice transfers Noun 142 to her new hardware wallet, wanting the delegation to Diva to persist.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 ⌐◨-◨
verbsA Nouns token delegation vulnerability
A Nouns token delegation vulnerabilityWe 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.TLDRWho’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 pr...
verbsIntroducing Nouns Fork: A Last-Resort Minority Protection Mechanism
Forking is the crypto-native way for groups of token holders to exit together into a new instance of their protocol, resulting in maximal conservation of momentum in the ecosystem; famous examples include the Ethereum Classic fork and the Bitcoin Cash fork. We believe it's time to enable DAO forks as well, starting here at Nouns. 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...
verbsClient Incentives V1 scope
Background & contextClient 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...
verbsA Nouns token delegation vulnerability
A Nouns token delegation vulnerabilityWe 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.TLDRWho’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 pr...
verbsIntroducing Nouns Fork: A Last-Resort Minority Protection Mechanism
Forking is the crypto-native way for groups of token holders to exit together into a new instance of their protocol, resulting in maximal conservation of momentum in the ecosystem; famous examples include the Ethereum Classic fork and the Bitcoin Cash fork. We believe it's time to enable DAO forks as well, starting here at Nouns. 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...
verbsClient Incentives V1 scope
Background & contextClient 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...
No activity yet