Bitcoin L2 Trust Spectrum: From Unilateral Exit to Federated Custody

Not all Bitcoin Layer 2s are created equal. Some let you withdraw your Bitcoin to the base chain at any time, without asking anyone for permission. Others require a federation of companies to cooperate before you can exit. The difference between these models is not cosmetic: it determines whether your funds are truly yours or whether you are trusting a group of signers not to collude, disappear, or get compromised.

As the Bitcoin L2 landscape expands, evaluating these trust assumptions has become one of the most important tasks for developers, institutions, and users choosing where to park their Bitcoin. This article presents a four-tier framework for classifying Bitcoin L2 trust models, maps every major protocol to its tier, and examines the practical consequences of each design choice.

Why Trust Models Matter

Bitcoin's base layer offers a specific guarantee: self-custody. If you hold your private keys, no entity on earth can prevent you from spending your coins. That property is the entire point. Every Layer 2 protocol makes some compromise on this guarantee in exchange for speed, cost, or programmability. The question is how much of a compromise.

Trust model analysis answers a simple question: what is the worst thing that can happen to your funds, and who has to misbehave for it to happen? A protocol where a single corrupt operator can steal your Bitcoin is fundamentally different from one where you can always broadcast a transaction to L1 and recover your coins. Both may call themselves "Layer 2s," but the security properties are not comparable.

This distinction matters most during stress events: exchange collapses, regulatory seizures, operator bankruptcies, or coordinated attacks. The protocols that survive these scenarios are the ones where users do not depend on any third party to exit.

A Four-Tier Trust Framework

We can classify Bitcoin L2 trust models into four tiers based on a single criterion: what does a user need in order to withdraw their funds back to Bitcoin L1? The tiers range from full sovereignty (no cooperation required) to full delegation (federation must cooperate).

Important nuance: Many protocols span multiple tiers depending on which operation you are analyzing. Lightning, for example, provides Tier 1 unilateral exit but requires Tier 2 liveness monitoring to prevent fraud. The tier a protocol occupies refers to the strongest guarantee it offers for fund recovery.

Tier 1: Unilateral Exit Without Cooperation

Tier 1 represents the gold standard for Bitcoin L2 security. Users hold pre-signed transactions that can be broadcast to Bitcoin L1 at any time, without cooperation from operators, counterparties, or any third party. The exit path is purely cryptographic: if you have the transaction, you can leave.

Lightning Network

The Lightning Network uses bidirectional payment channels secured by commitment transactions. Each party in a channel holds the latest commitment transaction, which they can broadcast to force-close the channel and recover their balance on L1. No cooperation from the channel partner is required.

The mechanism works through a penalty system: HTLCs and revocation keys ensure that broadcasting an outdated state results in the cheating party losing their entire channel balance. This makes fraud economically irrational rather than technically impossible.

Lightning's exit guarantee is strong but comes with operational overhead. Users must manage channel liquidity, maintain inbound and outbound capacity, and either stay online or delegate monitoring to a watchtower. For mobile users who cannot run persistent nodes, the watchtower dependency introduces a secondary trust assumption (Tier 2).

Spark

Spark achieves unilateral exit through a different mechanism. Rather than payment channels, Spark uses statechain-derived architecture where Bitcoin is held in 2-of-2 multisig outputs between the user and a set of operators. Upon receiving funds, users obtain pre-signed exit transactions with relative timelocks. These transactions can be broadcast to L1 at any time without operator participation.

The operator set (currently Lightspark and Flashnet) collectively holds one key via FROST threshold signatures. The user holds the other. Neither party can spend alone, and the pre-signed exit transactions guarantee the user can always recover funds on L1.

Spark's trust model operates on a 1-of-n assumption during transfers: as long as one operator honestly deletes its old key share after a transfer, the previous owner cannot double-spend. Once the transfer completes and keys are rotated, even a total compromise of all operators cannot reverse the transaction. This "moment-in-time" trust property provides perfect forward security.

Ark

The Ark protocol achieves unilateral exit through virtual UTXOs (VTXOs): off-chain representations of Bitcoin ownership backed by trees of pre-signed transactions. Users can convert any VTXO into an on-chain UTXO by broadcasting the relevant branch and leaf transactions, without cooperation from the Ark Service Provider (ASP).

