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 blog

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

Barkd is what you run when you want to enable bitcoin payments server-side. It's our reference daemon wallet: a single binary that runs alongside y...

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 blog

Fuzzing Bark for server reliability

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.

It's probably going to be a process of trial and error to find the optimal refresh strategy for users on Ark. Bark lets each wallet dev implement their own VTXO refresh strategy—set when VTXOs should be auto-refreshed based on expiry, size, or exit cost:

One-of-a-kind app onboarding from @Christoph Ono. Love it.

Bark's `Wallet` struct is the single entry point for Ark, Lightning, and on-chain payments. Create one with a mnemonic + sqlite + server URL and you're transacting.

The liquidity fee model in Ark is time-based: refreshing a VTXO costs more the further it is from expiry. This creates natural incentives to refresh closer to deadline rather than early.

On-chain payments on Bark no longer happen in rounds. They're now instant, kind of like Ark-to-onchain swaps. This makes them more expensive than before, but the upside is that they're now broadcast immediately (more intuitive UX).

Generating Ark addresses offline is now feasible with persisted server pubkeys. No need to be connected to the Ark server just to produce a receive address.

Payments on Bark currently use a single input. Instead of multi-input txs, large txs bundle independent arkoor txs into a "package" sent to the receiver in one go. Wallet history shows it as a single incoming payment.

Small Rust API design lesson from Bark development: if your top-level functions are just thin wrappers around methods on a struct, they shouldn't exist. Put the logic where it belongs.

If you're building on the Bark library, Lightning payments are now `wallet.pay_lnaddr(..)` instead of standalone functions that take a wallet reference. Smaller surface, fewer surprises.

We're building a shared corpus repository for our fuzz targets. Every time the fuzzer runs, it builds up optimized inputs that make future runs more efficient—it doesn't start from zero each time. Over time this becomes an automatically growing collection of edge cases that doubles as regression testing.