Ark
Ark is a Bitcoin layer-2 protocol in which users hold virtual transaction outputs (VTXOs). A VTXO is backed by a shared on-chain UTXO and by a path of pre-signed transactions that lets the holder create an on-chain output without further interaction. Users transfer VTXOs off-chain with the cooperation of an Ark server (sometimes called an Ark service provider, or ASP). Payments do not require a pre-existing bilateral channel. The original design was posted to the bitcoin-dev mailing list by Burak. The protocol has been revised substantially since that post.
Background
The Lightning Network moves bitcoin off-chain by locking a 2-of-2 output between two peers and updating a commitment transaction. Receiving Lightning payments requires inbound channel capacity. A new wallet therefore depends on a counterparty or a Lightning service provider to open a channel. Ark uses a different liquidity model. Several users share one large on-chain UTXO through a tree of off-chain transactions. A user who can spend a leaf of that tree owns the corresponding VTXO and can either exit on-chain or obtain a replacement leaf in a later tree.
The protocol is intended to work with currently active Bitcoin consensus rules. Covenant-less Ark (sometimes called clArk) uses pre-signed transactions as a pseudo-covenant and can operate on Bitcoin without new opcodes. Proposed Covenant opcodes such as CHECKTEMPLATEVERIFY would let the tree be committed without interactive pre-signing, but they are not required.
How it works
An Ark round is organized by the server. In current Bark, rounds are used to refresh VTXOs, not to pay other users. Users who wish to refresh register an intent. The server funds a round transaction whose output anchors a tree of pre-signed transactions. In covenant-less implementations, cooperative spend paths in the tree are represented using MuSig2 aggregate keys, and the relevant participants jointly pre-sign the tree. Root and branch cooperative paths are n-of-n arrangements among the users who share that node plus the server. Leaf cooperative paths are 2-of-2 between one user and the server. Each user receives the pre-signed transactions along the path from the round output to that user's leaf, which is what a unilateral exit needs.
A refresh exchanges a user's old VTXO for a new refresh VTXO belonging to the same user. The user signs a forfeit transaction that would pay the old leaf to the server. The server fronts the on-chain liquidity for the new tree and later reclaims the forfeited value when the old tree expires.
In the classic connector-based construction, refresh atomicity is enforced by making the forfeit transaction spend a connector output created by the new round transaction. This prevents the server from exercising the forfeit unless the replacement round exists on-chain. Some newer implementations use different mechanisms. Bark's hArk design, introduced in version 0.1.0-beta.6 in January 2026, uses hash locks for refreshes and retains connectors primarily for on-chain payments and offboarding. Under hArk, the server generates a preimage for each new VTXO. Both the new VTXO and the forfeit are hash-locked on that preimage, so the server cannot claim the old leaf without revealing the secret that unlocks the new one.
Ordinary user-to-user Ark payments are out-of-round (OOR, also called arkoor). They do not wait for the next round. The server co-signs a transfer of an existing VTXO to the receiver, producing a spend VTXO that extends the sender's leaf. Safety of a spend VTXO depends on the sender and server not colluding to double-spend. Refreshing the received VTXO in a later round replaces it with a refresh VTXO and removes that collusion assumption.
VTXOs expire. Once a VTXO reaches its expiry height, the server gains a unilateral path to reclaim the backing funds. The user may still be able to spend or exit a non-forfeited VTXO, but can no longer rely on exclusive control of the backing output, so wallets must refresh or exit before expiry. A valid, non-forfeited refresh VTXO can be exited unilaterally before expiry, at the cost of on-chain fees and delay. Delegated refreshes used by some mobile wallets have a weaker trust model and are not the same as a standard interactive refresh.
Before expiry, a standard refresh VTXO remains self-custodial. An honest user can unilaterally exit without server cooperation, and the server cannot take the user's funds unless the user has previously authorized a conflicting spend or forfeit. After expiry the server has a competing sweep path, so that exclusive guarantee no longer holds. The server is a liveness and liquidity provider. It is also a trust assumption for spend VTXOs that have not yet been refreshed.
Implementations
Bark is an open-source Ark client and server. No consensus change in Bitcoin Core is required. Bark publishes Signet instructions. A 2026 paper on off-chain transaction batching describes a mainnet implementation. The protocol is still evolving, and readers should not infer a mature public network from the existence of that implementation.