Abstract

This document specifies the changes included in the Builder Protocol upgrade named "Bali."

Specification

1. Token Reserve: Reserve n tokens for claiming when a DAO is created. Used for DAOs that want to offer reserved token claims via minters.
2. Merkle Reserve Minter: Allow reserved token claiming via merkle proofs. Used for DAOs that want to include a preset list of members to claim tokens.
3. L2 Migration Deployer: Helper contract that lets L1 DAOs deploy and seed a DAO on L2.
4. Alternate Metadata Renderers: Allow current DAOs to set a new metadata renderer. Allow new deployments to choose an alternate renderer.
5. Protocol Rewards: Rewards taken as a percent of protocol auctions distributed to bid referrals, DAO founders and BuilderDAO

Token Reserve

Allows DAO deployers to reserve n tokens for claiming via minters. Useful for deployers that want to use allowlists, presales or other claim systems.

Spec

Token.initialize

• A DAO creator can choose to reserve the first n tokens for claimants using TokenParams.reservedUntilTokenId. When unpaused auction will start at the given tokenId

Token.mintFromReserve

• Allows a minter to mint a token from the reserve to a given address

UI

• Change token artwork display to show a placeholder for claimed tokens that have not been minted yet (these will have no artwork).

Merkle Reserve Minter

DAO deployers want to seed DAOs with specific members. Deployers can use MerkleReserveMinter.sol to set a merkle root with a list of users to claim and optionally set a cost to claim. Users can claim reserved tokens using merkle proofs.

Spec

setMintSettings

• Allows the current DAO owner to set a merkle root, token price and start / end time.

mintFromReserve

• Allows a caller to mint from the token reserve if they provide a valid merkle proof and msg.value.
• Merkle leaf format: keccak256(abi.encode(claim.mintTo, claim.tokenId)))

L2 Migration Deployer

Users want to migrate DAOs from L1 onto L2. We are supporting DAOs moving from L1 to a set of OP stack L2s (optimism, base, zora) via this helper contract. This contract uses the Optimism CrossDomainMessenger.sol contract to get the L1 caller. The caller must set the L2MigrationDeployer.sol contract as the first founder (with 0 allocation) so it can manage setup. this ownership can be renounced once setup is complete. DAOs deployed via this contract will require a proposal to unpause auctions after renounceOwnership is called.

Spec

deploy

• Deploys a DAO with the given paramters on L2
• sets the merkle minter to allow L1 holders to claim
• stores a mapping of the L1 caller => L2 DAO

resetDeployment

• Resets the deployment mapping if a caller want to redeploy.

callMetadataRenderer

• Allows the caller to make generic calls to its deployed metadata renderer.
• This is a helper function so DAOs can deploy and set properties in one call.
• This function uses generic calls to support custom metadata renderers.

depositToTreasury

• Allows the caller to send value to it's deployed L2 treasury.

renounceOwnership

• Transfers ownership of owned contracts (Auction / Toekn) to the Treasury

Custom Metadata Renderers

Users feel that the dynamic artwork system can be challenging to work with at times, so we're adding support for custom metadata renderers. New DAOs can pass in a renderer address on deployment and current DAOs can replace their renderer.

Spec

Manager.deploy

• Allow users to pass in a custom metadata renderer using TokenParams.metadataRenderer

Manager.setMetadataRenderer

• Allow the Token contract owner to change the DAOs metadata renderer.

Token.setMetadataRenderer

• Allow the manager to change the tokens metadata renderer.

UI

• Add support for new media types when rendering token artwork..
• Change subgraph to work with generic metadata renderers.

Protocol Rewards

Builder Protocol Rewards is a rendition of the Zora Protocol Rewards model. This feature composes with the ProtocolRewards.sol contract from ourzora/zora-protocol/protocol-rewards repository. The final auction amount will be split three ways.

1. BuilderDAO Rewards (Static %)
2. Referral rewards (Static %)
3. Founder rewards (Variable 0% - 30%)
4. DAO Treasury (Remaining auction amount)

Manager.sol

• BuilderDAO reward recipient is set as an imutable on contract deployment
• Builder recipient is set here so it can be globally changed in future upgrades if needed.

Auctions.sol

• BuilderDAO and Referral reward percentages set as an immutable on contract deployment so DAOs can opt in to new reward percentages.
• A DAO founder can set a founder reward percentage and recipent in the initialization() call
• clients can call createBidWithReferral() to set an address as a referral when placing a bid
• _settleAuction() must payout rewards to ProtocolRewards.sol

UI

• Add an explanation on protocol fees to the docs, create DAO page, Upgrade notes, and bid flow for upgraded/new DAOs.
• Display a users available rewards on dashboard when wallet is connected