Deploy Bali to L2
This is a proposal to deploy the Builder Protocol upgrade "Bali" to the following L2 networks
- Optimism mainnet
- Base mainnet
- Zora mainnet
This proposal includes no upgrade transactions as the L2 deployments are currently managed by the tech pod multisig (Neokry, Zaak, Valcoholics and Bill). A 0.00001 ETH transfer is included to put this proposal onchain
Bali introduces the following changes:
- Token Reserve: Reserve n tokens for claiming when a DAO is created. Used for DAOs that want to offer reserved token claims via minters.
- 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.
- L2 Migration Deployer: Helper contract that lets L1 DAOs deploy and seed a DAO on L2.
- Alternate Metadata Renderers: Allow current DAOs to set a new metadata renderer. Allow new deployments to choose an alternate renderer.
- Protocol Rewards: Rewards taken as a percent of protocol auctions distributed to bid referrals, DAO founders and BuilderDAO
For more information: view the full Bali spec
Audit
The DAO funded one audit of this version with Sherlock.
Sherlock found:
- 2 high risk issues
- 2 medium risk issues
All issues were fixed in the mitigations review. For more info: view the full sherlock audit report
L2 Deployment Configuration
The contracts will be deployed with the following values set:
Protocol Rewards
- Builder Reward: 2.5% of final auction value
- Referral Reward: 2.5% of final auction value
- Builder Recipent: OPs working group multisig
Merkle Minter
- Builder Reward:
- 0.000777 ETH for every paid mint (Collection+ treasury seed fee)
- 0 ETH for free mints (L1 -> L2 Migration)
- Builder Recipent: OPs working group multisig
Staged rollout
Since these changes are additive we have decided to deploy the upgrade in two stages.
Stage one deployments:
- Optimism mainnet
- Base mainnet
- Zora mainnet
Stage two deployment:
Upon passing of this proposal we will execute the stage one deployments. The nouns builder UI will be updated to temporarily support both versions at the same time. After a period of 1 - 2 weeks of monitoring the stage one deployments we will submit a proposal for the stage two (Ethereum mainnet) deployment.
Why do a staged deployment?
- minimize costs for the DAO. deploying multiple times on L1 could lead to large deployment costs
- speed of issue handling flexibility. since the L2 deployments are managed by the tech pod multisig it allows us to quickly fix any issues that may come up during the monitoring period
- reduce risks for L1 DAOs with high treasury holdings
Will this delay L2 migration for L1 DAOs?
No, migration is only dependent on Bali being deployed to L2 therefore it can be shipped after we are confident there are no issues on L2 and before the upgrades are deployed on L1.