Ark's exit mechanism is genuinely trustless, but VTXOs carry an expiration: an absolute timelock after which the ASP can reclaim the funds. Users must refresh their VTXOs before expiry by participating in a new round with the ASP. This creates a liveness requirement that Lightning and Spark do not share: if you go offline for too long, you risk losing access to your funds.

Tier 2: Unilateral Exit With Liveness Requirements

Tier 2 protocols offer unilateral exit, but the exit is only secure if the user (or a delegate) performs specific actions within time-bound windows. Miss the window, and the security guarantee degrades.

Lightning Penalty Channels

Lightning's penalty mechanism requires monitoring: if your channel partner broadcasts a revoked commitment transaction, you must submit the justice transaction before the timelock expires. Fail to do so, and the counterparty successfully steals your funds.

For always-online nodes (routing nodes, merchant terminals), this is a non-issue: the software handles it automatically. For mobile wallets and casual users, the monitoring burden is delegated to watchtowers: third-party services that watch the chain on your behalf and submit penalty transactions if fraud is detected.

The watchtower model is pragmatically effective. But it introduces a trust dependency: you are trusting that the watchtower is online, honest, and correctly configured. If the watchtower fails during the exact window when your counterparty cheats, you have no recourse. This is why Lightning occupies both Tier 1 (the exit transaction itself requires no cooperation) and Tier 2 (the fraud prevention mechanism requires liveness).

Ark VTXO Expiry

Ark's expiration mechanic pushes it into Tier 2 for long-term holders. If a user receives a VTXO and does not refresh it before the timelock expires, the ASP can sweep the funds. The user must either participate in a new round (requiring ASP cooperation) or unilaterally exit to L1 before expiry.

This is not a flaw but a design constraint: the expiration is what allows Ark to operate without persistent on-chain footprints. The tradeoff is that passive holders must periodically interact with the system, unlike on-chain Bitcoin where a UTXO sits undisturbed indefinitely.

Tier 3: Honest-Minority Exit

Tier 3 protocols allow users to exit, but only if at least one honest participant in the system challenges fraudulent withdrawals. The user cannot exit purely on their own: the exit depends on the existence of a functioning dispute mechanism.

BitVM Bridges

BitVM introduced a mechanism for verifying arbitrary computation on Bitcoin through an optimistic execution model. In the context of L2 bridges, this translates to a 1-of-n trust assumption: bridge operators can process withdrawals, and anyone can challenge an invalid withdrawal by submitting a fraud proof.

The BitVM2 bridge design requires a one-time setup with a 1-of-n honesty assumption. During runtime, any party can challenge an invalid assertion without being part of the initial signer group. Even if all operators collude, they cannot steal deposits: the worst case is that they burn funds, not redirect them.

This is a significant improvement over federated bridges, but it is not equivalent to unilateral exit. The user depends on at least one honest challenger being online and willing to dispute fraud during the challenge window. If no challenger exists, a fraudulent withdrawal succeeds.

Citrea (Clementine Bridge)

Citrea launched its mainnet in January 2026 as Bitcoin's first production ZK-rollup. Its Clementine bridge uses a BitVM-based design with an optimistic 1-of-n honest assumption: at least one watcher must be online to challenge invalid withdrawals. There is no multisig federation controlling the peg.

Citrea publishes state diffs and validity proofs directly to Bitcoin, using Bitcoin as both the data availability and settlement layer. The ZK proofs verify that the rollup state transition was computed correctly, while the optimistic bridge handles the actual BTC peg.

The current implementation has additional trust considerations: a single sequencer orders transactions, and withdrawals include an optimistic delay for the challenge window. These are common properties of early-stage rollups that are typically decentralized over time.

Honest-minority vs. honest-majority: The distinction matters enormously. An honest-majority system (traditional multisig) requires that more than half of signers behave correctly. An honest-minority system (BitVM-style) requires only one honest participant out of potentially thousands. Attacking an honest-minority system requires compromising every single verifier, not just 51%.

Tier 4: Federated and Multisig Exit

Tier 4 protocols require a threshold of federation members to cooperate for users to withdraw funds. There is no unilateral exit mechanism: if the federation refuses, colludes, or loses keys, user funds are at risk. These systems trade sovereignty for operational features like faster block times, smart contracts, or confidential transactions.

Liquid Network

