Bitcoin L2 Governance Comparison: How Layer 2s Decide

Bitcoin Layer 2 Governance Models Compared

Governance determines how a Layer 2 protocol evolves: who proposes changes, how upgrades activate, and what happens when something goes wrong. Unlike Ethereum L2s that inherit a single execution environment, Bitcoin Layer 2s span a wide range of architectures, from federated sidechains to permissionless payment channel networks, and each architecture implies a fundamentally different governance model.

This comparison covers seven major Bitcoin L2 protocols across five governance dimensions: decision-making process, upgrade mechanisms, operator selection, emergency procedures, and decentralization status. For a broader technical comparison, see our Bitcoin Layer 2 comparison tool.

Lightning Network: Rough Consensus

The Lightning Network has no governing body, no token, and no foundation with binding authority. Protocol changes are proposed through the BOLT specification process and discussed on the Lightning development mailing list and in regular developer calls. The standard follows IETF-style "rough consensus": proposals advance when developers from multiple independent implementations converge on a design.

A critical interoperability rule enforces decentralization: a proposal only becomes an official BOLT after two independent implementations demonstrate interoperability. This is stricter than BIPs, which have no such requirement. Four major implementations (LND, Core Lightning, Eclair, and LDK) each maintain veto power through this rule, preventing any single team from unilaterally changing the protocol.

For features not intended to be universal, the bLIP (Bitcoin Lightning Improvement Proposal) framework provides a lighter process. bLIP authors build consensus within the community but do not need cross-implementation adoption. As of mid-2026, roughly 15 active bLIPs cover extensions like trampoline routing and BOLT12 Offers. BOLT12 itself was merged into the specification in September 2024 after years of development and is now supported natively by three of four major implementations.

Lightning has no formal emergency governance procedure. Individual implementations can ship hotfixes independently, but protocol-level changes still require rough consensus. This model prioritizes stability and censorship resistance over speed of iteration.

Liquid Network: Federated Governance

The Liquid Network is governed by the Liquid Federation, which consists of 81+ member organizations. The federation separates network operations (functionaries who produce blocks) from governance (elected boards that set policy).

Fifteen functionaries operate the consensus-critical infrastructure, producing blocks and managing the BTC peg through an 11-of-15 multisig wallet. Each functionary runs a Hardware Security Module that stores private keys. Keys never leave these HSM devices.

Three governance boards, each with five seats elected annually by federation members, handle distinct responsibilities:

• Membership Board: evaluates applicants and reviews member activity
• Technology Board: guides technical priorities and interfaces with Blockstream
• Oversight Board: sets governance policy, operational standards, and communications

Blockstream serves as the technical provider but does not control governance decisions. The DynaFed (Dynamic Federations) upgrade enables adding and removing functionaries without a hard fork. Functionary source code was open-sourced on August 15, 2023, enabling independent audits.

Liquid's Emergency Withdrawal Procedure provides a safety net: each pegged UTXO carries a timelock of approximately 28 days. If the federation stops functioning, emergency backup keys held in offline cold storage can recover funds after the timelock expires.

Stacks: SIP Process and On-Chain Token Voting

Stacks uses the most formalized governance process among Bitcoin L2s. The Stacks Improvement Proposal (SIP) lifecycle moves through draft submission, editor review, five specialized Consideration Advisory Boards (covering diversity, economics, ethics, governance, and technical merit), Steering Committee approval, and finally a community-wide on-chain vote for activation.

Voting power is tied to STX holdings and stacking participation. Solo stackers vote by sending 6,000 sats to designated Bitcoin addresses. Pool stackers send 1 microSTX via wallet transactions. Non-stackers connect web wallets to vote using liquid STX holdings. Voting power is calculated at the block height when voting starts, preventing transfers to double-vote.

Major upgrades require high thresholds: the Nakamoto upgrade, for example, needed 80% approval with at least 80 million stacked STX participating. It was approved in early 2024 and activated in Q4 2024. SIP-031, which established a 500 million STX Endowment for long-term ecosystem funding, passed in July 2025 with over 310 million STX in voting power and 97.5% approval, setting a record for voter turnout.

This model gives STX holders direct control over protocol economics, including emission schedules and treasury allocation. The tradeoff is that token-weighted governance concentrates power among large holders, and high approval thresholds can slow down critical changes.

Spark: Operator-Based Security

Spark currently operates with three operators (Lightspark, Flashnet, and Breez) that collectively form the Spark Entity. Each operator holds a FROST key share, and joint authorization between the user and the Spark Entity is required for any transaction. Neither the user alone nor operators alone can move funds.

