Bark & Ark: A Deep Dive into Bitcoin's Most Ambitious Payment Layer

Mon, 16 Mar 2026 12:26:35 +0000

A comprehensive technical and philosophical breakdown of what Ark is, how Bark implements it natively on Bitcoin, why it matters, and what could still go wrong.

The Problem Space — Why Bitcoin Needs More Than Lightning
Ark Fundamentals — The Original Design
Bark Specifically — What Second.tech Built and Why
Technical Deep Dive — How It Actually Works
Lightning vs Ark/Bark — Complement, Not Competition
The Bitcoin-Native Philosophy — Why No Liquid, No Bridges, No Soft Fork Required
Risks and Failure Modes — The Honest Breakdown

1. The Problem Space

Bitcoin's Fundamental Scaling Constraint

To understand why Bark was built at all, you first need to understand the ceiling Bitcoin runs into as a payment system. Bitcoin's blockchain can process roughly 3 to 7 transactions per second, a number determined by two hard constraints that were baked into the protocol from the beginning: a block time of approximately 10 minutes, and a block size capped at 1 megabyte.

Contrast that with Visa, which processes around 24,000 transactions per second at peak demand. For Bitcoin to function as a global payment layer used by billions of people, on-chain transactions alone can never get you there. That gap isn't a bug waiting to be patched, it's a fundamental design trade-off that Bitcoin made in exchange for decentralization and security. Bigger blocks mean fewer people can run full nodes, which means more centralization. Bitcoin's community has consistently chosen to preserve that decentralization, which means the base layer will always be a bottleneck at scale.

This is not a failing. It is a deliberate architectural choice. But it does create a genuine engineering problem: if billions of people can't settle transactions on-chain, what do they use instead?

What Lightning Solved — and What It Didn't

The Lightning Network, first described in a 2015 whitepaper by Joseph Poon and Thaddeus Dryja and launched in 2018, was Bitcoin's first serious answer to this question. The core idea is elegant: instead of recording every payment on the blockchain, two parties lock funds into a shared "payment channel" with a single on-chain transaction. They can then make as many payments as they want between themselves off-chain, updating their shared balance instantly and for near-zero cost. When they're done, they close the channel with one more on-chain transaction, and the final balance gets settled.

The genius of Lightning is that it extends this concept to a network. You don't need a direct channel with everyone you want to pay, you just need a connected path through the network. Alice can pay Dave by routing through Bob and Carol, with each hop atomically updating channel balances. In theory, this allows millions of transactions per second with no practical upper bound on throughput.

In practice, Lightning has delivered real results. By mid-2024, Lightning accounted for over 16% of all Bitcoin orders processed by European crypto payments processor CoinGate, up from around 6.5% just two years earlier. Routed payments on Lightning increased 1,212% between 2021 and 2023, according to River's Lightning report. Major integrations, Coinbase adding Lightning support in 2024, widespread wallet adoption across Africa, Latin America, and Asia, have proven that Lightning works and is growing.

But years of real-world deployment have also exposed structural friction points that don't disappear with more engineering. These aren't edge cases, they are fundamental properties of the channel-based model:

The Inbound Liquidity Problem. To receive a Lightning payment, someone else must have already committed bitcoin into a channel pointed toward you. If you're a new user or a new merchant, that liquidity doesn't exist yet. You can't just show up and start receiving. You either have to pay a Lightning Service Provider (LSP) to open a channel toward you, or you have to find someone willing to do it. This is confusing and counterintuitive to new users, and it creates friction during onboarding that has measurably slowed adoption.

Channel Management Complexity. Channels have finite capacity on both sides. If you exhaust the outbound capacity of your channel, you can't send until you receive more. If your inbound side runs dry, you can't receive until you send. Maintaining a "balanced" channel, or managing multiple channels strategically, is a continuous task that requires ongoing attention. For casual users or businesses that don't want to think about this, it's a significant burden. For developers building wallet products, it forces either custodial shortcuts or complex liquidity management code.

