Litepaper: Powers v0.4

Modular Institutional Design for On-Chain Governance

Docs | Examples | Deploy Your Own

1. Introduction

The crypto industry has successfully solved the problem of financial coordination. With the advent of Ethereum, we moved from the idea of rigid single-purpose Coloured Coins to a general-purpose substrate where any financial asset could be programmed.

However, we have not yet solved the problem of political coordination.

The current on-chain governance landscape resembles the pre-Ethereum Coloured Coins approach to financial coordination. If a DAO wants to implement state-of-the-art mechanisms such as Lido's Dual Governance or Optimism's Bicameralism, they must engineer massive bespoke and monolithic smart contracts. These systems are rigid, expensive to audit, and impossible for smaller organisations to replicate.

The Powers Protocol addresses this by introducing a general-purpose substrate for Institutional Design.

It is not a voting tool or a permission manager; it is an Institutional Virtual Machine. By treating power relationships—like checks, balances, vetoes, and delegations—as modular primitives rather than custom code, Powers allows any community to compose complex resilient institutions simply by configuring the relationships between role-restricted smart contracts called Mandates.

2. The Cost of Governance Architecture

As on-chain organisations mature, they face a critical paradox. The industry has realised that simple one-token-one-vote systems lead to apathy, inefficiency, and plutocracy. The solution is widely understood to be Separation of Powers and the delegation of powers to specialised governance bodies. This involves creating distinct organisational branches, such as Councils, Veto Guardians, and Citizen Assemblies that check and balance each other while handling specific domains of authority.

However, implementing these structures is currently a luxury good.

• The Bespoke Trap: Protocols like Lido and Optimism spend millions of dollars and years of R&D to build their specific Dual Governance contracts.
• The Moloch Drift: Because complex governance is too hard to code, most DAOs resort to Off-Chain Drift. They define their most important mandates, such as spending limits and veto rights, in forum posts or social agreements.

This reintroduces the very opacity and trust assumptions that blockchains were meant to eliminate. We need a way to bring this Constitutional Layer back on-chain without requiring every DAO to hire a solidity engineering team to write a custom Constitution Contract.

3. The Solution: Ethereum for Institutions

The Powers protocol allows DAOs to move from Governance by Forking (copying rigid contracts) to Governance by Composition.

It achieves this through a single flexible primitive called the Mandate.

3.1 Mandates: The Unit of Power

In the Powers protocol, all actions are executed through Mandates. A Mandate is a smart contract that transforms predefined input data into executable calldata. It grants the role-holder who calls it the power to act on behalf of the organisation.

This power is carefully constrained by two factors: Degrees of Freedom and Conditions.

• Degrees of Freedom: This refers to how much influence a user has over the final executable action. A Mandate that takes no input and simply mints 50 tokens to a preset address offers zero degrees of freedom. In contrast, a Mandate that allows a user to specify any target contract and arbitrary calldata grants them full degrees of freedom. By defining the scope of user input, Mandates grant granular levels of powers to specific roles.
• Conditions: These are the rules that restrict a Mandate's execution. Beyond being role-restricted, a Mandate can be made conditional on a successful vote, passing of a timelock, or the state of another Mandate.

3.2 Cross-Mandate Conditions

Institutional governance emerges not just from assigning powers but from encoding relationships between them. In Powers, these relationships are established through Cross-Mandate Conditions. This is where the execution of one Mandate is made dependent on the state of another.

This is possible because the protocol can trace a single action across multiple Mandates. Different Mandates can be designed to accept the same input data. Although each Mandate may produce different executable calldata (or none at all), the fact that the mandateId is the only parameter that differs between user inputs means that it is possible to calculate the actionId of the same input at a different mandate.

By checking whether an actionId has been fulfilled at another Mandate, we can create complex chains of logic without writing new code.

Optimistic Execution: Mandate A (The Action) can only execute if Mandate B (The Veto) has not been triggered within a specific timeframe.

Bicameralism: Mandate A (Token House) requires a signal from Mandate B (Citizen House) to proceed.

3.3 Governed Reform

