Ark Protocol

Original concept: Burak (2023, posted to bitcoin-dev as TBDXXX). First implementation on mainnet: ARKADE (Ark Labs) — first mainnet payments August 2025, public mainnet beta since October 2025. The reference impl bark (Second) reached mainnet on 9 June 2026.

Ark virtualizes Bitcoin's UTXO layer into VTXOs (Virtual Transaction Outputs) that are batched and settled periodically on chain.

Mechanism

Round-based architecture

An ASP (Ark Service Provider) runs periodic rounds (e.g., every few minutes / hours).
In the original round-based design, users send and receive funds via VTXOs during each round. Deployments have since moved payments out of the round — bark sends arkoor (out-of-round) transactions, ARKADE preconfirms VTXOs — so as of September 2026 rounds and batches carry refreshes and on-chain settlement, not payments (Second docs: "Early Ark protocol proposals included payments within rounds, but this is no longer the case").
At round end, ASP commits the round state on chain via a single pool tx.
Each user's VTXO is included in the pool tx as part of a Merkle/ binary tree structure.

VTXOs

A VTXO is a "virtual" output:

Represented as a leaf in the round's tree.
Spendable off-chain by sending it to another VTXO via ASP-mediated protocol.
Has a CSV expiry: after the expiry, owner can unilaterally claim on chain via the round's commitment tx.

Unilateral exit

Even if ASP disappears:

User can broadcast a chain of pre-signed txs to extract their VTXO from the round tree.
Cost: linear in tree depth (typically log N).
Time: limited by CSV expiry (typically days to weeks).

Covenant-less Ark (clArk) and the CTV dependency

Every Ark deployment running on Bitcoin today is covenant-less Ark (clArk). Bitcoin has no covenant opcode, so a pool-tx output cannot commit to the VTXO tree beneath it. Instead the tree is assembled from pre-signed transactions — what the Ark docs call a "pseudo-covenant" — which every affected participant must cosign while the round is open.

That substitution, not implementation immaturity, is the root cause of Ark's interactivity:

All cosigners must be online during the round; a dropout stalls or restarts the cosigning ceremony.
The tree shape is fixed before signing starts, so intents cannot join after the nonce ceremony has begun.
Holders must refresh VTXOs before expiry, so even an idle balance costs recurring interactivity.

An introspection primitive — OP_CHECKTEMPLATEVERIFY (BIP 119), TXHASH, or the taproot-native OP_TEMPLATEHASH variant — would let a single output commit to the pre-agreed tree directly, removing the round-time n-of-n pre-signing ceremony (VTXO expiry and refresh would remain). Bitcoin Optech frames the gain as supporting significantly more users and achieving greater fee efficiency.

The introspection opcode is what removes the round-time ceremony. CSFS addresses a different half of the problem: Roose and De Smedt's "Evolving the Ark protocol using CTV and CSFS" (Delving Bitcoin, 15 April 2025) combines the two into "rebindable signatures", letting a user pre-sign future refreshes so the server can refresh a VTXO perpetually without the user ever coming online. Ark is one of the headline applications argued over in the activation debate (Bitcoin Optech, 2025-04-04, "Benefit of CTV to Ark users").

As of September 2026 none of these opcodes is active on Bitcoin mainnet. Steven Roose demonstrated bark running against OP_TEMPLATEHASH on signet in August 2026 (Bitcoin Optech, 2026-08-21).

See ../../protocol/proposals/SKILL.md for the activation state of CTV and CSFS.

ARKADE features

Ark Labs' mainnet implementation:

VTXO batches via taproot trees.
Round time: ~5 seconds.
ASP-coordinated cosigning protocol.
Native BTC support; Arkade Assets for tokenized assets.
V-PACK: stateless VTXO verification standard.

