Bark: Self-custodial bitcoin payments without head-aches — Steven Roose | bitcoin++ Berlin, pay...

Summary

Steven Roose presents Bark, Second’s software built around the Ark protocol (rendered as “Arc” in parts of the subtitles). Its goal is to make Bitcoin payments easier while letting users retain control of their funds, rather than relying on a custodian that can freeze funds or require users to provide identity information.

Why Bark Is Being Developed

Roose argues that self-custody is relatively straightforward for on-chain Bitcoin but has been difficult for fast, small off-chain payments. He contrasts Bark’s approach with the Lightning setup commonly required by merchants:

• Merchants may need to choose and configure a Lightning node implementation, such as Eclair, LND, or Core Lightning.
• To receive payments, merchants need channels with enough incoming liquidity. Opening a channel puts funds on the merchant’s side, which does not by itself provide the capacity to receive.
• Merchants may need to buy incoming liquidity through services such as Pool or other providers. Roose notes that Pool and Loop are tied to LND.
• As liquidity is used up, submarine swaps or other rebalancing steps may be needed. Lightning Service Providers (LSPs) can simplify setup, but may require on-chain transactions and decide how much liquidity to reserve for each user. Roose says this reserved liquidity can be costly or sit unused.

Bark and the Ark Approach

Bark is presented as a way to use Ark-backed payments without configuring nodes or managing Lightning channels. Its main features, as described in the talk, include:

• Shared liquidity: The server pools liquidity and allocates it across users as needed, rather than reserving a separate channel for each user.
• Off-chain payments: Users can receive Ark or Lightning payments without first making an on-chain transaction. They can also send on-chain payments from an off-chain balance.
• More predictable fees: Roose says users do not need to rebalance channels or face additional on-chain costs when their incoming capacity runs out.
• Self-custody and exit options: Users can withdraw through a cooperating server or use a slower, more complicated unilateral exit if the server is unavailable or uncooperative.
• Periodic wallet maintenance: The wallet needs periodic activity to preserve self-custody under the protocol. Bark’s SDK is intended to perform this maintenance automatically when the wallet is running.

Products and Developer Tools

• BitPay plugin: Second built a plugin that lets a BitPay installation accept Ark and Lightning payments. Roose describes setup as a one-click process, without choosing a Lightning node, opening channels, or managing liquidity. Payments appear in a common balance.
• SDK: The open-source SDK is written in Rust, with bindings for Dart, Kotlin, Swift, Go, and TypeScript. Developers can use it to add wallet functionality to apps and backend services.
• Payment support: The SDK can create Bolt 11 invoices and handle payment methods including Bolt 12, Lightning URLs, and Lightning addresses. It can also send to on-chain Bitcoin addresses from an off-chain balance and send or receive native Ark payments. Roose says payments between Ark wallets can fall back to a direct Ark payment, avoiding Lightning routing fees.
• Other utilities: The SDK includes payment-request and QR-code utilities that can compare available payment options by fee.
• barkd: A standalone daemon for backend systems, with a REST interface and an integrated web interface. It can connect to Bitcoin Core or a public mempool service. The talk also mentions integrations for Umbrel and Start9.

Roose says Bark is open source and that external developers have adapted it, including through a fork with threshold-signing support. He points developers to second.tech/docs for documentation.

Audience Discussion and Limitations

In response to criticism that merchants can replenish incoming liquidity simply by spending from a channel, Roose agrees that spending can help. However, merchants may not spend their receipts quickly, or may have no suitable Bitcoin spending opportunities. He says Bark is aimed at merchants and users who want a service to simplify payments without taking custody of their funds.

Asked what most limits adoption, he says the main obstacle is currently demand and user experience, rather than missing technology. Bitcoin payments need to feel reliable and straightforward, and developers and designers need to build polished applications on top of the available tools.

The discussion also highlights the downside of unilateral exit: it can require several on-chain transactions, may take days, and requires on-chain funds to pay fees. Some wallets may keep a separate on-chain reserve or hide the emergency process until needed. Roose distinguishes this emergency exit from a normal withdrawal through a cooperative server, which he says is intended to be simpler and faster.

Guides, Tutorials, and Reviews

• Guides and documentation discussed: BitPay’s Lightning integration documentation; documentation for Lightning implementations and liquidity tools such as Pool; and Bark’s developer documentation at second.tech/docs.
• Tutorial or review: No formal product review or step-by-step tutorial is presented. The BitPay plugin is demonstrated as a simple setup, and Roose describes how developers can use the SDK and barkd.

Main Speakers and Sources

• Steven Roose — presenter, discussing Bark, Ark, and Second’s products.
• Audience members — ask questions about LSPs, adoption, and unilateral exits.
• Moderator — facilitates the audience Q&A.
• Other talks referenced: Eric’s presentation is mentioned in the adoption discussion, and Color’s presentation is referenced in connection with an open-source fork.