Two Bark releases in two days...we hope you'll understand given the emerging security environment in bitcoin. 0.6.0 has some breaking changes you're going to want to pay attention to: it's required to continue support for refreshes and Lightning payments, so please get updated asap. We know this may be a disruptive update, so let us know if we can help. And thanks to Philipp Hoenisch of Lendasat for the report behind a fix. Full changelog:

Second Docs

Changelog - Second Docs

Updates to Bark, our implementation of the Ark protocol. Including the SDK, wallet, server, and developer tools.

Bark 0.5.0 is out, and it delivers one of our most requested features. A wallet's full off-chain balance can now be restored from its mnemonic alone, retrieved from the server. Lightning receives can now land on external Ark addresses, unlocking non-custodial Lightning address servers (thanks to Ben Carman for this work), and delegated refreshes can be scheduled ahead of time, when they're cheaper. Note that boarding now requires bark 0.5.0, so upgrade your clients to keep boarding. Full changelog:

Second Docs

Changelog - Second Docs

Updates to Bark, our implementation of the Ark protocol. Including the SDK, wallet, server, and developer tools.

@npub1kuc7...0eyw has put together a walkthrough of how he presents emergency exits to users ("forced move") in Arké. He's a master of user-friendly bitcoin UX, so there are valuable tips for anyone building Bark into their app.

We've been doing some research on client-side Lightning pathfinding for Bark wallet apps. Instead of the Ark server working out the best payment route on the user's behalf, the wallet app builds the route and the payment onion itself, so the destination is not shared with the server and potentially eliminating minimum fees on Lightning transactions. Full findings, link to proof of concept, and areas for further research:

Second

Teaching Bark to find its own way through Lightning | Second Blog

Up until now, wallet apps built on Bark didn’t handle their own Lightning pathfinding. Instead, the wallet app would send the BOLT11 invoice, amo...

Bark 0.4.0 is out, and receiving just got simpler: one BIP 321 payment request covers Ark, Lightning, and on-chain, built in a single barkd call or straight from the SDK. Also in this release: fee quotes for on-chain payments before you send, wallet notifications without a websocket, control over exactly which VTXOs a payment spends, and crash safety across every payment operation. Full changelog:

Second Docs

Changelog - Second Docs

Updates to Bark, our implementation of the Ark protocol. Including the SDK, wallet, server, and developer tools.

Since launching on mainnet, we've been hard at work refining Bark's DX and UX, guided by all the feedback we've been getting from early integrators and users. Some of the highlights from releases 0.2.3 to 0.3.0: Bark now pays LNURL links anywhere it accepts a Lightning address, you can run barkd as a containerized web app to back browser-based wallets, and wallet setup is simpler with one consistent flow and per-platform storage defaults. Your bitcoin also stays liquid mid-exit: an Ark balance can be spent right up until your emergency exit's leaf transaction is confirmed on-chain (spending quietly cancels the ongoing exit). Lots more changes at:

Second Docs

Changelog - Second Docs

Updates to Bark, our implementation of the Ark protocol. Including the SDK, wallet, server, and developer tools.

Bark is now a Lightning backend option in Alby Hub—enabling self-custodial Lightning payments for all your connected wallets with no Lightning node, channels, or liquidity to manage. The integration enables Bark across all NWC-enabled apps like Alby Go, Zeus, and Damus, and even agents like Claude and GPT. More details:

Second

Now you can power your Alby Hub payments with Bark | Second Blog

Alby Hub lets you connect all your wallet apps to a single payment backend. It takes care of most wallet operations for you, but managing the Light...

Bark Wallet is now on the Umbrel app store. It's a simple, self-custodial bitcoin wallet covering the complete Bark experience: send and receive over Ark, Lightning, and on-chain, with automated refreshes, an emergency exit, and no channel and liquidity management. It's also open source, a great foundation for your next wallet app project! Learn more about what Bark Wallet can do and how it was built:

Second

Bark Wallet now available on Umbrel | Second Blog

Bark Wallet hit the Umbrel app store on the same day as our mainnet launch. A number of adventurous users have already installed it and started mak...

Bark went live with wallet apps ready to go on day one, built by bitcoiners who'd been working alongside us since long before launch. Noah, from the team behind Blixt, is the Ark wallet you'd expect from self-custodial wallet veterans, including some fancy Ark-infused Lightning addresses for static, free, offline payments. iOS and Android. Arké, from Christoph Ono, leverages years of the Bitcoin Design Community's open-source UX work, and pioneers brand-new UX for Ark. iOS only. Both apps are open source and available today. Full write-up:

Second

Introducing Noah and Arké: Two new Bark-based wallets | Second Blog

We

SECOND IS NOW ON MAINNET. Bark, our implementation of the Ark protocol, is available for anyone to start making bitcoin payments. Included in the launch are our mainnet Ark server, the Bark SDK, and multiple wallets to try from day one. More details, and our vision for bitcoin payments, from Steven Roose: blog.second.tech/bark-now-on-bitcoin-mainnet/

