Introduction

The first generation of DAO governance assumed that token-weighted voting was basically the same thing as democracy. It isn't, and the last few years have made that pretty clear. What we got instead was plutocracy with extra steps: low turnout, voter apathy, and legitimacy that snaps the moment anyone tests it.

There's a lot to learn from older political systems if we're willing to look. The U.S. gets a lot of mileage out of separation of powers and constitutional limits. Switzerland's legitimacy comes mostly from the fact that ordinary citizens can actually trigger referenda. And Bitcoin, which has no formal authority at all, holds together because rough social consensus turns out to be surprisingly durable.

This proposal pulls from all three. The result is a constitutional, multi-faction system with expiring delegation, permissionless participation, and emergency powers that are kept on a short leash.

U for United States, S for Switzerland, B for Bitcoin.

The USB System.

1. Constitutional Foundation

At the core of the system is a written constitution that draws the lines around what governance is allowed to do.

It defines:

• The rights of participants (users, builders, validators, and other stakeholders)
• The scope and limits of governance authority
• The rules for protocol upgrades
• Treasury constraints and spending authority
• Emergency procedures
• The structure and rights of stakeholder factions

Governance, in other words, is not sovereign. It can't rewrite the core rules on a whim — amendment thresholds have to be cleared first.

Amendment Rules

Constitutional amendments require:

• A supermajority of total voting power
• Approval from a supermajority of stakeholder factions
• A direct referendum of users
• A time delay before activation

This is essentially Switzerland's "double majority" idea, ported into a multi-faction context.

Seasons

The protocol enforces a sense of periodicity. Governance systems reset, and have to be reinstantiated from scratch.

The first four periods run 6 months, the next four run 18 months, and every period after that is 3 years. This schedule is immutable, so changing it requires a hardfork.

At the start of each season:

• Delegations get reset
• Proposal types expire
• Voting mechanisms revert
• Difficulty-bombs kick in

The point is to give the system a heartbeat. The status quo gets challenged on a regular cadence, which lets new leaders surface and steer things in whatever direction the stakeholders actually want.

2. The Five-Faction Model

Rather than mashing governance into a single electorate, the system treats blockchains as the multi-stakeholder things they actually are. Different groups, different forms of legitimacy.

A reasonable cut is five factions:

1. Token Holders (Capital)
2. Validators / Operators (Infrastructure)
3. Builders / Core Contributors (Protocol Development)
4. Application Developers (Ecosystem)
5. Users / Citizens (End Participants)

Each faction is its own "house" within governance.

Voting Models

Each house picks its own voting mechanism. The protocol ships these as base primitives — interchangeable, upgradeable, and installable like modules. After every season the mechanism reverts to a base model and has to be re-enacted by the newly chosen stewarts.

• Token holders: capped or quadratic token voting
• Validators: one-entity-one-vote with stake caps
• Builders: reputation-based or contribution-weighted voting
• Applications: recognized ecosystem entities
• Users: identity-based, delegated, or community-weighted voting

Example Proposal

A standard proposal passes only if:

• It achieves a majority across all participating houses
• It is approved by at least 3 of 5 factions
• It is not vetoed by a directly affected faction

The structure makes it hard for any one group — capital especially — to run the table.

3. Separation of Powers

Borrowing from constitutional systems, governance gets split into three jobs:

Legislative

The multi-faction system proposes and approves policy.

Executive

Execution is delegated out — to protocol foundations, working groups, or whatever service providers are doing the implementation.

Judicial

A constitutional review mechanism checks that proposals actually comply with the constitution. It's a narrow role on purpose: validity, not policy.

4. Protocol Upgrades via Rough Consensus

Formal voting on its own isn't enough for protocol-level changes. The upgrade process borrows from Bitcoin:

1. Proposal specification (technical RFC)
2. Independent implementations by multiple client teams
3. Public review and testing
4. Testnet deployment
5. Ecosystem signaling
6. Governance approval
7. Delayed activation with opt-in participation

The goal is for legitimacy to come from alignment between developers, operators, and users — not just from a vote count.

5. Direct Democracy Mechanisms

To keep governance from being captured, citizens need a way to push back.

Initiatives

Stakeholders can force proposals onto the agenda if they hit certain thresholds:

• User signatures
• Validator support
• Cross-faction sponsorship

Referenda

