Governance Legos

These are pluggable components that define how voting power is calculated and aggregated. Key types include:

• Token-weighted voting: One token equals one vote.
• Quadratic voting: Voting power increases with the square root of tokens committed, reducing whale dominance.
• Conviction voting: Voting power accrues over time a token is staked on a proposal.
• Multisig execution: Proposals require signatures from a threshold of designated keyholders.

Systems that allow token holders to delegate their voting power to experts or representatives, enabling efficient governance at scale.

• Liquid delegation: Delegation is fluid and can be changed or withdrawn at any time.
• Delegation platforms: Tools like Snapshot or Tally that facilitate finding and tracking delegates.
• Expert councils: Delegation to subject-matter experts for specific proposal types (e.g., grants, technical upgrades).

Modules for managing a DAO's capital, including multi-signature wallets, streaming payments, and grant frameworks.

• Multi-sig Safes: Require M-of-N approvals for transactions (e.g., Gnosis Safe).
• Streaming payments: Continuous fund disbursement over time (e.g., using Sablier or Superfluid).
• Grant frameworks: Structured programs for community funding, often using Quadratic Funding to match contributions.

Components that manage the end-to-end flow of a governance proposal, from ideation to on-chain execution.

• Temperature checks: Informal polls to gauge sentiment before a formal proposal.
• Timelocks: Enforced delay between a vote passing and execution, allowing for a safety review period.
• Automated execution: Smart contracts that automatically enact a passed proposal's payload (e.g., via Zodiac's Reality Module).

Primitives that decouple governance rights from pure token ownership, often based on contributions or verified identity.

• Non-transferable tokens (Soulbound Tokens): Represent membership, roles, or reputation that cannot be bought or sold.
• Proof-of-Personhood: Systems like Worldcoin or BrightID to prevent Sybil attacks.
• Attestation frameworks: Protocols like EAS (Ethereum Attestation Service) to issue verifiable credentials about a user's actions.

Shared interfaces and cross-chain protocols that allow Legos from different ecosystems to work together.

• ERC-20 / ERC-721: Standard token interfaces for voting power.
• EIP-4824: A proposed standard for common DAO interfaces.
• Cross-chain messaging: Using protocols like LayerZero or Axelar to enable governance across multiple blockchains.

Modules that enable token-based representation without requiring direct voter participation.

• Delegate.cash: A registry for secure, non-custodial delegation of voting power.
• Governor Bravo's Delegation: The standard mechanism where token holders delegate votes to an address. This lego separates voting power from direct wallet control, enabling expert representatives and voter apathy solutions.

Components that automate post-vote actions and enforce governance decisions on-chain.

• Gnosis Zodiac's Reality Module: Executes transactions based on the outcome of a real-world event or vote.
• OpenZeppelin Defender: A platform for automating smart contract administration and governance operations.
• Safe Snapshot X: A bridge that allows off-chain Snapshot votes to trigger on-chain Safe transactions. This layer closes the loop between decision-making and real-world execution.

Legos that move beyond pure token-weighted voting to incorporate identity and contribution.

• Gitcoin Passport: A sybil-resistant identity aggregator that scores wallet addresses.
• BrightID: A social identity network for proving uniqueness.
• POAP (Proof of Attendance Protocol): Badges that represent participation in events. These systems enable soulbound tokens (SBTs) and reputation-based voting models like conviction voting.

The delegation of voting power to a few large token holders or liquid staking derivatives (e.g., stETH, cbETH) can create single points of failure. This centralization risk is amplified when governance tokens are used as collateral in DeFi, concentrating control.

• Example: A protocol's fate could be decided by a handful of large staking pools.
• Mitigation: Implement vote-escrow models or time-locks to discourage short-term manipulation.

Modularity expands the attack surface. Key risks include:

• Proposal Spam: Flooding the system to hide malicious proposals.
• Time Manipulation: Exploiting timing between proposal, voting, and execution.
• Contract Upgradability: A malicious upgrade passed by governance can compromise the entire system.
• Example: The 2022 Beanstalk Farms exploit, where a governance proposal passed a malicious flash loan-enabled transaction.

Governance often controls a protocol treasury. Composability with DeFi Legos (e.g., yield strategies, asset managers) introduces smart contract and economic risks.

• Asset Exposure: Treasury assets deployed in other protocols inherit their risks.
• Liquidity Crises: Poorly structured proposals can drain the treasury or lock funds.
• Mitigation: Use multi-signature safeguards, treasury diversification, and slow, multi-step execution for high-value actions.

Low voter turnout is a critical security flaw, making governance susceptible to capture by a small, motivated group. This is exacerbated by gas costs and complex interfaces.

• Consequence: A proposal with 5% participation and a 51% majority is decided by just 2.55% of token holders.
• Solutions: Gasless voting (via signatures), delegation incentives, and improved UX are essential to secure broader participation.

Governance Legos often depend on external price oracles, cross-chain bridges, and other infrastructure. A failure in a dependent Lego can cripple governance functionality.

• Oracle Failure: Could break token-weighted voting or treasury valuation.
• Bridge Compromise: Could freeze cross-chain governance assets.
• Defense: Implement circuit breakers, multi-oracle feeds, and fallback mechanisms for critical dependencies.

A governance mechanism where voting power is directly proportional to the quantity of governance tokens held. This is the most common voting model in DAOs.

• Example: 1 token = 1 vote.
• Pros: Simple to implement, aligns incentives with economic stake.
• Cons: Can lead to plutocracy, where large holders dominate decisions.

A voting system designed to reduce the power of large token holders. The cost of casting additional votes on a proposal increases quadratically.

• Mechanism: Cost = (Number of Votes)².
• Goal: To measure the intensity of preference, allowing many small holders to collectively outweigh a single large holder.
• Use Case: Implemented in projects like Gitcoin Grants for community funding rounds.

A digital asset that confers voting rights within a decentralized protocol or DAO. It is the primary coordination lego for aligning stakeholders.

• Utility: Used to create proposals, vote, and delegate voting power.
• Examples: UNI (Uniswap), MKR (MakerDAO), AAVE (Aave).
• Distribution: Often issued via liquidity mining, airdrops, or gradual decentralization.

A model where proposals are executed immediately after a vote, but can be challenged and reversed during a dispute period. It combines speed with security.

• Process: 1) Vote passes, 2) Action executes, 3) Challenge period begins where anyone can dispute the result.
• Security: Relies on a fraud-proof or dispute resolution system (like a DAO or security council).
• Use Case: Adopted by Optimism and other Layer 2 networks for fast protocol upgrades.

A design philosophy aiming to reduce the scope and frequency of active governance. The goal is to create systems that are credibly neutral and require minimal human intervention, thus lowering attack surfaces and political risk.

• Principles: Immutable core contracts, parameterized adjustments, and exit rights for users.
• Example: Uniswap v3's core AMM logic is immutable, limiting governance to fee tier changes and treasury control.