This proposal upgrades the DAO's core contracts to V3, including the Governor, Auction, Token, and Treasury, while keeping the DAO's custom MetadataRenderer unchanged.

The main governance improvements come from Governor V3:

• Updatable proposals — proposers get a short window to fix or improve a proposal before voting begins
• Signed proposals — multiple token holders can collectively sponsor a proposal using signatures

This proposal also enables a 1-day updatable proposal period as part of the same execution.

The upgrades preserve the DAO's existing proxy addresses and stored state.

⚠️ Audit Status

The V3 upgrade has not received an independent external audit.

The implementation has undergone development review and testing, including upgrade/fork testing, storage-layout validation, and internal security review, but this should not be considered a substitute for an independent audit.

The implementation and contract changes are available for review in:

BuilderOSS/nouns-protocol — PR #5

Members are encouraged to review the changes, or rely on technical reviewers they trust, before voting.

---

What This Proposal Does

If passed and executed, this proposal will:

1. Upgrade the DAO's Governor, Auction, Token, and Treasury proxies to their V3 implementations
2. Set the Governor's updatable proposal period to 1 day (86,400 seconds)
3. Enable Governor V3's signed-proposal functionality
4. Leave the DAO's custom MetadataRenderer unchanged

The Governor upgrade and configuration of the 1-day updatable period happen together in this proposal.

No additional governance proposal is required to enable the updatable period.

Good to Know: Proposal #68

An earlier Proposal #68 included the intended V3 upgrades for Governor, Auction, Token, and Treasury, but also included a MetadataRenderer upgrade by default.

Builder DAO uses a custom MetadataRenderer from its Mainnet → Base migration, so that contract should remain unchanged.

The UI default has since been corrected, Proposal #68 was cancelled, and this proposal replaces it with the intended upgrade set.

What Does Not Change

This proposal does not:

• Redeploy or replace any of the DAO's proxy contract addresses
• Change existing proposals or their voting history
• Upgrade or replace the DAO's custom MetadataRenderer
• Move treasury funds or token balances
• Alter existing token metadata or attributes

These are proxy implementation upgrades: the existing contract addresses and stored state remain in place while their implementations are updated.

---

Updatable Proposals

Today, once a proposal is submitted, its contents are effectively fixed.

Governor V3 introduces a new Updatable phase before the normal voting lifecycle:

Updatable → Pending → Active

For this DAO, the Updatable phase will last 1 day.

During this period, the original proposer can update:

• Transaction targets
• ETH values
• Calldata
• Proposal description

This allows mistakes or transaction details to be corrected, or community feedback to be incorporated, without abandoning the proposal and starting again.

What Happens When a Proposal Is Updated?

An update creates a new proposal version.

The previous version becomes Replaced, and the Governor records which proposal replaced it so the full history remains traceable.

Importantly, updating a proposal does not reset its governance timeline or voting-power snapshot.

The replacement inherits the original proposal's:

• Voting-power snapshot
• Vote start
• Vote end
• Proposal threshold
• Quorum

This prevents the update mechanism from being used to change the electorate or extend the voting timeline.

---

Signed Proposals

Governor V3 also introduces proposeBySigs.

Instead of requiring one proposer to independently satisfy the proposal threshold, multiple token holders can collectively sponsor a proposal.

How It Works

1. A proposal is prepared
2. Token holders sign their support for it
3. Their voting power is combined with the proposer's voting power
4. Once the proposal threshold is exceeded, the proposal can be submitted onchain

A signed proposal can include up to 16 sponsors.

Signatures use EIP-712, include nonce and deadline protection, and support smart-contract wallets through ERC-1271.

All proposal sponsors can be recorded and displayed by supporting interfaces.

Important Signer Behavior

For signed proposals, the proposer or any individual sponsor can cancel the proposal before execution.

This is intentional behavior in Governor V3 and should be understood before sponsoring a proposal.

---

New Proposal States

Governor V3 introduces two additional proposal states:

Updatable

The proposal has been created but is still within its configured editing window.

Replaced

The proposal was updated and superseded by a newer version.

This makes proposal history explicit rather than treating an updated proposal as simply cancelled.

---

Compatibility Note

Governor V3 changes the format used by castVoteBySig.

Any external application, relayer, bot, or gasless-voting integration that creates off-chain vote signatures using the V2 format will need to support the V3 signature format.

Regular onchain voting is unaffected.

Interfaces and integrations that rely on Governor events or proposal-state enums should also support the new Updatable and Replaced states.

---

Technical Details

• Contract Version: 3.0.0
• Updatable Period: 1 day / 86,400 seconds
• Maximum Proposal Sponsors: 16
• Upgrade Type: Proxy implementation upgrades
• Upgraded Contracts: Governor, Auction, Token, Treasury
• MetadataRenderer: Unchanged
• Implementation PR: BuilderOSS/nouns-protocol #5

Governor V3 includes additional protections around proposal updates and signed sponsorship, including:

• Voting-power snapshots remaining fixed across proposal updates
• EIP-712 domain separation
• Per-signer nonces and signature deadlines
• Duplicate-signer prevention
• ERC-1271 smart-wallet signature support
• Proposal replacement tracking
• Storage-layout validation for the upgrade

For voters who want to review the implementation, upgrade architecture, storage compatibility, and testing in more detail, see PR #5 above.

---

Security & Upgrade Considerations

• These are proxy upgrades, not contract redeployments
• Existing contract addresses and stored state are preserved
• Existing proposals and votes remain intact
• The V3 implementations must be registered through the Builder Manager
• The DAO itself must approve and execute the upgrades through governance
• The Governor's updatable period is configured immediately after the Governor upgrade as part of this same proposal
• The updatable period can be changed again through governance in the future
• The contracts can be upgraded again through a future governance proposal

⚠️ Independent Audit Disclaimer

Despite the testing and review performed to date, the V3 upgrade has not undergone an independent external audit.

Smart-contract upgrades can introduce unexpected behavior or integration issues even when extensively tested.

---

Voting Acknowledgement

By voting FOR this proposal, you are approving:

1. The upgrade of the DAO's Governor, Auction, Token, and Treasury implementations to V3
2. Enabling a 1-day updatable proposal period
3. The introduction of signed proposal sponsorship
4. The new Updatable and Replaced proposal lifecycle states
5. The integration changes associated with Governor V3
6. Keeping the DAO's custom MetadataRenderer unchanged

You also acknowledge that:

• The upgrade is currently unaudited by an independent external auditor
• Smart-contract upgrades carry technical risk
• You have reviewed the implementation and proposal details, or are comfortable relying on technical reviewers you trust