Ark Protocol: Shared UTXOs and Virtual Channels for Bitcoin

Every Bitcoin Layer 2 protocol makes a fundamental choice about how to represent off-chain value. Lightning uses bilateral payment channels. Spark uses statechains with FROST threshold signatures. Ark, proposed by Burak Keceli in 2023, takes a different path: it pools multiple users into shared on-chain UTXOs and issues virtual UTXOs (vTXOs) that can be transferred off-chain without opening or managing channels.

The goal is familiar: instant, low-cost Bitcoin payments with self-custodial guarantees. The mechanism is not. Ark introduces a round-based coordination model, a new role called the Ark Service Provider (ASP), and a liquidity structure that inverts Lightning's capital requirements. This article explains how Ark works, what it requires, and where it fits in the broader landscape of Bitcoin scaling.

The Problem Ark Addresses

Lightning solves Bitcoin's throughput limitations, but it introduces its own set of operational burdens. Liquidity management is the most prominent: every payment requires a pre-funded channel between sender and receiver (or a route through intermediaries), and each channel requires its own on-chain UTXO. Opening and closing channels costs on-chain fees. Users must manage inbound liquidity to receive payments and monitor channels for fraud using watchtowers.

For a mobile wallet user who sends a few payments per month, these requirements are disproportionate. Ark asks: what if many users could share a single on-chain UTXO, eliminating per-user channel creation while preserving the ability to exit unilaterally?

Core Concepts

Virtual UTXOs (vTXOs)

A vTXO is an off-chain claim on Bitcoin value backed by a shared on-chain output. It behaves like a regular UTXO from the user's perspective: it has a specific value, belongs to a specific public key, and can be spent. The difference is that a vTXO does not exist as its own output on the blockchain. Instead, it is a leaf in a transaction tree whose root is a shared UTXO controlled by the ASP.

Users can always "reveal" their vTXO by publishing the full branch of pre-signed transactions from the shared UTXO root down to their specific leaf. This constitutes a unilateral exit: it costs on-chain fees (one transaction per tree level), but it does not require ASP cooperation.

Shared UTXOs and Pool Transactions

The ASP periodically creates pool transactions that aggregate multiple users' funds into a single on-chain output. This shared UTXO is structured as a Taproot tree where each leaf corresponds to a vTXO belonging to a specific user. The tree structure is committed on-chain via Taproot, so the full set of vTXOs is cryptographically bound to the shared output without being individually visible on the blockchain.

Each pool transaction represents a "round" in Ark's terminology. Rounds happen periodically (proposed intervals range from every few seconds to every few minutes), and each round creates a new shared UTXO containing the vTXOs for that round's participants.

Ark Service Providers (ASPs)

The ASP is Ark's central coordinator. It constructs pool transactions, manages the shared UTXO tree, and provides the liquidity that makes off-chain transfers possible. The ASP role is analogous to a Lightning routing node, but instead of maintaining bilateral channels with each user, it maintains a shared pool that all users draw from.

Non-custodial by design: Despite its coordinating role, the ASP never takes custody of user funds. Users hold pre-signed transactions that allow unilateral exit at any time. The ASP can refuse to include a user in future rounds (censorship), but it cannot seize funds already held in vTXOs.

How a Payment Works

Suppose Alice wants to send 50,000 sats to Bob, and both are users of the same ASP. The payment flow proceeds through a round:

1. Alice registers her intent to spend her vTXO with the ASP during the next round.
2. The ASP constructs a new pool transaction. This transaction spends the ASP's own on-chain funds and creates a new shared UTXO. Inside the new tree, Bob receives a 50,000 sat vTXO.
3. Alice signs a forfeit transaction that gives the ASP the right to claim her old vTXO once the new pool transaction confirms. This is linked via connector outputs: special outputs that ensure atomicity between the old and new pool.
4. The ASP broadcasts the pool transaction (or, in some designs, keeps it off-chain with periodic on-chain settlement). Bob now holds a valid vTXO in the new pool.

The critical insight: Alice's old vTXO and Bob's new vTXO are in different pool transactions. The ASP fronts the capital for Bob's vTXO in the new pool, then reclaims Alice's funds from the old pool via the forfeit transaction. This is what makes the round-based model work: the ASP acts as a temporary liquidity bridge between rounds.

Connector Outputs and Atomicity

Connectors are the mechanism that binds Alice's forfeit to Bob's receipt. A connector output is included in the new pool transaction. Alice's forfeit transaction spends both her old vTXO and this connector output. Since the connector only exists if the new pool transaction is valid, the forfeit can only execute if Bob's vTXO was actually created. If the pool transaction fails or is never broadcast, Alice's forfeit is invalid, and she retains her original vTXO.