The Liquid Network is a federated sidechain operated by a group of functionaries: 15 entities that collectively validate blocks and manage the BTC peg. Blocks require signatures from 11 of the 15 functionaries (two-thirds threshold). Withdrawals from Liquid back to Bitcoin L1 require the same 11-of-15 threshold to sign.

As of Q1 2026, the broader Liquid Federation has 87 members across six continents, though only 15 operate as functionaries with signing authority. Functionary keys are stored in Hardware Security Modules (HSMs), adding a physical security layer. But the fundamental trust assumption is clear: users must trust that fewer than 5 of the 15 functionaries collude. If 5 or more are compromised, they can censor transactions. If 11 or more collude, they can steal the BTC backing the peg.

RSK (Rootstock)

RSK uses the Powpeg: a federation of Hardware Security Modules that manage the BTC peg. The current configuration is a 5-of-9 multisig, where five known entities must collude to steal locked BTC. RSK adds merge-mining attestations so that malicious federation behavior requires overcoming both the HSM protections and the hashrate-based detection mechanism.

The RSK team has been developing Union Bridge, a trust-minimized replacement for the Powpeg that would allow anyone to become a bridge functionary by posting security bonds. As of mid-2026, Union remains on testnet. Until it launches, RSK's peg operates as a federated model with a lower threshold (5-of-9) than Liquid (11-of-15).

Stacks (sBTC)

Stacks uses a dynamic signer set to manage its sBTC peg. Unlike Liquid's static federation, Stacks signers rotate based on STX staking, and their economic incentives are tied to their staked holdings. The Nakamoto upgrade (activated in late 2024) gave Stacks Bitcoin-equivalent finality: reversing a Stacks transaction is at least as hard as reversing the Bitcoin block that anchors it.

Despite this finality improvement, the sBTC peg remains a threshold signature scheme. Withdrawing BTC requires the signer set to cooperate. Users cannot unilaterally exit: if the signer set refuses or is compromised, BTC locked in the peg is inaccessible. sBTC TVL surpassed $545 million by Q1 2026, indicating market confidence in the signer set, but the trust assumption is architecturally identical to a federation.

Mapping Every Major Bitcoin L2

The following table maps major Bitcoin L2 protocols to their trust tier, along with the specific security assumptions and exit mechanisms for each.

What Happens When Things Go Wrong

Trust models are theoretical until tested by failure. Here is how each tier behaves under three common stress scenarios: operator disappearance, federation collusion, and contested exits.

If Operators Disappear

In Tier 1 systems, operator disappearance is an inconvenience, not a catastrophe. Lightning users can force-close channels and recover funds on-chain. Spark users can broadcast their pre-signed exit transactions to L1 at any time: operators cannot prevent this even if they go permanently offline. Ark users can unilaterally exit before their VTXOs expire.

In Tier 3 and 4 systems, operator disappearance is more dangerous. If a BitVM bridge's operators all vanish, no new withdrawals can be processed, and existing funds depend on whether the challenge period has passed. If a Liquid functionary quorum is lost (more than 4 of 15 go offline), no new blocks can be signed and no peg-outs can be processed. BTC locked in the federation is stuck until enough functionaries come back online.

If the Federation Colludes

Collusion is not a risk for Tier 1 systems. Even if every Spark operator colluded, they could not steal user funds: they hold only one key in a 2-of-2 multisig, and the user holds the other. The worst a colluding operator set can do is refuse to process new transfers, forcing users onto their L1 exit path.

For Tier 4 federations, collusion is the existential risk. If 11 of Liquid's 15 functionaries collude, they can sign transactions redirecting all pegged BTC to themselves. If 5 of RSK's 9 Powpeg members collude, they can extract the BTC backing. No user action can prevent this: there is no unilateral exit, no challenge mechanism, and no on-chain recourse.

Tier 3 systems occupy a middle ground. In a BitVM bridge, even if all operators collude, the dispute mechanism means a single honest challenger can block a fraudulent withdrawal. The operators cannot steal funds, only burn them. This is a meaningful improvement over federation models, even though it still depends on at least one honest participant.

Exit Costs and Timing

Every L2 exit to Bitcoin L1 requires an on-chain transaction, which means paying mining fees. During high-fee periods, small balances may become uneconomical to exit: a limitation shared by all Bitcoin L2s regardless of tier.

