Timechain Wiki

Ark protocol

12 min read

Ark is a Layer-2 protocol proposed by Burak Keceli in 2023 aiming at near-Lightning UX without per-user inbound-liquidity bootstrapping. Users transact via "virtual UTXOs" (vUTXOs) coordinated by an Ark Service Provider (ASP), which batches many vUTXOs into periodic on-chain rounds settling a single transaction for many off-chain payments; vUTXOs are valid for a bounded window after which the ASP can reclaim unclaimed funds. The architecture removes Lightning's inbound-liquidity-bootstrapping problem at the cost of a different trust profile — the ASP is a coordinator with substantial operational influence, though users retain unilateral exit via vUTXO-claim transactions. Native Ark is cleanest with covenant-enabling soft forks (OP_CTV or CHECKSIGFROMSTACK), which are not yet activated — but covenantless implementations now run on mainnet: Ark Labs' Arkade (public mainnet beta October 2025, the first Ark on mainnet, later adding Arkade Assets for stablecoins) and Second's Bark (mainnet June 2026, self-custodial-payments-focused, ex-Blockstream team). The landscape is now early-production self-custodial payments, not the signet-only experiment of a year earlier.

Why this note matters

Ark occupies a structurally distinctive position in the Layer-2 design space: it addresses the inbound-liquidity bootstrapping problem that has been Lightning’s most persistent UX friction without introducing the federated-trust requirements that characterize sidechain architectures. The design is a serious contender for the next-generation Layer-2 system; whether it succeeds depends on covenant-enabling soft-fork activation timelines and on practical ASP deployment.

Ark is also load-bearing for the broader covenant-and-protocol-evolution debate. Several of Ark’s most attractive properties require covenant opcodes that are themselves the subject of contested protocol-evolution discussion. The Ark proposal has been a principal motivator for the OP_CTV side of the covenants debate.

The vUTXO and round mechanic

Ark’s core construct is the virtual UTXO (vUTXO; the deployed implementations now standardize on the term VTXO, “virtual transaction output” — the two are equivalent). A vUTXO is a claim on a portion of an Ark Service Provider’s pooled funds — valid for a bounded time window, after which the ASP can sweep the underlying pool back to itself.

The round mechanism:

  1. Round preparation. The ASP collects vUTXO transfer requests from users during a round-collection window (typically 1-5 seconds). Each user can request to receive or send vUTXOs in the round.
  2. Round construction. The ASP constructs a single on-chain transaction (the “round transaction”) whose outputs encode the new vUTXO distribution. The transaction is structured so that users can claim their vUTXOs via separate unilateral-exit transactions if the ASP becomes unresponsive.
  3. Round confirmation. The round transaction is broadcast to the base layer. Once confirmed, the new vUTXO distribution is in effect.
  4. Round expiry. After the round’s expiry window (typically 4 weeks or longer), the ASP can sweep unclaimed vUTXO outputs back to itself via a CTV-enabled spending path. The expiry creates the inbound-liquidity recycling mechanism.

The vUTXO claim and unilateral exit. At any time during the vUTXO’s validity window, the holder can claim their vUTXO via a unilateral on-chain transaction. This is the holder’s exit guarantee — even if the ASP becomes unresponsive, the holder can claim their funds. The unilateral-exit transaction is structured similarly to Lightning’s force-close: a single base-layer transaction at the prevailing fee rate.

The inbound-liquidity inheritance. Because vUTXOs are valid claims on ASP-pooled liquidity, new users joining an ASP can receive payments immediately without per-user channel-open. This is the principal UX improvement over Lightning.

The covenant dependency

Native Ark requires the ASP to commit at round-construction time to a specific spending template for the round’s outputs — the ASP can sweep unclaimed vUTXOs back to itself after expiry, but only via the committed template, ensuring that the ASP cannot arbitrarily redirect the funds.

The required primitive. The cleanest design uses OP_CTV (CHECKTEMPLATEVERIFY; BIP119) which allows a transaction to commit to a specific output template. Alternative designs use CHECKSIGFROMSTACK or various other covenant proposals. None are currently activated on Bitcoin mainnet.

From signet emulation to covenantless mainnet. Through 2023–2024, Ark ran on Bitcoin signet (which supports covenant opcodes via signet-specific consensus) as the principal reference, with Burak Keceli (Ark Labs) leading the original implementation. The production implementations that reached mainnet in 2025–2026 did not wait for covenants: they deploy covenantless Ark — historically prototyped under the “Clark” (Covenant-light Ark) name — trading the clean covenant-based sweep for heavier machinery that works on current Bitcoin. The principal covenantless techniques:

  • Pre-signed transaction trees that emulate covenant behavior via large pre-signed transaction sets. The cost is greater round-construction overhead and coordination.
  • Existing-primitive approximations (multisig, timelocks) that reconstruct the expiry-and-sweep guarantees with weaker or more operationally-demanding properties than a native OP_CTV path would provide.