The Liquidity Model

Ark's liquidity requirements differ fundamentally from Lightning's. In Lightning, each channel locks up capital between two specific parties. The total network capacity is the sum of all individual channel balances, and moving liquidity between channels requires on-chain transactions or techniques like splicing.

In Ark, the ASP provides pooled liquidity. When constructing a new round, the ASP must fund the entire value of all new vTXOs from its own capital. It recovers this capital only when the old vTXOs expire (after a timeout period, typically proposed as four weeks) or when users forfeit their old vTXOs during subsequent rounds.

The tradeoff is clear: Ark eliminates per-user channel management but concentrates liquidity requirements on the ASP. An ASP serving 10,000 users with an average balance of 100,000 sats needs to maintain roughly 10 BTC in active liquidity, plus additional capital to cover overlapping rounds during the expiry window. This capital cost ultimately gets passed to users as fees.

vTXO Expiry and Refresh

Unlike Lightning channel balances, which persist indefinitely as long as the channel remains open, Ark vTXOs have a built-in expiration. After the timeout period, the ASP can reclaim the funds backing expired vTXOs. This means users must periodically "refresh" their vTXOs by participating in a new round before expiry.

If a user goes offline for longer than the timeout period without refreshing, they risk losing their funds. In practice, wallets would automate this process, but it introduces a liveness requirement that does not exist in Lightning (where channel funds persist as long as the channel is open) or in Spark (where funds have no expiration).

Expiry is a design constraint, not a bug: The timeout mechanism is what allows the ASP to recover its locked capital. Without expiry, the ASP's liquidity would be permanently tied up in old pool transactions. The timeout period represents a tunable tradeoff between user convenience (longer timeouts require less frequent refresh) and ASP capital efficiency (shorter timeouts free up liquidity faster).

The Role of Covenants

Ark's design is heavily influenced by whether Bitcoin supports covenants: opcodes that restrict how a UTXO can be spent in future transactions. The two most discussed proposals are OP_CTV (BIP 119, also known as CheckTemplateVerify) and OP_CAT.

Without Covenants

Ark can function today on Bitcoin without any soft fork, but with significant limitations. Without covenants, every participant in a round must be online and co-sign the pool transaction. The ASP cannot unilaterally commit to a spending structure: all exit paths must be pre-signed by all affected parties. This introduces interactivity requirements that undermine one of Ark's key selling points (non-interactive receiving).

Pre-signed transaction trees also become large. For a round with N participants, the number of pre-signed transactions scales with the depth of the tree. Each participant must verify and store their branch of the tree, increasing bandwidth and storage requirements.

With Covenants

Covenants would allow the ASP to construct pool transactions with committed spending rules enforced by Bitcoin Script itself. The ASP could publish a pool transaction where each vTXO's exit conditions are encoded directly in the script, without requiring pre-signatures from every participant. This would enable:

• Truly non-interactive rounds (recipients do not need to be online)
• Smaller on-chain footprint (fewer pre-signed transactions to store)
• More participants per round (no per-participant signing overhead)
• Faster round creation (ASP constructs the tree independently)

The covenant dependency is a significant factor in Ark's timeline. OP_CTV and OP_CAT remain proposed soft forks without consensus activation dates. This means Ark's most efficient design cannot be deployed until Bitcoin's consensus rules change, though covenant-less variants with reduced functionality are possible in the interim.

Trust Model and Security

Ark's trust assumptions center on the ASP. Understanding what the ASP can and cannot do is essential for evaluating the protocol's security guarantees.

The security model is similar to a federated sidechain in its availability guarantees but closer to Lightning in its custody model. Users retain the ability to exit unilaterally, but the ASP can degrade service quality through censorship or downtime. A key difference from Lightning: there is no equivalent of a justice transaction. If the ASP publishes an old state, users rely on timelocks rather than penalty mechanisms to protect their funds.

On-Chain Costs

One of Ark's stated goals is to reduce the on-chain footprint per user compared to Lightning. In the cooperative case (users participate in rounds and forfeit old vTXOs properly), the on-chain cost is amortized: one pool transaction serves many users, so the per-user cost decreases as more users participate in each round.

However, unilateral exits are expensive. Revealing a vTXO requires publishing the full branch from the shared UTXO root to the specific leaf. For a binary tree with 1,024 leaves, this means 10 on-chain transactions. During periods of high Bitcoin fees, the cost of unilateral exit could exceed the value of small vTXOs, creating an economic constraint similar to the dust problem in Lightning channel closes.

Comparing L2 Approaches

