# 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