Ark Protocol

What Is Ark Protocol?

Ark Protocol is a Bitcoin Layer 2 design proposed by Burak Keceli in May 2023. It enables off-chain Bitcoin transfers by pooling multiple users into shared on-chain UTXOs and issuing virtual UTXOs (vTXOs) that represent each user's claim on the pooled funds. Unlike the Lightning Network, Ark does not require users to open channels, manage inbound liquidity, or remain online to receive payments.

At the center of the protocol sits an Ark Service Provider (ASP): a coordinator that batches transfers into periodic rounds, fronts the on-chain liquidity, and maintains the off-chain transaction trees. The ASP plays a role similar to a server in a client-server architecture, but with a critical constraint: it cannot spend user funds. Users hold pre-signed transactions that guarantee unilateral exit to on-chain Bitcoin at any time, preserving self-custody.

The protocol emerged from an attempt to solve Lightning's user experience challenges: channel management, inbound liquidity requirements, and the need for both parties to be online during payment routing. For a detailed comparison of Bitcoin Layer 2 approaches, see the Ark Protocol deep dive.

How It Works

Ark operates through three core mechanisms: round-based batching, virtual UTXO trees, and forfeit transactions secured by connector outputs. Together, these allow users to transfer Bitcoin off-chain while retaining the ability to settle on-chain unilaterally.

Rounds and Batch Coordination

A round is a periodic coordination event where the ASP creates a new shared on-chain UTXO containing a tree of vTXOs for all participating users. The process works as follows:

1. The ASP announces a new round and collects participation requests
2. Users who want to send, receive, or refresh vTXOs register their intent
3. All participants and the ASP collectively construct a transaction tree and co-sign it
4. Users who are spending existing vTXOs sign forfeit transactions for their old ones
5. The ASP broadcasts the root transaction on-chain
6. Users receive their new vTXOs in the freshly created tree

Round frequency varies by implementation. Ark Labs originally proposed rounds every five seconds, while Second's implementation runs refresh rounds approximately every hour. Between rounds, out-of-round payments (sometimes called "arkoor" transactions) can occur instantly but carry additional trust assumptions.

vTXO Tree Structure

Each round produces a tree of pre-signed transactions rooted in a single on-chain UTXO. The tree uses a quad-tree architecture where each branch splits into four outputs, minimizing the depth required for large participant counts. A round with 256 users needs only four branch layers.

The tree has three transaction types:

• Root: the only transaction confirmed on-chain, creating the shared UTXO that backs all vTXOs in the round
• Branch: off-chain transactions that progressively split value among groups of users
• Leaf: individual exit transactions that deliver bitcoin to a specific user's address

Each leaf transaction has two spend paths. The first is a 2-of-2 multisig between the user and the ASP with no timelock, used for cooperative operations like spending or refreshing. The second is a user-only path with a relative timelock (approximately 144 blocks, or around 10 hours, enforced via OP_CHECKSEQUENCEVERIFY) for emergency unilateral exit.

# Simplified vTXO tree structure (quad-tree)
# 256 users require only 4 branch layers

Root TX (on-chain)
├── Branch A
│   ├── Branch A1
│   │   ├── Leaf (User 1 vTXO)
│   │   ├── Leaf (User 2 vTXO)
│   │   ├── Leaf (User 3 vTXO)
│   │   └── Leaf (User 4 vTXO)
│   ├── Branch A2 ...
│   ├── Branch A3 ...
│   └── Branch A4 ...
├── Branch B ...
├── Branch C ...
└── Branch D ...

# Each leaf has two spend paths:
# 1. Cooperative: 2-of-2 (user + ASP), no timelock
# 2. Unilateral: user-only, ~144 block CSV delay

Connectors and Forfeit Transactions

When a user spends or refreshes a vTXO, they must forfeit the old one to prevent double spending. Ark uses two mechanisms to make this atomic:

• Connector outputs: specialized outputs in the round transaction tree that serve as dependencies for forfeit transactions. A forfeit transaction requires a connector as an input, making it valid only if the new round transaction confirms on-chain. This ensures that forfeiting old vTXOs is atomic with the creation of new ones.
• Forfeit transactions: pre-signed transactions that grant the ASP control over a user's old vTXO. The ASP holds these off-chain as a safeguard. If a user attempts to unilaterally exit with an already-forfeited vTXO, the ASP can broadcast the forfeit transaction during the 10-hour timelock window to reclaim the funds.

vTXO Expiry and Refresh