Spark's security model relies on a 1-of-n honest operator assumption: as long as one operator remains honest, user funds are secure. Operators can view transfer metadata and temporarily delay transactions by going offline, but they cannot steal funds, reverse finalized transactions, or prevent users from exiting to Bitcoin mainchain unilaterally.

Spark does not yet have a formal governance framework: no token voting, no foundation, and no public proposal process. Operator selection is currently managed by Lightspark. The stated roadmap includes expanding the operator set to additional entities across diverse jurisdictions, though specific timelines have not been published. This positions Spark as a protocol that prioritizes shipping and iterating over governance formalization in its early stages.

Citrea: Token-Governed Rollup

Citrea, the first BitVM-based ZK rollup on Bitcoin, launched its CTR governance token in late May 2026. CTR has a fixed supply of 10 billion tokens with no inflation. To gain voting power, holders stake CTR to receive xCTR, a non-transferable vault receipt token. The 90-day unstaking window (with a 50% penalty for instant exit, decaying to 0% over 15 to 90 days) discourages short-term speculation.

Citrea employs a dual treasury system: a Governance Treasury controlled entirely by public xCTR voting (managing liquidity incentives, council selection, and infrastructure provider payments) and a Foundation Treasury for R&D, ecosystem grants, and strategic initiatives. The Foundation explicitly cannot use its treasury for liquidity emissions.

xCTR holders direct emissions through gauge voting each epoch and can veto proposals. The governance scope is designed to eventually include election and removal of sequencers and operators, though the sequencer remains centralized as of mid-2026 with no published timeline for decentralization.

Rootstock: RSKIP Process and Merge Mining

Rootstock combines a formal improvement proposal process (RSKIPs) with a federated peg secured by merge mining. RSKIPs follow a structured lifecycle with draft, active, accepted, adopted, deferred, rejected, withdrawn, and superseded statuses. Proposals are submitted via pull requests to the RSKIPs GitHub repository.

The PowPeg bridge operates as a 5-of-9 multisig secured by Ledger HSMs. Nine pegnatories (including Luxor, Sovryn, Xapo Bank, and others) run HSM devices that never expose private keys. Merge mining reached 87.1% of Bitcoin's hashrate in Q2 2025, providing substantial security but conferring no direct governance rights.

PowPeg composition changes require majority acceptance by current pegnatories, followed by a consensus-enforced one-week delay that allows users to exit if they distrust the new configuration. An Emergency Recovery Protocol activates after a time-locked delay if the majority of PowPeg signers stop functioning, enabling a separate public recovery multisig to release funds.

Rootstock's 2025 upgrade cycle demonstrated active governance: the Lovell upgrade (Q1) reduced gas fees by 60%, the Reed upgrade (Q3) introduced Segwit-compatible pegouts, and the Vetiver upgrade (Q4) laid groundwork for the Union Bridge. The Reed upgrade expanded maximum pegnatories from 9 to 20, with a long-term target of 60. The planned Union Bridge will shift the peg from a 5-of-9 federation to a 1-of-n honest assumption model using BitVMX.

Ark: Market-Based Governance

Ark takes a fundamentally different approach: governance through permissionless market competition rather than institutional structures. Anyone can deploy an Ark Service Provider (ASP) without permission from any authority. There is no token, no foundation, and no formal proposal process.

ASPs serve as liquidity providers, CoinJoin coordinators, and transaction round coordinators. They must lock capital to operate, creating economic alignment. Each VTXO includes a pre-signed exit path that lets owners recover bitcoin on-chain even if the ASP becomes unavailable or refuses to cooperate. An ASP can censor (refuse to include a user in future rounds) but cannot steal funds, and censored users can unilaterally exit to another ASP.

Multiple implementations exist: Arkade (by Ark Labs), which processed its first mainnet payments at the Baltic Honeybadger conference in August 2025, and Bark (by Second). The protocol's governance thesis is that competition between ASPs, combined with guaranteed exit rights, creates sufficient accountability without formal governance structures.

Upgrade Mechanisms Compared

How a protocol handles upgrades reveals the practical implications of its governance model. The following table compares upgrade activation across Bitcoin L2s, including whether upgrades can be imposed on users and what options users have to opt out.

A key pattern emerges: protocols with permissionless participation (Lightning, Ark) give users implicit opt-out by letting them choose their provider. Federated protocols (Liquid, Rootstock) provide time-locked exit windows. Token-governed protocols (Stacks, Citrea) offer voting rights but concentrate power among large holders. For a deeper analysis of the trust assumptions behind these models, see our Bitcoin L2 trust model comparison.

Evaluating L2 Governance

