Community Product Session #4 - Coining

[b3nedictvs]

Hi Builder!

Together with @benedictvs.eth and @dan13ram.eth we'll be organising the 3rd Builder Community Product Sync on Thursday, 14 October 2025 at 12:00 pm (ET) in ⁠our 🎙voice channel on Discord. We want to discuss the Coining Design Document and the implementation of the integration of the Zora SDK.

What feedback do you have? Are there any change requests? Got something we should add? Let us know and we'll put it on the agenda.

Agenda

1. Revisiting the Coining Design Document
2. Review the Comments
3. Open Floor for Coining-related Questions

Looking to prepare for the event? Check out the Figjam for the session here.

The v.0.1 of the DRAFT Builder Coining Design Document was released by us today with the request for comments until October 17. https://ipfs.io/ipfs/QmXCCDsaS2X2E6uP61aijo6jEYLerMtFbc3VPo1U8zSQtQ

Request for Comments

Please feel free to post your comments here.

[xSatori]

A few questions that came up as I read through the document

• Should there be rate limits or constraints on how often DAOs or users can mint content coins to prevent spam?
• If a creator’s status changes (becomes a member of a DAO but wasn't when a coin was created), how are 0xSplits updates triggered? Will gas costs for these updates be passed on to users?
• Is there a plan for moderation and/or abuse prevention, especially for permissionless user-generated content coins?
  • Builder should have complete moderation control for content on nouns.build in my opinion. While DAOs can ultimately do whatever they like on their own frontends, we should be able to hide content we deem inappropriate or malicious on our own platform.
  • Should DAOs be required to elect a moderator with permissions to hide content or blacklist certain wallets?
  • Should Builder have some universal moderation controls like blacklisting wallets from the protocol?
• Will reward-split logic and LP mechanics be upgradeable via governance, or immutable?
• We should consider a leaderboard page to display top content by marketcap/volume/trending, as well as top DAO coins based on number of contributors, rewards generated, etc.

[swarthyhatter]

The more time goes by, the more I grow concerned with spamming from NonDAO Affiliates as mentioned by @xSatori

[b3nedictvs]

What specifically are your concerns? Propdates also allow for non-DAO members posting and spamming has not been an issue whatsoever.

[swarthyhatter]

1. Will DAOs be allowed to withdraw liquidity from their DAO↔BUILDER or Content↔DAO pools, and what would be the downstream effects on price stability and the Builder liquidity hierarchy?
2. Can DAOs modify their governance weighting (e.g., 1 token = 1 vote vs. custom weighting) by adjusting admin or Governor contract settings on Builder?
3. How are creator/DAO rewards routed on-chain (via 0xSplits), and can DAOs replace the default split contract with a custom one?
4. Can a Content Coin reference multiple DAOs simultaneously (multi-pair liquidity or multi-split reward distribution)?

[b3nedictvs]

@scottrepreneur shared the concern

earning fees in zora seems operationally risky. is ETH an option there?

[b3nedictvs]

@xSatori

A few questions that came up as I read through the document

• Should there be rate limits or constraints on how often DAOs or users can mint content coins to prevent spam?

Ideally yes, but depends on the implementation as coining is a contract interaction and costs gas.

• If a creator’s status changes (becomes a member of a DAO but wasn't when a coin was created), how are 0xSplits updates triggered? Will gas costs for these updates be passed on to users?

0xSplits can be made deterministic on the creator and DAO address. Once it changes, it will also change for older posts.
What happens when the user changes the split (as a controller)? Perhaps it would be better to batch split changes or have the delegated resolver handle it.

• Is there a plan for moderation and/or abuse prevention, especially for permissionless user-generated content coins?

What should that plan look like? On the frontend not a problem.

• Builder should have complete moderation control for content on nouns.build in my opinion. While DAOs can ultimately do whatever they like on their own frontends, we should be able to hide content we deem inappropriate or malicious on our own platform.

Both good ideas and feasible on the frontend

• Should DAOs be required to elect a moderator with permissions to hide content or blacklist certain wallets?
• Should Builder have some universal moderation controls like blacklisting wallets from the protocol?
• Will reward-split logic and LP mechanics be upgradeable via governance, or immutable?

Reward splits are upgradeable for splits involving the specific DAO. Reward splits set on Builder would be subject to Builder, i.e. a global setting. LP mechanics unlikely to be upgradeable

• We should consider a leaderboard page to display top content by marketcap/volume/trending, as well as top DAO coins based on number of contributors, rewards generated, etc.

This is what we refer to as "gallery"

@swarthyhatter

1. Will DAOs be allowed to withdraw liquidity from their DAO↔BUILDER or Content↔DAO pools, and what would be the downstream effects on price stability and the Builder liquidity hierarchy?

It is possible to migrate liquidity to a different pool, but you cannot remove it in that sense. Please see https://docs.zora.co/coins/contracts/liquidity-migration#liquidity-migration.

2. Can DAOs modify their governance weighting (e.g., 1 token = 1 vote vs. custom weighting) by adjusting admin or Governor contract settings on Builder?

Unrelated to coining, currently not possible, but may be prioritised by the community together with other requests for contract changes.

3. How are creator/DAO rewards routed on-chain (via 0xSplits), and can DAOs replace the default split contract with a custom one?

Theoretically they could replace it, but it will not be surfaced on the UI unless there is strong demand for it post launch of v.0.

4. Can a Content Coin reference multiple DAOs simultaneously (multi-pair liquidity or multi-split reward distribution)?

Zora limits the pairing to one creator coin for the content.

@scottrepreneur

• Earning fees in zora seems operationally risky. is ETH an option there?

The API allows ETH, so we should not be limited to Zora.

[b3nedictvs]

Outcomes on the FigJam Board

Key Takeaways

Design Document Review and Community Engagement

• A draft design document was published, and the team is requesting feedback.
• The document aims to define the vision for coining on builder and request community input.
• The document includes a high-level roadmap and a summary of the current stage in the iteration process.
• The team is currently in the process of setting up the backend and familiarizing themselves with the Zora SDK, which is a key technical component for the coining implementation.

Revenue Model and Fee Splitting

• The proposal involves defining a creative fee structure where multiple personas (DAOs, members, users) would earn rewards from content creation and trading.
• A discussion was held regarding the 100%-creator, 30%-DAO, and 50%/50%-user split models for different types of content and referral interactions.
• The team emphasized the importance of flexibility and governance in defining how these fees are split, especially in light of upcoming protocol upgrades.
• A request was also raised to clarify whether the proposal is for a creative split or if it's a light-weight mechanism that could evolve into an immutable specification.

User Interface and Moderation

• The team is designing a social feed component inspired by Skatehive and Gnars.
• A gallery view was discussed for displaying trending content, followed by a hover effect to simulate trading or trending behavior.
• Moderation controls are under discussion; the team is creating a section for moderation.
• Feedback around censorship and wallet blacklisting were raised, particularly concerning the limitations on the front-end implementation.

[b3nedictvs]

After today's general discussion on the Builder Coining initiative during the DAO townhall meeting, I'm sharing the slide deck with the latest updates and considerations.

2025-12-08_Coining_Update.pdf

[b3nedictvs]

Hi everyone!

We have finalised the Builder Coining Design Document on v.1.0, which specifies the Builder Coining Feature Suite and the coining protocol strategy after according to your input over the last month. We chose a dual-protocol approach to distinguish between governance-level DAO Coins and social Content Coins.

The prototypical infrastructure is nearly complete on the testnet, with an alpha version expected for community review by the final week of January 2026. We now seek community deliberation on non-technical details, including the starting price, market cap, and liquidity seeding for the potential $BUILDER coin.

• DAO Coins are deployed through Clanker v.4.0 as the primary coordination and value-capture layer
• Content Coins utilise the Zora SDK to facilitate the monetisation of posts and individual contributions
• Operations are currently restricted to the Base network until underlying protocols expand cross-chain support
• The mobile-first social feed is already live (any feedback is much appreciated) that is already becoming the primary interface for engagement within the Builder client

The document is available for review and download here: https://ipfs.io/ipfs/bafybeibhkzuibuhmkgtaybs7nndccxwapgwfcfymsham5xcayqas64qaqe

[swarthyhatter]

Revenue Capture: Enforce token hierarchy ($DAO → $BUILDER → $ETH) to route
trade fees to Builder DAO via coins, referral rewards, and liquidity rewards.

In meetings prior we discussed making the hierarchal association with BUILDER optional --with caveats about feature capabilities should a community chose to pair only directly with ETH. I think this is an important design consideration to keep in mind, and just want to confirm that it is still included in the broader specification. It would not be necessary for an MVP in any case. I think allowing Nouns Builder Protocol to earn the alignment of communities and developers rather than force it is an important aspect of the value we are creating.

[b3nedictvs]

Apologies for the miscommunication here. It will continue to be optional, as we can suggest this on the frontend only anyway. Thus, rather than "enforce" this should state suggest. I will correct the document accordingly. Thank you for pointing this out.

[b3nedictvs]

@swarthyhatter please find the revised version here https://ipfs.io/ipfs/bafybeiej7a3lq3mc45dqai4s3jmohn634vna3ahsjhfcuefqea6wmtdwse