\* Websites that want to claim this reward must call the `createBidWithReferral` function on the upgraded contract and pass the reward recipient as the `_referral` parameter. ### Builder DAO Rewards Recipients BuilderDAO's portion of the rewards will go to a 3/6 multisig on each network managed by the DAO's Operations Working Group. The addresses are: - **Ethereum Mainnet:** 0x38C170B11038eBEf16f3EC4F9b8a3A51B045533d - **Base:** 0x894F30da29216516b5aE85207dED77038C107f22 - **OP Mainnet:** 0x7C69609645837a77915410B9B5605f54C79Da5D2 - **Zora Network:** 0x7229F0c537e64f3EA9E9b993601578A7B09c402C ## Getting Started / Onboarding Source: https://docs.nouns.build/onboarding/getting-started-onboarding/ This section is designed to help you begin your journey with Builder DAO and the Nouns Builder ecosystem. Whether you're a new community member, a developer, or a community manager, you'll find clear instructions and guidance to help you get started confidently. --- ## 🧑💻 For New DAO Members ### Setting Up a Wallet and Joining a DAO To participate in a Builder DAO, you’ll need an Ethereum-compatible wallet such as [MetaMask](https://metamask.io/), [Rainbow](https://rainbow.me/), or [Coinbase Wallet](https://www.coinbase.com/wallet). **Steps to set up:** 1. Download and install your preferred wallet. 2. Create a new wallet and back up your seed phrase securely. 3. Connect your wallet to [nouns.build](http://nouns.build/). 4. Browse and join a DAO by participating in an auction or acquiring a governance token.  --- ### Introduction to Builder DAOs and Auctions Each Builder DAO operates using a recurring token auction. This auction system replaces traditional token launches and distributes voting power transparently over time. **Key concepts:** - **Token Auction**: New DAO tokens are auctioned one at a time, usually every 24 hours. - **Auction Winner**: The highest bidder receives the governance token. - **Treasury**: Funds from auctions go to the DAO treasury to fund community initiatives.  --- ### How to Participate in Governance Governance is the core mechanism that allows DAO members to propose and vote on decisions. **How it works:** 1. **Propose**: Members with proposal rights can create a proposal. 2. **Vote**: Token holders vote FOR or AGAINST the proposal. 3. **Execute**: If quorum and majority are reached, the proposal is executed onchain. **To get involved:** - Join DAO discussions (Discord, Warpcast, etc.) - Review active proposals on [nouns.build](http://nouns.build/) - Vote using your wallet when governance periods are open  --- ## 🧑💻 For Developers ### Quickstart: Deploying via [nouns.build](http://nouns.build/) The easiest way to launch a DAO is directly through the nouns.build interface. **Steps:** 1. Go to [nouns.build](http://nouns.build/). 2. Click **Launch a DAO**. 3. Fill in your DAO’s name, auction settings, governance rules, and artwork. 4. Deploy contracts with your connected wallet. Within minutes, your DAO will be live and ready to auction its first token. --- ### Testnet vs Mainnet: What You Need to Know Before launching your DAO on mainnet, it's a good idea to test your setup on testnet (e.g., Optimism Sepolia). **Testnet benefits:** - No real funds required - Safe environment to test settings and DAO logic - Helps ensure your deployment will work as expected **How to switch networks:** - Configure your wallet for the appropriate testnet. - Use test ETH from a faucet. - Deploy and test your DAO using [nouns.build](http://nouns.build/) or locally. --- ## 🧑🎤 For Community Managers ### DAO Tooling Overview Community managers often act as glue within a DAO. They coordinate contributors, organize calls, moderate communication, and ensure proposal momentum. **Recommended tools:** - **Discord** – for asynchronous conversation and community chat - **Farcaster / Warpcast** – for social broadcasting and engagement - **Notion / HackMD / Google Docs** – for drafting proposals, docs, and updates  :::tip[Satori's Knowledge Base] If you want to read more on Nouns Builder, visit [Satori's Builder DAO Dashboard](https://0xsatori.notion.site/Builder-DAO-Dashboard-a66f8a89dce64ed680a9c16eb2dec364). ::: ### Using Discord, Warpcast, and Twitter for Coordination **Discord**: - Create dedicated channels for governance, auctions, proposals, and casual chat - Assign roles (e.g. voters, admins, mods) **Warpcast**: - Announce new auctions and proposals via Farcaster channels - Enable reactions and comments to gather feedback **Twitter/X**: - Share major milestones and community wins - Reach audiences outside the onchain space  --- ### Managing Proposals and Community Updates Community managers play a key role in: - Ensuring proposals are well-formatted and properly timed - Hosting proposal discussion calls - Posting clear summaries and updates after votes **Pro tip**: Use a recurring governance digest or update thread to keep your community in the loop. ## Propdate EAS Schema Source: https://docs.nouns.build/contributors/attestations/ ## Overview This schema defines how users of Nouns Builder can submit *Propdates*, i.e., *updates*, *comments*, and *milestone-related actions*, to DAO proposals using the [Ethereum Attestation Service (EAS)](https://docs.attest.org). All attestations using this schema are displayed under the **Propdates** section of the proposal UI. It supports Markdown, IPFS links, structured JSON, and threaded discussions via reply references. ## Sequence Diagram  ```mermaid sequenceDiagram participant User participant DAO Frontend participant Ethereum Attestation Service (EAS) participant Blockchain User->>DAO Frontend: Compose Propdate update DAO Frontend->>User: Prompt to sign transaction User->>Blockchain: Sign and submit Propdate attestation Blockchain->>EAS: Store attestation DAO Frontend->>EAS: Fetch Propdates for proposal/activity feed EAS->>DAO Frontend: Return Propdate data DAO Frontend->>User: Display Propdates (filtered by member/all) ``` ## Schema Specification The schema with the UID `0x8bd0d42901ce3cd9898dbea6ae2fbf1e796ef0923e7cbb0a1cecac2e42d47cb3` enables Nouns Builder Propdates. It is deployed onchain on all networks supported by Nouns Builder **except Zora**. The schema consists of mandatory and optional fields. The payload displayed on the frontend is wrapped in a `message` field, which MAY contain a *JSON* string. ### Deployed Schemas - [Base](https://base.easscan.org/schema/view/0x8bd0d42901ce3cd9898dbea6ae2fbf1e796ef0923e7cbb0a1cecac2e42d47cb3), - Zora Mainnet **(not supported)** - [OP Mainnet](https://optimism.easscan.org/schema/view/0x8bd0d42901ce3cd9898dbea6ae2fbf1e796ef0923e7cbb0a1cecac2e42d47cb3), - [Ethereum Mainnet](https://easscan.org/schema/view/0x8bd0d42901ce3cd9898dbea6ae2fbf1e796ef0923e7cbb0a1cecac2e42d47cb3), - [Base Sepolia](https://base-sepolia.easscan.org/schema/view/0x8bd0d42901ce3cd9898dbea6ae2fbf1e796ef0923e7cbb0a1cecac2e42d47cb3), - [OP Sepolia](https://optimism-sepolia.easscan.org/schema/view/0x8bd0d42901ce3cd9898dbea6ae2fbf1e796ef0923e7cbb0a1cecac2e42d47cb3), - Zora Sepolia **(not supported)** - [Ethereum Sepolia](https://sepolia.easscan.org/schema/view/0x8bd0d42901ce3cd9898dbea6ae2fbf1e796ef0923e7cbb0a1cecac2e42d47cb3) ### Schema Structure ```solidity bytes32 proposalId; bytes32 originalMessageId; uint8 messageType; // 0: INLINE_TEXT, 1: INLINE_JSON, 2: URL_TEXT, 3: URL_JSON string message; // Inline content or off-chain URL ``` ### Field Breakdown | Field | Type | Description | |---------------------|-----------|-------------| | `proposalId` | `bytes32` | Proposal ID (usually keccak256 of the proposal metadata or ID hash) | | `originalMessageId` | `bytes32` | UID of another attestation being replied to. Use `0x0` for top-level comments. | | `messageType` | `uint8` | Specifies how to interpret `message`. See types below. | | `message` | `string` | Inline content (if `INLINE_*`) or a URL (e.g., IPFS) if `URL_*` | ### Message Type Definition | Code | Name | Description | |------|---------------|----------------------------------------------------| | `0` | `INLINE_TEXT` | Raw Markdown string submitted inline | | `1` | `INLINE_JSON` | JSON payload embedded directly in the attestation | | `2` | `URL_TEXT` | URL (e.g., IPFS) pointing to a Markdown file | | `3` | `URL_JSON` | URL (e.g., IPFS) pointing to a JSON file | --- ### JSON Payload (For `INLINE_JSON` or `URL_JSON`) ```json { "milestoneId": 2, "content": "Delivered frontend with tests.", "labels": ["delivery", "frontend"], "attachments": ["ipfs://bafybeigdyrhnsq.../demo.mp4"] } ``` ### JSON Field Reference | Field | Type | Description | |---------------|------------|---------------------------------------------------------| | `milestoneId` | `number` | [Optional] Milestone index the update refers to | | `content` | `string` | [**Required**] text content | | `labels` | `string[]` | [Optional] Tags for filtering/search | | `attachments` | `string[]` | [Optional] List of media or file URLs (preferably IPFS) | ## Usage ### Example Attestation [View on EASScan](https://base.easscan.org/attestation/view/0xf1c43e68c96c29831af1760979b3c7f52abfb14561434381a5983f356c2f9ab8) ```json { "proposalId": "0x20dce33aa50446e11ad5e97321f50e98c5d4fa41b0cfa87b5a525a6d1100fc4b", "originalMessageId": "0x0000000000000000000000000000000000000000000000000000000000000000", "messageType": 1, "message": "{\"milestoneId\":1,\"content\":\"Milestone 1 complete. All Figma wireframes uploaded.\",\"labels\":[\"figma\",\"ux\"],\"attachments\":[\"ipfs://bafybeihpky3lq4m/demo.mp4\"]}" } ``` ### Workflow for Non-UI Propdates 1. **Create attestation** A wallet with authority can submit an attestation directly through [EAS](https://base.easscan.org/) using the schema UID. 2. **Fetch and display attestations** Fetch the schema on the relevant network using EAS Scan and the Schema UID. Connect your wallet and post an update. 3. **Propdates versus release requests** Release request must be made independently of updates and comments, using the `Release Milestone` functionality, as described in the [Nouns Builder Escrow Proposal Guide](../guides/builder-escrow-proposal) ### Usage in Nouns Builder Frontend - Appears in the **Propdates** tab on the proposal page. - Posts by DAO members are shown by default, but anyone can: - Post progress updates - Comment on milestones - Start threaded conversations ## Attestation Policy and Deploying Schemas Only attestations from DAO members are displayed under **Propdates** by default, but users can select **All Propdates** to see non-member comments. The attestation schema can be deployed to additional networks using the same UID by anyone. ## Creating a DAO Source: https://docs.nouns.build/guides/creating/ ##### Highlights the 3 Steps for Creating a DAO --- Useful resources for creating a DAO: [Interface](https://nouns.build/) | [Testnet Interface](https://testnet.nouns.build) | [Deploy Guide](../../guides/builder-deployment) ## Deployment First, the founder calls the Manager contract with all the selected settings to deploy the DAO contracts. This deploys new contracts for each component of the DAO and has the owner set to the founder's address. In this stage, the founders can edit the contracts directly and make any necessary changes before handing off control to the DAO.  --- ``` /// @notice Deploys a DAO with custom token, auction, and governance settings /// @param _founderParams The DAO founders /// @param _tokenParams The ERC-721 token settings /// @param _auctionParams The auction settings /// @param _govParams The governance settings function deploy( FounderParams[] calldata _founderParams, TokenParams calldata _tokenParams, AuctionParams calldata _auctionParams, GovParams calldata _govParams ) ``` --- ## Metadata Configuration Next, a separate transaction is sent to the Metadata Render contract to store all the property values. This way the Render contract knows all the possible properties and items when randomly generating the images for the DAO NFTs. ``` /// @notice Adds properties and/or items to be pseudo-randomly chosen from during token minting /// @param _names The names of the properties to add /// @param _items The items to add to each property /// @param _ipfsGroup The IPFS base URI and extension function addProperties( string[] calldata _names, ItemParam[] calldata _items, IPFSGroup calldata _ipfsGroup ) external onlyOwner ``` --- ## Starting Finally, starting hands control over to the DAO by setting the Treasury contract as the owner and then starting the first auction. The Treasury contract is set as the owner since it is the contract that executes transactions based on governance votes. Once a DAO has been initialized the founders are no longer able to directly change the contracts and must have a proposal pass governance to do so. 
The DAO is initialized by calling the `unpause()` function on the Auction contract. Calling this function will start the first auction. ## The Nouns Builder Protocol Source: https://docs.nouns.build/onboarding/nouns-builder-protocol/ The Nouns Builder Protocol is an open-source smart contract system that allows anyone to launch a fully onchain DAO with programmable governance, automated token issuance, and treasury management. This section breaks down how the protocol works, its architecture, and how to interact with it. --- ## How It Works ### Token Auction Mechanisms At the heart of every Builder DAO is a recurring token auction system. Instead of launching all governance tokens at once, new tokens are auctioned one at a time on a fixed schedule. **Key characteristics:** - **Auction Interval:** Each DAO configures how often a new token is auctioned (e.g., every 24 hours). - **Bidding Process:** Participants bid using ETH, and the highest bidder wins the token. A new high bid within the last 5 minutes of the auction will extend the auction duration for another 5 minutes. This will continue until the auction goes 5 minutes without a new high bid and the auction closes. - **Token Minting:** Settling an auction distributes the last token to the winner, mints the next token, and kicks off a new 24 hour auction. This approach ensures fair distribution over time and creates a predictable funding stream for the DAO treasury.  --- ### Governance Parameters Builder DAOs use onchain governance to make decisions. The protocol provides customizable governance settings when launching a DAO: - **Voting Delay:** Time between when a proposal is submitted and when voting begins. - **Voting Period:** Duration the community has to vote on a proposal. - **Quorum Threshold:** Minimum number of votes needed for a proposal to be valid. - **Proposal Threshold:** Minimum number of tokens required to create a proposal. These parameters shape how responsive, secure, and participatory your DAO will be.  --- ### Treasury Management Funds from each token auction are automatically routed to the DAO's treasury, which is controlled by governance. - **No central ownership:** The treasury is owned and managed by the DAO itself. - **Proposal-controlled spending:** Members propose and vote on how funds are used. - **Transparency:** All transactions are recorded onchain and visible to the public. DAOs often use these funds for grants, contributor payments, community tools, or protocol improvements.  --- ## Contract Architecture ### Key Smart Contracts and Their Roles The Nouns Builder Protocol consists of several modular smart contracts. These include: - **Auction Contract:** Manages the auction logic and token minting. - **Token Contract (ERC-721 or ERC-20):** Represents ownership and governance power. - **Governor Contract:** Handles proposal creation, voting, and execution. - **Metadata/Render Contract:** Controls visual and metadata logic for NFTs (if using NFTs). - **Treasury Contract:** Stores and secures the DAO's funds. Each component is interoperable and can be extended or customized by developers. --- ### Upgradeability and Modularity The protocol is designed with flexibility in mind: - **Upgradeable Governance Contracts:** Using the OpenZeppelin upgrade pattern, governance logic can evolve over time. - **Modular Design:** DAOs can replace or extend individual components (e.g., custom token logic or auction formats). - **Parameter Tuning:** Governance can change auction intervals, governance rules, and more post-launch. This makes the protocol suitable for both simple and highly customized DAO setups. --- ### Security Model Security is paramount for onchain governance systems. Key features include: - **Immutable Treasury Ownership:** Only proposals passed by token holders can move treasury funds. - **Audit History:** The protocol builds on audited components from Nouns and OpenZeppelin. - **Permissionless Deployments:** Anyone can deploy without relying on a central admin. DAOs should still conduct additional audits if they customize or extend the system. --- ## Interacting with the Protocol ### Frontend Options The easiest way to interact with the protocol is through the [nouns.build](http://nouns.build/) web interface. From the dashboard, you can: - Launch a DAO - View and bid on auctions - Submit and vote on proposals - Monitor treasury and DAO activity  --- ### Using the Builder SDK and API For developers, the [Builder SDK](https://github.com/BuilderOSS/nouns-builder) offers tools to build and interact with DAOs programmatically. **Features:** - Fetch auction data and governance states - Submit transactions via script - Integrate DAO data into custom apps **Example Use Cases:** - Custom frontend for your DAO - Proposal automation tools - Onchain analytics dashboards --- ### CLI Tools and Third-Party Integrations In addition to the SDK, you can use command-line tools and third-party platforms: - **Hardhat/Foundry**: For deploying and testing DAO contracts - **Tally.xyz**: Some DAOs integrate with external governance dashboards - **Dune Analytics**: Track DAO performance using community dashboards - **Gnosis Safe & Zodiac**: Extend DAO control with multisig integrations ## How to Create a DAO Source: https://docs.nouns.build/guides/builder-deployment/ ##### Learn how to build your own DAO --- [Nouns DAO](https://nouns.center/intro) launched in late 2021 and created a novel way of distributing governance by minting 1 NFT a day forever. These NFTs are perpetually auctioned off to the public and give voting rights in the future of the DAO. Nouns Builder allows anyone to build their own Noun-styled DAO in minutes. This guide will walk you through how to use the [Nouns Builder interface](https://nouns.build/create) to create your own DAO. :::note We highly recommend first creating a test DAO on the [Sepolia Testnet](https://testnet.nouns.build/) before creating one on Mainnet. We also recommend using a personal wallet to create your DAO. Creating a DAO with a [Safe multisig](https://safe.global/) is currently not supported. - Visit Testnet **[here](https://testnet.nouns.build/)**. - Obtain Sepolia ETH **[here](https://sepolia-faucet.pk910.de/)**, **[here](https://www.alchemy.com/faucets/ethereum-sepolia)** or **[here](https://cloud.google.com/application/web3/faucet/ethereum/sepolia)**. ::: --- ## General Settings First, you will need to provide the name, symbol, image for your DAO, and optionally a website. Note, the symbol is used as the name in the DAO NFT metadata. For example, a DAO with a symbol of `NOUN` would have NFTs named `NOUN #1`, `NOUN #2`, etc.  --- ## Auction Settings Next, you will need to configure your auction settings. Keep in mind, a new DAO NFT is minted every time an auction is started. - `Duration:` How long an auction runs for - `Reserve Price:` Minimum bid amount required to start an auction #### Advanced We have chosen safe default values so don't feel pressured to change these unless you feel like a different setting is truly preferential. - `Proposal Threshold:` Min percent of total votes (NFTs) balance needed to put a proposal to a vote. For example, if the Proposal Threshold is set to 0.5% and there are 1000 total NFTs minted then 5 NFTs need to approve the proposal for it to be put to a vote. - `Quorum Threshold:` Min percent of total **For** votes (NFTs) required for a proposal to pass  --- ## Veto Power After that, you can choose if you would like to have the power to veto proposals. Veto power is encouraged due to the small number of votes (NFTs) at the beginning of a DAO. The veto can later be removed once the NFTs have become sufficiently decentralized.  --- ## Allocations #### Founder Allocation As a founder, you can set an allocation to yourself. The contract will automatically send the NFTs to your address upon mint. Note, these founder NFTs do not impact the auction cadence. 
#### BuilderDAO Allocation In addition, there is an optional allocation to BuilderDAO for providing the software to build your DAO. You can opt out of this allocation in the advanced settings on the page if you so choose. --- ## Artwork Setup Next, you will need to upload your artwork to Builder. The image files will be stored on IPFS, but the random combination of traits for an NFT is calculated on-chain at the time of mint. Check out the [Example Artwork Toolkit](https://www.figma.com/community/file/1166768320345172833) to learn more about formatting the art for the DAO NFTs. #### Image Requirements - PNG and SVG are the only supported file types - 600px x 600px minimum for PNGs and 32px minimum for SVGs - Images must be square - Maximum directory size: 200 MB #### Properties vs Items - `Properties:` Categories of different traits for the DAO NFTs - `Items:` Distinct image options that make up a property #### Folder Structure Please format your art folder like the example below. Make sure that each property has a separate folder holding the items for each property.  #### Layering Each property should be a different layer in the NFT. This means the order of the layers matters. You can use the interface to reorder the properties to make sure that they are in the correct order.  #### Preview Lastly, you can use the preview on the left to view random combinations of the art layers to confirm everything is correct. There is also a playground feature that allows you to get more granular with the previewing.  --- ## Deploying the DAO Contracts Now that you have chosen all the settings for your DAO, we are ready to deploy all the contracts. This step will prompt a transaction in your wallet.  --- ## Setting Token Metadata Since we have deployed all of our DAO contracts we can see their addresses on this page. Make sure to record these so that you have them stored somewhere for future reference. Next, we are ready to update the metadata on-chain. Even though the images are stored on IPFS, we need to update the Metadata Render to be aware of our different properties and items. That way it can generate random combinations when minting NFTs. This step will also prompt a transaction in your wallet. Once the transaction confirms you will be redirected to your DAO's dashboard.  --- ## Editing the DAO Settings Now that we have deployed all the contracts and updated the metadata on-chain, we can confirm and make last-minute edits to our DAO settings before we initialize it. First, click "Edit Settings" 
This will take you to the setting page for the DAO. As a founder, you can edit these settings before initializing. Make sure to double-check that they are all correct.  --- ## Starting the DAO Finally, once you have confirmed all the settings are correct, you are ready to start your DAO. You can do this by going to your dashboard and clicking on "Start Auction". This step will start the first auction and also hands over admin controls to DAO governance. Note, once you start your DAO the settings can't be changed by a founder and must pass a governance vote. 
The next auction will start when the winner of the first auction goes to claim their NFT. Meaning the auctions will keep running perpetually. #### Congratulations on creating your first DAO 🥳 ## The Nouns.build Platform Source: https://docs.nouns.build/onboarding/nouns-build-platform/ The [nouns.build](http://nouns.build/) platform is the primary frontend interface for launching, discovering, and managing Builder DAOs. It abstracts complex smart contract interactions into a clean and user-friendly experience, allowing individuals and communities to create and participate in DAOs without needing to write code. --- ## Platform Overview ### What It Does The platform serves as: - A **DAO launcher**: Create a fully onchain DAO in minutes. - A **management dashboard**: Interact with proposals, token auctions, and treasury funds. - A **discovery tool**: Browse and learn from other DAOs in the ecosystem. Everything that happens through the platform is executed onchain, making governance actions transparent and verifiable. --- ### Hosted vs. Self-Hosted Options There are two ways to interact with the protocol: ### 1. **Hosted (via nouns.build)** - **Fast and convenient**: No deployment or server required. - **Managed frontend**: All the logic is handled for you. - **Recommended for most users**: Ideal for creators and communities launching their first DAO. ### 2. **Self-Hosted** - **Customizable**: Modify branding, layout, or logic. - **Requires development skills**: You’ll need to fork the [open-source code](https://github.com/BuilderOSS/nouns-builder) and deploy it yourself. - **Ideal for advanced teams**: Great for DAOs with specific design or integration needs. --- ## DAO Discovery & Profiles ### How DAOs Appear and Are Categorized DAOs launched through the platform are publicly visible on the homepage and DAO index. They are typically sorted by: - **Launch date** - **Auction activity** - **Proposal volume** - **Treasury size** This allows users to explore and compare different DAOs across the Builder ecosystem. --- ### Profile Customization and Visibility Each DAO has its own profile page, featuring: - Token auctions - Proposal activity - Treasury overview - Governance settings DAOs can customize: - **Name and description** - **Banner image** - **Token artwork or visual logic (NFTs or static art)** These profiles act as a landing page for new members and voters. --- ## Feature Guide ### Launch Flow Walkthrough Launching a DAO on nouns.build takes only a few steps: 1. **Click “Launch a DAO”** 2. **Enter basic details**: Name, symbol, auction settings, governance rules 3. **Customize visuals**: Upload artwork or configure token rendering logic 4. **Deploy**: Confirm the transaction in your wallet to launch Once deployed, your DAO will begin auctioning its first token and be publicly visible on the site. --- ### Proposal Management UI The proposal interface makes it easy to: - Draft and submit proposals - View voting timelines and quorum status - Cast onchain votes directly through your wallet - Track executed proposals Each proposal page includes a live status indicator and transaction history for transparency.  --- ### Auction Dashboard and Analytics Every DAO has a real-time auction dashboard where you can: - View current and past auctions - Place bids - See top bidders - Track token issuance history Some DAOs integrate analytics dashboards (e.g., Dune) to visualize treasury growth, proposal metrics, and community engagement. --- ## Limitations & FAQs ### Known Issues and Feature Roadmap The nouns.build platform is rapidly evolving, but some current limitations include: - No built-in multisig or offchain voting options (requires integration) - Limited support for DAO-to-DAO relationships or delegation - Proposal templates are basic (no advanced formatting or attachments) Upcoming roadmap features may include: - Delegation and voting enhancements - Easier token art customization tools #### Confirmed Roadmap - **July 2025**: - Finalise SDK, including utils and hooks ([#574](https://github.com/BuilderOSS/nouns-builder/issues/574), [#575](https://github.com/BuilderOSS/nouns-builder/issues/575)) - **August 2025**: - Add "User votes", "User proposals", and voting history to a new "Activity" tab on profile page ([#318](https://github.com/BuilderOSS/nouns-builder/issues/318)) - **August–September 2025**: - Enable payment streaming through proposals (e.g. Sablier, Superfluid) ([#463](https://github.com/BuilderOSS/nouns-builder/issues/463)) - **TBD**: - Community-led Nouns Site template ([Noun Site repo](https://github.com/BuilderOSS/noun-site)) :::tip **Community Product Prioritisation Sessions** are held at least every two months, where you can advocate for your favourit feature to make it onto the short-term roadmap. ::: ### What Requires Direct Smart Contract Interaction While most actions can be done via the UI, some advanced tasks may require interacting directly with smart contracts: - Upgrading governance logic - Adding custom proposal logic/hooks - Migrating treasury assets across protocols - Advanced rendering configuration Developers can use tools like Etherscan, Hardhat, or the Builder SDK for deeper control. ## Image Configuration Source: https://docs.nouns.build/guides/img-config/ # Configuring the NFTs Images Every time an auction is started a new NFT image is randomly generated. These properties are first set when the DAO is created by providing a folder of artwork layers. Note, that the properties for the DAO NFTs are stored in a single folder on IPFS and then randomly generated using the image properties. Check out the [Example Artwork Toolkit](https://www.figma.com/community/file/1166768320345172833) to learn more about formatting the art for the DAO NFTs. ## Image Requirements - Maximum of 500 files - PNG and SVG are the only supported file types - 600px x 600px minimum for PNGs and 32px minimum for SVGs - Images must be square :::caution Currently no maximum image size is set on the frontend, which is **subject to change**. ::: ## Properties vs Items - `Properties:` Categories of different traits for the DAO NFTs - `Items:` Distinct images that make up a property 
## Seed Generation The seed is used to create a random combination of properties for the DAO NFTs. It is generated in the [Metadata Render Contract](https://github.com/BuilderOSS/nouns-protocol/blob/main/src/token/metadata/MetadataRenderer.sol#L329) by calling `_generateSeed` with the current tokenId and salting the hash with block data. ``` function _generateSeed(uint256 _tokenId) private view returns (uint256) { return uint256(keccak256(abi.encode(_tokenId, blockhash(block.number), block.coinbase, block.timestamp))); } ``` ## Adding Properties Once the properties have been uploaded to IPFS they then need to be added to the metadata render by calling `addProperties`. ``` /// @notice Adds properties and/or items to be pseudo-randomly chosen from during token minting /// @param _names The names of the properties to add /// @param _items The items to add to each property /// @param _ipfsGroup The IPFS base URI and extension function addProperties( string[] calldata _names, ItemParam[] calldata _items, IPFSGroup calldata _ipfsGroup ) external onlyOwner ``` ## Governance Source: https://docs.nouns.build/onboarding/governance/ Governance is the process through which Builder DAOs make decisions, allocate funds, and evolve over time. The Builder Protocol enables fully onchain, transparent governance where token holders can create, vote on, and execute proposals. This section explains how proposals work, how voting power is calculated, and the tools and practices that support effective DAO governance. --- ## 🗳️ Proposal Lifecycle ### Creating, Voting On, and Executing Proposals Governance proposals allow DAO members to make decisions about how the DAO operates or spends treasury funds. **The standard lifecycle:** 1. **Proposal Creation** - A member with the required number of tokens (proposal threshold) submits a proposal. - Proposals include a title, description, and one or more onchain actions (e.g., sending ETH, calling a contract). - After creation, the proposal enters the *voting delay* period. 2. **Voting Period** - Once active, DAO members can vote **FOR**, **AGAINST**, or **ABSTAIN** using their tokens. - Voting is open for a set period (e.g., 2–5 days), as configured during DAO setup. 3. **Execution** - If the proposal reaches quorum and has a majority of **FOR** votes, it becomes queueable. - Any user can then trigger the execution after a 48 hour delay, which carries out the proposed onchain actions. --- ## 🧮 Voting Power ### How Voting is Calculated Voting power in Builder DAOs is typically based on the number of governance tokens a member holds at the time a proposal is created. - **Snapshot Voting** The system takes a snapshot of token balances at proposal start to determine eligible voters and their weight. - **One Token = One Vote** Each token counts as one vote. In DAOs using NFTs, this might mean 1 NFT = 1 vote. In DAOs using ERC-20s, the weight is proportional to your token balance. This prevents manipulation by acquiring tokens after a proposal has already begun. --- ### Delegation Token holders who don’t want to vote on every proposal can **delegate** their voting power to another address. **Benefits of delegation:** - Enables active contributors to represent passive holders - Makes governance more efficient - Reduces voter apathy and improves quorum rates **How to delegate:** 1. Go to the DAO's governance interface 2. Choose a delegate address. 3. Confirm the transaction via your wallet.  --- ## 🧠 Governance Best Practices ### Proposal Formatting Well-structured proposals lead to more thoughtful discussion and greater chances of passing. **Suggested format:** - **Title:** Clear and concise - **Summary:** One-sentence overview of the proposal - **Context/Background:** Why this proposal matters - **Execution Details:** What exactly will happen if the proposal passes - **Budget (if applicable):** Requested amount, recipient, and use of funds Use plain language, break up text into sections, and include links or diagrams when helpful. A good proposal can be found [here](https://nouns.build/dao/base/0xe8af882f2f5c79580230710ac0e2344070099432/vote/43). --- ### Managing Community Engagement Governance isn’t just technical—it’s social. **Tips for encouraging participation:** - Share proposals early in community forums (e.g., Discord, Warpcast) - Host proposal Q&A or discussion calls - Recap passed proposals and share updates post-execution - Encourage respectful disagreement and open dialogue A healthy governance culture is built on transparency, inclusion, and consistent communication. --- ## 🛠️ Governance Tools ### Builder Voting, or Custom Interfaces Builder DAOs can use a variety of interfaces to manage and interact with governance proposals: ### **1. Voting through Nouns.build** - Minimal and fast - Built directly into [nouns.build](http://nouns.build/) - Great for DAOs that want a simple, no-frills solution ### 2. **Custom Interfaces** - DAOs can fork and customize their own governance UIs - Useful for projects with unique branding or voting logic - Requires frontend development experience Choose the tool that best fits your community’s needs and technical capacity. ## Changing and Adding Artwork Source: https://docs.nouns.build/guides/artworks/ This guide covers the proposal types for modifying artwork in your Nouns Builder DAO: **Replace Artwork** (also known as Change Artwork) and **Add Artwork**. These features allow DAOs to update or expand their generative NFT artwork. Note that all changes require a proposal to be created, voted on, and executed on-chain. Artwork in Nouns Builder is structured in layers (traits or properties), with each layer containing multiple variants (items). The system uses IPFS for storage and an on-chain metadata renderer to compose NFTs generatively. ## Overview - **Layers (Traits/Properties)**: Up to 15 maximum, e.g., background, body, accessories - **Variants (Items)**: No hard contract limit per layer, but practical limits apply due to upload constraints. - **Process**: Changes are additive and immutable on IPFS. You cannot delete existing artwork; replacements or additions are the only options. - **Proposal Flow**: Use the proposal creation interface on nouns.build. Upload folders must follow a specific structure (e.g., numbered folders for layers, with variants inside). Refer to the [Configuring the NFT's Images guide](/guides/img-config) to learn how to set up your NFT artwork. ## Replace Artwork Proposal This proposal type replaces the entire artwork set for your DAO. It is ideal for major overhauls, such as changing file types, dimensions, or replacing multiple variants. ### Steps 1. Navigate to your DAO on nouns.build and select "Create Proposal". 2. Choose the "Replace Artwork" template. 3. Upload your artwork folder: - Structure: Organize into subfolders (e.g., `0-background/`, `1-body/`) containing variant files. - File type: All files in the replacement set must share a single type (PNG, SVG, or GIF). You may change the collection’s overall type in a Replace Artwork proposal, but mixing types within the same set is not supported. - Ensure the total directory size is under 200 MB. 4. Validate the upload: The interface will check layer ordering and variant counts. 5. Submit the proposal for voting and execution. ### Use Cases - Overhauling the entire collection, e.g., replacing **ALL** existing art, or switching file types. - Replacing a single variant (requires re-uploading all artwork with the change). - Adjusting dimensions or file types across the board. ### Limitations - You must re-upload the entire artwork set; selective changes are not supported. - Existing tokens may render updated assets if your renderer retrieves files on-chain rather than using cached snapshots. Test your renderer’s behavior on staging before proposing changes. - To “remove” a variant, replace it with a transparent file; note this can cause visual issues for already-minted NFTs when that variant is rendered. - File type: all files in a single Replace Artwork proposal must share one format. You may switch the collection’s overall file type by replacing the entire set, but do not mix formats within one proposal. ## Add Artwork Proposal This proposal type adds new variants to existing layers or introduces entirely new layers. It is additive and does not replace the full set. ### Steps 1. Navigate to your DAO on nouns.build and select "Create Proposal". 2. Choose the "Add Artwork" template. 3. Upload your new artwork folder: - Structure: Use subfolders matching existing layer names to add variants (e.g., `background/` for new backgrounds). - To add a new layer, use a new folder name (e.g., `hats/`). - Folders with the same name as existing layers will append variants. 4. Validate the upload: Ensure compatibility with existing artwork (e.g., same file type and dimensions). 5. Submit the proposal for voting and execution. ### Use Cases - Expanding a layer with new variants (e.g., adding new backgrounds). - Introducing a new layer (e.g., adding "hats" to an existing collection). - Adding multiple variants across different layers in one proposal. - Note: Add Artwork does not support mixing file types within the same collection. To change file type (e.g., PNG → GIF), use a Replace Artwork proposal. :::note Although the folder structure must also be consistent with previous uploads when adding artwork, not all files need to be reuploaded. In other words, when adding artwork only the artwork to be added must be uploaded, but follow the existing folder structure. ::: ### Limitations - Cannot delete or replace existing variants; additions only. - Dimensions must match existing artwork. - Layer ordering: New layers are appended; ensure correct sequencing in the upload. - If adding to multiple layers, include each layer as its own folder in one upload batch. Avoid duplicate filenames within a layer; uploader behavior may overwrite or fail—do not rely on it. - Large additions (e.g., >500 variants per layer) may hit transaction/upload limits; test on staging. ## General Limitations - **Maximum Layers**: 15 (hard contract limit). - **Variants per layer**: No contract limit. Operationally, we recommend 150–200 variants per layer to avoid upload issues. We have tested up to ~250 variants per layer. - **File Count and Size**: - Total directory: Up to 200 MB. - Individual media files: Up to 50 MB. - File limit: As of August 2025, the v3 Pinata API reliably handles ~150 files per batch in our flows. We are temporarily using the legacy API to improve stability; this may change—check release notes before large uploads. - **Immutability**: Once uploaded to IPFS, content cannot be deleted. Use transparent files for "removals," but test thoroughly. - **Rendering impact**: Future mints will use the updated assets. Already-minted tokens may or may not change depending on your renderer (on-chain retrieval vs. cached snapshots). Verify on staging before proposing changes. - **Testing**: Always test (**extensively!**) on testnets first (testnet.nouns.build) before mainnet proposals. - **Complex Scenarios**: Adding GIFs or mixing types requires replacing all artwork. Untested for varying GIF durations or frame rates. :::caution The upload of GIF file types is currently only available on staging as **PROTOTYPICAL** implementation. Please proceed with caution, as this feature is not yet cleared for production and **ACTIVELY** worked on. ::: ## Supported File Types Collections use a single file type across all layers at a time. To change the collection’s file type (e.g., PNG → GIF), submit a Replace Artwork proposal. Each Add/Replace transaction must contain a single file type (PNG, SVG, or GIF). - **PNG**: Standard for static layers. - **SVG**: Vector-based; supported for scalability. - **GIF**: Animated; **PROTOTYPICAL IMPLEMENTATION—staging only**. If using GIFs, the entire replacement set must be GIF (convert static layers to single‑frame GIFs as needed). ## DAO Operations and Tools Source: https://docs.nouns.build/onboarding/dao-ops/ Builder DAOs thrive on active coordination, transparent execution, and engaged community participation. This section covers the core operational tools and workflows needed to run your DAO smoothly—from daily tasks to analytics and off-chain collaboration. --- ## 🛠️ Daily Operations ### Moderation, Bot Management, and Announcement Workflows Keeping your DAO organized and safe begins with clear communication and consistent moderation. **Moderation tasks:** - Maintain Discord and Warpcast channels for civil, on-topic discussion. - Assign roles (e.g. voter, contributor, core team) with specific permissions. - Enforce community guidelines and escalate disputes if needed. **Bot management:** - Use bots like **Gnosis Safe Notifier**, **DAO Activity Pings**, or **Builder Voting Alerts** to automate proposal and auction updates. - Integrate **Propdate** or **Warpcast Bots** for governance notifications. **Announcements:** - Pin important updates in Discord or Warpcast. - Use recurring governance digests to summarize activity and drive participation. --- ### Handling Auctions, Votes, and Proposals Most Builder DAOs run a 24-hour auction cycle for minting new governance tokens. Here's how to manage and monitor auction-related governance tasks: **Auctions** - Track auction start/end times on [nouns.build](https://nouns.build/). - Share current auction links and encourage bidding. - Announce winners and welcome new token holders. **Votes & Proposals** - Guide members through the proposal lifecycle: draft → discussion → onchain submission → vote → execution. - Use templates to standardize proposals and help contributors stay consistent. --- ## 🧾 Multisig Management ### Setting Up Gnosis Safe and Transaction Workflows For offchain assets (like USDC or grants), use a **Gnosis Safe** multisig to hold and manage funds securely. **Setup steps:** 1. Go to [gnosis-safe.io](https://gnosis-safe.io/) and create a new safe. 2. Add DAO signers (e.g. 3-of-5 core contributors). 3. Fund the safe with treasury tokens or ETH. 4. Create and execute transactions with signer approval. **Best practices:** - Rotate signers if roles change. - Keep the Safe address public and verifiable in DAO docs. --- ### Using Zodiac or Third-Party Tools for Off-Chain Voting Builder DAOs can extend governance via **Zodiac**, allowing offchain decisions to be executed onchain via Gnosis Safe modules. **Use Cases:** - Approve proposals via Snapshot and execute via Zodiac. - Allow subcommittees or working groups to manage smaller budgets. **Other tools:** - **SafeSnap** – Snapshot voting that triggers onchain actions via Gnosis Safe. - **Coordinape** or **Clarity** – For contributor compensation and voting-based allocations. --- ## 📊 Analytics & Reporting ### Suggested KPIs for DAO Health Tracking the right metrics helps you understand what’s working and where support is needed. **Key DAO health indicators:** - Proposal submission rate - Proposal pass/fail ratio - Voting participation (active wallets / total supply) - Treasury inflows/outflows - Auction revenue per cycle - Community growth (Discord, Warpcast, email, etc.) Track these monthly to maintain transparency and inform strategy. --- ### Tools: Dune, Builder Explorer, and Custom Dashboards **Dune Analytics** - Prebuilt or custom SQL dashboards using indexed onchain data. - Great for visualizing auctions, treasury trends, and token distribution. **Nouns Builder** - Lightweight web interface to explore Builder DAOs, proposals, and auctions. - Useful for internal review or investor/stakeholder overviews. **Custom Dashboards** - Use the Builder SDK + Subgraph for tailored analytics tools. - Embed charts into Notion, Webflow, or community websites. --- ## 🤝 Community Coordination ### Event Planning Hosting regular events keeps your community active and engaged. **Types of events:** - Weekly community calls (proposal previews, Q&A, show-and-tell) - Governance hackathons or bounties - DAO onboarding walkthroughs - IRL meetups or sponsored activations at crypto conferences **Planning tips:** - Assign a lead or team for coordination. - Use shared docs or Notion for logistics. - Publicize events across Discord, Warpcast, and Twitter. --- ### Grants and Bounties Builder DAOs often distribute funding through: - **Grants**: For larger projects aligned with DAO goals. - **Bounties**: Smaller, task-based rewards for quick contributions. **Workflow:** 1. Draft grant/bounty scope 2. Publish in Discord, Notion, or a Prop House round 3. Evaluate submissions or applicants 4. Distribute funds and report outcomes **Tools to explore:** - [Prop House](https://prop.house/) - [CharmVerse](https://charmverse.io/) - [Dework](https://dework.xyz/) ## Auctions Source: https://docs.nouns.build/guides/auctions/ ##### Bidding and Settling an Auction --- Auctions play a key role in a DAO as the main form of perpetual funding. The frequency of an auction is set by the founder when the DAO is created. Once the DAO has been initialized it will hand over control of the auction house to the treasury and start the first auction. - `Duration:` How long an auction runs/how often a new NFT is created - `Reserve Price:` Min bid amount required to start an auction - `Min Bid Increment:` The min percent greater a bid must be than the current highest bid to be valid. Nouns builder default sets the minBidIncrement to 10%. For example, if the current highest bid is 1 ETH and then the next bid must be 1.1 ETH or greater - `Buffer:` The time window in the final minutes of an auction when a new bid can reset the timer. The default time buffer is 5 minutes, meaning that a bid in the last 5 minutes of the auction resets the timer to 5 minutes. ## Creating a Bid Anyone can create a bid by calling `createBid` and passing in the tokenId of the NFT that is currently being sold. Note, submitting a bid within the range of the buffer time will reset the auction timer to the buffer time. The DAO defaults to a 5-minute buffer meaning that a bid in the last 5 minutes of the auction resets the timer to 5 minutes. Also, a bid must be equal to or greater than the `minBidIncrement` amount which is set to 10% in the DAO by default. For example, if the current highest bid is 1 ETH and the `minBidIncrement` is set to 10% then the next bid must be 1.1 ETH or greater. ``` // @notice Creates a bid on an NFT. Note the ETH is sent in the value field of a transaction. function createBid(uint256 _tokenId) external payable nonReentrant ``` ## Starting and Settling an Auction Once the first auction has been started by initializing the DAO, perpetual auctions are set into motion. Setting the auction is done by calling `settleCurrentAndCreateNewAuction` which allows the winner to claim the NFT. In addition, the same transaction mints and starts the next auction for a new NFT. ``` /// @notice Settles the current auction and creates the next one function settleCurrentAndCreateNewAuction() external nonReentrant whenNotPaused { _settleAuction(); _createAuction(); } ``` ## Technical Documentation Source: https://docs.nouns.build/onboarding/technical-documentation/ This section provides a deep dive into the technical foundation of Builder DAOs, including smart contract architecture, developer tools, and supported infrastructure. Whether you're customizing your DAO, integrating it with other applications, or simply learning how it works under the hood, this guide will help you get started. :::tip[For Developers] If you want to get an in depth technical perspective, please head to the [Contributor Guide](/contributors/intro-contributors). ::: ## 🔗 Smart Contract Reference ### Core Contracts and Interfaces The Nouns Builder Protocol is made up of modular, upgradeable contracts designed to work together to create and manage fully onchain DAOs. **Key contracts:** - `Auction`: Handles token auctions, bidding logic, and minting of new governance tokens. - `Token`: ERC-721 (NFT) or ERC-20 (fungible) token contract representing DAO membership and voting power. - `Governor`: Manages proposals, voting logic, and execution of onchain actions. - `Treasury`: Holds ETH or other native tokens for the DAO and executes approved spending. - `Metadata Renderer`: Controls how token metadata is rendered (e.g., static art, generative logic). **Standard interfaces include:** - `IAuction` - `IGovernor` - `IToken` - `IMetadataRenderer` These follow common patterns established by Nouns DAO and OpenZeppelin standards for interoperability. --- ### Upgrade Paths and Governance Hooks The protocol is **upgradeable** using proxy contracts (via OpenZeppelin’s UUPS or Transparent proxies), allowing Builder DAOs to evolve over time. **Upgrade mechanics:** - Proposals can include contract upgrades by specifying new implementation addresses. - DAOs must hold sufficient voting power and pass the proposal onchain. - Upgrades affect logic contracts but preserve storage and state via the proxy. **Governance hooks** are extension points for advanced functionality: - Proposal execution hooks - Auction settlement hooks - Metadata customization and trait updates These allow power users to inject custom logic or bridge to external contracts. ## 📊 Subgraph and APIs ### Using the Builder Subgraph The protocol provides a [GraphQL subgraph](https://thegraph.com/) that indexes onchain events such as: - New auctions - Proposal lifecycle events - Treasury transfers - Token mints **Example query: Fetch latest auctions** ```graphql graphql CopyEdit { auctions(first: 5, orderBy: startTime, orderDirection: desc) { id startTime endTime highestBid } } ``` ### REST and GraphQL APIs Available While the subgraph is the primary source of indexed data, DAOs and developers can also use: - **Builder REST API** (coming soon): Useful for integration with low-code platforms and mobile apps. - **GraphQL API**: Preferred for web interfaces and data dashboards. - **Onchain reads**: For real-time, trustless data via JSON-RPC (e.g., `eth_call`). --- ## 🚀 Deployment Details ### Supported Chains Builder DAOs can be deployed on any EVM-compatible chain. Official support currently includes: - **Ethereum Mainnet** - **Optimism** - **Base** - **Zora Network** **Testnets:** - Ethereum Sepolia - Optimism Sepolia - Base Sepolia - Zora Sepolia Chain selection affects gas costs, UX, and community reach. Most DAOs currently launch on low-cost L2s like Base or Optimism. --- ### Gas and Cost Considerations **Key cost components:** - **DAO Deployment**: ~0.1–0.2 ETH (varies by chain) - **Auction Bids**: Transaction fees per bid and settlement - **Proposal Actions**: Voting and execution transactions - **Metadata Rendering**: If using generative or dynamic logic **Tips to save gas:** - Launch on a Layer 2 like Base - Use static metadata rendering - Minimize external calls in proposals ## Mint Governance Tokens Source: https://docs.nouns.build/guides/mint_gov_tokens/ ## Creating a Proposal to Mint Governance Tokens The **Mint Governance Tokens** proposal type enables DAOs to distribute governance tokens directly to specified addresses via on-chain proposals. This is particularly useful for migrations, bootstrapping membership, or rewarding contributors. Minting is executed through the token contract and **can occur even if auctions are paused**, as it does not interact with the auction mechanism.
## Step-by-step Guide
1. Navigate to the **Activity** section in your DAO and click **Create Proposal**.
2. On the Add Transactions step, select **Mint Governance Tokens** from the transaction type dropdown.
3. Add recipients manually or via CSV upload.
4. Specify the number of tokens per recipient (must be a positive integer).
5. Review the live summary beneath the Recipients label, which displays the total recipient
count and total tokens to be distributed, and updates as recipients are added or removed.
6. Click **Add Transaction to Queue**, then proceed to submit the proposal for voting.
7. Once passed and executed, tokens are minted and transferred in batched transactions.
### Manual Entry
For smaller distributions, add recipients directly via the form:
- Enter a valid Ethereum address or ENS name in the **Address** field.
- Specify the token amount (positive integer) in the **Amount** field.
- Click **Add Recipient** to include additional entries.
- Recipients can be edited or removed individually.
- ENS names are resolved per recipient during submission.
### Using CSV Upload
For larger distributions, use the CSV upload feature:
- Click **Download Template** to get a pre-formatted CSV with the required `address` and
`amount` headers.
- Populate the file with valid Ethereum addresses (or ENS names, resolved on submission)
and positive integer amounts.
- Upload via drag-and-drop into the upload area, or click to browse for the file.
- The form parses the CSV, validates entries, and reports errors inline.
- A maximum of 100 recipients per CSV is enforced to avoid gas limits. For larger
distributions, add multiple Mint Governance Tokens transactions within the same proposal.
Example CSV structure:
```csv
address,amount
0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e,10
0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe,25
```
Validation ensures no more than 100 rows per CSV and enforces the required headers. Errors
are displayed inline and submission is disabled until all entries are resolved.
## Limitations and Best Practices
:::caution
CSV uploads are limited to 100 recipients per transaction due to gas constraints. For larger
distributions, queue multiple Mint Governance Tokens transactions within a single proposal —
but be aware that a very large number of transactions may exceed the block gas limit, causing
execution to fail. Test on testnet before submitting large distributions to mainnet.
:::
:::note
Token mints cannot be undone once a proposal is executed. Verify all addresses carefully
before submitting.
:::
## Final Remarks
- For migrations from existing collections, consider taking a holder snapshot before minting,
to accurately capture current membership.
- Minting governance tokens does not unpause auctions. The two mechanisms are independent.
- Newly minted tokens do not affect quorum or threshold calculations until they have been
delegated by their recipients.
:::tip
Looking to distribute tokens via a Sablier merkle campaign instead? Use the
**Airdrop Tokens** proposal type, available in the same transaction type dropdown.
:::
## Community and Support
Source: https://docs.nouns.build/onboarding/community-support/
Builder DAO is more than a protocol—it's a community of creators, builders, and organizers. Whether you’re new to the space or looking to contribute more deeply, this section will guide you through how to get connected, find support, and start contributing.
---
## 💬 Discord Channels & Roles
### How to Join
The Builder DAO Discord is the central hub for discussion, coordination, and support.
**To join:**
1. Visit [discord.gg/f845eBCyyb](https://discord.gg/f845eBCyyb)
2. Connect your wallet (if prompted)
3. Introduce yourself in the #introductions channel!
### Key Channels
- `#announcements`: Official updates, proposals, and events
- `#general`: Open discussion and questions
- `#support`: Technical or operational help
- `#governance`: Proposal drafts, voting discussion
- `#builders`: Dev chat and protocol-related coordination
- `#community-calls`: Meeting links, agendas, and recordings
### Common Roles
- **Builder** – General contributor role
- **Core** – Ongoing contributors and maintainers
- **Council** – Elected or delegated leaders
- **Newcomer** – Recently joined members (default)
- **Bot** – Automated bots for alerts and updates
Roles help manage permissions and direct people to the right working groups.
---
## 📣 Farcaster Channel Guide
Warpcast is the Farcaster-native social app where many Builder DAO discussions take place. It offers a more open and decentralized alternative to Twitter/X.
### How to Participate
1. Sign up at [farcaster.xyz](https://www.farcaster.xyz/)
2. Search for the `builder` channel
3. Follow, cast, and reply to join the conversation
### What You’ll Find
- Auction alerts and proposal links
- Governance discussions and vote reminders
- Community memes, events, and DAO milestones
- Cross-posts from other Builder DAOs (e.g. Purple, Collective Nouns)
**Tip**: Turn on notifications for the channel to stay in the loop.
---
## 🏗️ Open Bounties & Opportunities
Builder DAO and its affiliated communities often fund work through open bounties, grants, or contributor roles.
### How to Find Opportunities
- Browse Prop House rounds
- Look at Notion or Airtable contributor boards (linked in Discord pins)
- Subscribe to the Builder Buzz newsletter for contributor calls
### Types of Opportunities
- Technical tasks (SDK updates, frontend fixes)
- Design and branding contributions
- Governance facilitation or proposal writing
- IRL event coordination
- Content, memes, and newsletters
**Tip**: Start small. Complete a bounty, then join a working group!
---
## 🆘 How to Get Help / Report Issues
Whether you're stuck on a wallet connection, proposal logic, or just navigating the platform—help is always available.
### Where to Ask
- `#general-chat` channel in Discord (best for quick responses)
- Create a Warpcast post in the `builder` channel
- DM a mod or council member (only if urgent or sensitive)
- Open a GitHub issue (for SDK, contracts, or frontend bugs)
### Emergency Issues
If you suspect:
- A bug affecting auctions or governance
- A malicious contract or exploit
- A compromised account or mod
Ping a `Ops` or `Tech Pod` member immediately in Discord.
---
## 🧭 Contributor Guide
Interested in going deeper? Here’s how to become a regular contributor.
### Step-by-Step
1. **Introduce Yourself**: Share your background in `#share-your-dao`
2. **Join a Call**: Weekly calls are posted in `#announcements`
3. **Pick a Lane**:
- Governance
- Community
- Dev/Tooling
- Design/Comms
4. **Complete a Task**: Start with a bounty or help in support threads
5. **Stay Consistent**: Show up, contribute, and communicate
6. **Apply for a Grant or Proposal**: If you're adding value, Builder DAO can fund you!
## How to Create an Escrow Proposal
Source: https://docs.nouns.build/guides/builder-escrow-proposal/
## Overview
The Escrow Builder Proposal enables Nouns Builders to create proposals for milestone-based grants that enhances accountability and transparency within Nouns Builder DAOs. This upgrade leverages Smart Invoice's escrow and arbitration features, empowering DAOs to proactively manage funds tied to deliverables. A brief demo of the functionality can be found [here](https://www.loom.com/share/d1a42ab110b94c7e8df8ec6452dd3669?sid=b4b5399f-f706-4b1a-8b80-097cab658769).
## Key Terms
- **`Escrow Proposal`**: A proposal type allowing funds to be allocated and released based on defined milestones.
- **`Safety Valve`**: Ensures funds are not stuck in escrow and can be withdrawn after the safety valve date passes.
- **`Milestone`**: A defined deliverable or objective that triggers the release of a portion of escrowed funds.
- **`Arbitration`**: The resolution process for disputes regarding milestones or fund releases.
- **`Proposal Submission`**: The process of creating, reviewing, and submitting an Escrow Proposal.
- **`Attestation`**: The process of formally verifying delegation authority using the Ethereum Attestation Service (EAS).
- **`Delegation`**: The act of assigning fund release authority to a "Client" address that is different from the DAO address.
- **`Release`**: The action of transferring funds from escrow upon the successful completion of a milestone.
- **`Client`**: The entity responsible for managing and withdrawing funds from the escrow after milestones are met.
- **`Recipient`**: The wallet address or entity receiving funds allocated for milestones.
---
## Creating an Escrow Proposal
Functionally Funds are secured in escrow and released upon milestone completion. Milestone releases can be requested under the milestone management page.
### Step 1: Select the Escrow Proposal Type
1. Navigate to the **`Activity`** section in the Nouns Builder dashboard.
2. Click **`Create Proposal`** and choose **`Escrow Milestones`** from the proposal type menu.
### Step 2: Add Recipient and Safety Valve
1. Enter the recipient's wallet address (e.g., `vitalik.eth`).
2. Set a **`safety valve date`** to ensure funds are locked for at least 30 days.
- Use the calendar picker to select the appropriate date.
- Ensures that funds are not stuck in escrow and can be withdrawn after the safety valve date passed. Once the selected Safety Valve Date is passed, the client can withdraw the funds out of the escrow and back into their own wallet. The safety valve must be a minimum of 30 days after invoice creation date or the last milestone date, whatever is later.
### Step 3: Define Milestones
1. User can add and configure as many milestones as needed by using the `Create Milestone` functionality. Configuration options include `amount`, `title`, `description`, `delivery date`, and optional `media uploads`. For each milestone, provide:
- **`Title`**: A descriptive name for the milestone (e.g., "Milestone 1").
- **`Description`**: Details about the milestone deliverables.
- **`Delivery Date`**: The expected completion date for the milestone.
- **`Amount`**: The allocated funds for the milestone.
- Optional: Upload media files to enhance milestone descriptions.
2. Add additional milestones as needed. The **Total Escrow Amount** will automatically update.
3. The appropriate arbitration provider is selected automatically and displayed in the top right corner of the proposal builder page.
- Internal arbitration by Smart Invoice for amounts below $1,000.
- Kleros arbitration for amounts exceeding $1,000.
### Step 4: Review and Submit
1. Ensure the **`Safety Valve Date`** is at least 30 days after the final milestone.
2. Scroll to the end of the page and select **`Add Transaction to Queue`** and wait for the confirmation **"`n` transactions queued"**.
3. Once your transaction was queued, select **`Continue`**. You are being redirected to the next screen.
4. Add a **`Proposal Title`** and **`Summary`** to add the actual proposal content.
3. Click **`Submit Proposal`** to finalize the submission.
Add a title and a proposal summary according to the Nouns Builder proposal template. Refer to the [proposal writing guide](https://paragraph.xyz/@nounishprof/howtoprop) and the [Nouns Builder proposal template](https://hackmd.io/@profwerder/builderdaotemplate) for further information.
### Release Milestone Flow
Milestones can be released using the "Release Milestone" button. This action moves funds allocated to the milestone from escrow to the recipient's wallet. DAO members can vote on the milestone release proposal before execution.
1. Navigate to the **Proposal Details** page to review the associated milestones.
2. Select the milestone to release and click **"Release Milestone"**.
3. You are being redirected to the proposal screen. Describe your deliverables and substantiate the release. Then submit the transaction.
3. DAO voting or multisig approval is required before funds are transferred.
:::tip[Conditional UI]
Depending on the release authority (delegate vs. DAO) you will only be shown the release button if you are logged in with the appropriate wallet.
Once you click `Release` with a multisig as delegate, you will be redirected to the Safe frontend, where you must **whitelist [smartinvoice.xyz](https://smartinvoice.xyz) as a Safe App**.
For further documentation on the release flow, please visit the [SmartInvoice Docs](https://www.smartinvoice.xyz/tutorials/client/release-escrow-funds-inside-milestone).
:::
---
## Delegating Release Authority
Delegation streamlines milestone management by allowing DAOs to assign fund release authority to specific entities. Attestation for this process occurs separately from the proposal builder, enabling predefined entities to securely confirm their roles and ensure transparent governance.
Attestations can be made by the following entities in this order of priority:
1. **DAO’s Own Treasury Address** (specific to each DAO)
2. **Builder DAO Treasury (`0xcf325a4c78912216249b818521b0798a0f904c10`)**
3. **Builder DAO Operations Multisig (`0x58eAEfBEd9EEFbC564E302D0AfAE0B113E42eAb3`)**
4. **Smart Invoice Multisig (`0xD609883e5eb442d364Aa57369224bE839A38C6f9`)**
:::tip[Use Nouns Builder Proposals for Delegation]
You can now use a proposal template on Nouns Builder to nominate a delegate for releasing escrowed milestones.
:::
### How Attestations Use EAS (Ethereum Attestation Service)
This separate attestation flow ensures that all delegations are securely recorded, verifiable, and aligned with DAO governance protocols. If additional attestations or attesters are required for a DAO on Nouns.Builder, DAOs should contact Builder DAO or the SmartInvoice Team for assistance.
#### Attestation Flow
- Each attestation follows the schema ID `0x1289c5f988998891af7416d83820c40ba1c6f5ba31467f2e611172334dc53a0e`.
- EAS verifies attestations to confirm delegation authority.
- Users can query the EAS registry to view or verify attestations for a specific DAO address.
#### Attestation Usage
1. The attestation **MUST** be done on same chain as where dao exists.
2. The schema only has `daoMultisig` address, which is the delegated address. The recipient **MUST** be the DAO token address.
---
## Further Reading
### FAQ
#### Why is a safety valve required?
The safety valve locks funds for a minimum of 30 days, ensuring sufficient time for review and dispute resolution.
#### Can this proposal type handle non-milestone grants?
While you can create proposals with only one milestone, for direct release proposals you should choose the appropriate proposal type.
#### What happens during a dispute?
- For amounts below $1,000, disputes are resolved internally by Smart Invoice.
- For amounts exceeding $1,000, disputes are escalated to Kleros for arbitration.
- To create a dispute, you first must locate the escrow using its address.
- Then visit `https://app.smartinvoice.xyz/invoice/base/ESCROW_ADDRESS`.
- Replace `ESCROW_ADDRESS` with the relevant escrow address.
- Connect your **Recipient** wallet and click **`Lock funds`**.
---
### Architecture
---
### Links
- [Smart Invoice Documentation](https://www.smartinvoice.xyz/)
- [Nouns Builder Documentation Repository](https://github.com/SmartInvoiceXYZ/nouns-builder-docs)
- [Smart Invoice App](https://app.smartinvoice.xyz/)
- [Kleros Arbitration Policy](https://docs.smartinvoice.xyz/arbitration/kleros-arbitration)
- [Smart Invoice Arbitration Infrastructure](https://docs.smartinvoice.xyz/arbitration/arbitration-infra)
### Support
Smart Invoice provides dedicated support for Nouns Builder DAOs. Users can contact Smart Invoice via the support channel with a 24-hour response time for any issues related to escrow, arbitration, or proposal submission.
For additional support, reach out via [Discord](https://discord.gg/eDb4frFuym) or email at [team@smartinvoice.xyz](mailto:team@smartinvoice.xyz).
## Use Cases and Examples
Source: https://docs.nouns.build/onboarding/examples/
The Builder Protocol is flexible by design, enabling DAOs to experiment with governance, art, community models, and funding strategies. This section highlights notable Builder DAOs, explains how to customize your own DAO, and explores how Builder DAOs integrate with other tools in the web3 ecosystem.
---
## 🌟 Successful Builder DAOs
### Case Studies
### **Purple**
Purple is a DAO built on Builder Protocol that governs a community supporting [Farcaster](https://www.farcaster.xyz/), the decentralized social network. It focuses on funding public goods and growing the Farcaster ecosystem through grants, events, and content.
- **Unique Features**: Proposal-based funding rounds, community media initiatives
- **Outcome**: Catalyzed developer interest in Farcaster and helped establish ecosystem norms
---
### **Nouns Esports**
Nouns Esports launched as a Builder DAO to bring web3-native branding into competitive gaming. It funds esports teams, tournaments, and player sponsorships under the Nouns IP.
- **Unique Features**: Athlete and team sponsorship via DAO governance
- **Outcome**: Expanded Nouns brand awareness through high-profile esports activations
---
### **Collective Nouns**
Collective Nouns is a Builder DAO focused on public goods, storytelling, and creative coordination. It was designed as a community-native extension of the Nouns ecosystem, using Builder Protocol to explore new models for narrative building and cultural experimentation.
- **Unique Features**: Collaborative lore-building, art commissions, and themed auctions
- **Notable Projects**: *Nouns Comic*, *Nounish Propaganda Packs*, cross-DAO art initiatives
- **Outcome**: Created a culture-forward subDAO model that merges creative expression with governance
---
### **Gnars DAO**
Gnars DAO is a Builder DAO launched by members of the Nouns and action sports communities to support athletes, events, and creators in skateboarding, snowboarding, BMX, and beyond. Built on the same auction mechanics as Nouns, it uses governance to sponsor extreme sports culture in an onchain-native way.
- **Unique Features**: Athlete sponsorships, branded gear, video bounties, IRL events
- **Notable Campaigns**: Gnarcade at NFT NYC, video contests, athlete onboarding with daily token incentives
- **Outcome**: Expanded the Nouniverse into youth culture and action sports, pioneering DAO-powered sponsorship
---
### **Kendama DAO**
Kendama DAO was launched to merge the global kendama community with onchain coordination. It funds creative kendama projects, supports players, and hosts DAO-powered activations at Web3 events, using Builder Protocol to promote mindfulness, creativity, and play.
- **Unique Features**: Real-world gear giveaways, mental health nonprofit collabs, educational content
- **Notable Initiatives**: *Mindfulness Through Play* workshops, Nouns-themed kendama drops, NFT scavenger hunts using POAPs and IYK devices
- **Outcome**: Introduced thousands of people to Web3 through in-person play, events, and physical-digital integrations
---
### Lessons Learned
From these DAOs, we can observe several patterns:
- **Clarity of purpose leads to engagement**: DAOs with strong missions (e.g. supporting Farcaster, esports, local communities) attract more aligned contributors.
- **Flexible tooling supports growth**: Builder DAOs can evolve from small experiments to full-scale communities.
- **Onchain transparency builds trust**: Voters can always verify where funds go and who is participating.
---
## 🛠️ Customizing Your DAO
### Changing Parameters
Builder DAOs are initialized with governance and auction parameters, but most of these can be changed via proposal after launch:
- **Auction duration**
- **Quorum threshold**
- **Voting delay/period**
- **Proposal threshold**
**How to update parameters:**
1. Draft a proposal using the DAO’s frontend or SDK
2. Specify new parameter values as onchain calls
3. Submit and pass the proposal
---
### Upgrading Visual Identity (Art, Metadata)
Builder Protocol allows full customization of how your DAO's tokens look and behave:
**Options include:**
- **Static Images**: Upload your own artwork or logo
- **Dynamic Metadata**: Use generative art or trait-based logic (common in NFT communities)
- **Metadata Renderer Upgrades**: Deploy a new renderer and update via proposal
**Tips for strong visual identity:**
- Align artwork with your DAO’s mission or vibe
- Use color and iconography that’s recognizable across platforms
- Collaborate with artists in your community
---
## 🔌 Ecosystem Integrations
### POAPs (Proof of Attendance Protocol)
Builder DAOs can use POAPs to reward participation at events or governance milestones. For example:
- Give a POAP to voters in a key proposal
- Distribute POAPs during IRL meetups or community calls
POAPs help gamify participation and foster collector culture within your DAO.
---
### Farcaster
Builder DAOs frequently coordinate on [Farcaster](https://www.farcaster.xyz/), the decentralized social network. You can:
- Create a DAO-specific channel
- Post governance updates, auction links, and discussions
- Use reactions and replies for informal signaling
Some DAOs even delegate voting power based on Farcaster reputation or activity.
---
### Onchain Art and NFTs
Many Builder DAOs use onchain art to:
- Embed metadata traits into token auctions
- Incentivize participation with art-based drops
- Collaborate with artists for limited edition series
You can deploy custom metadata renderers, use `tokenURI` hooks, or collaborate with generative artists to create new experiences.
## ERC-721 Drop Proposal (Droposal)
Source: https://docs.nouns.build/guides/droposals/
:::caution
As Zora pivoted from non-fungible tokens to ERC-20-based posts ("coining"), **droposals are no longer supported on the Zora app**. The ERC-721 Droposal standard is a legacy format. Builder has reinstated legacy support so that existing droposals remain mintable and discoverable, and DAOs can continue creating new content. Nonetheless, we encourage communities to consider using a [Content Coin proposal](/guides/coining/) instead.
The technical reference below was adapted from [Zora's archived documentation](https://web.archive.org/web/20250124141839/https://docs.zora.co/contracts/ERC721Drop).
:::
:::tip
[GnarsDAO](https://www.gnars.com/droposals) has built a custom [frontend](https://www.gnars.com/droposals/droposals) to support droposals and is the best point of contact for learning how to continue using them. The Gnars code implementing droposals can be found [here](https://github.com/sktbrd/gnars-terminal/blob/main/src/app/droposal/%5BcontractAddress%5D/page.tsx).
:::
## Overview
A droposal is an ERC-721 Drop Proposal — an on-chain DAO proposal that, if passed, deploys a new NFT collection contract and makes it available for public minting. The contract is based on Zora's `ERC721Drop` standard.
Builder has reinstated legacy support for droposals alongside the launch of the coining feature. This means:
- **Standalone mint pages** are available for every droposal, allowing creators to share a direct minting link with their audience.
- **Droposals appear in the DAO Gallery** tab, tagged with a **Drop** badge, so they remain discoverable alongside other DAO content.
New droposals can still be created via the **Droposal: Single Edition** transaction type in the proposal builder.
## Standalone Mint Page
Every droposal has a dedicated public mint page at: `nouns.build/drop/[chain]/[contractAddress]`
This page shows the collection media, title, creator, price, and a **Mint** button. Share this URL directly with your audience — no DAO interface or governance knowledge is required to mint.
*The standalone droposal mint page. Share this URL directly with your audience so they can mint without interacting with the DAO governance interface.*
## Droposals in the DAO Gallery
Droposals appear in the **Gallery** tab of any DAO that has created them. Each droposal card is labelled with a **Drop** badge in the top-right corner to distinguish it from other gallery content types.
Visitors can mint directly from the gallery card without leaving the DAO page, or click through to the full standalone mint page.
*The DAO Gallery tab. Droposals are marked with a **Drop** badge and include a **Mint** button directly on the card.*
## Creating a Droposal
To create a new droposal:
1. Navigate to your DAO's dashboard and click **Create Proposal**.
2. Write a proposal title and description explaining the drop.
3. On the Add Transactions step, select **Droposal: Single Edition** from the transaction type dropdown.
4. Configure the drop settings (see Sales Configuration below).
5. Add the transaction to the queue, then review and submit the proposal for a governance vote.
6. If the proposal passes and is executed, the `ERC721Drop` contract is deployed and the mint page becomes active.
*Select **Droposal: Single Edition** from the transaction type dropdown on the Add Transactions step.*
You can then also define edition parameters and set a royalty payout address.
#### Droposal Edition Parameters
#### Droposal Royalties Payout Address
## Technical Reference
The following section covers the `ERC721Drop` contract standard used by droposals. This is adapted from [Zora's archived documentation](https://web.archive.org/web/20250124141839/https://docs.zora.co/contracts/ERC721Drop).
### Contract Types
NFT contracts created from the `ZoraNFTCreator` are known as `ERC721Drop` contracts. Each drop contract is cloned from an `implementation` address and receives its own address. Both `Editions` and `Drops` use the same base contract but have different metadata rendering contracts.
Every time an NFT is minted and sold using these contracts, 5% of the primary sale amount is reserved by the Zora DAO. Nothing is taken on secondary sales.
- `Edition`: A collection where all NFTs share the same media asset.
- `Drop`: A collection where each NFT has its own individual media asset.
## Sales Configuration
The sales configuration is set when the contract is created and holds all minting and sales parameters.
### Times are Unix Timestamps
- `publicSaleStart`: Start time for public minting
- `publicSaleEnd`: End time for public minting
- `presaleStart`: Start time for private (allowlist) minting
- `presaleEnd`: End time for private minting
- `publicSalePrice`: Price in ETH required to mint one NFT
- `maxSalePurchasePerAddress`: Max number of NFTs one address can mint during the public sale
- `presaleMerkleRoot`: Cryptographic proof used for presale allowlist minting
Note that `presaleMerkleRoot` can be set to `0x0000000000000000000000000000000000000000000000000000000000000000` if no allowlist minting is planned. Current values can be read by calling `salesConfig` on the contract, and updated by calling `setSaleConfiguration`.
```solidity
function setSaleConfiguration(
uint104 publicSalePrice,
uint32 maxSalePurchasePerAddress,
uint64 publicSaleStart,
uint64 publicSaleEnd,
uint64 presaleStart,
uint64 presaleEnd,
bytes32 presaleMerkleRoot
)
```
## Collection Size
### Fixed Size
A fixed-size collection has a maximum number of NFTs that can be minted, set via the `editionSize` parameter at contract creation.
### Open Edition
An open edition has no maximum supply but has a defined minting window. Once the window closes, public minting is no longer possible. `finalizeOpenEdition` must be called by an admin after the window closes.
```solidity
function finalizeOpenEdition()
```
## Minting Functions
### adminMint
Allows an admin to mint a number of NFTs to an address without paying the base price or protocol rewards.
```solidity
function adminMint(address recipient, uint256 quantity)
```
### adminMintAirdrop
Allows an admin to mint one NFT to each of multiple addresses in a single transaction.
```solidity
function adminMintAirdrop(address[] calldata recipients)
```
### mintWithRewards
The public minting function, callable by anyone once the public sale has started.
```solidity
function mintWithRewards(
address recipient,
uint256 quantity,
string calldata comment,
address mintReferral
)
```
### purchasePresaleWithRewards
The allowlist minting function, requiring a Merkle proof.
```solidity
function purchasePresaleWithRewards(
uint256 quantity,
uint256 maxQuantity,
uint256 pricePerToken,
bytes32[] calldata merkleProof,
string memory comment,
address mintReferral
)
```
## Collection Roles
### Owner
The owner has no write access to contract functions. They can only set royalty and contract configurations on third-party platforms that expect an owner field. Defaults to the default admin address at creation, but can be updated by a default admin.
### Default Admin
The most privileged role, set at contract initialisation. Capabilities include:
- Assign and revoke admin roles
- Call `adminMint` and `adminMintAirdrop`
- Change the owner address
- Update `salesConfig`
- Call `finalizeOpenEdition`
```solidity
bytes32 role = 0x0000000000000000000000000000000000000000000000000000000000000000
```
### Minter Role
A restricted admin that can only access the `adminMint` and `adminMintAirdrop` functions.
`bytes32 role = MINTER_ROLE`
### Sales Manager Role
A restricted admin that can only update `salesConfig` and call `withdraw`.
`bytes32 role = SALES_MANAGER_ROLE`
## Assigning and Revoking Roles
Admin roles can only be assigned and revoked by default admins.
### Checking Admin Status
```solidity
function isAdmin(address user)
function hasRole(bytes32 role, address account)
```
### Granting a Role
```solidity
function grantRole(bytes32 role, address account)
```
### Revoking a Role
```solidity
function revokeRole(bytes32 role, address account)
```
### Changing the Owner
```solidity
function setOwner(address newOwner)
```
## Withdrawing Funds
Once minting concludes, funds can be moved out of the contract by calling `withdraw`. This can be called by a default admin, the `fundsRecipient` address, a sales manager, or the Zora DAO.
```solidity
function withdraw()
```
Funds are pushed to the `fundsRecipient` address (set to the default admin at initialisation). This can be updated:
```solidity
function setFundsRecipient(address payable newRecipientAddress)
```
## Creating a Presale Allowlist
A Merkle root condenses a large list of allowed addresses into a single small piece of data stored on-chain. Use the following tools to generate a Merkle root and proofs:
- [Lanyard Tool](https://lanyard.org)
It is also possible to upload an allowlist via the manage interface on the create website and access proofs from the API.
## Updating Contract Info on OpenSea
Once deployed, the address set as the owner must log in to OpenSea to access and update contract information.
## Upgrading the Contract
Upgrades are opt-in and can only be initiated by a default admin. Only upgrades listed in the Zora registry are available.
```solidity
function upgradeTo(address newImplementation)
function upgradeToAndCall(address newImplementation, bytes data)
```
## Retrieving DAO Artwork via IPFS
Source: https://docs.nouns.build/guides/retrieve_img_files/
This guide explains how to retrieve and download your DAO's artwork from IPFS using IPFS Desktop. This is useful when you need to view the existing folder structure before adding or replacing artwork, or when you want to download the complete artwork set.
## Prerequisites
- [IPFS Desktop](https://docs.ipfs.tech/install/ipfs-desktop/) installed on your machine
- Your DAO's artwork IPFS CID (Content Identifier)
## Finding Your DAO's Artwork CID
Your DAO's artwork is stored on IPFS and can be accessed via its CID. To locate this:
1. Navigate to [nouns.build/playground](https://nouns.build/playground)
2. Select your DAO from the list
3. Locate the "Explore on IPFS" section
4. The CID will be displayed as a clickable link (e.g., `bafybeieah7w...wzf7mzqi`)
## Viewing Artwork in Your Browser
Before downloading, you can explore the artwork directory structure directly in your browser using an IPFS gateway:
1. Click the CID link in the Playground section, or manually construct the URL: `https://ipfs.io/ipfs/[CID]`
2. Replace `[CID]` with your DAO's artwork CID
3. Example: `https://ipfs.io/ipfs/bafybeihjotbyklahe2bi4zmlaoryxwy5xmwfhyyyhv5bu4saoivx3nxpta/`
Alternative gateways if ipfs.io is unavailable:
- `https://dweb.link/ipfs/[CID]`
- `https://gateway.pinata.cloud/ipfs/[CID]`
:::note
Gateway access allows you to view individual files and the directory structure, but does not currently support downloading the entire folder as a ZIP archive. For complete folder downloads, use IPFS Desktop as described below.
:::
## Downloading Artwork via IPFS Desktop
### Step 1: Configure Peering with Pinata
To ensure IPFS Desktop can retrieve content pinned by Nouns Builder's infrastructure, you need to peer with Pinata's IPFS nodes:
1. Open IPFS Desktop
2. Navigate to Settings
3. Locate the "Peers" or "Swarm" section
4. Add Pinata's peering addresses following [Pinata's peering documentation](https://docs.pinata.cloud/files/uploading-files#peering-with-pinata)
This ensures your IPFS node can efficiently discover and retrieve content from Pinata's infrastructure.
### Step 2: Retrieve the Artwork Folder
1. In IPFS Desktop, navigate to the "Files" tab
2. Select "Import" or use the search function
3. Enter your DAO's artwork CID
4. IPFS Desktop will begin retrieving the content from the network
:::caution
Large artwork folders may take several minutes to retrieve depending on your internet connection and the total folder size. Folders approaching the 200 MB limit will require more time.
:::
### Step 3: Download the Files
Once retrieved:
1. The artwork folder will appear in your IPFS Desktop file browser
2. Right-click on the folder
3. Select "Export" or "Download" to save it to your local machine
4. Choose your destination directory
The complete folder structure, including all layers and variants, will be downloaded to your computer.
## Troubleshooting
### CID not found or timing out
- Verify you're using the correct CID from the Playground section
- Check your internet connection
- Ensure you've configured Pinata peering correctly
- Try accessing via a browser gateway first to confirm the content exists
### Slow retrieval speeds
- Large artwork sets (>100 MB) take longer to retrieve
- Consider retrieval during off-peak hours
- Check if your ISP blocks or throttles peer-to-peer traffic
### Gateway displays "Invalid CID" error
- Ensure the CID is correctly formatted with no extra characters
- Note that ipfs.io does not yet support all CIDv1 formats; try alternative gateways like dweb.link
## Understanding the Folder Structure
Downloaded artwork follows this structure:
```
artwork-folder/
├── 0-background/
│ ├── variant1.png
│ ├── variant2.png
│ └── ...
├── 1-body/
│ ├── variant1.png
│ └── ...
└── 2-accessories/
└── ...
```
Each numbered folder represents a layer (trait/property), with variants stored inside. This structure must be maintained when creating Add Artwork or Replace Artwork proposals.
Refer to the [Changing and Adding Artwork guide](/guides/artworks) for details on modifying your DAO's artwork using this structure.
## FAQs
Source: https://docs.nouns.build/onboarding/faqs/
This section answers frequently asked questions about participating in Builder DAOs, navigating governance, and working with the protocol on a technical level. If you're unsure where to start or stuck on a detail, you're in the right place.
---
## 🧑🤝🧑 DAO Participation
### “How do I join a DAO?”
To join a Builder DAO, you typically acquire one of its governance tokens. These are distributed through auctions or can sometimes be purchased on secondary markets (e.g., OpenSea or Zora).
**Ways to join:**
1. **Participate in a live token auction** on [nouns.build](https://nouns.build/).
2. **Buy a token** from a previous winner via a marketplace.
3. **Engage without owning a token** by contributing to discussions, helping with proposals, or participating in grants and bounties.
Ownership isn't required to be part of the community—many DAOs welcome contributors of all kinds.
---
### “What happens if I win an auction?”
If you win a DAO auction:
- You receive a **governance token** (usually an NFT) minted directly to your wallet.
- You **gain the ability to vote** on proposals and shape the future of the DAO.
- You become part of the DAO’s **onchain record of contributors**.
Your funds (ETH) go directly to the DAO treasury to support community initiatives.
---
## 🗳️ Governance Questions
### “Why did my proposal fail?”
There are a few common reasons a proposal might fail:
- **Didn’t reach quorum**: Not enough voting power participated.
- **Insufficient votes in favor**: More tokens voted against than for.
- **Invalid execution logic**: Proposal included incorrect or broken contract calls.
- **Poor communication**: The community didn’t understand or support the idea.
**Pro tip**: Share proposals early in Discord or Warpcast to gather support and feedback before submitting onchain.
---
### “How do I delegate my vote?”
Delegation allows you to assign your voting power to another wallet (often a trusted contributor or “Nouncillor”).
**To delegate:**
1. Visit the DAO’s voting interface (e.g., Tally or Builder Voting).
2. Navigate to the **Delegation** section.
3. Enter the wallet address of the person you want to delegate to.
4. Confirm the transaction in your wallet.
You can undelegate or change your delegate at any time.
---
## 🧰 Technical Questions
### “Can I use my own frontend?”
Yes! The Builder Protocol is fully open-source and modular, meaning you can fork the [frontend codebase](https://github.com/BuilderOSS/nouns-builder) and deploy a custom UI for your DAO.
**Reasons to use a custom frontend:**
- Tailored branding or user experience
- Added features (e.g., analytics, contributor tools)
- Native integrations with your project’s ecosystem
**Steps:**
1. Clone the repository.
2. Configure it with your DAO’s contract addresses.
3. Customize visuals and components.
4. Deploy to your own domain.
---
### “Where can I find verified contracts?”
All Builder DAO contracts are deployed onchain and most are verified on block explorers like **Etherscan**, **Basescan**, or **Optimism Explorer**.
**To find your DAO’s contracts:**
1. Go to your DAO’s profile on [nouns.build](https://nouns.build/).
2. Scroll to the DAO Settings or Auction Details section.
3. Click the contract address links to view on the block explorer.
4. Use the **“Contract”** and **“Read/Write”** tabs to interact or inspect.
## The Builder Social Feed
Source: https://docs.nouns.build/guides/feed/
#### *Stay up to date with everything happening across Nouns Builder DAOs in one personalised, filterable feed: auctions, proposals, posts, and more.*
## Overview
The **Feed** is the primary landing experience on [nouns.build](https://nouns.build/). It provides a real-time, chronological stream of activity across all Nouns Builder DAOs on supported chains, including auction events, governance updates, community posts, and coin deployments.
The feed is personalised when you connect your wallet. It filters by the DAOs you belong to by default and surfaces quick actions relevant to your role in those communities.
## Feed Layout
The feed is divided into two columns:
- **Left column (main feed):** a chronological list of activity cards, each representing a single event from a DAO.
- **Right column (sidebar):** your profile, quick-action buttons, a collapsible summary of your DAOs with auction controls, and a collapsible view of active proposals.
At the top of the feed column, a `Customize Feed` button lets you filter what appears.
## Feed Cards
Each card in the feed represents a single on-chain or protocol-level event. Cards display:
- The **user address** (or ENS name) and **DAO name** that generated the event
- A **thumbnail** of the relevant token or media
- An **event title** (e.g. "New auction for Example DAO #007")
- **Chain indicator** and **relative timestamp** (e.g. "Base · 37m ago")
- **Contextual action buttons** depending on the event type
### Supported Event Types
| Event | What it means | Actions shown |
|---|---|---|
| **Auction Created** | A new auction has started for a DAO token | `Place Bid`, `View Auction` |
| **Auction Bid** | A bid has been placed on an active auction | `Place Bid`, `View Auction` |
| **Auction Settled** | An auction has ended and the token has been claimed | `Go to Latest Auction`, `View Auction` |
| **Proposal Created** | A new governance proposal has been submitted | `View Proposal` |
| **Proposal Vote** | A vote has been cast on an active proposal | `View Proposal` |
| **Proposal Executed** | A proposal has passed and been executed on-chain | `View Proposal` |
| **Proposal Update** | A Propdate has been posted on a proposal | `View Propdate` |
| **Coining** | Coining posts appear in the feed and show the associated coin page. | `Trade` or `Buy`, `View Coin` |
| **Creator Coin Deployed** | A creator coin has been deployed for a DAO | `View Coin` |
| **Drop Created** | An ERC-721 drop proposal has been executed | `View Drop` |
The share icon (↗) on each card copies a direct link to that event.
Clicking the **DAO name or avatar** in the top-left corner of any card navigates directly to that DAO's page.
## The Sidebar
The sidebar on the right-hand side of the feed gives you a real-time snapshot of your activity across the platform and surfaces quick actions without leaving the feed.
### Profile Row
At the top of the sidebar your connected **ENS name or wallet address** is displayed alongside your avatar, with a note showing how many DAOs you are a member of (e.g. "Member of 5 DAOs").
### Quick Actions
Three action buttons sit directly below your profile:
- **`Create Post`** — publish a content coin on behalf of one of your DAOs. Opens a DAO selector, then a publish form with media upload, coin name, symbol, and description fields. This action is available only for DAOs that already have a Creator Coin deployed.
- **`Create Proposal`** — start a new governance proposal for one of your DAOs. Opens the standard proposal builder. See [How to Create a Proposal](/onboarding/builder-proposal/) for a full walkthrough.
- **`Create a DAO`** — deploy a new Nouns Builder DAO. See [How to Create a DAO](/guides/builder-deployment/) for a full walkthrough.
### DAOs
The **DAOs** section is a collapsible panel listing all DAOs you are a member of. Click the section header to expand or collapse it.
When expanded, each DAO you belong to appears as a card showing:
- The **DAO name** and token avatar
- The **chain** it is deployed on (e.g. Base)
- An auction status indicator:
- **`Start next Auction`** — the previous auction has settled and a new one can be kicked off. Click to trigger the settlement and start the next auction.
- **Auctions are paused** — the DAO's auction mechanism is currently paused. A `View activity` link takes you to the DAO's activity page.
The count of your member DAOs (e.g. "5 DAOs") is shown in the collapsed state as a summary.
In case you have hidden DAOs, they are nested in a droplist of "Hidden DAOs" that can be expanded. Please see further documentation on hiding DAOs in the [User Profile Section](/onboarding/user-profile).
### Proposals
The **Proposals** section is a collapsible panel showing active governance proposals across all the DAOs you belong to. Click the section header to expand or collapse it.
When there are no active proposals, the panel displays: *"No active proposals at the moment."*
When active proposals are present, each one appears as a card with its title, DAO name, and voting status. Clicking a proposal card takes you directly to the proposal page.
### Unauthenticated state
When no wallet is connected, the sidebar shows only a prompt to connect your wallet. The quick-action buttons, DAOs section, and Proposals section are not visible until you connect.
## Customising the Feed
Click `Customize Feed` at the top of the feed column to open the filter panel.
You can filter by three dimensions:
### Chains
Select one or more chains to include in your feed:
- **Base**
- **Ethereum**
- **OP Mainnet**
- **Zora**
By default, all chains are included.
### Event Types
Toggle individual event types on or off:
- Auction Created
- Auction Bid
- Auction Settled
- Proposal Created
- Proposal Vote
- Proposal Executed
- Proposal Update
- Creator Coin Deployed
- Post Published
- Drop Created
This is useful if, for example, you only want to track governance activity and want to hide auction noise, or you're specifically watching for new coin deployments.
### DAOs
Choose between:
- **All DAOs** — show events from every DAO on the selected chains (default)
- **Specific DAOs** — restrict the feed to a curated list of DAOs you choose
Once you've configured your filters, click `Apply Filters` to update the feed. Select `Reset to Defaults` to clear all filters and return to the default view.
## Creating a Post
:::caution
**Coining posts are currently only supported on Base Mainnet and Base Sepolia.** Please see the [Coining Section](/guides/coining) for further information.
:::
To publish a post from the feed:
1. Click `Create Post` in the sidebar.
2. In the **Select DAO for Post** dialog, select the DAO you want to publish on behalf of. You can search by name.
3. Click `Continue`.
4. On the **Publish Post** page:
- Upload your **media** (image, video, or audio).
- Enter a **name** (1–100 characters) — this becomes the display name for your content coin.
- Set a **symbol** (1–10 uppercase letters/numbers) — auto-generated from the name, but editable.
- Add a **description**.
5. Review the live **preview** on the right to see how your post will appear to collectors.
6. Submit to deploy the post on-chain.
Posts are published as Content Coins using Zora's ERC-20 Coining SDK and appear in the feed under the **Post Published** event type.
Posts published from the feed are coining posts. When a DAO publishes a post, the post is created as an associated coin and appears in the feed as a **Published post** event. From the feed, members can open the coin page and, depending on the state of the asset, see actions such as `Trade`, `Buy`, and `View Coin`.
:::note
You must be a member of the DAO you're publishing for. Only DAOs associated with your connected wallet appear in the DAO selector.
:::
Once the post is live, you can:
- Trade coins on the coin page
- Comment on Content Coins on the coin page
- Like coins by purchasing USD 0.10, USD 0.50, or USD 1.00 worth of the coin.
- Share the coin by copying the link
:::caution
Trades are disabled for Content Coins on Base Sepolia.
:::
## Tips
- **Filter to your DAOs** — if you're a member of several DAOs, set the DAOs filter to "Specific DAOs" and select only the ones you actively follow to reduce noise.
- **Chain-specific views** — working only on Base? Deselect other chains to keep the feed focused.
- **Auction controls** — use the `Start next Auction` button in the DAOs sidebar panel to kick off a new auction for your DAO without leaving the feed page.
- **Governance tracking** — enable "Proposal Created" and "Proposal Vote" in the event type filters to stay informed about governance activity across your communities without visiting each DAO page individually.
## Bridging on Nouns Builder
Source: https://docs.nouns.build/onboarding/builder-bridging/
##### What is bridging?
A blockchain bridge is a tool that connects two separate blockchain networks to enable assets to be transferred between them. This includes bridges that connect Ethereum (“Layer 1” or “L1”) to Layer 2 (“L2”) networks like Zora Network, OP Mainnet and Base that sit on top of Ethereum to enhance the speed and reduce the costs of performing onchain transactions. Nouns Builder's native bridge allows you to transfer your ETH from Ethereum to the Zora Network, OP Mainnet and Base.
##### Why do I need to bridge my ETH?
You must bridge your ETH to an L2 in order to transact on the L2, for example, to bid on L2 auctions or vote on L2 proposals.
##### What happens to my ETH when I am bridging?
By bridging your ETH, you make it available for use on the L2. When you bridge ETH to an L2 supported on Nouns Builder (Zora Network, OP Mainnet, Base), your ETH is locked on L1 in the canonical bridge contract and a corresponding representation is made available on the L2. You control both sides with your wallet keys; Nouns Builder does not take custody. Bridged ETH is not spendable on L1 until you withdraw it back through the bridge.
## Bridging ETH to L2 networks on Nouns Builder
While we recommend using a commercial third-party bridge to access your funds more quickly, Nouns Builder also provides access to native bridges that are more cost-effective. If you use the native bridges available at [nouns.build/bridge](https://nouns.build/bridge), you will experience longer lock times before completion and cannot withdraw using the Builder UI.
For withdrawals and bridging from your L2 DAO treasury to Ethereum Mainnet or another L2, please use the **WalletConnect** Proposal Template to connect to a third-party bridge.
The Nouns Builder bridge currently supports **deposit-only** bridging to Zora Network, OP Mainnet and Base. We use the native bridge for each of these L2 networks. The Nouns Builder bridge does not currently support withdrawals. Users will need to use other bridges to withdraw - see below for more details.
To bridge on Nouns Builder:
1. Connect your wallet on [nouns.build](https://nouns.build).
2. Select "Bridge" in the navigation bar.
3. Select the chain you would like to deposit ETH to.
4. Enter the desired ETH amount.
5. Click "Bridge" to begin bridging your ETH to the selected network. This will prompt a wallet transaction to accept a gas fee.
6. Confirm the transaction in your wallet. **This may take ~1-2 minutes, depending on how congested Ethereum mainnet is.**
7. Your ETH has been bridged.
8. Enjoy Nouns Builder on L2!
:::note
As of August 2025, bridges provided by Nouns Builder are only accessible through the [Bridge Tab](https://nouns.build/bridge) because the modal UX has been deprecated.
:::
---
## Withdrawing ETH from L2 networks on Nouns Builder
The Nouns Builder bridge **does not** currently support withdrawals.
To withdraw from Zora Network, OP Mainnet or Base to Ethereum Mainnet:
- Withdraw from [Zora Network](https://bridge.zora.energy/)
- Withdraw from [OP Mainnet](https://app.optimism.io/bridge/withdraw)
- Withdraw from [Base](https://bridge.base.org/withdraw)
## Coining
Source: https://docs.nouns.build/guides/coining/
## Overview
Coining is Builder's framework for launching on-chain fungible tokens directly from DAO proposals. It is an addition to the legacy Droposal model. Communities now also can make use of two ERC-20 coin types, **Creator Coins** and **Content Coins**, for governance and community engagement. These coin types are as follows:
- **Creator Coin (DAO Coin):** The primary coordination token for a DAO, deployed via [Clanker](https://clanker.world/). Always governance-gated — a DAO vote is required to deploy it.
- **Content Coin:** A post- or contribution-level token, deployed via Zora's ERC-20 Coining SDK. Issued through a DAO proposal or as a [permissionless post](/guides/feed) and paired against the DAO's Creator Coin.
:::caution
**Coining is currently only supported on Base Mainnet and Base Sepolia.** Base Sepolia is supported for Nouns Builder-related testing only and does not support testing trading functionalities. If you require a test DAO on Base Mainnet with shortlived voting cycles for testing trading functionalities in production, please reach out to the Tech Pod team or open a ticket on Discord.
:::
Together, these two coin types form a hierarchy: `$CONTENT → $CREATOR → $WETH`, in which trading fees flow up the chain, rewarding the DAO and supporting long-term sustainability.
:::tip
A DAO can only have one Creator Coin. Content Coins are unlimited and can be created for individual posts, artworks, or contributions — each paired to the DAO's Creator Coin.
:::
## Key concepts
- **Creator Coin:** A DAO-level ERC-20 token deployed via Clanker. Represents the primary value-capture layer for the DAO.
- **Content Coin:** A post-level ERC-20 token deployed via Zora Coining SDK, paired to the DAO's Creator Coin.
- **Base Currency:** The token a coin is priced against. For Creator Coins this is WETH; for Content Coins this is the DAO's Creator Coin.
- **Pool Configuration:** Liquidity pool settings (fee structure, tick ranges) set at deployment and managed by the DAO treasury.
- **Initial Purchase:** An optional ETH amount the treasury spends to seed initial liquidity on Creator Coin deployment.
- **Coin Creations:** The section on a proposal's detail page showing which coins will be (or were) deployed if the proposal passes.
---
## Creator Coin (DAO Coin)
### Concept
A Creator Coin is the DAO's primary ERC-20 token. It is deployed once per DAO and acts as the base currency for all Content Coins that DAO subsequently creates or that are created on its behalf. Deployment requires a successful governance vote.
Creator Coins are powered by [Clanker v4](https://clanker.world/) and launch with a Uniswap v4 liquidity pool. The DAO treasury becomes the token admin and liquidity reward recipient.
### Workflow overview
1. Draft and publish a proposal.
2. Add a Creator Coin transaction with metadata and pool settings.
3. Review, submit, and execute the proposal on-chain.
4. Use the coin page and Coin Creations section to monitor and trade.
### Step 1: Write the proposal
1. Go to your DAO's dashboard and click **Create Proposal**.
2. Enter a clear **title** (for example, "Deploy [DAO Name] Creator Coin") and a **markdown description** explaining why the DAO is launching a Creator Coin and what it will be used for.
3. Click **Continue** to proceed to the **Add Transactions** step.
### Step 2: Add the Creator Coin transaction
1. Select **Creator Coin** from the transaction type dropdown on the **Add Transactions** step.
2. Fill in the coin metadata on the left; the right panel updates with a live preview as you type.
3. Optionally expand **Advanced Pool Settings** to configure pool and vault behaviour.
#### Creator Coin metadata
| Field | Description |
|-------------------|-----------------------------------------------------------------------------|
| **Media** | Upload a MP4, JPG, PNG, WebP, or SVG file for your coin. |
| **Name** | The display name for your coin (1–100 characters). |
| **Symbol** | A short ticker (1–10 uppercase letters/numbers). Auto-generated but editable. |
| **Description** | A description of the coin and its purpose within the DAO. |
| **Base Currency** | The token your Creator Coin will be paired against. Defaults to WETH. |
#### Creator Coin pool configuration
#### Vault settings
*The Advanced Pool Settings panel configures the fee structure and optional initial ETH purchase.*
- **Fee Configuration:** Choose between Static (fixed 1% fee) or Dynamic (1–5% based on trading volume).
- **Initial Purchase (ETH):** An optional amount of ETH for the treasury to spend on the coin at deployment, seeding initial liquidity. The current treasury balance is shown inline.
- **Automatically pin creator coin to treasury:** Enables the coin to appear prominently in the DAO treasury view.
4. Read and accept the disclaimer, then click **Add Transaction to Queue**.
:::note
The **Initial Purchase** field draws from the DAO treasury balance shown in the form. Leave it at 0 if you do not want the treasury to buy tokens at launch.
:::
### Step 3: Review, submit, and execute
1. Click **Continue** to reach the **Review and Submit** step.
2. Check the transaction simulation results and confirm the on-chain details.
3. Submit the proposal on-chain.
Once the proposal passes and is executed, the Creator Coin is deployed. This is helpful from a governance perspective, as the executed [Creator Coin proposal page](https://nouns.build/dao/base/0xe5b2789eac1c60afeaafb9c92149add89eb9e102/vote/1) also displays the relevant proposal data.
It nests a Coin Creations section that shows the deployed coin's name, symbol, description, and a link to the coin page. The **Coin Creations** section on the proposal detail page will update to show the deployed coin name, symbol, description, and a [link](https://nouns.build/coin/base/0x250422c9cc891FE672d99B6B829EfF9c96884B99) to the coin's page.
---
## Content Coin
### Concept
A Content Coin is a post-level ERC-20 token linked to a specific piece of content — an artwork, a post, a community contribution, or any other discrete output. Content Coins are:
- Deployed via Zora's ERC-20 Coining SDK.
- Always paired to the DAO's Creator Coin as their base currency.
- Created through a governance proposal, giving the DAO collective ownership over what gets coined on its behalf, or as a permissionless post.
:::tip
A Content Coin proposal is only available for DAOs that have already deployed a Creator Coin. The Creator Coin automatically becomes the **Base Currency** for the Content Coin's liquidity pool.
:::
### Workflow overview
1. Draft and publish a proposal identifying the content to be coined.
2. Add a Content Coin transaction with media, metadata, and optional custom properties.
3. Review, submit, and execute the proposal.
4. Use the Gallery and coin page to view and trade the coin.
### Step 1: Write the proposal
1. Navigate to your DAO's dashboard and click **Create Proposal**.
2. Write a **title** and **description** that clearly identify the content being coined — include a link to the artwork, post, or contribution where relevant.
3. Click **Continue**.
### Step 2: Add the Content Coin transaction
1. Under **Select Transaction Type**, choose **Content Coin** from the dropdown.
2. Fill in the coin metadata
3. Optionally expand **Custom Properties** to add key-value metadata attributes to the coin.
4. Accept the disclaimer and click **Add Transaction to Queue**.
#### Content Coin metadata
| Field | Description |
|-------------------|------------------------------------------------------------------------------------------------------|
| **Media** | Upload the media for your coin (images, videos, or audio). |
| **Name** | The display name for the coin (1–100 characters). |
| **Symbol** | A short ticker (1–10 uppercase letters/numbers). Auto-generated from the name but editable. |
| **Description** | A description of the content this coin represents. |
| **Base Currency** | Pre-filled with the DAO's Creator Coin. This cannot be changed — Content Coins are always paired to the DAO's Creator Coin. |
*The Content Coin form. The Base Currency field is automatically pre-filled with the DAO's Creator Coin.*
#### Custom settings
#### Launch economics
### Step 3: Review, submit, and execute
1. Click **Continue** to reach the **Review and Submit** step.
2. Verify the simulation results and confirm the transaction details.
3. Submit the proposal on-chain.
*A proposal detail page showing a Content Coin in the Coin Creations section.*
---
## Reading Coin Creations and post-execution views
### Coin Creations on proposals
After a coining proposal is submitted, the proposal detail page shows a **Coin Creations** section under the **Details** tab. This section is visible at any proposal state — pending, active, executed, or expired — so voters can review what will be deployed before casting their vote.
Each coin card in the section displays:
- The coin type (**Creator Coin** or **Content Coin**) and its index within the proposal (for example, "Creator Coin 1").
- The coin's ticker symbol (for example, `$BLDC`).
- The full name, symbol, and description.
- A **View Coin Page** button linking to the coin's live trading and collector page (visible after execution).
### After execution
Once the proposal is executed:
- The Content Coin is deployed and listed under the [**Gallery** section](https://nouns.build/dao/base/0xe5b2789eac1c60afeaafb9c92149add89eb9e102/15?tab=gallery) of the DAO.
- You can also view the coin on its [coin page](https://nouns.build/coin/base/0x334d84062fa9db869642f9c6e42eb7d0825ef02c), where you can trade.
Once executed, you can:
- Trade coins on the coin page.
- Comment on Content Coins on the coin page.
- Like coins by purchasing USD 0.10, USD 0.50, or USD 1.00 worth of the coin.
- Share the coin by copying the link.
- See the top holders.
:::caution
Trades are disabled for Content Coins on Base Sepolia.
:::
## How to Create a Proposal
Source: https://docs.nouns.build/onboarding/builder-proposal/
##### Learn how to submit a governance proposal in your DAO
Proposals are the core mechanism of DAO governance. Any token holder who meets the Proposal Threshold can submit a proposal — and if it passes a vote, the DAO will execute whatever transactions you've attached to it automatically.
The proposal flow is split into three steps: write your proposal, add transactions, then review and submit on-chain.
:::note
To follow along safely before going to mainnet, use the [Sepolia Testnet](https://testnet.nouns.build/). You'll need a governance token for the DAO you want to propose in. Your wallet must hold enough tokens to meet the DAO's Proposal Threshold.
:::
## Key Terms
- `Proposal Threshold:` The minimum number of governance tokens (as a percentage of total supply) required to submit a proposal. For example, if the threshold is 1% and 500 tokens have been minted, you'll need at least 5 tokens.
- `Quorum Threshold:` The minimum number of **For** votes required for a proposal to pass.
- `Voting Delay:` The time between a proposal being submitted and voting opening, in seconds.
- `Voting Period:` How long voting remains open, in seconds.
- `Time Lock Delay:` The waiting period between a successful vote being queued and the transaction being executed. Defaults to 2 days.
## Proposal Lifecycle
Once submitted, a proposal moves through the following stages:
1. **Pending** — The proposal is on-chain but voting hasn't started yet (Voting Delay is active).
2. **Active** — Voting is open. Token holders cast For, Against, or Abstain votes.
3. **Succeeded / Defeated** — Voting closes. The proposal passes if For votes exceed Against votes and meet the Quorum Threshold. Otherwise it's defeated.
4. **Queued** — A successful proposal enters the time lock queue.
5. **Executed** — After the Time Lock Delay, anyone can trigger execution. The DAO's treasury carries out the attached transactions.
## Creating a Proposal
Navigate to your DAO's **Activity** tab and click **Create proposal**.
The proposal builder opens at Step 1. A progress indicator at the top of the page shows all three steps throughout the flow.
:::note
**First time?** A tip banner at the top of the page summarises the flow: write the proposal, add transactions, then do a final preflight before submitting. Click **Got it** to dismiss it.
:::
## Step 1: Write Proposal
Fill in the two fields:
- **Title** — A concise, descriptive name for your proposal. This is what token holders will see in the proposals list.
- **Description** — The full proposal write-up. The editor supports Markdown: use the toolbar for headings, bold, italic, links, code blocks, images, and lists. You can also drag and drop files into the description area to attach them.
Once both fields are complete, click **Continue** to move to Step 2.
### Optional Fields
Beyond the title and description, Step 1 exposes two optional fields that are worth knowing about.
#### Discussion URL
Paste a link to any off-chain discussion thread related to the proposal — a governance forum post, a Farcaster cast, a Discord thread, or similar. This gives voters context without cluttering the on-chain description. Please refrain from adding IPFS URLs.
#### Submitting on Behalf of Someone Else
If you are submitting a proposal on behalf of another token holder, check the **Are you submitting this proposal on behalf of someone else?** box. An address field will appear — enter the proposer's wallet address (`0x…`) or ENS name. The proposal will be attributed to that address on-chain in the proposal metadata.
:::note
The wallet you connect with must still meet the DAO's Proposal Threshold. The on-behalf-of field adds data on the attributed proposer in the proposal metadata but does not delegate voting power.
:::
## Step 2: Add Transactions
Transactions define what the DAO actually *does* if the proposal passes. You need to queue at least one transaction to proceed. The header shows a running count of transactions queued.
### Selecting a Transaction Type
Use the **Select transaction type** dropdown to choose from the available options:
| Transaction Type | Description |
|---|---|
| **Send Tokens** | Send ETH or ERC-20 tokens from the treasury to one or more recipients |
| **Send NFTs** | Send NFTs from the treasury |
| [**Stream Tokens**](/guides/sablier-proposal.mdx) | Set up continuous token payments over time (powered by Sablier) |
| [**Airdrop Tokens**](/guides/sablier-proposal.mdx) | Distribute tokens via Sablier merkle campaigns |
| [**Milestone Payments**](/guides/builder-escrow-proposal.mdx) | Schedule token releases tied to milestones |
| [**Mint Governance Tokens**](/guides/mint_gov_tokens.mdx) | Mint governance tokens to specific addresses |
| **WalletConnect** | Connect to a dApp and execute transactions via WalletConnect |
| [**Nominate Delegate**](/guides/builder-escrow-proposal.mdx) | Nominate a delegate for milestone payments or token streams |
| **Pin Treasury Asset** | Whitelist a token or NFT for prominent display in the treasury |
| **Custom Transaction** | Any other contract call — paste an ABI and select a function |
| [**Coining**](/guides/coining.mdx) | Create a proposal to mint a Content or DAO Coin |
| [**Droposal: Single Edition**](/guides/droposals.mdx) | Create a single-edition ERC-721 collection droposal |
| [**Pause Auctions**](/guides/auctions.mdx) | Pause DAO auctions |
| [**Add Artwork**](/guides/artworks.mdx) | Add new artwork layers to your DAO's NFT collection |
| [**Replace Artwork**](/guides/artworks.mdx) | Replace an existing artwork layer in your collection |
**Once you added the transaction details, you can add it to the queue.**
### Example: Sending Tokens
Select **Send Tokens** to send ETH or an ERC-20 token from the treasury.
**If you want to reset your progress, follow the red arrows above. You will have to confirm to reset your progress.**
1. Choose a token from the **Select a token** dropdown (ETH or any ERC-20 held by the treasury).
2. Enter the recipient address and amount. Use the **Number of Recipients** control to add multiple recipients in a single transaction.
3. Click **Add Transaction to Queue**.
The transaction appears in the queue. You can add multiple transactions of different types to a single proposal — they'll all execute together if the proposal passes.
### Updating DAO Settings via a Proposal
If you want to change a governance parameter (auction duration, voting period, quorum, and so on), you don't need a custom transaction. Use the **Configure DAO Settings** shortcut at the bottom of the page — this takes you directly to the Admin tab where settings changes are automatically encoded as proposal transactions.
Once you've queued all your transactions, click **Continue**.
## Step 3: Review and Submit
The final step gives you a full summary of everything before it goes on-chain:
- **Proposal title and description** — review for accuracy.
- **Transaction list** — confirm each transaction, the target addresses, and amounts.
- **Simulation results** — the interface runs a simulation of your transactions so you can catch any execution errors before spending gas.
- **Governance timeline** — a projected timeline showing when voting will open and close, and when the proposal could be executed if it passes.
If anything looks wrong, use the **←** back button to return to the previous step and make changes. The draft is preserved.
When you're satisfied, click **Submit proposal**. Your wallet will prompt you to sign and broadcast the on-chain transaction.
:::note
Your wallet must hold enough governance tokens to meet the Proposal Threshold at the moment of submission. If you don't meet the threshold, the transaction will revert.
:::
Once the transaction confirms, the proposal will appear in your DAO's **Activity** tab with a **Pending** status. It will move to **Active** once the Voting Delay period has elapsed.
## ERC-721 Redeem Minter
Source: https://docs.nouns.build/guides/redeem-minter/
##### Distribute governance tokens to holders of an existing NFT collection
Nouns Builder supports two custom minter contracts that allow a DAO to distribute governance tokens to holders of a pre-existing NFT collection, rather than (or in addition to) the standard auction mechanism. Both contracts live in the [nouns-protocol repository](https://github.com/BuilderOSS/nouns-protocol/tree/main/src/minters).
| Minter | UI Support | Use Case |
|---|---|---|
| `ERC721RedeemMinter` | ✅ Supported | Redeem DAO tokens 1:1 to holders of a specific ERC-721 NFT collection |
| `MerkleRedeemMinter` | ❌ Not supported — contact the team | Distribute tokens based on a merkle allowlist |
:::caution
If you do not reserve tokens during DAO creation, you cannot do this later — you would need to deploy a new DAO.
:::
## Step 1: Reserve Tokens During DAO Creation
This must be done before deploying the DAO.
During the DAO creation flow on [nouns.build](https://nouns.build/create):
1. Navigate to the **Rewards & Allocations** step
2. Open the **Advanced Settings** toggle
3. Find the section labelled **Reserve Tokens for Airdrops or Manual Mints**
4. Enter the number of tokens to reserve in the `Reserve Tokens Until` field (e.g. `202` if your presale had 202 NFTs)
The helper text reads: "Token IDs below this number are reserved for DAO minting. Auctions start at this ID. Cannot be lowered after minting begins."
#### Other settings on this screen
- **Auction Rewards** — optionally set aside a percentage of each auction's highest bid for a specified address. This is separate from token allocation.
- **Token Allocation** — allocate a percentage of minted tokens to founder addresses. Toggle off to create a DAO with no founder allocation. Note: you cannot fully remove the founder entry — set the percentage to `0` with a short end date if you want no allocation.
## Step 2: Manage Minters
After deploying the DAO, go to your DAO's admin panel on nouns.build. You will see:
- **Reserved Tokens** range (e.g. 0–5)
- Total tokens reserved and tokens remaining to mint
- **Edit Reserved Tokens** — adjust the reserved count post-deployment
- **Manage Minters** — open the minter management interface
- **Start Auction** — begins the standard auction mechanism
:::caution
Set up your custom minters **before** clicking "Start Auction". Once auctions have started, the option to redeem tokens is no longer shown in the UI.
:::
### Manage Minters modal
Click **Manage Minters** to open the modal. The header confirms how many tokens are in reserve (e.g. "You have 100 tokens in reserve.").
**Default Minters**
- `ERC721 Redeem Minter` — check this box to enable it. Description: "Allows users to redeem specific ERC721 tokens for tokens from your reserve." The contract address is shown below the label.
**Custom Minters**
- An address input field (`0x…` or `.eth`) where you can add any minter contract address manually — for example, your own wallet if you want to mint token #0 yourself, or the `MerkleRedeemMinter` address if setting it up manually.
Click **Save Changes** to apply. This calls `updateMinters` on the token contract, whitelisting the selected contracts.
:::note
`MerkleRedeemMinter` is not available as a default option in the UI. Contact the Nouns Builder team to set it up manually.
:::
## Step 3: Configure Mint Settings
Once you enable the ERC-721 Redeem Minter and save, a new **Erc721 Redeem** tab will appear in your DAO's navigation alongside About, Activity, Admin, and Contracts.
Click the tab to open the **Configure Mint Settings** form:
| Field | Description | Example |
|---|---|---|
| `Mint Start Date` | When minting becomes available | 2026-04-03 |
| `Mint End Date` | When minting closes | 2026-04-09 |
| `Price Per Token (ETH)` | Cost to redeem; set to `0` for a free airdrop | 0 |
| `Redeem Token Address` | Contract address of the source NFT collection | 0x000...000 |
Click **Save Settings** to write the configuration on-chain.
## Step 4: Mint Tokens
After saving settings, the tab displays a **Mint Settings** summary:
- **Mint Start / Mint End** — timestamps for the active window
- **Price Per Token** — `0 ETH` for a free airdrop
- **Redeem Token** — the source NFT collection address (with link and copy icons)
- **Status** — shown as `Active` in green when within the mint window
- **Edit Settings** and **Reset Settings** buttons
Below the summary is the **Mint Tokens** section:
- An input field: "Enter Token IDs to redeem (comma-separated or ranges)"
- Supported formats: `1,2,3` or `1-10` or `1-5,10,15-20`
- A **Mint X Tokens** button that updates dynamically as you enter IDs
Enter the token IDs of the presale NFTs you want to redeem. The minter looks up the current holder of each token ID in the source collection and mints the corresponding DAO token to that wallet. You can execute this on behalf of all holders — holders do not need to take any action themselves.
## Step 5: Start Auctions
Once the reserve tokens have been redeemed, return to the DAO admin panel and click **Start Auction** to begin the standard auction mechanism for remaining tokens.
:::note
You do not have to wait for all tokens to be redeemed before starting auctions. However, once auctions start, the **Mint Tokens** UI is no longer displayed. If you still need to redeem reserved tokens after starting auctions, you will need to call the contract directly via the block explorer.
:::
## Manual Path via Block Explorer
If the UI is unavailable or you need more control, all of the above can be done directly on Basescan.
#### Verifying contracts as proxies
The DAO deploys 5 contracts (token, auction, governor, treasury, metadata). None show callable functions by default on Basescan because they are proxy contracts. To expose them:
1. Go to the contract on Basescan
2. Click the three dots (⋯) → **Is this a proxy?**
3. Confirm — this unlocks **Read as Proxy** and **Write as Proxy** tabs
4. Repeat for each of the 5 DAO contracts
:::note
Use [sepolia.basescan.org](https://sepolia.basescan.org/) for testnet, not the regular Basescan URL.
:::
#### Key contract calls
On the **Token Contract**:
| Function | Parameters | Purpose |
|---|---|---|
| `updateMinters` | `[(minterAddress, true)]` | Whitelist the `ERC721RedeemMinter` (or your own wallet) as an allowed minter |
| `mintFromReserveTo` | `(to: yourAddress, tokenId: 0)` | Manually mint a specific reserve token to an address |
On the **ERC721RedeemMinter Contract**:
Configure settings with the equivalent of the UI form (`mintStart`, `mintEnd`, `pricePerToken`, `redeemToken`, `tokenContract`), then call the redeem/mint function passing an array of presale token IDs.
## Token ID Mapping
Reserve token IDs in the DAO map directly to the token IDs of the source collection:
- DAO token `#0` → presale token `#0`
- DAO token `#1` → presale token `#1`
- and so on
If your presale collection starts at ID `#1` (common on Highlight.xyz), then DAO token `#0` has no corresponding presale holder. In that case you can either leave it unclaimed, or manually mint it via `mintFromReserveTo` after adding your own wallet address under **Custom Minters** in the Manage Minters panel (or via the contract directly).
:::note
Token `#0` does not automatically go to the deployer or any founder address.
:::
## Troubleshooting
| Issue | Resolution |
|---|---|
| "Manage Minters" buttons don't respond | Ensure your wallet (e.g. Rabby) is unlocked. A locked wallet causes silent failures. Hard refresh after unlocking. |
| Connected to wrong chain | Confirm your wallet is on the correct chain (Base mainnet or Base Sepolia for testnet). A chain mismatch causes calls to fail silently. |
| Can't see the Manage Minters / reserved tokens UI | Navigate to the DAO admin panel. If using testnet, ensure you're on [testnet.nouns.build](https://testnet.nouns.build/). |
| Redeem tab disappears after auctions start | Expected behaviour. Use the manual contract path on Basescan to complete any remaining redemptions. |
| `MerkleRedeemMinter` not in the UI | Contact the Nouns Builder team — this must be set up manually. |
## Summary Flow
```
DAO Creation
└─ Rewards & Allocations → Advanced Settings
└─ Set "Reserve Tokens Until" (e.g. 202)
↓
Post-Deployment (before starting auctions)
└─ DAO Admin Panel → Manage Minters
└─ Check "ERC721 Redeem Minter" → Save Changes
↓
"Erc721 Redeem" tab appears in DAO navigation
└─ Configure Mint Settings
(dates, price=0, redeem token address) → Save Settings
↓
Mint Tokens
└─ Enter token IDs (comma-separated or ranges) → Mint X Tokens
↓
Start Auction
```
## How to Get Farcaster Notifications
Source: https://docs.nouns.build/onboarding/builder-farcaster-notification/
## Overview
[Propdate](/onboarding/builder-propdates) notifications can be received through the existing [Farcaster bot](https://github.com/BuilderOSS/builder-farcaster) by following the bot account on [Farcaster](https://farcaster.xyz/builderbot).
The bot supports two types of notifications, *Propdates* and *proposal and release related* updates.
### Propdate Notifications
### Proposal Notifications
## Tutorial
1. Go to Warpcast.
2. Follow the account: https://farcaster.xyz/builderbot
3. Receive propdate updates in your DMs.
## Visual Guide
The propdate notifications will look like this:
## Stream Tokens and Airdrop Tokens
Source: https://docs.nouns.build/guides/sablier-proposal/
##### Learn how to create Sablier-powered token stream and airdrop proposals
Nouns Builder integrates [Sablier](https://sablier.com) to give DAOs two powerful ways to distribute tokens from their treasury over time: **Stream Tokens** and **Airdrop Tokens**. Both are available as transaction types when creating a proposal.
## Stream Tokens
The **Stream Tokens** transaction type lets a DAO create one or more continuous token payment streams to recipients. Streams are powered by Sablier's Lockup protocol and flow tokens in real time from the moment the proposal is executed. Each stream is represented as an NFT on-chain.
### When to Use Stream Tokens
Use Stream Tokens when your DAO wants to:
- Pay a contributor or grantee continuously over a defined period
- Vest tokens to a team member with an optional cliff
- Disburse funds at a predictable, auditable rate without manual payments
### Creating a Stream Tokens Proposal
#### Navigate to the Proposal Builder
Go to your DAO's governance page and click **Create Proposal**. On the **Add Transactions** step, open the transaction type selector and choose **Stream Tokens**.
#### Select Token
Use the **Select Token** dropdown to choose the treasury asset you want to stream. The dropdown shows all tokens held in the DAO treasury, including ETH and any ERC-20 tokens. You can also enter a **Custom Token Address** if the token is not listed.
The panel below the dropdown confirms the token name, treasury balance, and decimal precision.
#### Sender / Delegate
The **Sender / Delegate** field sets which address retains the right to cancel the stream (if cancellability is enabled) and receives any unclaimed tokens upon cancellation. By default, this is pre-filled with the treasury address or the nominated delegate, if configured prior to the proposal creation via the "Nominate Delegate" proposal (see documentation for nominating a delegate in the [Escrow Section](/builder-escrow-proposal)). You can click the swap icon to change it.
:::note
The Sender / Delegate address holds governance power over the stream. Choose carefully — this address can reclaim unstreamed tokens if the stream is cancelled.
:::
#### Duration Type
Select how the stream timing is defined. This setting applies to **all streams** in the transaction.
- **Days from now** — Streams start immediately when the proposal executes and run for a specified number of days.
- **Start & End Dates** — Streams begin and end at specific calendar dates and times.
#### Stream Options
These checkboxes apply to **all streams** added in this transaction.
- **Cancelable** — Allows the Sender / Delegate to cancel the stream and reclaim any tokens that have not yet vested. Enabled by default.
- **Transferable** — Allows the recipient to transfer their stream NFT to another address. If disabled, the stream is bound to the original recipient.
- **Exponential Curve** — Uses an exponential vesting curve instead of a linear one. Tokens unlock slowly at first and accelerate toward the end of the stream period.
#### Configuring Individual Streams
Each stream is listed as a collapsible panel (e.g., **Stream #1: 0 ETH**). Expand it to fill in the per-stream details.
##### Recipient Address
Enter the wallet address that will receive the streamed tokens. The recipient can withdraw vested tokens at any time via [app.sablier.com](https://app.sablier.com).
##### Amount
Enter the total number of tokens to deposit into this stream. The full amount is deducted from the treasury when the proposal executes.
##### Duration (in days)
Enter how many days the stream should run. Tokens unlock proportionally over this period (or according to the selected curve).
##### Cliff Period (optional, in days)
Enter a cliff duration in days. During the cliff, no tokens are withdrawable by the recipient — the full amount remains locked. Once the cliff ends, the proportional share accrued since the stream start becomes available, and the stream continues normally.
Leave this field at `0` to create a stream with no cliff.
#### Adding Multiple Streams
Click **+ Add New Stream** to add additional streams in the same proposal. Each stream can have a different recipient and amount, but shares the token, duration type, and stream options set above.
#### Queuing and Submitting
When all streams are configured, click **Add Transaction to Queue**. The running total is shown in the top-right corner as **Total Amount**. You can add additional transaction types to the same proposal before proceeding.
Once all transactions are queued, click **Continue** to move to the **Review and submit** step.
### What Happens On-Chain
When a Stream Tokens proposal passes and is executed, the DAO treasury:
1. Approves the Sablier Batch contract to spend the required token amount
2. Calls `createWithDurationsLL` (or `createWithTimestampsLL`) on the Sablier Batch Lockup contract
3. One NFT per stream is minted to each recipient's address
Recipients can view their streams at [app.sablier.com](https://app.sablier.com) and withdraw vested tokens at any time. Streams are also visible in the **Details** tab of the executed proposal on Nouns Builder.
:::note
If ETH is used, the DAO treasury wraps it to WETH automatically before the stream is created.
:::
---
## Airdrop Tokens
The **Airdrop Tokens** transaction type lets a DAO distribute tokens to a list of recipients using a Sablier Merkle campaign. Recipients claim their tokens independently — no batch transactions are needed. The airdrop can be configured as an instant claim or a linear vesting stream that begins at the moment of claim.
### When to Use Airdrop Tokens
Use Airdrop Tokens when your DAO wants to:
- Distribute tokens to many addresses simultaneously
- Allow recipients to claim at their own convenience
- Combine a token distribution with linear vesting (so recipients unlock tokens gradually after claiming)
### Creating an Airdrop Tokens Proposal
#### Navigate to the Proposal Builder
Go to your DAO's governance page and click **Create Proposal**. On the **Add Transactions** step, open the transaction type selector and choose **Airdrop Tokens**.
#### Airdrop Type
Select the distribution mechanism. This setting applies to the entire campaign.
- **Instant** — Recipients receive their full token allocation the moment they claim. Tokens are transferred directly to their wallet.
- **LL (Linear Vesting)** — When a recipient claims, a Sablier Lockup Linear stream is created for them. Tokens vest over the campaign's configured duration, starting from the moment of claim.
#### Campaign Name
Enter a human-readable name for the airdrop campaign (e.g., `Builders Airdrop`). This name is displayed in the Sablier interface and in the proposal details view on Nouns Builder.
#### Select Token
Choose the treasury asset to distribute. The dropdown lists all tokens held in the DAO treasury, plus a **Custom Token Address** option for tokens not shown.
:::note
ETH cannot be used directly in an airdrop campaign. Select an ERC-20 token. If you wish to distribute ETH, wrap it to WETH first via a separate transaction.
:::
#### Recipients
Once a token is selected, the recipients section allows you to define the airdrop allocation list. You can:
- **Upload a CSV file** — Each row should contain a recipient address and a token amount.
- **Paste addresses manually** — Enter addresses and amounts directly into the interface.
The **Airdrop Overview** panel at the top of the form updates dynamically to show the total number of recipients and the aggregate token amount.
#### Vesting Duration (LL type only)
If you selected **LL (Linear Vesting)** as the airdrop type, an additional field appears to set the vesting duration in days. Tokens will unlock linearly over this period starting from the moment each recipient claims.
#### Expiration (optional)
You may optionally set an expiration date for the campaign. After this date, unclaimed tokens can be clawed back to the DAO treasury. If no expiration is set, the campaign remains open indefinitely.
#### Queuing and Submitting
When the campaign is fully configured, click **Add Transaction to Queue**. Proceed with the rest of the proposal flow and click **Continue** to reach the **Review and submit** step.
### What Happens On-Chain
When an Airdrop Tokens proposal passes and is executed, the DAO treasury:
1. Approves the Sablier Merkle factory contract to spend the required token amount
2. Deploys a new Merkle campaign contract with the recipient data stored as a Merkle root on IPFS
3. Tokens are locked in the campaign contract until recipients claim
Recipients can view and claim their allocation at [app.sablier.com](https://app.sablier.com) by connecting their wallet. For **LL** campaigns, a personal Lockup Linear stream NFT is minted to the recipient at the moment of claim.
## Viewing Streams and Airdrops After Execution
Once a Sablier proposal has been executed, the **Details** tab of the proposal page on Nouns Builder displays:
- A summary panel for each stream or campaign, including recipient, token, amount, duration, and current status
- A link to view the stream or campaign directly on [app.sablier.com](https://app.sablier.com)
- For streams: the delegated sender address and real-time withdrawal data
## How to Post a Propdate
Source: https://docs.nouns.build/onboarding/builder-propdates/
## Overview
In addition to creating milestone-based escrow proposals and requesting the release of milestones, users and DAO members can now **post updates**, so‑called *Propdates*, directly within the proposal feed. These updates use the [Ethereum Attestation Service (EAS)](https://docs.attest.org/) to record comments and updates on-chain in a secure and verifiable way. A brief demo of the functionality can be found [here](https://www.loom.com/share/d1a42ab110b94c7e8df8ec6452dd3669?sid=b4b5399f-f706-4b1a-8b80-097cab658769).
Users can access the Propdate functionality by navigating to the DAO’s `Activity` section, selecting a proposal, and scrolling down.
## Viewing Propdate
Propdates and comments by DAO members are shown by default, but non-member updates can be viewed by selecting `All Propdates`.
## How It Works
Each update or release request is stored as an **on-chain attestation** using EAS, read more at the [Attestations Reference](../contributors/attestations). Propdates you post will appear in the **"Propdates"** feed under the proposal.
By selecting `Post Propdate` users and DAO members can comment on proposals before, during, and after voting ended to:
- Add public updates
- Track progress across milestones
- Reply to comments and updates
## Submitting an Update
1. Open the **Proposal Page**.
2. Click `Create Propdate` under the Propdates section.
3. Type your message.
4. Click `Post Propdate` and sign the transaction in your wallet.
5. Wait for the propdate to be posted on chain.
Alternatively, you can also respond to Propdates by using the `Reply` functionality.
Using Propdates will create an EAS attestation on-chain that is tied to the selected proposal, and your wallet address or ENS will be associated with the content.
## Recent Additions
1. You can now select a milestone for making a propdate on a specific milestone.
2. Propdates now support markdown.
## Founder Rewards Allocation
Source: https://docs.nouns.build/onboarding/founder-rewards-vs-token-allocation/
Description: Clarifies the difference between protocol reward distribution and configurable token allocations in Nouns Builder.
#### Understanding the difference between Reward Splits vs. Token Allocations
When deploying a DAO with Nouns Builder, there are two distinct settings that govern how funds and tokens are distributed. These are often confused but are technically and operationally separate.
This guide explains the key differences between **protocol-level auction reward splits** and **configurable token allocations**, and provides instructions for withdrawing funds from the Rewards contract.
## 1. Auction Rewards (Protocol-Level Split)
When a DAO is deployed, a fixed portion of auction proceeds is routed to a designated **Rewards Recipient**. This address is set at deployment and **cannot be changed later**. It is part of the protocol logic.
These rewards accumulate in the Builder Protocol Rewards contract and can be claimed via the Builder frontend.
The Auction Rewards section displays the following splits with tooltips:
- **Builder Rewards:** Rewards paid to Nouns Builder for maintaining the DAO’s core infrastructure and tooling. (2.50%)
- **Referral Rewards:** Rewards paid to users who refer new bidders to auctions, or to developers integrating referrals into external UIs. (2.50%)
- **Founder Rewards:** Rewards paid to the DAO founders for their role in creating the DAO. (e.g., 50.00%)
The **Recipient** address and **Balance** are shown below, along with a **Withdraw** button. Note that the Recipient and Balance are not displayed if the Founder Rewards Split Percentage is set at 0.
## Claiming Protocol Rewards
To withdraw funds:
1. Navigate to the Auction Rewards section in your DAO's dashboard.
2. Ensure you are connected with the wallet that controls the Rewards Recipient address.
3. Review the current Balance.
4. Click the **Withdraw** button to claim the full accumulated ETH rewards.
:::tip[Note:]
If the Founder Rewards Split is set at 0, no Recipient or Balance will be displayed, and no withdrawal is available.
:::
Alternatively, for manual claiming via contract interaction:
1. Go to the [Rewards Contract on BaseScan](https://basescan.org/address/0x7777777F279eba3d3Ad8F4E708545291A6fDBA8B#writeContract)
2. Connect your wallet via "Connect to Web3"
3. Navigate to the `Write Contract` tab
4. Use function `#5 withdrawFor(address recipient, uint256 amount)`
5. For `recipient`, input the DAO’s reward address (typically your treasury or multisig)
- **Example only:** `0x894F30da29216516b5aE85207dED77038C107f22` (used by nouns.build — do not use this for your DAO)
6. For `amount`, input `0` — this will sweep the full balance owed.
## 2. Token Allocations (Configurable)
Token Allocations allow a DAO to automatically allocate a percentage of newly minted NFTs to one or more addresses. This setting **can be configured or updated via the Admin tab** in the app UI.
These allocations are not related to the ETH collected from auctions. Instead, they govern who receives minted NFTs and in what proportion.
## Common Use Cases
- Allocating tokens to contributors
- Reserving a percentage for community treasury
- Routing mints to sub-DAOs or partnerships
## Summary
| Feature | Auction Rewards | Token Allocations |
|----------------------|------------------------------------------|---------------------------------------------|
| Funds or Tokens? | ETH from auction proceeds | ERC-721 NFTs |
| Configurable? | No (hardcoded at DAO deployment) | Yes (configurable via UI) |
| Purpose | Sends ETH to reward address | Sends NFTs to allocation addresses |
| Where to Manage | Auction Rewards section in DAO dashboard | Admin tab in nouns.build UI
## Your Profile
Source: https://docs.nouns.build/onboarding/user-profile/
##### Learn how to manage your profile and customize which DAOs appear in your dashboard.
# Your Profile
##### Manage your identity and DAO visibility on Nouns Builder
Your profile page gives you an at-a-glance view of your on-chain activity and the DAOs you are a member of. It is accessible by connecting your wallet and navigating to your profile via the avatar menu in the top-right corner of the app.
## Profile Overview
Once connected, your profile displays:
- Your **ENS name** (or shortened wallet address if no ENS is set)
- Your **wallet address**, with a one-click copy button
- A **Feed** of your recent on-chain activity across all DAOs — including proposals submitted, votes cast, and proposals executed
- A **Tokens** tab listing the DAO tokens you hold
## DAOs Section
The **DAOs** section on your profile lists every DAO in which your connected wallet holds a token. Each entry shows the DAO name, logo, and the network it is deployed on (e.g. Ethereum mainnet, Base, Optimism).
DAOs you have chosen to hide are collapsed under a **Hidden DAOs** counter. Click the arrow to expand and view them.
**Hidden DAOs (default)**
**Open DAOs**
## Editing Your DAO List
You can customise which DAOs are visible on your profile and in your wallet dropdown by using the **Edit** mode.
1. **Open Edit mode**
Click the **Edit** button next to the DAOs heading on your profile page. Each DAO entry will now show additional controls.
2. **Hide a DAO**
Click the **minus (−)** icon next to a DAO to hide it. Hidden DAOs are moved to the **Hidden DAOs** group and are no longer shown in your profile or wallet dropdown by default. You can also use the arrows to reorder DAOs.
3. **Restore a hidden DAO**
Expand the **Hidden DAOs** section by clicking the arrow. Click the **plus (+)** icon next to any hidden DAO to make it visible again.
4. **Reorder your DAOs**
Click and drag the **move (⊕)** handle on the right side of a DAO entry to reorder how DAOs appear in your list.
5. **Save your changes**
Click **Done** to exit Edit mode and save your preferences.
## Wallet Dropdown
The wallet dropdown — accessible by clicking your avatar in the top-right corner — mirrors your profile's DAO list. It shows:
- Your **ENS name** and current **ETH balance**
- Your **visible DAOs**, each with its network indicator
- A count of **Hidden DAOs**, expandable inline
- A **Create a DAO** button to launch a new DAO
- A quick link to switch between **Mainnet** and testnet environments
Changes made in Edit mode on your profile are reflected immediately in the wallet dropdown.
:::note
DAOs are only shown if your connected wallet holds at least one token for that DAO. If a DAO you expect to see is missing, verify that you are connected with the correct wallet and on the correct network.
:::
## Next Steps
- [How to Create a DAO](/guides/builder-deployment/)
- [Proposals and Voting](/guides/governance/)
- [How to Create a Proposal](/onboarding/builder-proposal/)
## Nouns Builder Docs
Source: https://docs.nouns.build/
Description: Nouns builder allows anyone to easily deploy a DAO in minutes
## Deploy a DAO in minutes with Nouns Builder!