If governance is a process to be managed, then the ability to change the rules is the ultimate power. In Powers, reform is treated like any other executive action.

Since Mandates encode power relations, the ability to adopt or revoke Mandates is the power to reform the governance system itself. This allows for Governed Reform. The power to add or remove a Mandate is itself a Mandate.

An organisation can start simple and define a specific governed path for evolution. This creates a living constitution where changes follow a transparent on-chain process rather than requiring a hard fork or contract migration.

4. Comparison

5. Applications

The modular architecture of Powers allows communities to move beyond simple token voting and design bespoke governance systems that fit their specific needs.

The Trustless Multisig

• The Context: Small teams typically start with a multisig wallet. While efficient, this relies entirely on social trust. As the project grows, moving to a decentralised governance system usually requires a complex migration of the treasury known as the governance cliff.
• The Mandate Solution: Powers can serve as a Trustless Multisig. The Core Team is granted a Mandate to spend funds but it is strictly constrained by code (e.g. "Max 10k USDC/month") rather than just social agreement.
• The Benefit: This allows the organisation to start with a centralised-but-constrained team mandate and progressively introduce Veto Mandates or Council Mandates as it scales without ever migrating the underlying contract.

Accountable Working Groups

• The Problem: As organisations professionalise, they delegate tasks to specialised bodies like grants committees. However, these delegations often rely on informal off-chain mandates that are unclear or fragile.
• The Mandate Solution: A working group is granted a Mandate with high degrees of freedom to execute actions but within clear encoded boundaries (such as a budget cap or domain restriction).
• The Benefit: This clarity gives specialised teams the confidence to act swiftly while ensuring they remain trustlessly aligned with the community's goals.

Increased Efficiency

• The Problem: Voters are often overwhelmed by the cognitive burden of auditing the technical complexity of every single transaction proposal.
• The Mandate Solution: Technical constraints are embedded directly into Mandates. Voters only need to evaluate and approve the scope of the Mandate once rather than auditing every execution.
• The Benefit: The heavy lifting of security is reserved for the rare moments when a Mandate is adopted or revoked. This balances rigorous security checks with operational speed.

Asynchronous Coordination

• The Mechanism: The protocol's architecture is inherently asynchronous, allowing the fulfillment of one Mandate to trigger another at a later time.
• The Capability: Powers can natively handle workflows that span different environments whether off-chain or cross-chain.
• Example: A governance process could start on one chain, wait for a state verification from a contract on another chain, or pause for an off-chain signal before unlocking the final execution.

The AI Guardian Integration

• The Context: As Autonomous Agents become active DAO participants, they require a safety layer.
• The Mandate Solution: An AI agent is assigned a role with a specific Mandate (e.g. Rebalance Portfolio) constrained by strict Degrees of Freedom (only interact with Whitelisted Pools).
• The Safety Layer: A second Guardian AI or human committee holds a linked Veto Mandate to halt operations if anomaly detection triggers, serving as an Accountability Protocol for AI.

6. Ecosystem Context

Powers builds upon the foundational innovations of the last cycle but bridges the gap between Tooling and Institution.

• OpenZeppelin Governor: Solved Voting but treats governance as a discrete event, not a continuous process.
• Hats Protocol: Solved Role Identity but is static. It defines who has power not how it flows.
• Aragon OSx / Zodiac: Solved Permission Management but lacks the native abstractions for political relationships like checks and balances.

Powers synthesises these into a higher-order protocol. It uses voting (Governor) as an input, roles (Hats) as actors, and permissions (Aragon) as a base but binds them together with Cross-Mandate Conditions to create a living, breathing Governance system.

7. Proof of Concept & Resources

A live Proof of Concept exists that provides a full-stack governance solution.

• Protocol: https://github.com/7Cedars/powers
• Interface: https://powers-protocol.vercel.app/
• Documentation: https://powers-docs.vercel.app/

The Powers Protocol is not just an upgrade to DAO tooling; it is the infrastructure for a Cambrian explosion of on-chain institutions. Just as Ethereum allowed us to dream up any financial asset, Powers allows us to create and deploy any political structure.