iiinova — where your digital self keeps evolving

6/ The plugin runs on self-hosted BTCPay Server 2.4.4 or later, and special thanks go to James Bitcoin Bond for extensive contributions. Features, screenshots, and setup instructions are on the blog: second.tech/blog/bark-p...

000

5/ To give the plugin a proper showcase, we've also opened our own swag store. Pick up Second- and Bark-themed tees, hats, and more, and pay with Lightning or Ark through a BTCPay checkout running the plugin: store.second.tech/

A wall clock, a black zip hoodie, and a mug from the Second swag store, with the BTCPay payment option selected at checkout

110

4/ Receiving over Lightning is free, and with no inbound liquidity to worry about, you can receive payments, large and small, indefinitely. Customers using a Bark-enabled wallet app like Noah, Arké, Satsigner, Cypher Box, or Ibis get free Ark payments.

100

3/ With the Bark plugin, you don't need to worry about node ops, channels, or liquidity. Install the plugin, flick a toggle, and your store is immediately Lightning-enabled. Customers see one unified QR code offering on-chain, Lightning, and Ark.

BTCPay checkout on the Second swag store showing one unified QR code for on-chain, Lightning, and Ark payments

100

2/ Lightning has become the de facto bitcoin standard for retail payments. But traditionally, merchants running BTCPay-based checkouts had to manage a full Lightning node plus all its channels and liquidity, which is a big devops burden for most small business owners.

100

1/ The Bark plugin for BTCPay Server is now ready for production. It's possibly the simplest way for a business to take self-custodial bitcoin payments (especially Lightning) on their online store, and you don't need to run a Lightning node to do it.

Bark plugin for BTCPay Server: dashboard, send and receive pages, and settings screenshots

200

cdk-payment-processors/crates/bark at main · cashubtc/cdk-payment-processors

6/ On the Cashu side, the Payjoin extension to NUT-30 is a draft spec and thesimplekid's implementation is a draft in CDK. But mints don't need to wait for that to power their Lightning payments with Bark: github.com/cashubtc/cd...

github.com

Cashu Development Kit - Payment Processors. Contribute to cashubtc/cdk-payment-processors development by creating an account on GitHub.

100

5/ If you're building on Bark, the new primitive is board_psbt, which lets Bark board from a transaction it did not build. A board composes into an app built on PDK and BDK: PDK negotiates the Payjoin, BDK handles the sender's wallet, Bark cosigns the board.

100

4/ This gives Cashu mints an on-ramp with no channel management. The mint adds a Payjoin offer to its deposit quote, the user's wallet app pays it, and the mint's Bark backend swaps in the board output. One transaction, paid by the user, lands in the mint's Ark balance.

Illustrated dog trotting with a cashew nut in its mouth, representing a Cashu mint deposit boarding into an Ark.

100

3/ Dan Gould of Payjoin Dev Kit calls this the first example of "Transaction Cut-Through" bitcoin has seen: Greg Maxwell's 13-year-old idea to combine dependent transactions into one, saving time and fees, that awaited a standard way to coordinate. bitcointalk.org/index.php?t...

100

2/ Boarding used to take two transactions, one to reach the Bark wallet app and a second to board. With Payjoin boards, the first does both jobs: the sender pays over Payjoin v2, Bark swaps in the board output and cosigns it, and the sender's transaction lands the bitcoin on Ark.

100

Second @second.tech · 07/09/2026

1/ Payjoin boards have been available in Bark for a couple of weeks now, so we thought it was time to take a closer look at what they can do: boarding direct from external wallet apps, saving the user fees and time, and the same trick applied to on-ramping into Cashu mints.

Two illustrated dogs each leaping through an oval portal, one outlined in blue and one in orange.

100

3/ On the server side, watchmand is now a separate process, and operators can cap or switch off individual operations with per-action amount limits. There's plenty more, including breaking changes, so read the changelog before you upgrade: second.tech/docs/changelog

second.tech

Changelog - Second Docs

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

000

Second @second.tech · 07/09/2026

2/ Any Ark payments that are received and expire while offline are now retained and refreshed on wake. Bark also checks more of what the server sends it, both in rounds and on Lightning receives, before committing any bitcoin.

100

Second @second.tech · 07/09/2026

1/ It's hardening season. Bark 0.7.0 is all about improving security and reliability. There's nothing more important to be working on right now. Thanks again to Project Loupe and Greg Sanders for the disclosures behind several fixes.

A hand-drawn server rack with a riveted armour plate being bolted onto its side, representing a release that hardens Bark and the Ark server

100

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

7/ Lots more protocol hardening (thanks to the bitcoin Red Team and Project Loupe for the disclosures!) and breaking changes in this release, so you'll want to read the details: second.tech/docs/changelog

second.tech

Changelog - Second Docs

000

6/ Sign messages with an Ark address: a wallet app can sign with the key behind one of its addresses, and anyone can verify the signature statelessly against the address or public key, no wallet needed. Mobile-wallet backends can use it to authenticate their clients' requests.

100

5/ Bark will verify more of what the server sends before bitcoin moves: round results are checked for the expected server key, exit delta, and a safe expiry before Bark forfeits its inputs, and incoming payments must be final, self-custodial VTXOs from the right server.

100

4/ You can now estimate what an emergency exit will cost before committing to one, and whether the wallet's confirmed on-chain balance covers the up-front broadcast fees. It's available across the SDK, CLI, and REST API.

100

