BTCPay's Bark Plugin — Accept Lightning Payments Without Running a Node

Lightning has become the de facto bitcoin standard for retail payments, but merchants running BTCPay Server checkouts have traditionally had to operate a full Lightning node — complete with channels and inbound liquidity — just to accept it. The Bark plugin for BTCPay Server, now at version 0.9.2 and production-ready, removes that requirement entirely. It’s built on the Ark protocol, a newer bitcoin layer-2 design that replaces payment channels with shared, off-chain UTXOs. This article explains how Ark works, what the plugin actually does for a merchant, and what trade-offs come with it.

Why Lightning got hard for small merchants

Running a Lightning node isn’t just software installation — it’s ongoing operations work. A merchant needs to open channels, fund them on-chain, and keep enough inbound liquidity available so customers can actually pay them. Because retail payment flows are almost entirely one-directional (customers paying the store, rarely the reverse), a merchant’s channels drain of inbound capacity as sales come in, and need periodic, often costly, rebalancing to keep working.

That devops burden — node uptime, channel management, liquidity sourcing — is a big reason why Lightning adoption among small BTCPay-based stores has lagged behind interest. Business owners want to accept Lightning; most don’t want to run a node to do it.

What is the Ark protocol?

Ark is a bitcoin layer-2 protocol, originally proposed on the bitcoin-dev mailing list, designed to enable cheap off-chain transactions without the setup cost of opening and funding payment channels. Despite the natural comparison, Ark’s design has little in common with Lightning’s. Lightning is a network of two-party payment channels that route payments across paths between them. Ark is instead a client-server protocol: users coordinate through a central Ark server but retain control of their own bitcoin at all times.

The core building block is the VTXO (virtual UTXO) — a user’s share of a large UTXO that’s held jointly among potentially hundreds of thousands of participants. Where Lightning shares a UTXO between exactly two channel counterparties, Ark shares a single UTXO among a whole cohort of users, structured as a tree of off-chain transactions.

• Rounds: The Ark server periodically organizes “rounds,” where users can refresh their existing VTXOs into a new shared UTXO. This keeps VTXOs valid without requiring an on-chain transaction for every user, every time.
• Connectors: Special outputs in the shared UTXO transaction make each round’s refreshes atomic, so a user never forfeits an old VTXO without a guaranteed new one.
• Arkoor (out-of-round payments): Because rounds take time and require on-chain confirmation, actual payments between users happen instantly, off-round, co-signed by the Ark server. The receiver can either hold that VTXO until it needs refreshing, or fold it into the next round.

Critically, the Ark server never takes custody of user funds — VTXO holders can always broadcast their branch of transactions and reclaim their bitcoin on-chain, without the server’s cooperation. Two independent implementations of the protocol are currently in development: Second (second.tech, the team behind Bark) and Arkade (arkadeos.com).

What the Bark plugin actually does for a BTCPay store

The Bark plugin connects a BTCPay Server store directly to an Ark wallet, so there’s no separate node process, no channel management, and no liquidity to source. A store owner installs the plugin, enables it, and their checkout is immediately Lightning- and Ark-enabled — no syncing wait, and no on-chain transaction required to open a first channel.

Figure 1: A Bark wallet dashboard, showing the off-chain/on-chain balance split, the countdown to the next VTXO refresh round, and a mix of Ark, Lightning, and on-chain transactions in one view — the same wallet engine that powers the BTCPay plugin.

At checkout, customers see a single, unified QR code that offers on-chain, Lightning, and Ark payment options simultaneously, letting each customer’s wallet pick whichever method is most efficient for it. Because there’s no inbound liquidity ceiling, the store can receive payments — large or small — indefinitely, and payments down to a single sat are supported over both Lightning and Ark. Receiving over Lightning is free for the merchant, and customers pay nothing beyond standard Lightning routing fees. Every payment lands in the store’s off-chain Ark balance, which can be withdrawn over Lightning, on-chain, or Ark whenever needed.

Beyond the checkout itself, the plugin is a fairly complete wallet in its own right:

• Dashboard widgets for at-a-glance on-chain and off-chain activity.
• Full send and receive pages, including optional destination verification.
• Automated wallet maintenance via Barkd, the reference wallet daemon, which keeps the store’s Ark balance refreshed in the background.
• Refresh controls — auto-refresh near expiry to keep it free, or refresh on receipt for a small fee and extra security.
• A VTXO management page for advanced users to inspect, refresh, offboard, or exit individual VTXOs.
• Recovery-phrase backup and restore, so a fresh BTCPay install can recover the store’s balance if the server dies.
• An emergency exit function, letting the plugin independently reclaim the store’s entire off-chain balance on-chain, without needing the Ark server’s cooperation — the self-custody guarantee that makes the whole model work.

Bark-enabled wallets: who gets free Ark payments

Any Lightning wallet can pay a Bark-powered BTCPay checkout over Lightning, for the usual routing fee. But customers using a Bark-enabled wallet get free Ark payments directly into the merchant’s balance. Wallets built with Bark include:

• Noah
• Arké
• Satsigner
• Cypher Box
• Ibis

Trade-offs to weigh before installing

Ark’s design trades some of Lightning’s assumptions for simpler onboarding, and that trade-off is worth understanding before relying on it for a business:

• Out-of-round payments rely on the Ark server acting honestly. Arkoor payments are cosigned by the Ark server, and the trust model assumes the sender and server won’t collude to double-spend before the receiver refreshes the VTXO into the next round. Refreshing promptly reduces this exposure window.
• A single Ark server is a coordination point, even though it never holds custody. Users can always exit to an on-chain UTXO independently, but that exit still depends on broadcasting a specific tree of transactions correctly and on time.
• The plugin requires a self-hosted BTCPay Server, not the hosted version, running version 2.4.4 or later.
• It’s a young piece of software. The plugin only reached what its developers call production-readiness at version 0.9.2 in September 2026, having launched on bitcoin mainnet just three months earlier, in June 2026.

How to install it

1. Make sure your store runs a self-hosted BTCPay Server on version 2.4.4 or later.
2. Install the plugin from the BTCPay Plugin Builder, or follow Second’s step-by-step setup guide.
3. Enable it on your store and confirm the unified QR code appears at checkout.
4. For support, use Second’s community forum or community chat.

For businesses already tracking bitcoin’s price to reconcile sales or set product pricing, Bitcoin Utility Tools’ price tracker is a free way to watch live prices alongside a Lightning- and Ark-enabled checkout.

Sources

1. Neil Woodfine, “Accept Lightning on BTCPay without running a node”, Second blog (September 24, 2026) — plugin features, requirements, and credit to James Bitcoin Bond for contributions to the plugin.
2. Ark Protocol — official technical overview of VTXOs, rounds, connectors, and out-of-round (arkoor) payments.
3. Steven Roose, “Bark now on bitcoin mainnet”, Second blog (May 21, 2026).