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...
verbsNouns Governor: Design Alternatives
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 curren...
we build smart contracts for Nouns. we're on twitter @davidbrai and @eladmallel.
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...
verbsNouns Governor: Design Alternatives
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 curren...
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
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.
In V1 the following interactions will be rewarded:
Creating proposals
Voting on proposals
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.
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:
percentRewardAuctions: % of auction revenue rewarding auction bidding
percentRewardProposals: % of auction revenue for rewarding writing proposals
percentRewardProposalVotes: % of auction revenue for rewarding votes
For more detailed description, please review the spec.
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.
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.
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.
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.
In V1 the following interactions will be rewarded:
Creating proposals
Voting on proposals
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.
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:
percentRewardAuctions: % of auction revenue rewarding auction bidding
percentRewardProposals: % of auction revenue for rewarding writing proposals
percentRewardProposalVotes: % of auction revenue for rewarding votes
For more detailed description, please review the spec.
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.
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.
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.
No activity yet