The Ark protocol is an alternative scaling solution that offers different trade-offs than the Lightning Network. Like the Lightning Network, Ark offers multiple implementations to choose from, and as a developer, you can pick the one that fits your needs and gives your users the best experience.
Bark is Second’s implementation of the Ark protocol, a Bitcoin layer-two system built to make self-custodial payments easy. Second launched it on Bitcoin mainnet on 9 June 2026, with a public server anyone can connect to.
The pitch from CEO Steven Roose is that Bark should make it “ridiculously easy” to hold and spend bitcoin you control, without surprise fees and without managing channels or liquidity.
That sentence points to the problem Bark wants to tackle.
Self-custody on Bitcoin has long come with a trade-off.
On-chain payments are slow and costly, while Lightning requires channels, inbound liquidity, and usually an always-online node.
Many people end up on custodial apps because they are simpler.
Bark aims to offer custodial-style simplicity while keeping the keys with the user. You manage your keys; you offload the UTXO management to an operator- in this case, one run by Second- but there could be multiple operators available for you to switch to or maintain balances with, should the ecosystem grow.
For the penny-pinching pleb, fees are the primary concern, and many would consider giving up some ownership of their coins to save on fees. While Lightning is cheap once you’re onboarded, those costs don’t show up on your Lightning invoices.
The cost comes from opening and closing channels, rebalancing channels, and maintaining a constantly live node; this could be a cloud node (with monthly fees) or your own node, which requires upfront costs and expertise.
The average person is not going to sign up for that, especially if they only wish to receive and send a few dollars’ worth of value; they want an app that works like a modern banking app, and this is the market Bark wants to target: the average consumer who wants a Bitcoin wallet.
How Bark Works
Bark runs on the Ark protocol, where many users share on-chain UTXOs through trees of pre-signed, off-chain transactions. Fees are spread across participants, while each person keeps control of their own share.
- VTXOs. Your balance is held as virtual UTXOs. A VTXO is an output that hasn’t been published on-chain but could be. Second’s documentation describes it as a series of pre-signed transactions that can take you from the shared on-chain output to your own coins. Bark’s wallet checks that it holds those pre-signed transactions before registering an incoming payment, so you never see funds you couldn’t exit with on your own.
- Client and server. Bark has three main pieces: the wallet (bark), the Ark server (captaind), and a set of libraries holding the protocol primitives. Second runs the public mainnet server, and anyone can point a wallet at it. Because it is a client-server design rather than a peer-to-peer network, integration is simpler than with Lightning.
- Rounds and refreshes. The server coordinates periodic rounds in which wallets swap old VTXOs for fresh ones. On mainnet, refresh rounds run roughly hourly. VTXOs have a built-in lifetime of around 30 days, and wallets must refresh them before they expire.
- Arkoor payments. Second’s design includes “arkoor” (out-of-round) transactions, so payments between Ark users happen instantly, without waiting for a round. The receiver temporarily trusts that the sender and the server won’t collude to double-spend. If either is honest, the payment is secure, and the receiver can refresh the coins in the next round to restore the standard trust model.
- One balance, three networks. A Bark balance can be sent to Ark, Lightning and on-chain destinations. The SDK handles payment requests, including BIP-321 URIs, so you can receive a single payment string across all three. Lightning payments work through a bridge that lets users pay invoices straight from an Ark balance with no channel management, no hosted channels, liquidity, or LSP required. Moving money on-chain means paying any on-chain address, which is broadcast in the next round.
- Exits. If the server disappears or refuses to cooperate, you can broadcast your pre-signed transactions and exit unilaterally, though this costs on-chain fees and takes time.
- Covenant-less design. The original Ark proposal leaned on covenants, which Bitcoin doesn’t have. Bark implements what’s known as covenant-less Ark, using pre-signed transactions and MuSig2 collaborative signing. Second says the design is forward-compatible, so Bark could benefit from OP_CHECKTEMPLATEVERIFY if it ever activates.
- The tooling. Developers get the Bark SDK, written in Rust with bindings for Kotlin, Swift, React Native, Flutter, Go, Python and WebAssembly. For servers, Second ships Barkd, a wallet daemon that exposes a local REST API with an OpenAPI spec. Second positions it for self-hosted node platforms such as Umbrel and Start9, webshops, exchanges that manage deposits and withdrawals, payment processors, and backends that automate payouts. Typed clients are available for TypeScript, C# and Python.
- The Trade-Offs
- Bark’s simplicity comes from design choices that carry real costs.
- You depend on the server. Payments, refreshes and round participation all go through the Ark server. If it goes offline, you are limited to a unilateral exit. That is a safety net, but it is slower and more expensive than normal use. Second currently runs the public mainnet server, so it’s a single point of failure.
- Expiry and refreshing. Coins expire. If a wallet is offline too long and misses its refresh window, the server can, in theory, claim the on-chain funds backing it. Second’s forum notes that the planned mitigation is for the server to re-issue expired VTXOs automatically, but wallets still need to stay on top of renewals. Third-party developers report that Second’s server charges nothing to refresh coins close to expiry, and 2,000 to 5,000 parts per million if they have plenty of life left, which discourages needless churn.
- Dust and small balances. Second has said that amounts under 330 sats can’t propagate on Bitcoin’s relay network, so they can’t be redeemed on-chain. Funds that small are not protected if the server disappears. Your wallet consolidates them automatically once you hold more than that.
- Arkoor trust. Instant payments carry the temporary trust assumption described above. It is narrow, but it is a step down from a fully settled transaction until the next refresh.
- Backups are more involved. Recovery needs the recovery phrase and wallet database backups. Per-VTXO state is stored on the device, though a unified mailbox shipped in February 2026 helps wallets recover VTXOs from the server.
- It is young. Earlier Bark releases carried explicit warnings that the code was experimental and that updating could corrupt a wallet. Second launched on mainnet with a “start small” message. Check the current release notes before putting meaningful sums in.
Bark vs Arkade
Both Bark and Ark Labs’ Arkade are live on mainnet, and both implement Ark. They are separate systems, and the architecture does not require interoperability. Payments between users of different implementations would typically route over Lightning.
A March 2026 proposal called V-PACK aims to give both a neutral format for verifying and backing up VTXOs.
| Bark (Second) | Arkade (Ark Labs) | |
|---|---|---|
| Focus | Simple self-custodial bitcoin payments and Lightning interoperability | A programmable platform: assets, swaps, contracts |
| Fast payments | Arkoor transactions | Virtual mempool |
| Server | captaind | arkd |
| Extras | Barkd daemon, BTCPay plugin, Umbrel app | Arkade Assets, Arkade Script, Intents |
| Mainnet launch | 9 June 2026 | Public opening October 2025 |
As Bitfinex’s July 2026 overview put it, Arkade is exploring assets, swaps and more complex financial applications, while Second is refining Bark around self-custodial bitcoin payments. If you want a wallet that sends and receives bitcoin, Bark’s approach is narrower and more payment-focused.
If you are building financial products with assets and contracts, Arkade is where that work is happening.
Bark is Bitcoin-only
While Arkade looks to be a general-purpose settlement layer through the Arkade Assets Framework, Arkade Bitcoin’s Virtual Transaction Output (VTXO) virtualisation model supports multiple token types—such as fiat-backed stablecoins; Bark looks to remain Bitcoin-only.
Who Is Using Bark?
At launch, several applications were mainnet-enabled:
- Noah, a full-stack mobile Ark wallet with a React Native frontend and a Rust backend.
- Arke, a design-led native iOS wallet built on open-source UX principles from bitcoin.design.
- Satsigner, which brings Sparrow-style UTXO management and multisig workflows to mobile.
- Bark Wallet, an Umbrel app supporting Ark, Lightning and on-chain payments, built by Second.
- A BTCPay Server plugin, also by Second, that lets merchants accept self-custodial Lightning payments without opening channels or managing liquidity.
Outside Second’s own tools, ArkPool, a small Bitaxe mining pool in alpha, uses Bark to pay out miners over Ark. Since the ecosystem is still in its early days, the only other application I found was a blast rehashing of Satoshi Dice now running on Bark.
Who Funds Second?
Second is a Bitcoin development lab founded by former Blockstream executives. CEO Steven Roose and CTO Erik De Smedt are both ex-Blockstream, as is CMO Neil Woodfine, and the team has drawn in other former Blockstream engineers.
According to Bitcoin Magazine, Second has raised $5.1 million from a single private investor and operates with a team of 11. The investor’s identity isn’t disclosed in any of the sources I found, and Second describes itself as a development lab rather than a venture-backed startup with a conventional cap table.
That matters, since a small team with one backer has a limited runway, and the long-term question for any project like this is how the Ark server is funded once the initial capital is spent.
Fees from refreshes and services are the obvious source, but I couldn’t find a revenue model Second has published.
Barking Up An Ark Tree
Bark tries to make key ownership self-custody feel as easy as a custodial app by moving liquidity management onto a server while keeping a pre-signed exit path in users’ hands. It works today, with wallets, a merchant plugin and an SDK, and it is available to anyone.
The costs include server dependence, regular refreshes, awkward small balances, and the risks of early software. For people who find Lightning too heavy but don’t want to give up their keys, that may be a fair trade, provided they start small.
As your balances and volumes grow, your confidence and exposure to Bark might change, and trade-offs you were happy with moving satoshis might not work for holding thousands or millions of sats. If you don’t like these trade-offs, you can always head back to on-chain or move to Lightning, where you have more control over your UTXOs.
Do your own research.
If you want to learn more about the Bark, use this article as a starting point. Don’t trust what we say as the final word. Take the time to research other sources, starting with the resources below.
Sources:
- Second’s documentation (second.tech/docs, including barkd) and launch blog post;
- Bitcoin Magazine (9 June 2026, and its earlier interview with Second);
- Bitfinex Blog (24 July 2026);