When choosing a Bitcoin L2 based on governance, consider these dimensions:

Credible exit rights: can you leave the protocol unilaterally if governance decisions go against your interests? Lightning and Ark provide the strongest exit guarantees through on-chain settlement paths. Escape hatches are the most important governance feature for users who cannot influence votes.

Upgrade velocity vs. stability: token-governed protocols like Stacks can move relatively quickly on upgrades (SIP-031 passed in a single voting cycle), while rough consensus models like Lightning prioritize stability over speed. Your preference depends on whether you value rapid feature development or protocol ossification.

Operator concentration: three operators (Spark) or nine pegnatories (Rootstock) represent different points on the decentralization spectrum. Both are expanding their sets, but the current state matters more than roadmap promises for users deploying today.

Token voting risks: protocols with governance tokens (Stacks, Citrea) can face voter apathy, plutocratic capture, or governance attacks. The absence of token voting (Lightning, Liquid, Ark) eliminates these risks but removes direct user influence over protocol direction.

Frequently Asked Questions

How does Lightning Network governance work without a token?

Lightning uses rough consensus among developers from four independent implementations (LND, Core Lightning, Eclair, LDK). Changes are proposed on the development mailing list and become official BOLT specifications only after two independent implementations demonstrate interoperability. There is no voting, no foundation with binding authority, and no single entity that can force changes. Any node operator can choose which implementation and version to run.

Which Bitcoin L2 has the most decentralized governance?

Lightning Network has the most decentralized governance: no token, no governing body, permissionless participation, and a multi-implementation interoperability requirement that distributes veto power. Ark follows a similar philosophy with permissionless ASP deployment. Stacks offers decentralized governance through on-chain voting but concentrates power among large STX holders. Federated models (Liquid, Rootstock) and operator-selected models (Spark) are more centralized by design, though each has published plans to expand participation.

Can Bitcoin L2 operators steal user funds?

The answer varies by protocol. On Lightning, channel counterparties cannot steal funds because justice transactions punish dishonest closures. On Spark, operators cannot move funds without the user's cryptographic signature, even if all operators collude. On Liquid, the 11-of-15 functionary multisig could theoretically move peg funds, but HSMs are designed to prevent unauthorized signing. On Rootstock, the PowPeg HSMs only sign transactions proven valid by sufficient proof-of-work. Ark ASPs cannot steal VTXOs because each includes a pre-signed on-chain exit path.

What happens if a Bitcoin L2 federation stops operating?

Federated protocols include emergency recovery mechanisms. Liquid uses time-locked emergency withdrawal keys held in offline cold storage: after approximately 28 days of inactivity, these keys can recover funds. Rootstock's Emergency Recovery Protocol activates after a time-locked delay, enabling a separate public recovery multisig. Spark preserves unilateral L1 exit rights regardless of operator status. These mechanisms ensure users are not permanently locked out of their funds, though recovery may take days or weeks.

How do Stacks on-chain votes actually work?

Stacks votes are conducted on the stx.eco platform during designated reward cycles. Solo stackers send 6,000 sats to designated Bitcoin addresses from their stacking reward wallets. Pool stackers send 1 microSTX via Leather or Xverse wallets. Non-stackers connect web wallets to vote using liquid STX holdings (minimum 1 STX). Voting power is locked at the block height when voting starts to prevent manipulation. Major upgrades require 80% approval with minimum participation thresholds.

What is the difference between a soft fork and an L2 upgrade?

A soft fork changes Bitcoin's base layer consensus rules and requires miner coordination across the entire network. An L2 upgrade modifies only the Layer 2 protocol's rules and can be activated through the L2's own governance process (federation vote, token vote, rough consensus, or operator coordination) without changing Bitcoin itself. However, some L2 features depend on base layer capabilities: Lightning's proposed PTLCs require Taproot, and full BitVM verification benefits from potential future opcodes like OP_CAT.

Does Citrea's CTR token give governance control over the rollup?

CTR alone carries no voting rights. Holders must stake CTR to receive xCTR, a non-transferable vault receipt token, which grants governance power. xCTR holders control the Governance Treasury (directing liquidity incentives, council selection, and infrastructure payments) and can veto proposals. The governance scope is designed to eventually include sequencer and operator selection, but the sequencer remains centralized as of mid-2026. The 90-day unstaking window with early exit penalties (50% decaying to 0%) is designed to align long-term holder interests with governance decisions.

This tool is for informational purposes only and does not constitute financial advice. Governance models, operator counts, and decentralization roadmaps change frequently. Data is based on publicly available information as of mid-2026. Always verify current governance structures through official protocol documentation before making decisions.