Root and branch transactions carry absolute timelocks enforced via OP_CHECKLOCKTIMEVERIFY. After approximately 30 days, vTXOs expire and the ASP can reclaim the backing capital. Users must refresh their vTXOs by participating in a new round before expiry. This periodic refresh requirement is one of Ark's key tradeoffs: users who fail to refresh risk losing funds.

The Role of Covenants

Ark can operate today on Bitcoin without any soft fork, using a variant called clArk (covenant-less Ark). In clArk, all participants in a round generate temporary signing keys, co-sign the transaction tree via n-of-n multisig, and then permanently delete those temporary keys. If at least one participant honestly deletes their key, the pre-signed tree becomes the only valid spending path.

However, Bitcoin covenant proposals like OP_CAT or OP_CHECKTEMPLATEVERIFY (CTV) would significantly improve Ark. Covenants would enable non-interactive vTXO issuance (recipients need not be online during rounds), in-round payments to third parties with full security, and automatic vTXO reissuance for expired balances. Without covenants, all round participants must be online simultaneously and co-sign transactions, which limits scalability.

Ark vs Lightning: Why It Matters

Ark and Lightning approach Bitcoin scaling from different directions. Understanding where each excels helps developers and users choose the right tool.

Ark eliminates the biggest pain points in Lightning for end users: channel management, inbound liquidity problems, and the requirement to be online to receive. In exchange, it introduces the ASP as a central coordinator and requires periodic vTXO refresh. For a broader comparison of Bitcoin Layer 2 approaches, see the Bitcoin Layer 2 comparison.

Spark takes a different approach to the same problems. Rather than shared UTXOs and transaction trees, Spark uses statechains with FROST threshold signatures and a 1-of-N trust model. Where Ark relies on a single ASP, Spark distributes trust across multiple operators: if any single operator honestly deletes their keyshare, the transfer is secure. Spark also avoids vTXO expiry, meaning users do not need to periodically refresh their balances.

Use Cases

• Simplified onboarding: new Bitcoin users can receive vTXOs without opening channels or managing liquidity, making the first experience closer to a traditional payment app
• Merchant payments: the non-interactive receiving model (with covenants) allows merchants to accept payments without running always-online infrastructure
• Stablecoin transfers: Ark Labs introduced "Arkade Assets" in 2026 to support token issuance on Bitcoin, with Tether backing development for USDT integration
• Batch payroll and payouts: organizations can distribute payments to many recipients in a single round, amortizing on-chain fees across all participants
• Privacy-preserving transfers: because vTXOs are created in shared rounds, individual transfers are mixed with other activity in the same batch, offering some privacy benefit over transparent on-chain transactions

Current Implementations

Two independent teams are building Ark implementations as of mid-2026:

• Arkade (Ark Labs): founded by Burak Keceli, launched in public beta in October 2025. Raised $5.2M in a seed round backed by Tether in March 2026. Focuses on programmable finance and stablecoin support on Bitcoin.
• Bark (Second): launched on Bitcoin mainnet on June 9, 2026 with a Rust SDK offering bindings for Kotlin, Swift, React Native, Flutter, Go, Python, and WebAssembly. Released alongside five launch applications including a BTCPay Server plugin.

Risks and Considerations

ASP Availability

The ASP cannot steal funds, but must remain available for normal operations. If the ASP goes offline, no new rounds can be created and all transfers halt. Users retain the ability to unilaterally exit, but must do so before their vTXOs expire (within approximately 30 days). This availability dependency is similar to a federated sidechain but with stronger custody guarantees.

vTXO Expiry Risk

Because vTXOs expire after roughly 30 days, users who go offline for extended periods risk losing their funds if they fail to refresh. Applications built on Ark must implement monitoring and reminders to ensure timely refreshes.

Unilateral Exit Costs

Exiting unilaterally requires broadcasting one transaction per tree level. In a quad-tree with 256 users, that means five on-chain transactions. During periods of high fee estimation, exit costs could exceed the value of small vTXOs, effectively trapping dust-sized balances.

ASP Liquidity Requirements

The ASP must front all liquidity for each round. Every payment in transit requires the ASP to commit its own capital until old rounds expire (approximately 30 days). This creates significant capital requirements for the ASP and may result in higher fees compared to Lightning, where liquidity is distributed across the network.

Out-of-Round Trust Assumptions

Instant payments between rounds (arkoor transactions) extend existing transaction trees rather than creating new on-chain anchors. These require trusting that the sender and ASP do not collude to double-spend, introducing a weaker security model compared to in-round transfers.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.