Second

Update on Nested MuSig2: Beulah Evanjalin's proposal is now available as a BIP. It's going to enable lots of cool multisig and multi-device setups for Ark and Lightning wallets, plus more efficient Lightning channels inside Ark.

We'd appreciate any review we can get on this: https://github.com/bitcoin/bips/pull/2297

Flash meetup!

Payjoin boards are now available in Bark and enable a wallet app to receive a Payjoin and board onto Ark in the same transaction, saving the user fees and time. The same trick can also be used to on-ramp onto a Cashu mint running Bark, no channel management required. It may also be the first example of Transaction Cut-Through bitcoin has seen, a 13-year-old idea from Greg Maxwell!

More details on the blog: https://second.tech/blog/payjoin-boards-board-psbt/

We've released Bark 0.6.2. You can now use one call to pay anything: an Ark or on-chain address, any Lightning destination, or a multi-rail BIP 321 URI, with a fee estimate for each option when there's more than one way to pay. Bark can also now cosign a Payjoin-funded board, enabling boards from external wallets and some interesting Cashu interop. And big thanks to the bitcoin Red Team and Project Loupe for the responsible disclosures behind several of this release's fixes.

Full changelog: https://second.tech/docs/changelog

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: https://second.tech/docs/changelog

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: https://second.tech/docs/changelog

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: https://blog.second.tech/bark-client-side-pathfinding/

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: https://second.tech/docs/changelog

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: https://second.tech/docs/changelog

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: https://blog.second.tech/bark-powers-alby-hub/

Bark added in the latest Alby Hub release. Possibly the simplest way to add self-custodial Lightning to all your NWC-connected apps.

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: https://blog.second.tech/bark-wallet-now-on-umbrel/

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: https://blog.second.tech/introducing-noah-and-arke/

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/

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.

https://github.com/BEULAHEVANJALIN/nested-musig2-python

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.

https://blog.second.tech/running-barkd-in-a-tee/

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.

https://second.tech/docs/built-with-bark

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 👍

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: https://blog.second.tech/fuzzing-bark-for-server-reliability/

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

. Love it. https://blossom.primal.net/eb5db7b105d6617f17b54e0ad7e8ba26b9656769663a717235bd505b8645166a.mov

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.

1/ Getting honggfuzz running inside a Nix development shell was its own adventure. Nix's hardening flags conflict with how honggfuzz instruments binaries, and glibc version mismatches between NixOS and honggfuzz added another layer.

Fuzz testing throws massive volumes of random and malformed data at your code to find crashes that normal testing misses. @lucad70's been adding it to our QA process and it's already caught arithmetic overflows and unwrap panics that could crash the server. Fuzzing is pretty much a requirement when you're building protocol-level software.

Bitcoin scaling has two sides: transactions in blocks and UTXOs. Lightning scales transactions. Ark scales both.

We've redesigned how Bark-based wallets sync with the Ark server. The new unified mailbox replaces per-address polling with a single feed for all wallet notifications (Ark and Lightning payments, refreshes, and more) with support for real-time push subscriptions. One endpoint, checkpoint-based sync, and delegated notification auth for mobile. Available now in Bark.

Refreshes on Bark no longer use connectors for atomicity, that's now handled by good ol' hash-locks. Confusingly, on-chains payments now use connectors instead, which are no longer handled alongside refreshes!

Bark's new unified mailbox consolidates all wallet notifications into a single feed: Ark payments, Lightning preimages, BOLT-12 offers, and refresh completions. Checkpoint-based sync fetches only what's changed.

Taproot happened because Lightning proved the need for it. The best way to get covenants is for Ark to prove the need for them too.

We chose honggfuzz over libfuzzer for fuzz testing bark. libfuzzer is simpler to set up, but honggfuzz gives us more flexibility for complex targets down the road. And it's what rust-bitcoin uses, so we can borrow from their what they're doing!

The Ark protocol is not constrained by the need to standardize across implementations like Lightning. This means that each implementation is react fast to users' needs.

Ark's transaction trees feel exotic until you realize they're just cleverly arranged standard bitcoin transactions. No special opcodes needed. Just signatures, timelocks, and multisigs held off-chain.

We've released bark-0.1.0-beta.6 featuring hArk (Hash-lock Ark), a major protocol evolution that eliminates synchronous interactivity during rounds. Previously, all round participants had to be online simultaneously to sign intermediate transactions. hArk removes this requirement—the server generates a unique secret for each VTXO, and participants can claim asynchronously after signing a forfeit transaction.

This also enables efficient consolidation of multiple VTXOs into a single output and reduces server costs during malicious exit scenarios.

Note: Wallets created before this release require migration due to security upgrades with hardened key derivations. Create a new wallet and transfer funds before upgrading.

Lots more updates on the changelog: https://docs.second.tech/changelog/changelog