Online Requirement and Security Risks. To route Lightning payments, a node needs to be online. This creates a liveness requirement, a technical term meaning the system requires you to be present and active. If a node goes offline and a counterparty broadcasts an outdated channel state (an attempted theft), the victim has a limited time window to detect and respond. While watchtower services mitigate this, they introduce additional trust and complexity. The attack vector is real: in 2023, Lightning developer Antoine Riard disclosed a new class of vulnerabilities called replacement cycling attacks targeting hash time-locked contracts (HTLCs), the cryptographic mechanism Lightning uses to route payments.

Routing Failure Rates. Lightning payments are routed through the network by finding a path with sufficient liquidity at each hop. As networks scale, finding reliable paths becomes harder, particularly for larger payments. Routing failures cause payments to hang, retry, or fail outright. While routing algorithms have improved dramatically, payment reliability remains uneven across the network, especially for large or unusual payment amounts.

The Onboarding Cost Problem. Every new Lightning user needs at least one on-chain transaction to open a channel. During periods of high on-chain fees, like the 2021 and 2023 congestion spikes driven by NFT activity and Ordinals inscriptions, this cost can easily exceed the value of small payments. The channel opening fee makes Lightning economically inaccessible for users who hold small amounts of bitcoin.

These aren't fatal flaws. Lightning is real, it works, and it serves hundreds of millions of dollars worth of payments. But collectively, these constraints define the population of users Lightning can't serve well: new users without existing channels, users in low-trust environments where custodial trade-offs are unacceptable, and users in regions where on-chain fees represent a significant financial barrier to entry.

That gap, self-custodial payments for users who can't or won't manage channels, liquidity, and routing complexity, is exactly the problem Ark was designed to solve.

2. Ark Fundamentals

The Origin Story

In May 2023, a developer named Burak Keceli — known in the Bitcoin community simply as "Burak" — published a proposal to the bitcoin-dev mailing list under the placeholder title "TBDXXX." He had previously been dissatisfied with both Blockstream's Liquid sidechain (which requires a permissioned federation) and the Lightning Network (with its liquidity and privacy constraints). Ark, as the protocol was soon renamed, was his attempt to design a second layer that eliminated those frustrations while remaining fully self-custodial.

Burak's core insight was that Lightning's fundamental limitation isn't the idea of off-chain payments, it's the channel model itself. Channels require pre-allocated, per-user liquidity. They require both parties to be online. They require routing. What if instead, you could take Bitcoin's UTXO model, which is already beautifully simple and doesn't require any of those things, and extend it off-chain?

The Shared UTXO Concept

To understand Ark, you first need to understand what a UTXO is. In Bitcoin, every time you receive a payment, it creates a new "Unspent Transaction Output" (UTXO), essentially a chunk of bitcoin locked to your address that only your private key can spend. When you want to pay someone, you spend that UTXO as an input to a new transaction, and new UTXOs are created as outputs.

Ark's fundamental innovation is the shared UTXO. Instead of each user owning their own separate UTXO on the blockchain, multiple users, potentially hundreds of thousands of them, share a single on-chain UTXO. Each user holds a virtual claim on their portion of that shared pool, represented by what Ark calls a Virtual Transaction Output (VTXO).

From the blockchain's perspective, there is one UTXO. From the users' perspective, they each have their own independently spendable balance.

The elegance of this is immediately apparent from a fee perspective. One on-chain transaction can anchor the funds of a thousand users. The cost of that transaction is split across all of them, making each user's effective on-chain footprint vanishingly small.

What Is a VTXO?

A VTXO (Virtual Transaction Output) is the central unit of value on Ark. The most accurate way to think about it is this: a VTXO is a pre-signed, off-chain transaction that proves you have the right to create a real on-chain UTXO whenever you want to.

You never need to broadcast it. You simply hold it. If everything goes well, if the Ark server keeps operating, if your counterparty doesn't try to cheat, the VTXO stays off-chain forever, and you just keep transacting within Ark. But if anything goes wrong, you can take that pre-signed transaction to the Bitcoin blockchain and claim your sats as a real, fully confirmed UTXO. No one can stop you.