The covenant debate. The debate over activating OP_CTV (see OP_CAT and the covenants programmability debate) has long had Ark as one of its principal application cases. Pro-CTV advocates cite Ark as a Layer-2 architecture that covenants would make dramatically simpler and more capital-efficient. Anti-CTV advocates raise broader programmability and protocol-evolution concerns. The resolution is no longer a gate on Ark existing — covenantless Arkade and Bark are live on mainnet — but it remains the path to a cleaner, cheaper native Ark, which is the endpoint the OP_CTV side of the debate points toward.

ASP architecture and trust profile

The Ark Service Provider is a coordinator with substantial operational responsibility:

  • Liquidity provision. The ASP provides the pooled funds that back vUTXO claims. The ASP must maintain sufficient pooled-fund inventory to honor user transactions.
  • Round construction. The ASP coordinates round-collection windows and constructs round transactions. The ASP’s operational reliability determines round latency and reliability.
  • Online presence. The ASP must be available during round-collection windows. Users sending or receiving payments interact through the ASP.

The trust assumptions:

  • The ASP cannot steal user funds during the vUTXO validity window. The unilateral-exit guarantee is structural. A user with a valid vUTXO can always claim their funds via on-chain transaction.
  • The ASP can refuse to coordinate rounds. If the ASP refuses to construct a round, users cannot transact through that ASP. Multi-ASP deployments would mitigate this; single-ASP deployments would not.
  • The ASP sees user transactions. As coordinator, the ASP knows the round-by-round transfer history. Privacy-against-ASP is comparable to privacy-against-Lightning-LSPs.
  • The ASP could fail and require user-initiated unilateral exit. If the ASP collapses or goes permanently offline, all users with valid vUTXOs must unilaterally exit on-chain — producing a large base-layer transaction volume. The “ASP-collapse exit storm” is the principal operational-risk scenario.

Multi-ASP deployments. The architecture supports multiple competing ASPs. Users can choose ASPs based on liquidity availability, fee structure, and operational reliability. The competitive dynamic should produce ASP-by-ASP differentiation.

Comparison with Lightning

Ark’s principal claims relative to Lightning:

PropertyLightningArk
Inbound liquidityPer-user bootstrapping requiredProvided by ASP for all users
Payment privacyOnion-routed; per-hop encryptionASP sees all transactions
Online requirementRequired for safetyRequired during round windows; lower otherwise
Force-close costChannel commitment fee + timelockvUTXO claim fee + expiry-window wait
Network topologyChannel network; routing concentrationHub-and-spoke per ASP; multi-ASP possible
Implementation complexityHigh (channels, HTLCs, routing, watchtowers)Lower (no channels, no routing layer)
Covenant dependencyNoneCleaner with OP_CTV; covenantless variants deployed today
Production deploymentSubstantial (~40k channels, ~4–5k BTC)Live on mainnet (Arkade Oct 2025; Bark Jun 2026), early-stage

The architectural tradeoff is real. Lightning is the deployed dominant Layer-2; Ark is the proposed improvement. Whether Ark supplants Lightning or coexists in different use-case niches is unsettled.

Tradeoffs and design choices

Covenant dependency vs covenant-less deployment. Native Ark needs OP_CTV; Clark variants can deploy without but with weaker properties. The covenant-debate resolution shapes Ark’s near-term trajectory. Pro-CTV advocates argue Ark is a major user benefit; anti-CTV advocates argue the broader programmability concerns outweigh specific application benefits.

ASP coordination vs trust-minimization. The ASP is operationally trusted for round-coordination and is informationally trusted for transfer-history. The unilateral-exit guarantee ensures the ASP cannot steal funds, but the ASP’s coordination role is non-trivial. The trust profile is structurally between Lightning’s per-hop-routing trust and Liquid’s federated-functionary trust.

Round-based throughput vs per-transaction throughput. Ark’s round-based architecture amortizes the on-chain footprint across many off-chain payments — efficient for high-volume environments. The cost is per-payment latency tied to round windows. Lightning has lower per-payment latency but higher per-transaction on-chain overhead at channel-open and channel-close.

Inbound-liquidity inheritance vs Lightning’s bootstrapping cost. Ark’s principal UX improvement. New users receive payments immediately; Lightning users require channel-open or LSP-mediated inbound-liquidity provisioning. This addresses Lightning’s most persistent UX friction.