After a proposal passes, stakeholders get a window in which they can trigger a referendum.

This is a second layer of legitimacy. It keeps governance accountable even after a vote technically went through.

6. Expiring Delegation and Campaign Cycles

One of the recurring failures of DAO governance is that delegated power tends to stick around forever, whether or not the delegate is still doing anything.

The system enforces delegation expiration at the protocol level:

• Delegations automatically expire at the end of each season
• Users must actively re-delegate, or vote directly
• Delegation can be domain-specific (e.g., separate delegates for treasury, protocol, and ecosystem decisions)

Effects

This produces recurring campaign cycles:

• Delegates have to keep earning trust
• New entrants can challenge incumbents
• Governance stays dynamic instead of ossifying

Legitimacy becomes something you keep up, not something you win once.

7. Proposal Admission and Curation

There's no single gatekeeper. Proposals can come in through multiple paths:

• Stakeholder sponsorship
• User-driven initiatives
• Delegate-backed proposals
• Technical RFC processes
• Permissionless submission with anti-spam constraints

Anti-Spam Mechanisms

Permissionless proposals get submitted to the chain through a proof-of-work gate. PoW is here for spam resistance, not for governance weight.

The required PoW is pegged to an oracle that tracks Bitcoin's difficulty, so the cost moves with market rates.

8. Emergency Mechanisms Without Centralized Councils

Instead of a standing emergency council, the system uses constitutional circuit breakers.

Emergency Actions

Temporary measures can:

• Pause specific modules
• Restrict functionality
• Trigger investigation processes

They cannot:

• Transfer funds
• Change balances
• Permanently alter the protocol

Activation

Emergency actions require:

• Approval from multiple stakeholder factions
• Participation from infrastructure operators
• Public justification

All actions:

• Expire automatically after a short duration
• Require post-hoc ratification

You get responsiveness without handing anyone a permanent kill switch.

9. Design Principles

A few principles run through the whole system:

Legitimacy is Multi-Dimensional

Different stakeholders have authority over different things.

Governance is Constrained

The constitution defines what governance can't do.

Participation Must Be Renewed

Delegation expires. Engagement has to be ongoing.

Power Must Be Distributed

No single faction runs the system.

Processes Must Be Transparent and Deliberative

Decisions are supposed to come out of structured review, not instant voting.

Conclusion

The next generation of blockchain governance shouldn't just copy traditional systems, and it shouldn't keep extending the DAO playbook either. The interesting move is to compose the strongest pieces of each:

• The constitutional safeguards of the United States
• The direct participation of Switzerland
• The consensus-driven legitimacy of Bitcoin
• The programmability and transparency of blockchains

What you end up with is governance that can resist capture, adapt over time, hold legitimacy across very different stakeholder groups, and scale with the actual complexity of decentralized systems.

The deeper point is this:

Governance isn't really about who votes. It's about who has legitimate authority over which decisions, and how that authority is continuously earned.

Expected Questions

How does a network upgrade work?

A network upgrade follows a staged, legitimacy-first process: it begins as a public technical RFC, undergoes rigorous review and testing (including implementations and testnet deployment), and is classified by impact before entering a signaling phase across all stakeholder factions; only once rough consensus emerges does it become a formal proposal, requiring a multi-faction supermajority vote, followed by a challenge window to catch constitutional or technical issues; if approved, the upgrade proceeds to a validator readiness phase and activates only after sufficient network adoption, with a delayed activation and post-upgrade review ensuring that changes are not merely voted in, but broadly validated, safely implemented, and socially accepted.

Where does this breakdown?

Technologist-Control. While the proposal calls out 5 factions, there are 2 super factions. Technologists, and non-technologists. The forcing function to bind governance-driven outcomes, and the will of the voting class, is held hostage by the technologists, who do unfortunately wield power over the system.

Complexity. The system is fairly complex, so there is a risk that only a fraction of the stake holders engage.

Latency. The process is slow. There is a material lag between idea and implementation.

Grid-lock. The seasonal resets carry a risk of blocking change management, if the stakeholders fail to take action.

Seasonal Fatigue. The exact timing of each season could be sub-optimal. They are chosen in a subjective way by the author.

Bootstrapping is Hard. The system really is designed to work at scale, not when numbers are low.

Disclosures

** This submission was voluntary, but done by an employee from Agora. **