Gideon Bature

Posted on Mar 15

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

#bitcoin #bark #ark #second

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 functional guarantee, that the tree structure is predetermined and immutable, through user signatures rather than Bitcoin script primitives.

The Additional Step: Interactive Signing

The practical consequence of using pre-signed transactions instead of covenants is that clArk requires an extra interactive signing round compared to covenant Ark.

In covenant Ark, the ASP can construct the VTXO tree and broadcast it unilaterally — users just need to watch the chain. The covenant enforces the structure mechanically.

In clArk, users must actively participate in signing the tree before it is finalized. This means:

The ASP announces a round and collects user requests.
The ASP constructs the unsigned VTXO tree and sends a "VTXO proposal" to all participating users.
Users review the proposal, generate temporary signing keypairs, and send back pre-generated MuSig2 nonces.
The ASP assembles the nonces, creates the complete signature, and the tree is locked.
The round transaction is broadcast.

This is more interactive than covenant Ark, but it's entirely workable with modern cryptographic tooling. MuSig2 — a two-round Schnorr-based multi-signature scheme, was designed precisely to make this kind of collaborative signing efficient. It reduces what would otherwise require many rounds of communication down to two rounds, and the first round can be pre-computed ahead of time.

What Bark Adds and Changes

Beyond implementing clArk (covenant-less Ark on Bitcoin), Second has made several distinct design and engineering contributions:

Rust implementation. Bark is built entirely in Rust, Bitcoin's de facto systems programming language for security-critical financial software. This gives Bark performance, memory safety, and straightforward portability across platforms — including mobile via UniFFI bindings.

The bark and captaind architecture. Second has separated the concerns cleanly: bark is the wallet client (available as a CLI, a library, or a daemon with a REST API), and captaind is the ASP server software. This clean separation means any developer can run their own ASP, and any wallet can use any ASP.

Lightning gateway built into the ASP. Rather than treating Lightning interoperability as an afterthought, Second has built Lightning payment capability directly into their ASP implementation. The atomic swap from an Ark VTXO to a Lightning payment happens server-side, with cryptographic guarantees that ensure the user never takes on counterparty risk during the swap. From the user's perspective, they simply pay a Lightning invoice, the complexity is invisible.