This unilateral exit capability is what makes Ark genuinely self-custodial rather than custodial or federated. You are not trusting the Ark server to hold your money. The server cannot take your money. It can at most inconvenience you by going offline, in which case you exit unilaterally to the base layer.

The VTXO Tree: How Shared UTXOs Are Built

Here's the clever part of the construction. When an Ark server wants to anchor the funds of a large group of users, it doesn't just lock a pile of bitcoin into one massive multi-signature address. That would create a problem: if any user wanted to unilaterally exit, they'd need everyone else to cooperate.

Instead, Ark builds a tree of pre-signed transactions. Think of it like a binary tree. At the root is a single on-chain UTXO — the shared output. This UTXO has a covenant (more on how this works without soft forks later) that says: "the only valid ways to spend this UTXO are the pre-signed transactions we've already prepared." Each internal node of the tree is a pre-signed transaction that splits the previous output into two. Each leaf of the tree is a pre-signed transaction that delivers a specific amount to a specific user.

To exit, a user broadcasts their branch, the chain of pre-signed transactions starting from the shared UTXO down to their leaf. Only their branch goes on-chain. Other users' branches stay off-chain.

The trade-off: an individual exit is more expensive than a direct UTXO spend, because you're broadcasting multiple transactions. But this is far more efficient than having everyone exit simultaneously, which would be catastrophic for blockspace and fees. The tree structure allows individual users to exit independently without forcing everyone else to do the same.

The ASP: Ark Service Provider

Coordinating all of this, building the VTXO trees, batching users together, providing liquidity, managing rounds, is the job of the Ark Service Provider (ASP). The ASP is a server that users connect to in order to participate in Ark. It is always online, provides the liquidity that backs new VTXO issuance, and coordinates the periodic "rounds" that settle the off-chain payment activity into new on-chain transactions.

Critically, the ASP is not a custodian. It cannot steal your bitcoin. Its role is purely coordinative and operational. Users sign their own exit transactions before any of their funds are committed, so the ASP never has unilateral access to user funds. This is architecturally closer to how a Lightning node operates (where you remain in custody of your keys) than how an exchange or custodial wallet operates (where they hold your funds on your behalf).

The ASP does have some power, though: it can refuse to serve you. It can decline to include you in rounds, effectively making you unable to transact within Ark. But it cannot take your money, you can always exit unilaterally.

How Rounds Work

An Ark round is the periodic batch event that anchors off-chain activity to the Bitcoin blockchain. Here's the sequence:

The ASP announces the start of a round.
Users who want to participate: to refresh their VTXOs, make payments, or onboard, communicate to the ASP what they want.
The ASP constructs a new VTXO tree containing all the requested new outputs.
All participating users sign the tree (and their associated "forfeit transactions" — more on this below).
The ASP broadcasts the root transaction on-chain, permanently anchoring this round's state to Bitcoin.

Every round produces a single on-chain transaction. Whether ten users participated or ten thousand, the blockchain sees one output. That is the fundamental efficiency of the model.

The Forfeit Transaction: How Trust Is Maintained

There's a subtle problem in the above flow. When a user is receiving a new VTXO in a round, what stops them from simultaneously trying to broadcast their old VTXO to claim their funds on-chain while also getting the new VTXO? This would be double-spending.

Ark prevents this through forfeit transactions. Before the new VTXO tree is finalized, the user signs a transaction saying "if my old VTXO ever appears on-chain, the ASP gets to claim it." This is the forfeit. The ASP keeps the signed forfeit. If the user misbehaves, by broadcasting their old VTXO after they've already gotten a new one, the ASP can immediately claim the old UTXO as compensation.

The atomicity guarantee works in the other direction too, via connector outputs. The user's forfeit transaction is only valid if the ASP actually published the new round transaction on-chain. If the ASP fails to do so, the forfeit transaction is invalid, and the user loses nothing.

Out-of-Round Payments (ArkOOR)

Rounds are powerful but not instant, users have to wait for the next round to begin, which could be minutes or hours depending on ASP configuration. For cases where speed matters more than maximum trustlessness, Ark supports out-of-round payments, often written as "arkoor."