• Lightning force-closes typically require one on-chain transaction per channel, plus additional transactions if HTLCs are pending.
• Spark exits require broadcasting the pre-signed exit transaction tree, with costs proportional to the number of leaves being settled.
• Ark exits require broadcasting branch and leaf transactions, which can be expensive if many users exit simultaneously from the same tree.
• Tier 3 and 4 exits are processed by the bridge or federation, which typically batches withdrawals to amortize fees.

The fee floor matters: For all L2s, the minimum economically viable balance is determined by L1 transaction fees. At 50 sat/vB, a simple transaction costs roughly 5,000 to 10,000 sats. Any L2 balance below this threshold cannot be profitably exited, regardless of the trust model. This is a fundamental constraint of Bitcoin's base layer, not a flaw in any specific L2.

The Trust-Feature Tradeoff

There is a persistent tension in Bitcoin L2 design between trust minimization and feature richness. Protocols with the strongest trust guarantees tend to offer narrower functionality, while protocols with weaker trust assumptions offer more expressive execution environments.

Lightning and Spark are optimized for payments: fast, low-cost transfers of Bitcoin and (in Spark's case) stablecoins with strong exit guarantees. Liquid offers confidential transactions and asset issuance. RSK and Stacks provide full smart contract environments. Citrea delivers EVM compatibility with ZK-proven execution.

This tradeoff is not static. Protocols in every tier are actively working to push the frontier: RSK's Union Bridge aims to move from Tier 4 to Tier 3, sBTC's roadmap includes self-custodial minting to reduce federation dependence, and BitVM developments continue to shrink the assumptions needed for trust-minimized bridges.

The Blockchain Trilemma on Bitcoin

The blockchain trilemma (security, scalability, decentralization: pick two) manifests clearly in Bitcoin L2 design. Tier 1 protocols maximize security and decentralization but constrain scalability and programmability. Tier 4 protocols maximize scalability and features but centralize trust in a federation.

Tier 3 (honest-minority) systems represent an emerging middle path: they offer broader programmability while requiring only a minimal trust assumption. As BitVM-based bridges mature and ZK-proof costs decrease, this tier is likely to expand.

Evaluating Trust Models in Practice

When choosing an L2, the trust model should be evaluated alongside practical concerns. Here are the questions that matter most:

• Can I exit without anyone's permission? If not, who must cooperate, and what happens if they refuse?
• What is the worst-case scenario? Funds locked temporarily (liveness failure) or funds stolen permanently (safety failure)?
• How many parties must collude to steal my funds? One compromised entity, a majority of a known set, or every verifier in an open set?
• Is the trust assumption at transfer time only, or does it persist for the entire duration I hold funds on the L2?
• What is the operational burden on me as a user? Must I stay online, refresh state, or monitor the chain?

For payment use cases where users frequently move Bitcoin, Tier 1 systems like Lightning and Spark offer the strongest security with the fewest ongoing obligations. Spark in particular eliminates the liquidity management burden that makes Lightning operationally complex for casual users, while maintaining the same unilateral exit guarantee. For DeFi applications requiring smart contract expressiveness, Tier 3 and 4 systems provide capabilities that payment-focused L2s do not.

Where the Spectrum Is Heading

The Bitcoin L2 trust spectrum is not fixed. Several technical developments are actively reshaping the boundaries between tiers.

OP_CAT and other proposed covenant opcodes could enable native Bitcoin verification of L2 state transitions, potentially allowing validity proofs to be checked directly on L1. This would move ZK-rollups from Tier 3 toward Tier 1 by eliminating the need for an honest challenger.

BitVM continues to evolve: the BitVM3 design reduces verification overhead further, making honest-minority bridges cheaper to challenge and thus more secure in practice. As the cost of challenging fraud decreases, the practical security of Tier 3 systems approaches Tier 1.

For developers building on Bitcoin, the choice of trust model is a foundational architectural decision. The Spark documentation provides technical details on implementing Tier 1 unilateral exit in applications. For a broader comparison of L2 capabilities beyond trust models, see our Bitcoin Layer 2 comparison and the scaling landscape overview.

Users looking to experience Tier 1 exit guarantees in practice can try General Bread, a Spark-powered wallet that provides self-custodial Bitcoin and stablecoin payments without channel management or federation trust.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.