The Ark model of Lightning: Users hold "funds at rest" in VTXOs, then swap into Lightning channels via HTLCs to make payments.

Latest changelog for bark 0.1.0-beta.3 to beta.5 is out!

The biggest addition is barkd—a wallet daemon with RESTful API for node runners and businesses wanting simple automation. We've also made ark-lib WASM-compatible for web environments, replaced the arkoor-depth limitation with checkpoints, and improved Lightning payment reliability.

Full changelog: docs.second.tech/changelog/changelog

Added

to the team for DevRel. He showed up, immediately fixed up our faucet, and is already close to shipping a Bark web wallet. Also runs bitcoin education content in Portuguese and contributed to

+

. Welcome Carlos (follow him for updates!)

Before joining Second,

did stellar work with

on Lightning protocol development. Nice profile on his work below.

"Being a grantee at Btrust was, first and foremost, the best grantee experience I had throughout my grant-funded open source development career so far."

https://blog.btrust.tech/celebrating-duncan-deans-journey-with-btrust/

Rapid progress being made by

with his Bark-based Arké wallet, which now has an iOS companion under development to complement the macOS app.

Our software is all open source, with one conspicuous exception. We fixed that today (after a bit of spring cleaning!). The code for our signet faucet and test store is now available on GitLab!

https://gitlab.com/ark-bitcoin/faucet

https://blossom.primal.net/80b481e9020178b52a03938257b748577e94c610644dc8c4a1a00bd905091a9b.png https://blossom.primal.net/18360fb9e7f951507902a7b195b853a9b822acd3729662f5abf14aa79070e23c.png

We've been wanting nested MuSig for a while now, so we can distribute Ark server keys and improve security. The problem is, it's specialized cryptographic work that we probably don't have within the team.

Jesse Posner (Vora founder) approached us with a solution: fund a grant for Beulah Evangelin to build it. Beulah's already contributing to secp256k1-zkp, just finished Chaincode Labs' secp256k1 workshop, and is perfect for the job.

So we're funding the grant. Jesse/Vora will provide ongoing mentorship. And Beulah's nested MuSig implementation will go into libsecp256k1-zkp as open source, so any project can use it. It's going to be particularly valuable for layer 2s, e.g., Vora needs it for their Lightning implementation too.

Full details: https://blog.second.tech/nested-musig-grant/

Attack, attack!

We're hiring.

Like tinkering on bitcoin software? We need someone to help us build app prototypes and POCs on Bark. Non-stop "hackathons", publishing open-source, and posting your progress publicly.

Normally bitcoin companies need to be cautious with vibe coding. For this role, we want you to go nuts with it.

More details and application link at

: https://bitcoinerjobs.com/job/1975320-devrel-engineer-second

If you're in Mauritius for @Btrust's Dev Day tomorrow, don't miss @dunxen's session on how Bark makes adding self-custodial Lightning to your apps simple.

Another new project building on Bark. https://blossom.primal.net/6baa5c041d36d7ed474f71ceca2ed2b2f2611bbeab633a4d9b57085869f3b41b.png

https://github.com/HalFinneyIsMyHomeBoy/bark-wallet-frontend

Some really neat send payment UX going into

Arké wallet, based on some patterns established in

. By integrating with Bark, a wide range of payment formats are available immediately across Lightning, Ark, and on-chain.

Video demo of Arké's send page dynamically reacting to what's held in the clipboard—fewer clicks and less to think about for the user:

New updates from the Bark-based Arké wallet:

• Tight integration with macOS's Contacts app (handled locally and privately!).
• Improved tagging management UX
• Lots of design refinements across send and receive

Our goal isn't replacing Lightning. It's ensuring every bitcoin user can access Lightning without needing to become a node operator. Ark is the gateway—you hold a self-custodial balance, pay Lightning invoices when needed, no channel management required.

During a round, the Ark server + users construct a tx tree. Each leaf of the tree is controlled by a single user.

The root of the tree is broadcast on-chain (the round tx). Once confirmed, each user has verifiable assurance they can unilaterally retrieve their bitcoin on-chain.

We've released bark 0.1.0-beta.2—our second beta release. This update simplifies VTXO state management, enhances UX with immediate VTXO availability, and makes wallet integration easier with non-mutable API methods.

Note: The VTXO state simplification and BlockRef representation changes may require code updates if you're building on the bark API or CLI.

Highlights: VTXOs are now usable within the same round they're created (no more waiting!), VTXO states reduced from many to just three (Spendable, Locked, Spent), nearly all Wallet methods are now non-mutable for easier integration, Lightning receives are faster and more secure, and on-chain spends automatically refresh VTXOs by default.

Full changelog: docs.second.tech/changelog/changelog

Kept you waiting, huh?

(We're finally on Nostr)