Recent Bark releases 0.1.4, 0.2.0, and 0.2.1 have been packed with updates. The highlights: Slim VTXO storage cuts wallet memory use 20–100x, real-time notifications replace polling so wallets update the instant something happens, and a single payment request now bundles Ark, Lightning, and on-chain into one QR. And to ensure Bark slots nicely into existing stacks, emergency exits and boarding can now both be driven by an external on-chain wallet with its own signer. Full changelog: second.tech/docs/changelog

Nested MuSig2 now has a Python reference implementation. Beulah Evanjalin built it on secp256k1lab with tests, examples, and protocol notes—generally in a good state for review and discussion. This is the blueprint that will inform the secp256k1-based C work.

GitHub

GitHub - BEULAHEVANJALIN/nested-musig2-python: Nested MuSig2 reference implementation in Python over secp256k1, built on secp256k1lab, with tests, examples, and protocol notes, intended for study, testing, and review of the construction.

Nested MuSig2 reference implementation in Python over secp256k1, built on secp256k1lab, with tests, examples, and protocol notes, intended for stud...

Barkd is what you run when you want to enable bitcoin payments server-side. On a standard cloud VM, the provider, hypervisor, and co-tenants can theoretically read your signing keys from memory. We decided to run some tests to see if TEEs were the solution. Intel SGX was a dead end. AWS Nitro Enclaves worked but needed excessive custom plumbing. Azure's confidential VMs seemed to be the sweet spot, achieving the convenience of a hosted wallet while minimizing trust in the host.

Second

Running Barkd in a TEE: Hardware-protected keys in the cloud | Second Blog

Barkd is what you run when you want to enable bitcoin payments server-side. It

New page up: a directory of wallets building on Bark. Most are open source, so you can see how teams are handling the Bark SDK and Barkd to deliver bitcoin payments over Lightning, Ark, and on-chain.

Second Docs

Built with Bark - Second Docs

Real apps shipping bitcoin payments on Ark, Lightning, and on-chain. Built by teams using the Bark SDK and Barkd.

Small but mighty changelog for 0.1.3. Bark now ships an IndexedDB StorageAdaptor—the missing piece for browser-based wallets. Combined with the WASM and gRPC-web support from 0.1.0, you can now build Ark wallets that run entirely in the browser with persistent state. Bark can now also connect to access-controlled Ark servers via bearer tokens. You know what this means. 😉 Full release notes available at the usual place: second.tech/docs/changelog

Double changelog today for bark-0.1.0 (you know we’re getting closer to mainnet when the “beta” tag is dropped!). Highlights include event-driven notifications replacing polling, a fee estimation API for all operation types, Tor connectivity, barkd security hardening with auth tokens and CORS, HTLC preimage recovery from on-chain exits, and WASM compilation for browser-based Ark wallets. Full changelog: second.tech/docs/changelog

Nice one AJ Towns. Your signet reorg simulations caught a nasty bug lurking in unusually deep reorgs. Thank you for passively torturing our code with edge cases 👍

"This was a genuinely fun build. The Bark integration was way smoother than I expected going in. Being able to accept Lightning payments without running my own node, and having native Ark payments work alongside that, made the whole payment layer surprisingly simple to wire up." - PiHiker, ArkAPI dev Cool new project for charging for API calls:

Second Community

ArkAPI: a pay-per-call API gateway with Lightning and native Ark payments, built on Bark and live on Signet

Hey all! I wanted to share a project I’ve been building. ArkAPI is a pay-per-call API gateway live on Signet where sessions are funded via Bark....

We caught a capacity overflow bug in Bark before it ever hit a user—thanks to the fuzz testing @luca0x46 has been running around the clock. A malformed VTXO could have requested an arbitrary vec size during deserialization, triggering a panic. Now it's patched. Bark's client-server architecture means the server has to gracefully handle anything thrown at it—malformed VTXOs, malicious client requests, unexpected edge cases. Fuzzing helps make sure the server stays up and keeps serving rounds no matter what comes in. The vec allocation bug is a good example of something easy to miss in review—stable Rust doesn't yet support try_with_capacity, so the bounds check has to be done manually. Our first fuzz target was a straightforward deserialize/serialize pass, and it surfaced the issue immediately. The fuzzer runs 24/7 now, with minimized corpora pushed to our bark-qa repo alongside test vectors used throughout Bark's development. More targets coming—serialization/deserialization expansions first, then method-level fuzz targets. Full writeup:

Second

Fuzzing Bark for server reliability | Second Blog

Ark users are always in control of their bitcoin. They can perform an emergency exit to get back on-chain whenever they need to. But Bark is a clie...

Bark's Rust API docs are live on docs(dot)rs. `Wallet` is the central entry point—create, sync, inspect VTXOs, pay Lightning invoices, refresh in rounds, exit unilaterally. All from one struct.