In an arkoor payment, Alice transfers her VTXO directly to Bob without waiting for a round. She signs a transaction passing her VTXO to Bob. The ASP co-signs to confirm it won't double-spend. Bob receives immediately, nearly instantly, with just one round-trip to the server.

The trade-off: Bob must trust that Alice and the ASP aren't colluding to double-spend. This is a different security model than an in-round payment. If Bob is worried, he can "refresh" his arkoor VTXO in the next round, upgrading it to full trustlessness.

This two-tier system, fast arkoor payments for everyday use, in-round payments for full trustlessness, is one of the most pragmatic design choices in the protocol.

3. Bark Specifically

Who Is Second.tech?

Second is a Belgium-based Bitcoin company whose stated mission is to bring self-custodial Bitcoin payments to billions of people. Their CEO is Steven Roose, a Bitcoin developer with deep roots in the ecosystem. The team decided early on that Ark was the most promising protocol architecture for solving the onboarding and liquidity problems that have held back self-custodial Lightning adoption, and they went all-in on building it.

Bark is the name of Second's implementation of the Ark protocol. It is written in Rust, hosted on GitLab, and designed to be used both as a standalone CLI wallet (for testing and development) and as a library that developers can integrate into their own applications via FFI (Foreign Function Interface) bindings.

The name "Bark" is a playful reference, Ark, plus the sound a dog makes, because why not. Their ASP server implementation is called captaind (the captain of the Ark, presumably).

What Bark Inherits from Ark

Bark is fundamentally an implementation of the Ark protocol design. Everything described in the previous section, VTXOs, VTXO trees, ASPs, rounds, forfeit transactions, connector outputs, arkoor payments, Bark implements all of it. The core protocol design is not Second's invention; it evolved from Burak's original proposal through a community design process.

Bark inherits from Ark:

The shared UTXO model as the primary scaling primitive.
The VTXO abstraction — off-chain ownership claims with on-chain exit guarantees.
The tree-based transaction structure that enables individual exits without group coordination.
The ASP coordination model — centralized coordination with non-custodial guarantees.
The rounds mechanism for periodic on-chain settlement.
The arkoor (out-of-round) payment mechanism for instant off-chain transfers.
The Lightning interoperability design — the ASP acts as a Lightning gateway, enabling users to pay any Lightning invoice directly from their Ark balance.
The unilateral exit guarantee — users can always retrieve their funds on-chain without ASP cooperation.

The Pivotal Decision: Bitcoin-Only, No Soft Fork Required

Here's where Bark diverges significantly from the original Ark vision and from other implementations. The original Ark design, as proposed by Burak, required covenants, a Bitcoin scripting primitive that doesn't currently exist in Bitcoin's protocol.

Specifically, the original Ark needed OP_CHECKTEMPLATEVERIFY (CTV), a proposed opcode defined in BIP 119. CTV would allow a transaction output to specify exactly which future transactions are allowed to spend it, a "covenant" constraining how funds can be moved. With CTV, you could build the VTXO tree natively: the root UTXO's script would encode the entire tree structure, making it deterministic and tamper-proof without requiring any signatures.

The problem: CTV doesn't exist in Bitcoin yet. It's been a contentious proposed soft fork for years. Getting changes into Bitcoin's consensus rules requires persuading the global community of node operators and miners, a process that has historically been slow, contentious, and deeply political. The Bitcoin community does not accept protocol changes lightly, and for good reason.

Second's decision was bold: build Ark on Bitcoin today, without waiting for any consensus changes.

This required solving a fundamental problem. Without CTV, how do you make the VTXO tree tamper-proof? The answer they implemented is called clArk (covenant-less Ark), and it uses pre-signed transactions and multi-party signing to simulate what a covenant would do natively.

The clArk approach: instead of a covenant that mechanically enforces the tree structure, all users who are participating in a given round collectively sign the VTXO tree using n-of-n multi-signature via MuSig2. Because every participant has signed the tree, and any single participant can refuse to sign a conflicting transaction, the tree is effectively locked, not by a covenant, but by collective cryptographic commitment.

This is what Second's documentation describes as a "pseudo-covenant": it achieves the same

Coder Legion - Recent posts tagged ark