Governance Charter

The charter establishes the formal process for proposing, debating, and ratifying changes to the protocol. This includes:

• Proposal Lifecycle: Defines stages from ideation to final execution.
• Voting Mechanisms: Specifies the system (e.g., token-weighted, quadratic, conviction voting).
• Quorum & Thresholds: Sets minimum participation and approval requirements for a vote to be valid.

It clearly delineates the rights and responsibilities of different actors within the ecosystem.

• Token Holders: Defines voting power, delegation rights, and proposal submission requirements.
• Core Developers/Teams: Outlines their mandate, scope of authority, and accountability.
• Delegates/Representatives: Establishes rules for delegation, including slashing or recall mechanisms for bad actors.

The charter governs the protocol's treasury, detailing how funds are managed and disbursed.

• Budgetary Control: Establishes processes for funding proposals, grants, and operational expenses.
• Multi-Sig Requirements: Defines signatory schemes for treasury transactions (e.g., 3-of-5 multi-sig).
• Example: The Uniswap Grants Program is governed by specific charter rules for allocating community funds.

It specifies the meta-governance rules for changing the charter itself and the underlying protocol.

• Constitutional Amendments: Outlines a higher-bar process for modifying the charter's core tenets.
• Smart Contract Upgrades: Defines the path for code changes, often involving timelocks and emergency procedures.
• Forking Rights: Clarifies the conditions under which the community can legitimately fork the protocol.

The charter provides a framework for handling conflicts and enforcing rules.

• Arbitration Processes: May designate on-chain courts (e.g., Kleros, Aragon Court) or off-chain mediation.
• Slashing Conditions: Defines penalties for protocol violations by validators, delegates, or other participants.
• Example: MakerDAO's charter includes explicit processes for handling oracle failures and collateral liquidations.

It mandates standards for open communication and record-keeping.

• Proposal Transparency: Requires all governance actions to be documented on-chain and in public forums.
• Vote Disclosure: May enforce a delay between vote snapshot and execution to allow for reaction.
• Reporting Standards: Obligates core teams or delegates to provide regular, verifiable reports on activities and finances.

The charter defines the formal process for submitting and processing governance actions. This includes:

• Proposal Types: Distinguishes between signaling votes, treasury spends, and parameter changes.
• Submission Requirements: Specifies prerequisites like a minimum token deposit or a forum discussion period.
• Lifecycle Stages: Outlines the path from a draft to a temperature check, formal proposal, voting, and execution.

This section specifies the technical and social rules for decision-making.

• Voting Systems: Defines the method, such as token-weighted voting, quadratic voting, or conviction voting.
• Quorum Requirements: Sets the minimum participation threshold (e.g., 4% of circulating supply) for a vote to be valid.
• Voting Period: Establishes the fixed duration (e.g., 7 days) during which votes can be cast.

The charter establishes the rules governing the protocol's treasury, which is often the largest asset under community control.

• Multisig Signers: Defines the composition and authority of a Gnosis Safe or other multisig wallet for executing approved proposals.
• Spending Limits: May set thresholds requiring different voting majorities for small vs. large expenditures.
• Asset Management: Outlines policies for holding, diversifying, or investing treasury assets like ETH, USDC, or native tokens.

To combat voter apathy, charters often formalize delegation systems.

• Delegated Voting: Allows token holders to delegate their voting power to experts or representatives.
• Delegate Requirements: May define criteria or processes for becoming a recognized delegate.
• Revocation Rights: Explicitly states that delegators can revoke their delegation at any time, preserving sovereignty.

A meta-governance clause that defines how the charter itself can be changed. This is critical for long-term adaptability.

• Higher Thresholds: Amending the constitution typically requires a supermajority (e.g., 66% or 75%) rather than a simple majority.
• Explicit Procedures: Details a specific proposal type or process reserved for charter amendments, ensuring changes are deliberate and transparent.

Prominent DAOs publish their charters as living documents.

• Uniswap: The Uniswap Governance Process is detailed in its documentation and executed via the Uniswap Governor Bravo contract.
• Compound: The Compound Governance system, powered by the Governor Bravo contract, defines proposal and voting logic in its whitepaper.
• Aragon: Provides template charters for new DAOs, covering roles, voting, and fund management in a modular format.

A robust charter defines the governance framework, including:

• Proposal Types: Specification of what can be voted on (e.g., parameter changes, treasury spend).
• Voting Mechanisms: Rules for quorum, voting power (often token-weighted), and execution delays.
• Delegation: Processes for token holders to delegate voting rights.
• Treasury Management: Guidelines for accessing and using the protocol's funds.

Ambiguity or omissions in a charter create critical vulnerabilities:

• Governance Attacks: Malicious actors can exploit vague proposal categories to drain the treasury.
• Constitutional Crises: Unclear processes for amending the charter itself can lead to forks and community splits.
• Execution Risks: Lack of timelocks or multi-sig requirements allows for rapid, uncontested execution of malicious proposals.
• Legal Liability: Poorly defined participant rights and responsibilities can expose contributors to legal risk.

Charters specify where governance actions are finalized:

• On-Chain: Votes are transactions that directly execute code changes (e.g., Compound, Uniswap). More secure but less flexible.
• Off-Chain: Voting occurs on platforms like Snapshot, with execution requiring a separate, trusted multi-sig. More flexible but introduces executor centralization risk. Most protocols use a hybrid model, with signaling off-chain and binding execution on-chain.

Some protocols implement a higher-order constitution or meta-governance layer. This is a set of immutable or extremely hard-to-change rules that the charter operates within. It protects core protocol values (e.g., "the treasury cannot be used for X") and provides a framework for resolving disputes about the charter itself, acting as a final backstop against governance capture.

The Uniswap charter outlines a structured, multi-phase process:

1. Temperature Check: Off-chain signal on the forum.
2. Consensus Check: Refined proposal requiring a minimum threshold of support.
3. Governance Proposal: Formal, on-chain proposal requiring a 4% quorum and 10 million UNI votes to pass.
4. Timelock: A 2-day delay between vote conclusion and on-chain execution. This process balances community input with security against rash changes.

• Governance Token: The asset (e.g., UNI, MKR) that confers voting rights as defined by the charter.
• Treasury Management: The rules and multi-sig signers responsible for protocol funds.
• Forking: A last-resort response to governance failure, where a community adopts a new charter and chain.
• Sybil Resistance: Mechanisms (like token weighting) to prevent one entity from creating many fake identities to sway votes.