3/ Payjoin boards: Bark can now cosign a board funded by a transaction someone else builds and broadcasts, so a Payjoin-capable wallet app can fund the board directly and save the user an on-chain transaction. It also opens up interoperability with Cashu mints (watch the blog).

100

2/ Better high-frequency payments. Rapid successive payments used to build long chains of change, hitting the server's depth limit and forcing a refresh of the whole wallet. Change now splits in two when it exceeds the amount paid, and input selection skips VTXOs at the limit.

100

1/ Bark 0.6.2 is out. One call can now pay whatever a user wants to pay: an Ark or on-chain address, any Lightning destination, or a multi-rail BIP 321 URI. When a destination can be paid more than one way, Bark lists each option with a fee estimate.

A hand-drawn shape-sorter box with one hole that a lightning bolt, a pyramid, and a ball all fit through, representing one payment call that pays any destination

100

5/ Also new: a `max_ln_receive_amount` server config caps individual Lightning receives (checked at invoice time, so nobody's left holding an unclaimable payment), and barkd's REST API gains CLI parity: `force` on wallet create, `token` on invoice generation.

100

4/ On-chain transactions now get a 30-second grace period after signing, so a wallet sync can't treat one as dropped before it reaches the mempool. That window used to hand a board's inputs back to coin selection, double-spending your own transaction.

100

3/ Depth limits no longer strand Lightning payments. Claims and revocations are now exempt from the VTXO exit-depth cap, and the pool stops its change chain growing. Previously a receive could land too deep to claim, with an emergency exit the only way out.

100

2/ Version 0.6.0 is required to continue support for refreshes and Lightning payments. Lightning HTLC and hArk round scripts now check the preimage is 32 bytes, matching Lightning's on-chain check. We know this may be a disruptive update, so let us know if we can help.

100

1/ Two 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, please get updated asap. And thanks to @bonomat of Lendasat for the report behind a fix.

100

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

5/ Bitcoin's security environment is heating up, so 0.5.0 puts a heavy focus on hardening across the server and wallet. Thanks @0xaudron, @benthecarman, and @theinstagibbs for testing that led to several of this release's fixes. Full changelog: second.tech/docs/changelog

second.tech

Changelog - Second Docs

000

4/ Delegated refreshes can now be scheduled for a future block height instead of joining the next round. Scheduling ahead is cheaper, since the liquidity fee for a refresh falls as a VTXO nears expiry and the server prices it at the scheduled height.

100

3/ Lightning receives can now land on external Ark addresses. A wallet claims an incoming payment for another wallet, so the recipient gets paid while offline and the forwarder never has custody. That unlocks non-custodial Lightning address servers. Thanks @benthecarman!

100

2/ Your wallet keeps a record of its VTXOs in a mailbox on the server that only your mnemonic can unlock. A restore pulls that record back and checks every VTXO before accepting it. Existing wallets are covered from their first sync on 0.5.0.

100

1/ Bark 0.5.0 is out, and it comes with one of the features you've asked for most: restoring a wallet's full off-chain balance from its mnemonic.

100

4/ You use the app from your browser, but it runs on barkd, our wallet daemon. If you're thinking about building on barkd, Bark Wallet is a working reference for how our team would approach a wallet app. Take inspiration from it, or just fork it!

100

3/ The StartOS build of Bark Wallet ships with its own continuous backup system, credit to Matt Hill for building this! After every change in wallet state, it ships an encrypted snapshot to the backup targets of your choice: Google Drive, Dropbox, Nextcloud, or SFTP.

100

2/ If you're new to it, Bark Wallet is an open-source wallet app from the Second team. Send and receive payments over Ark, Lightning, and on-chain, with no channels and no liquidity management. You can receive Lightning payments the second you set up a wallet.

100

1/ We got a lot of requests for Bark Wallet on Start9 after launching on Umbrel last month. Well, here it is: Bark Wallet is now available on the Start9 Registry!

100

7/ One other huge benefit client-side pathfinding may unlock: removing Bark's minimum 20-sat fee on Lightning transactions, good news for microtransactions. Full findings and areas for further research are on the blog: blog.second.tech/bark-client...

010

6/ grubles' proof of concept is available for testing and runs end-to-end on regtest for multi-hop routes: gitlab.com/grubles/bar...

100

5/ If they're building their own route, wallet apps will also require a gossip map. This is where another LDK feature comes in: the Rapid Gossip Sync server. This serves compact snapshots on-demand, with delta updates that cut sync time to a handful of milliseconds.

100

4/ Because the onion is built by the client, the gateway is blinded to what's inside it. The destination, the full route, the hop count, and the precise amount live only inside the onion. The gateway turns into a dumb onion relay: it just ships what your Bark wallet hands it.

100

3/ LDK's pathfinding component proved to be just the thing we needed. Bark can run the pathfinding with the gateway's node ID as the source, pull the destination, amount, and route hints out of the invoice, and build the payment onion as though the gateway were the sender.

100

2/ The challenge: a Bark wallet isn't a Lightning node. It has no channels. When you make a Lightning payment, the link to the Lightning Network is an HTLC VTXO cosigned with the Ark server, and it's the server that maintains channels with the wider network.

100

1/ Wallet apps built on Bark have never done their own Lightning pathfinding: the Ark server works out the best path on their behalf. It works great, but some users want more control, or don't want to share destination data. New research from grubles explores an alternative.

111

6/ Plus: crash safety now covers every payment operation and barkd wallet files are locked down on shared machines. There are breaking changes for integrators, so check the changelog before upgrading: second.tech/docs/changelog

000