Proposal 87
Executed
Deploy Bali to L2
For
97
Against
0
Abstain
0
Threshold
40 votes
Current threshold
Ended
Jan, 29, 2024
5:44:59 PM GMT +0:00
Snapshot
#19063828
Taken at block
Description

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:

  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

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:

  • Ethereum mainnet

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?

  1. minimize costs for the DAO. deploying multiple times on L1 could lead to large deployment costs
  2. 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
  3. 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.

Proposer
0x71f...41ee0
Proposed Transactions