Bark (Second's impl)

Open source (MIT), Rust. On Bitcoin mainnet since 9 June 2026; before that it ran on signet/testnet only.

Wallet client for Ark, plus an ASP server reference.
Public Ark server operated by Second, with mainnet and signet endpoints.
Bark SDK with bindings for Kotlin, Swift, React Native, Flutter, Go, Python and web (WebAssembly).
barkd: standalone wallet daemon exposing a REST interface with an OpenAPI spec.
Packaged as an Umbrel app (June 2026) and a Start9 service (July 2026); BTCPay Server plugin for self-custodial Lightning receive without opening channels.
Not interoperable with ARKADE. Since v0.3.0 (26 June 2026) bark parses an Arkade address only to reject it with "Ark address is for different server"; the two implementations have diverged (Second moved payments out of rounds entirely). Earlier docs here claimed ARKADE protocol compatibility; that is no longer true.
Release line as of September 2026: v0.7.1 (11 September 2026). v0.5.0 (4 August 2026) added restoring a wallet's full off-chain VTXO balance from its mnemonic, and Lightning receives claimable to another wallet's Ark address (enabling non-custodial Lightning-address servers).
Repo: https://gitlab.com/ark-bitcoin/bark (upstream — the README points issues and tags there), mirrored at https://codeberg.org/ark-bitcoin/bark and https://github.com/ark-bitcoin/bark. The old codeberg.org/ark-network/bark URL is dead.

Compared to Lightning

Aspect	Lightning	Ark
Liquidity setup	Channel funding	None per user
Receiver inbound	Need pre-existing channel	None needed
Aggregator	n/a (peer-to-peer)	ASP (1 per round)
Settlement	Off-chain instant	Off-chain instant (arkoor / preconfirmed VTXO)
On-chain batching	Channel open/close	Per round; interval is server policy (Second: hourly, September 2026)
Exit cost	Channel close (~1 tx + per-HTLC)	Tree extraction (~log N txs)
Protocol type	Per-channel	Batched
Asset support	Optional (TAP, RGB layered)	Native (Arkade Assets)

Use cases

Receive without channel — user gets their first sats without pre-funded inbound.
High-frequency micro-payments — payments settle off-chain with no on-chain cost each; any Ark payment fee is server policy, not fixed by the protocol (Second docs, September 2026).
Mobile-first — out-of-round payments give offline receive, so no always-online wallet is needed (Second docs, September 2026).
Asset issuance via Arkade Assets.

Status (September 2026)

ARKADE: mainnet public beta. First mainnet payments August 2025 (Baltic Honeybadger); opened publicly October 2025. Ark Labs raised $5.2M in March 2026, backed by Tether with Ego Death Capital, Epoch VC and Anchorage Digital.
bark (Second): on Bitcoin mainnet since 9 June 2026; release line v0.7.x as of September 2026.
ARKADE integrations: Lendaswap by Lendasat/Satora (November 2025), Hodl Hodl escrow (May 2026), Bitrefill gift cards (June 2026).
Bark integrations: Noah and Arké wallets plus Satsigner (June 2026), Alby Hub (June 2026), Umbrel and Start9 packages.
Neither CTV nor CSFS is active on mainnet, so both deployments are covenant-less Ark (see above).
Active competing model with Spark, Lightning.

Limitations / trade-offs

Round delay: as of September 2026 neither deployment makes the payer wait for a round — bark sends arkoor (out-of-round) transactions and ARKADE preconfirms in its Virtual Mempool — so the delay lands on refreshes and on reaching Bitcoin finality, not on the payment.
Preconfirmation trust: an instant payment is only operator- cosigned. Until the receiver refreshes (bark) or settles into a batch (ARKADE), they trust that sender and server do not collude to double-spend; only the on-chain round/batch restores the full unilateral-exit guarantee.
ASP availability: ASP outage = unilateral-exit window.
Tree depth scaling: log N exit cost; balanced trees keep this acceptable.
Privacy: ASP sees all VTXO transfers in plaintext (compared to LN's onion routing).

bitcoin-l2-ark