Signet-first testing approach. Bark is currently available on signet (Bitcoin's testing network) with a fully functional faucet, test store, and documentation. Second ran the first Ark transactions on Bitcoin mainnet on September 20, 2024, with notable Bitcoiners including Stephan Livera, Marty Bent, Robin Linus, and Super Testnet present on a live video call. But Second has deliberately kept the mainnet ASP in experimental mode, they prioritize correctness and safety over rushing to production.

Developer-friendly SDK. The bark-ffi repository provides UniFFI bindings that make it practical to build native iOS and Android applications on top of Bark without having to interact with raw Rust code. Second is actively developing these bindings toward stability, recognizing that most real-world usage will happen through mobile apps rather than command-line wallets.

4. Technical Deep Dive

The UTXO Model, Rebuilt Off-Chain

The deepest and most elegant thing about Ark is that it doesn't replace Bitcoin's UTXO model, it extends it into an off-chain domain while maintaining all of its key properties.

In on-chain Bitcoin:

You own a UTXO: an output locked to your public key.
To spend it, you provide a valid signature.
The blockchain permanently records the state transition.
Anyone can verify your ownership by looking at the UTXO set.

In Ark:

You own a VTXO: an off-chain commitment locked to your public key.
To spend it, you provide a valid signature.
The round transaction periodically records the state to the blockchain.
The ASP can verify your ownership; anyone can verify it by examining the VTXO tree.

The mental model maps nearly perfectly. The key difference is timing: UTXOs settle in the next block (~10 minutes, more for confirmation security). In-round VTXOs settle in the next round (configurable, typically minutes to hours). ArkOOR VTXOs settle instantly with a trust assumption, or in the next round for full trustlessness.

The Transaction Tree in Detail

Let's walk through how a VTXO tree is constructed for a round with four users: Alice, Bob, Carol, and Dave. Each has 1 BTC.

Step 1: Root UTXO. The ASP creates a single on-chain transaction output worth 4 BTC (plus fees). This is the round's "commitment transaction."

Step 2: Level 1 split. Two pre-signed transactions spend the root UTXO. The first delivers 2 BTC to an intermediate output for Alice and Bob. The second delivers 2 BTC to an intermediate output for Carol and Dave.

Step 3: Level 2 split (leaves). Four more pre-signed transactions split the intermediate outputs. The first delivers 1 BTC to Alice's VTXO. The second delivers 1 BTC to Bob's VTXO. And so on for Carol and Dave.

Total on-chain cost: One 4-BTC output. For four users, that's one-quarter of a normal UTXO each. For four thousand users, it's one-four-thousandth. The efficiency scales logarithmically with tree depth and linearly with user count.

Exiting: If Alice wants to exit unilaterally, she broadcasts two transactions: the Level 1 split (revealing the Alice/Bob branch) and the Level 2 split (delivering her leaf). Bob, Carol, and Dave are unaffected, their branches remain off-chain.

Note an important nuance: Alice's exit forces Bob's branch of the tree to become visible on-chain as well. Bob now needs to either claim his leaf or refresh his VTXO in a new round. This is by design, it's not an attack, just a consequence of the shared structure.

The Connector Output: Atomicity's Backbone

The forfeit transaction design described earlier solves double-spending between the old and new round. But how exactly is the atomicity enforced, how does the user know they won't sign away their old VTXO and then never receive their new one?

The answer is connector outputs. These are special outputs included in the round transaction that serve as inputs to the forfeit transactions. The forfeit transaction is only valid if it spends the connector output. The connector output only exists if the round transaction was confirmed on-chain. Therefore:

If the round confirms → connector outputs exist → forfeits are valid → ASP is protected from double-spending.
If the round never confirms → connector outputs don't exist → forfeits are never valid → user retains their old VTXO fully.

This is elegant. The user can safely sign their forfeit transaction without trusting the ASP to complete the round. The cryptographic structure ensures that the forfeit is only dangerous in the exact scenario where it needs to be — when the user has already received their new VTXO.

MuSig2: The Cryptographic Foundation of clArk

Because Bark uses pre-signed transactions instead of covenants, every VTXO tree must be signed by all participants in that round. With potentially hundreds of users per round, this requires an efficient multi-signature scheme.

MuSig2 (specified in BIP 327) is a Schnorr-based multi-signature protocol that achieves "key aggregation": regardless of how many signers are involved, the final signature looks identical to a single-party Schnorr signature on-chain. From Bitcoin's perspective, there's no visible indication that multiple parties were involved. This is both a massive privacy benefit and a significant efficiency gain, the on-chain footprint doesn't grow with the number of signers.

MuSig2 requires only two rounds of communication between signers:

Nonce exchange — each signer publishes a commitment to a random nonce they've generated.
Signing — after receiving everyone's nonces, each signer produces their partial signature.

The ASP aggregates the partial signatures into a single final signature. The critical improvement in MuSig2 over its predecessor is that the first round (nonce exchange) can be preprocessed ahead of time, before the message to be signed is known. This means users can pre-generate nonces in advance, dramatically reducing the round-trip latency during active signing.

In clArk, this translates to: users generate signing nonces when they submit their round participation request. By the time the ASP has assembled the VTXO proposal and sent it back, each user's nonce is already committed. The actual signing step, the second round — becomes near-instantaneous.

VTXO Expiry: The Liveness Requirement

One of the most important design elements to understand about Ark, and one of the most frequently misunderstood, is VTXO expiry.

Every VTXO has a built-in expiration date, typically around 30 days, though this is configurable per ASP. If a user does nothing before their VTXO expires, the shared UTXO that contains their VTXO becomes spendable by the ASP.

Why is this necessary? It's about liquidity recycling. The ASP fronts the bitcoin that backs new VTXO issuance. That capital is locked in the shared UTXO until either: (a) users cooperatively exit, (b) users refresh their VTXOs into a new round, or (c) the timelock expires. Without expiry, the ASP's capital would be locked forever by dormant users, making it economically impossible to run an ASP business.

Expiry solves this: the ASP knows that within 30 days, they can reclaim any liquidity that hasn't been actively used. This bounded capital commitment is what makes the ASP model economically viable.

The user-facing implication is a liveness requirement: users (or their wallets) must come online and either spend, refresh, or exit their VTXOs before they expire. In practice, well-designed wallets will handle this automatically, refreshing VTXOs in the background, well before the expiry deadline. Users should never notice this happening.

If a user does miss the expiry window, it's not an immediate loss, the ASP can sweep the funds, but responsible ASPs will generate an "Ark Note" (a signed IOU redeemable for new VTXOs) for any swept user balances, essentially crediting the user back when they next come online. This isn't part of the core protocol, but it's the expected behavior for any ASP that wants to retain users.

The Two Exit Paths: Cooperative and Unilateral

When a user wants to move their sats back on-chain, Bark supports two distinct methods with very different cost profiles:

Cooperative offboard: The user requests an offboard from the ASP. The ASP includes the user's withdrawal as a special output in the next round transaction. This is cheap, the user pays only their proportional share of the round transaction fee. The on-chain footprint is minimal. The downside: you have to wait for the next round, and it requires ASP cooperation.

Unilateral exit: If the ASP is unresponsive, offline, or malicious, the user broadcasts their branch of the VTXO tree directly to Bitcoin. This requires broadcasting multiple transactions (one per level of the tree) and paying fees for each. It's more expensive and slower, but it is entirely permissionless, no one can stop it. This is the ultimate guarantee that Bark is self-custodial.

In the September 2024 mainnet demo, Second had participants try both paths. Offboards were straightforward. Unilateral exits required more patience, multiple transactions with the appropriate time delays between them, but they worked.

5. Lightning vs Ark/Bark

The Wrong Question

The most common framing when people first hear about Ark is: "Is this going to replace Lightning?" This is almost certainly the wrong question, and the people who designed these protocols know it.

Burak Keceli himself has said he doesn't see Ark as a "Lightning killer." He envisions a future where Lightning Service Providers (LSPs) also function as ASPs, with the two layers deeply interwoven. Second has built Lightning payment capability directly into Bark's ASP. From the very first mainnet demo, they showed Ark users paying Lightning invoices seamlessly.

The more accurate framing: Lightning and Ark have nearly opposite sets of trade-offs, which makes them natural complements rather than competitors.

The Comparison Table

Dimension	Lightning	Ark/Bark
Onboarding	Requires channel opening (on-chain tx + liquidity)	No channel required — wallet + deposit, done
Receiving	Requires inbound liquidity pre-allocated	No pre-allocation needed — ASP handles liquidity
Liquidity management	Per-user burden	Abstracted to ASP
Throughput	Theoretically unlimited (entirely off-chain)	Bounded by Bitcoin block rate (each round = 1 on-chain tx)
Finality model	Fully off-chain, no blockchain interaction during payments	Full trustlessness requires on-chain settlement per round
Liveness requirement	Must be online for routing; watchtowers available	Must refresh VTXOs periodically (~30 days)
Privacy	Moderate (onion routing, but graph visible)	Better by default (CoinJoin-like batching in rounds)
Trust model	Primarily peer-to-peer, no central server	ASP coordination with non-custodial guarantees
Routing complexity	Complex multi-hop routing required	No routing — ASP is the "hub"
Cost per payment	Near-zero for established channels	Shared on-chain costs per round
Lightning interop	Native	Via ASP gateway (atomic swaps)
Covenant requirement	No	No (with clArk); better with CTV

What Lightning Does Better

Lightning has a genuine throughput advantage. Because Lightning payments happen entirely off-chain — updating channel states between peers with no blockchain interaction at all — the number of Lightning payments per second has no fundamental upper bound. The velocity of payments doesn't translate to on-chain transactions.

Ark is different. Every time a round settles, it produces one on-chain transaction. The number of rounds per unit time is bounded by how much blockspace is available. Even with very efficient VTXO trees, if millions of users are constantly transacting, the round frequency required to maintain trustlessness becomes a meaningful on-chain footprint. Bitcoin's block throughput becomes a ceiling on Ark's settlement rate.

For high-frequency, high-volume payment channels, think streaming satoshis, machine-to-machine payments, or very active merchants, Lightning's fully off-chain model is genuinely more efficient.

Lightning also has no liveness requirement for users (only for routing nodes). You can hold a Lightning channel and come online only when you want to transact, with some caveats around watchtowers.

What Ark/Bark Does Better

The single biggest advantage of Bark over Lightning is onboarding. A new user can download Bark, generate a wallet, receive sats into a VTXO, and start transacting, with zero channels to open, zero inbound liquidity to source, and zero understanding of channel management required. This removes the most significant friction point that has prevented Lightning from achieving mass adoption at the wallet layer.

For merchants and businesses, this is enormous. A business can accept Ark payments and Lightning payments from a single balance, with the ASP handling all the routing complexity on the Lightning side. The developer integration is simpler too: Ark uses a client-server model, which is architecturally familiar to any web developer. Lightning's peer-to-peer protocol requires understanding a fundamentally different mental model.

Ark's privacy model is also superior by default. Because round transactions use a CoinJoin-like structure: multiple inputs and outputs batched together, the link between senders and recipients is broken. The ASP processes all transactions through the same pool. On Lightning, while onion routing hides the full payment path, the channel graph is public and payments can be partially deanonymized through timing analysis and graph inference.

The Complementary Vision

The most sophisticated vision for how these two protocols fit together treats Ark as the onboarding and holding layer and Lightning as the payment routing layer for the broader ecosystem.

Here's how this might look in practice: A new user in a developing country downloads a Bark-based wallet. They receive their first sats from a friend or remittance service directly into Ark, no channel needed, no upfront fee. They hold their balance in Ark. When they want to pay a merchant who uses Lightning, their wallet automatically routes the payment: Ark VTXO → ASP → Lightning payment. The user sees a seamless experience. The ASP handles the complexity.

As the user becomes more sophisticated, or if they're doing high-frequency transactions, they might graduate to managing their own Lightning channels, using Ark as a liquidity reserve and onboarding layer. The two systems complement each other perfectly in this model.

The Bark README states this directly: Ark is "a complementary scaling solution that simplifies bitcoin self-custody" — not a replacement for Lightning, but an expansion of the accessible surface area of self-custodial Bitcoin payments.

6. The Bitcoin Native Philosophy

Why This Matters

Second's decision to build Bark without covenants, without Liquid, and without requiring any consensus changes is not just a technical constraint they're working around, it's a philosophical commitment that shapes every aspect of the project.

Bitcoin's value proposition rests on a very specific set of properties: verifiable scarcity, censorship resistance, permissionless access, and a security model that doesn't depend on trust in any central party. Every departure from these properties, every shortcut, bridge, or federation, introduces some degree of trust that wasn't there before.

The Bitcoin community has watched many "scaling solutions" appear over the years that solved the payment throughput problem by making trust assumptions so large that they effectively recreated the banking system. Liquid requires trusting a federation of 15 companies. Most Ethereum layer 2s require trusting a multisig or a sequencer. Lightning itself, in practice, has increasingly moved toward custodial implementations (wallets of Satoshi, Alby Hub without self-custody) because the self-custodial version is too complex for most users.

Second's bet is that the right path is harder and narrower: build on Bitcoin's security model, not around it. Use Bitcoin's existing scripting capabilities. Accept the trade-offs that come with not having covenants. Be willing to be more interactive, more complex internally, but less dependent on external trust assumptions.

Why Not Liquid?

Liquid is Blockstream's federated sidechain for Bitcoin. It has faster block times, confidential transactions, and, crucially for Ark, it already has covenant-like primitives that would make Ark easier to implement.

The problem: Liquid is operated by a federation of ~15 companies. To transact on Liquid, you peg in by trusting these companies to process your peg. If the federation is compromised, colluding, or shut down by regulators, your peg-in is at risk.

For a protocol whose entire value proposition is non-custodial, trustless Bitcoin payments, building on Liquid would be architecturally contradictory. The trust model of the base layer defeats the trust model of the application layer. Second chose not to make that trade.

Why Not Wait for CTV?

The other obvious path was to wait for OP_CHECKTEMPLATEVERIFY to be activated as a Bitcoin soft fork. CTV would make Ark dramatically more efficient — no interactive signing round, smaller transactions, lower ASP operational burden.

The problem: there's no timeline for CTV. It has been a contentious topic in the Bitcoin developer community for years. Some developers support it enthusiastically; others have significant concerns about its design. Bitcoin does not have a release schedule for protocol changes. Waiting for CTV could mean waiting indefinitely.

Second's decision to implement clArk: covenant-less Ark using pre-signed transactions and MuSig2, means they can ship real software today, build a user base, prove the protocol, and benefit from CTV if and when it activates without being blocked by it. The design of Bark is explicitly forward-compatible with covenant-based Ark. If CTV is ever activated, the ASP can upgrade to native covenants, reducing the interactive signing burden. Users see no difference.

This is a mature engineering posture: don't let the perfect be the enemy of the good. Build on what exists, design for what's coming.

Why No Altcoin Bridges, No Other Chains?

Ark as a protocol is purely about Bitcoin. VTXOs are denominated in satoshis. The shared UTXOs are on Bitcoin's blockchain. The exit path goes to Bitcoin's base layer.

Some Layer 2 projects for Bitcoin have experimented with cross-chain constructions, pegging to Ethereum or other chains to access their smart contract capabilities, then bridging back. These constructions introduce additional trust assumptions (bridge operators, oracle risks, smart contract vulnerabilities) that compound with each other.

Bark sidesteps all of this by operating entirely within Bitcoin's security model. There is no bridge. There is no oracle. The only chain that matters is Bitcoin's. The only consensus rules that matter are Bitcoin's. This isn't limiting, it's clarifying. It forces every component to be constructible from Bitcoin's existing primitives.

The Forward-Compatible Design

One of the most underappreciated aspects of Second's approach is that Bark is designed to improve automatically as Bitcoin improves.

If CTV is activated: the interactive signing round in clArk can be replaced by covenant-based tree construction. Rounds become faster, less interactive, and cheaper.

If CSFS (OP_CHECKSIGFROMSTACK) is activated: additional scripting capabilities become available for more complex VTXO conditions.

If Taproot continues to see wider adoption: MuSig2 key aggregation becomes more widely supported across tooling and hardware wallets, making the signing ceremonies more seamlessly integrated into the user experience.

None of these future improvements require any changes to Bark's core architecture. They're additive upgrades to the underlying primitives that Bark already uses. This is what "Bitcoin-native" means in practice: building on the grain of the wood, not against it.

7. Risks and Failure Modes

Being Honest About What's Unproven

Good research is incomplete without this section. Ark and Bark are genuinely exciting, genuinely novel, and genuinely work, Second demonstrated real transactions on Bitcoin mainnet. But they are also early-stage, with several significant challenges that haven't been fully solved. The goal here is not pessimism but clarity: understanding the risks is what lets you evaluate the project honestly.

Risk 1: ASP Centralization

The ASP model introduces a structural centralization pressure that the protocol's design cannot fully eliminate. Every user of an ASP connects to a single server that coordinates all their transactions. Even if the ASP can't steal funds, it can censor payments, refuse to serve specific users, and collect metadata about payment patterns.

This centralization pressure is not hypothetical, it follows directly from the architecture. Lightning's peer-to-peer routing distributes this power across many nodes. Ark concentrates coordination in one server per deployment.

The mitigants: Ark is permissionless, so anyone can run an ASP. Competition between ASPs creates market pressure against censorship. A user who is censored by one ASP can migrate to another. And crucially, the ASP can never confiscate funds, the worst it can do is refuse to process new transactions, which forces the user to the blockchain.

But will there actually be a competitive ASP market? In the early stages of Bark deployment, there will likely be very few ASPs. Network effects tend to concentrate users around the largest providers. If Second's ASP becomes dominant, the effective centralization of user activity on a single operator could become a meaningful concern, not for fund safety, but for censorship resistance and privacy.

The Ark specification paper itself acknowledges this: "The Ark protocol fundamentally relies on a single operator to coordinate offchain transactions... This introduces a centralisation vector." Research into federated or decentralized ASP designs is ongoing.

Risk 2: Liveness and VTXO Expiry

The ~30-day VTXO expiry window creates a liveness requirement that many users will fail to meet. People lose phones, forget passwords, get hospitalized, go on long trips without internet access. If your VTXO expires while you're offline and your wallet didn't automatically refresh it, the ASP has the right to sweep those funds.

The ASP has reputational incentives to honor these swept balances with Ark Notes. But that's a social convention, not a cryptographic guarantee. If an ASP decides to simply pocket swept funds from inactive users, there is no on-chain recourse. This is a meaningful trust assumption that doesn't exist in on-chain Bitcoin or in Lightning (where your funds are in your channel as long as you can broadcast a transaction).

The 30-day window is configurable per ASP — some may offer longer windows, with correspondingly higher liquidity costs passed to users through fees. The design is still evolving.

Risk 3: ASP Liquidity Requirements and Fee Volatility

Running an ASP requires locking up substantial amounts of bitcoin to back VTXO issuance. The liquidity requirements are complex and potentially extreme. Consider: every time a user makes a payment within Ark, the ASP must fund both the recipient's new VTXO and the change VTXO back to the sender. As transaction velocity increases, the ASP's capital requirements grow faster than proportionally.

Research from Ark Labs illustrates this starkly: an ASP supporting a single user with 1 BTC who makes ten payments of 0.033 BTC each requires 8.52 BTC in liquidity — more than 8x the user's balance. For high-velocity users, the capital multiplication factor is enormous.

If an ASP runs short on liquidity, it must either raise fees sharply or stop accepting new payments entirely, waiting four weeks for old timelocks to expire and liquidity to be recycled. This creates a potential boom-bust fee pattern that could be disorienting for users.

The VTXO expiry mechanism is designed to address this by bounding the lockup period. But an ASP that underestimates its liquidity needs could create a poor user experience during periods of high activity. The economics of running a sustainable ASP are not fully understood yet in practice.

Risk 4: Interactive Signing Adds Complexity and Failure Modes

The clArk requirement for all round participants to actively sign the VTXO tree introduces a new class of failure mode: signing round failures. If even one participant in a round goes offline or refuses to sign before the round is complete, the entire round fails. The ASP must discard the pending tree and start a new round without the non-cooperating participant.

This creates a DoS vector: a malicious user could join many rounds and consistently fail to complete signing, forcing repeated round failures and wasting ASP resources. The ASP can mitigate this with reputation systems, deposit requirements, or other anti-DoS measures, but these add complexity and potential exclusion mechanisms that touch on the censorship resistance question.

With covenants (if CTV ever activates), this failure mode disappears entirely, the ASP constructs the tree unilaterally and the participants don't need to sign. clArk's interactive signing is a direct cost of being covenant-free, and it's one that has real operational consequences.

Risk 5: Congestion at Unilateral Exit

In a disaster scenario, say, a major ASP going bankrupt or being seized by authorities, a large number of users may need to exit unilaterally simultaneously. Each user must broadcast their branch of the VTXO tree, which involves multiple on-chain transactions.

If thousands of users are broadcasting exit transactions at the same time, Bitcoin's mempool could experience significant congestion. Fees spike. Some users' exit transactions get stuck. The four-week timelock on VTXO expiry means the ASP can only claim unused funds after four weeks, but if the mempool is congested for weeks, users may face a race condition between their exit transactions confirming and the ASP's sweep transaction.

The Ark specification paper discusses this risk directly and proposes potential mitigations like rate-limited exits and off-chain exit markets, but notes these "constitute promising directions for future work" — meaning they don't yet have production solutions.

Congestion control techniques borrowed from Ark's covenant research (particularly CTV-based congestion control trees) could dramatically improve this situation. But until CTV or equivalent is available, the unilateral exit congestion scenario remains a meaningful systemic risk.

Risk 6: The ArkOOR Trust Assumption

Out-of-round payments are fast and convenient, but they carry an important trust caveat: the recipient must trust that the sender and ASP are not colluding to double-spend. In the first mainnet demo, Marty Bent described arkoor payments as "insanely fast." They are, but they achieve that speed by relaxing the trustlessness guarantee.

For most everyday payments of small values between known parties, paying a friend, buying a coffee, tipping a creator, this is a completely acceptable trade-off. For larger value transfers or payments to strangers, users should wait for the next in-round payment to receive full trustlessness.

Whether wallets will surface this distinction clearly enough for users to make informed decisions is an open UX question. A user who receives a large arkoor payment and treats it as fully final could be defrauded by ASP-sender collusion.

Risk 7: Still Early — Software Maturity

As of early 2026, Bark is in beta. The GitLab repository explicitly warns: "This repository contains experimental code. Using it with real bitcoin is reckless and can result in loss of funds." The mainnet ASP server is disabled. Backward compatibility is not guaranteed between releases.

This is not a knock against Second, it's responsible disclosure. Building a new cryptographic payment protocol correctly takes years of testing, security audits, and real-world stress testing. The Lightning Network took from 2015 (whitepaper) to 2018 (mainnet) to reach a first beta, and is still actively being hardened a decade later. Bark is moving faster because it builds on better tooling and a more mature Bitcoin ecosystem. But it is still early.

Serious users should treat Bark on mainnet as experimental until:

Multiple independent security audits have been completed.
The signet deployment has accumulated substantial testing.
The mainnet ASP has been running stably for an extended period.
The bark-ffi bindings have stabilized and been battle-tested in production mobile apps.

Conclusion: Why Bark Matters

Bark is not trying to replace Lightning. It's not trying to be a general-purpose smart contract platform. It's not trying to bridge to other blockchains. It is trying to do one very specific thing exceptionally well: give anyone with a smartphone the ability to hold and spend bitcoin in a self-custodial way, without needing to understand channels, liquidity, or routing, and without trusting a bank.

That is a hard problem. Lightning has been trying to solve it for a decade and has made extraordinary progress, but the onboarding and liquidity friction remain barriers that have pushed most users toward custodial wallets as a practical compromise. Bark takes a genuinely different architectural path, sharing UTXOs, batching state transitions, abstracting liquidity to the ASP, and that difference meaningfully changes the user experience curve.

The Bitcoin-native commitment is not just philosophical purity, it's what makes Bark's security guarantees coherent. The unilateral exit guarantee is only worth something if the exit path lands on sound money, secured by the most battle-tested consensus mechanism in existence. Building on Bitcoin's base layer, without bridges or federations, is what makes that guarantee real.

Whether Bark succeeds will depend on factors beyond the protocol design: ASP economics, wallet UX, developer adoption, and whether the tradeoffs around liveness and trust resonate with users better than the alternatives. But the foundation is sound, the team is credible, and the timing is right, the Bitcoin ecosystem is mature enough to support a new generation of payment infrastructure that was impossible to build five years ago.

This is worth watching closely.

Table of Contents