Expiry-and-recycling vs persistent state. vUTXOs expire after the round’s validity window; the ASP recycles unclaimed funds. This contrasts with Lightning channels, which persist indefinitely. The expiry mechanism is the inbound-liquidity-recycling-feature but adds per-user state-management overhead.

ASP-collapse exit-storm risk. If an ASP fails catastrophically, all vUTXO holders must unilaterally exit on-chain, producing a large base-layer transaction volume that competes for blockspace. The risk is real and is engaged in design discussions; mitigations include exit-cooperation protocols and multi-ASP architectures.

Substantive analytical critique of Ark’s covenant dependency, ASP-coordination trust, and exit-storm risk lives in OP_CAT and the covenants programmability debate (for the covenant question) and the broader Layer-2 design-space conversation.

Deployment status and ecosystem

By mid-2026, Ark has moved from a signet demonstration to two covenantless production implementations live on Bitcoin mainnet, each targeting a different niche:

  • Arkade (Ark Labs — Burak Keceli’s team; backed by Draper Associates, Axiom, and Fulgur Ventures) launched a public mainnet beta in October 2025, the first Ark implementation to reach mainnet. Arkade positions itself less as a payment app than as a programmable execution layer for Bitcoin — a virtualization model (VTXOs) intended to support lending, swaps, smart wallets, and trading with instant settlement. Alongside the launch, Ark Labs introduced Arkade Assets, a multi-asset framework extending the model to stablecoins and other tokens — the Ark-side analogue of Taproot Assets’ stablecoins-on-Lightning approach.
  • Bark (Second — led by Steven Roose, with a team drawn partly from former Blockstream engineers; roughly $5.1M raised) launched on mainnet in June 2026 with a payments-and-self-custody focus. Bark ships a Rust SDK with bindings for several languages, a standalone barkd wallet daemon, and a BTCPay Server plugin, so merchants can accept self-custodial payments without channel or liquidity management. Several wallets (Noah, Arke, Bark Wallet as an Umbrel app) were mainnet-enabled at launch.

Both are covenantless — they deploy on today’s Bitcoin without waiting for OP_CTV, at the cost of the heavier pre-signed-tree machinery described above. The competitive framing is now real: multiple protocols (the two Ark implementations, statechain-based Spark protocol, and Lightning itself) are converging on the same target — closing the gap between self-custody and usable payments. The base-layer settlement anchor and the ASP-coordination trust profile are common to both Ark deployments; they differ mainly in scope (execution-layer platform vs. payments wallet) and maturity.

The remaining catalyst is covenant activation. If OP_CTV or an equivalent activates, native Ark would be simpler, cheaper, and stronger than the covenantless implementations shipping today — but it is no longer the precondition for Ark to exist that it was a year ago.

Open questions for further development

  • Will OP_CTV (or equivalent covenant opcodes) activate, and on what timeline? No longer a gate on Ark existing — covenantless implementations shipped — but the path to a materially simpler and more capital-efficient native Ark.
  • Do the two covenantless implementations converge or diverge? Arkade (execution-layer platform + Arkade Assets) and Bark (payments wallet + SDK) are betting on different scopes; whether the ecosystem consolidates on one or sustains both is open.
  • What is the right ASP-economic model? Per-round fees, percentage-of-transaction fees, ASP-subsidized rounds, or mixed structures — the economic equilibrium is unsettled.
  • How do multi-ASP architectures compose? Inter-ASP payment routing, ASP-to-ASP rebalancing, ASP-failure-recovery — these architectural questions are partly developed but not fully resolved.
  • What is Ark’s role relative to Lightning? Coexistence with use-case differentiation, gradual replacement, or specialized niche — the medium-term landscape is unclear.
  • How does Ark interact with self-custody disciplines? ASP-coordination is a meaningful trust layer; the maximalist position has internal questions about whether ASP-mediated Bitcoin transactions are appropriate at scale.

Canonical sources for this note

Foundational design

  • Burak Keceli, “Ark: A Layer 2 for Bitcoin” (2023 proposal): arkdev.info and various conference presentations
  • Ark specification: github.com/ark-network

Production implementations

  • Arkade (Ark Labs) — docs.arkadeos.com, arkadeos.com; public mainnet beta October 2025; Arkade Assets multi-asset framework
  • Bark (Second) — second.tech; mainnet June 2026; Bark SDK and barkd daemon
  • awesome-ark-protocol (community index): github.com/aljazceru/awesome-ark-protocol

Adjacent designs and analysis

discussion references

Graph View

Backlinks