Ark sits in a growing ecosystem of Bitcoin Layer 2 proposals, each with different trust assumptions, liquidity models, and implementation status. The following table compares Ark with Lightning, Spark, and channel factories (another shared-UTXO approach that has been discussed in the context of scaling Lightning).

Relationship to Other Proposals

Channel Factories

Channel factories share Ark's insight that multiple users can share a single on-chain UTXO. The difference is structural: channel factories create Lightning channels within the shared UTXO, so users still manage channels and route payments through the Lightning network. Ark replaces channels entirely with vTXOs and round-based transfers. Factories reduce the on-chain cost of channel creation; Ark eliminates channels altogether.

Eltoo / LN-Symmetry

Eltoo (now called LN-Symmetry) proposes replacing Lightning's current penalty-based revocation mechanism with a simpler state-update model. Like Ark, eltoo depends on a soft fork (SIGHASH_ANYPREVOUT). Both proposals aim to simplify Bitcoin's L2 landscape, but they target different layers: eltoo improves how Lightning channels work, while Ark replaces the channel model entirely.

Statechains and Spark

Spark uses statechains to transfer UTXO ownership off-chain without channels. The philosophical overlap with Ark is significant: both protocols aim to eliminate Lightning's channel management complexity. Spark achieves this through key rotation with FROST threshold signatures, where transfers change who can sign for a UTXO rather than moving funds through a routing network. Ark achieves it through shared UTXOs and round-based pooling.

A practical difference: Spark is live today with over 20 integrations, while Ark remains in active development. Spark's statechain model does not require covenants or vTXO refresh, and its exit mechanism requires only a single on-chain transaction rather than revealing a full tree branch.

Tradeoffs and Open Questions

ASP Centralization

Ark's design concentrates significant responsibility in the ASP. While users retain self-custody through unilateral exit, the ASP controls round scheduling, fee setting, and transaction inclusion. A single ASP going offline halts all round-based transfers for its users. Users can switch ASPs, but this requires an on-chain transaction (exiting from one ASP's pool and entering another's), which introduces friction and cost.

Interactivity Without Covenants

Without covenant opcodes, Ark's round model requires all participants to be online and co-sign. This significantly limits the number of users per round and reintroduces the kind of online-requirement that Ark was designed to eliminate. The protocol's value proposition is substantially stronger in a post-covenant Bitcoin, but the timeline for any covenant soft fork remains uncertain.

Unilateral Exit Scalability

If many users attempt to exit simultaneously (for example, if an ASP announces shutdown), the resulting on-chain transaction volume could be substantial. Each exit requires multiple transactions proportional to tree depth. A mass exit event could congest the Bitcoin mempool and drive up fees, making exits progressively more expensive: a negative feedback loop similar to fee market dynamics during periods of high demand.

Privacy

The ASP sees all transfers within its rounds, similar to how a Lightning routing node sees payments it routes. Cross-ASP transfers (if supported) would require additional coordination and potentially reveal information to both ASPs. Ark's privacy model depends heavily on implementation details that are still being finalized, including whether blinded commitments or zero-knowledge proofs can be integrated into the round construction process.

Current Development Status

As of early 2026, Ark remains in active research and development. Several implementations are being built, including the Ark Network reference implementation and Bark, an alternative client. The protocol specification continues to evolve, particularly around the covenant-less variant and its interaction with existing Bitcoin Script capabilities.

The Ark developer documentation provides the most current technical specification. Key areas of ongoing work include optimizing round coordination, reducing the ASP's capital requirements, and designing cross-ASP transfer mechanisms.

Developers interested in Bitcoin's L2 landscape should also review payment channel fundamentals and Bitcoin's timelock mechanisms, as both concepts are foundational to understanding how Ark's security guarantees are constructed.

Conclusion

Ark represents a genuinely different approach to Bitcoin scaling. By pooling users into shared UTXOs and issuing virtual claims against them, it eliminates per-user channel management while preserving self-custodial exit guarantees. The ASP role concentrates liquidity provision and coordination, creating a model that is simpler for end users but more capital-intensive for infrastructure operators.

The protocol's most compelling features: non-interactive receiving, no channel management, and amortized on-chain costs: depend on covenant support that Bitcoin does not yet have. The covenant-less variant works but sacrifices key usability properties. This creates a chicken-and-egg dynamic: Ark's strongest argument for covenants requires covenants to demonstrate.

For now, Ark is best understood as an important design contribution to Bitcoin's L2 research, with production deployment contingent on both further engineering work and the broader Bitcoin consensus process. Protocols like Lightning and Spark serve users today with different tradeoffs. Ark may eventually join them as another option in Bitcoin's scaling toolkit: one optimized for shared-UTXO efficiency at the cost of ASP liquidity requirements and periodic vTXO refresh.

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.