Background & context

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.