> ## Documentation Index
> Fetch the complete documentation index at: https://second.tech/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Changelog

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

#### Update categories

<div className="changelog-key">
  <Icon icon="mobile-screen-button" size={14} /> Wallet    <Icon icon="server" size={14} /> Server    <Icon icon="gear" size={14} /> Protocol    <Icon icon="code-branch" size={14} /> Upstream
</div>

***

<Update
  label="20 July 2026"
  description="0.4.0"
  rss={{
title: "0.4.0 - 20 July 2026",
description: "One BIP 321 payment request spanning Ark, Lightning, and on-chain; wallet notifications without a websocket; a single trait for on-chain wallet integration; and crash safety completed across bark's payment operations."
}}
>
  <img src="https://mintcdn.com/second-0659a37d/nxUUZpMRXA-Zuljp/images/bip321-qr-card-light.svg?fit=max&auto=format&n=nxUUZpMRXA-Zuljp&q=85&s=37e4a8f317806c857239ae8d30632c9a" alt="A payment card showing a single QR code with chain, Lightning, and Ark icons beneath it, representing one payment request covering on-chain, Lightning, and Ark" className="block dark:hidden" width="1920" height="1080" data-path="images/bip321-qr-card-light.svg" />

  <img src="https://mintcdn.com/second-0659a37d/nxUUZpMRXA-Zuljp/images/bip321-qr-card-dark.svg?fit=max&auto=format&n=nxUUZpMRXA-Zuljp&q=85&s=3fe81c5a9399a613d32df85116a3f580" alt="A payment card showing a single QR code with chain, Lightning, and Ark icons beneath it, representing one payment request covering on-chain, Lightning, and Ark" className="hidden dark:block" width="1920" height="1080" data-path="images/bip321-qr-card-dark.svg" />

  <Warning>
    **Breaking changes**

    * **[On-chain wallet integration](#one-trait-for-on-chain-wallets):** a single `OnchainWalletTrait` replaces the previous trait set, and board and daemon calls drop their `onchain` argument.
    * **[Exit APIs](#cancel-an-emergency-exit-before-it-commits):** `ExitState` and `ExitError` gain variants, and status listings split into live and finished.
    * **[Custom persisters](#crash-safe-offboards-and-on-chain-sends):** `BarkPersister` gains required methods; the pending-offboard methods are removed.
    * **[Crash-safe Lightning receives](#crash-safe-lightning-receives):** the receive-status API is reshaped and the receive token moves to invoice generation.
  </Warning>

  ### <Icon icon="mobile-screen-button" /> One payment request for every rail

  Bark can now build a single BIP 321 payment request that a payer's wallet app can pay over whichever rail it supports. One string or QR code always carries a fresh Ark address, plus a BOLT11 invoice when you give an amount and an on-chain address when you ask for one. The new `POST /api/v1/wallet/bip321` endpoint can also return the URI upper-cased, which packs into a smaller QR code. \[[2242](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2242)]

  ### <Icon icon="mobile-screen-button" /> Estimate fees for on-chain payments

  A new `POST /api/v1/fees/offboard` endpoint quotes the cost of an on-chain payment (an offboard) funded by a chosen set of VTXOs before you commit. Each VTXO is spent in full to the destination address, and the response reports both the gross value of the selected VTXOs and the net amount that lands on-chain after fees. \[[2250](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2250)]

  ### <Icon icon="mobile-screen-button" /> Wallet notifications without a websocket

  Clients that can't hold a persistent websocket can now long-poll for wallet events. The new `GET /api/v1/notifications/wait` endpoint holds the request open until a notification arrives and returns a resume timestamp, so polling continues without gaps or busy loops. \[[1960](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1960)]

  ### <Icon icon="mobile-screen-button" /> Control which VTXOs a payment spends

  A new `InputSelection` builder lets SDK integrators steer which VTXOs a payment spends: limit how many inputs it uses, exclude specific VTXOs, and cover a fee that depends on the chosen set. On-chain sends now use it to honor the server's offboard-input limit. \[[2249](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2249)]

  ### <Icon icon="mobile-screen-button" /> One trait for on-chain wallets

  Integrating your own on-chain wallet is now one trait instead of eleven: `OnchainWalletTrait` replaces the patchwork of single-method traits. The wallet supplied at open also lives inside `Wallet` from then on, so board and daemon calls no longer thread it through every signature. \[[2121](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2121)]

  ### <Icon icon="mobile-screen-button" /> Wallet files locked down to user

  The bark CLI and barkd now create a wallet's data directory, seed, and database readable only by the operating-system user that created it, so other accounts on a shared machine can't read your seed. Existing wallets are untouched: Bark warns on open when their files are readable by others, rather than changing permissions itself. \[[2194](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2194)]

  ### <Icon icon="gear" /> Recovery mailbox posts are authenticated

  Posting recovery VTXO IDs to the server now carries a signed proof that you own the mailbox, verified the same way as reads, so a third party can no longer write entries into a mailbox that isn't theirs. The check stays optional for now so older clients keep working. \[[2234](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2234)]

  ### <Icon icon="mobile-screen-button" /> Filter wallet history server-side

  The `GET /api/v1/history` endpoint now takes optional `type` and `value` parameters identifying a payment method. Supply both and the response includes only movements involving that method, for example every payment sent to one address, so integrators no longer fetch the whole history and filter it client-side. \[[2227](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2227)]

  ### <Icon icon="mobile-screen-button" /> Crash-safe offboards and on-chain sends

  Offboards and on-chain sends now run as checkpointed wallet actions, so an interrupted offboard resumes on the next sync instead of being lost. A wallet that missed the server's response recovers the broadcast transaction from chain, retries with a fresh session, or cancels and releases the bitcoin. That completes the set: every payment operation now survives a crash. \[[2085](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2085)]

  ### <Icon icon="mobile-screen-button" /> Crash-safe Lightning receives

  An incoming Lightning payment now survives a restart: receives run through the same checkpointed machinery as Ark sends and resume where they left off, and a settled receive is stored permanently with its preimage. The receive-status API is reshaped around this lifecycle, and its token now belongs at invoice generation, not at claim. \[[2148](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2148)]

  ### <Icon icon="mobile-screen-button" /> Boarding rides out crashes and double-spends

  Boarding is now driven as a checkpointed wallet action, so a board survives a crash, resumes on the next sync, and re-broadcasts its funding transaction if it drops from the mempool. If that transaction is double-spent by a confirmed conflict, the board is now marked failed instead of being retried forever. \[[2236](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2236)] \[[2263](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2263)]

  ### <Icon icon="mobile-screen-button" /> Cancel an emergency exit before it commits

  An emergency exit can now be canceled while its final transaction is still unbroadcast. The VTXO stays spendable in Ark, and a fresh exit can be started later if needed. Cancellation is available across the SDK, the CLI (`bark exit cancel`), and the REST API. \[[2270](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2270)]

  ### <Icon icon="mobile-screen-button" /> No wasted fees on a doomed exit

  Before starting an emergency exit, Bark now checks the exit transactions for sub-dust or non-standard outputs that the bitcoin relay network would reject. A doomed exit is refused before any state is saved, so you don't burn fee-bump fees on transactions the network will never propagate. \[[2198](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2198)]

  ### <Icon icon="server" /> Offboard sessions retry safely

  Offboard sessions are now safely retryable: a client that lost the response to `prepare_offboard` or `finish_offboard` can re-send it and get the same session replayed, instead of being blocked by its own VTXO locks. Abandoned sessions also expire rather than pinning VTXOs and wallet UTXOs, which could previously starve round funding. \[[2252](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2252)] \[[2085](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2085)]

  ### <Icon icon="server" /> Ark server access token deprecated

  The Ark server doesn't enforce access tokens, so all of the access-token plumbing is now deprecated: the `--access-token` CLI flag, the SDK and REST create fields, and the `rpc.access_token` telemetry attribute. Everything still works for now, but configs, integrations, and dashboards relying on it should plan to drop it. \[[2171](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2171)]

  ### <Icon icon="list-ul" /> Additional improvements

  * A maintenance refresh where every due VTXO is unusable now returns an error instead of silently reporting success. \[[2246](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2246)]
  * Recovery VTXO IDs are now posted, and accepted by the server, in batches of at most 20 per request. \[[2267](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2267)]
  * The server now targets a 1-block confirmation for the round funding transaction. \[[2256](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2256)]
  * A new `bitcoin_address_blocklist_refresh_interval` server option sets how often the address blocklist file reloads (default 1 hour). \[[2169](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2169)]
  * A database race on the server can no longer mark VTXOs spent for a Lightning payment attempt whose success was never recorded. \[[2241](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2241)]
  * Removed the unused `GetFreshRounds` and `GetRound` gRPC methods. \[[2265](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2265)]
  * Manually refreshing specific VTXOs no longer pulls other refresh-due VTXOs into the same round; you get exactly the inputs you asked for. \[[2271](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2271)]
  * Exit status queries split into live and finished listings across the SDK and REST API; the old status endpoints are deprecated. \[[2270](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2270)] \[[2278](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2278)]
  * An exit fee-bump transaction's confirmation is now persisted, so exit status reads correctly immediately after a restart, even offline. \[[2299](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2299)]
  * Block-height arithmetic is hardened against overflow: exit status refresh no longer stalls on young chains, and confirmation counts survive reorg races. \[[2276](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2276)]
  * The server now validates CLN HTLC expiry heights instead of silently truncating them. \[[2276](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2276)]
  * Fixed `send_onchain` failing whenever the payment produced change. \[[2085](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2085)]

  [Full release notes in the repo](https://gitlab.com/ark-bitcoin/bark/-/blob/master/CHANGELOG.md?ref_type=heads).
</Update>

***

<Update
  label="26 June 2026"
  description="0.3.0"
  rss={{
title: "0.3.0 - 26 June 2026",
description: "Spend VTXOs even after queuing them for exit, Lightning receives protected from forced exits, automatic recovery of on-chain-pushed VTXOs, LNURL-pay support, and a simpler wallet setup API."
}}
>
  <img src="https://mintcdn.com/second-0659a37d/7vz3-vtFbgxMiLvB/images/exit-ice-cube-light.svg?fit=max&auto=format&n=7vz3-vtFbgxMiLvB&q=85&s=0282e3651ac0cdf4861acd3863d02865" alt="A glowing EXIT sign frozen in a melting ice cube, representing bitcoin that stays spendable while queued for exit" className="block dark:hidden" width="1920" height="1288" data-path="images/exit-ice-cube-light.svg" />

  <img src="https://mintcdn.com/second-0659a37d/7vz3-vtFbgxMiLvB/images/exit-ice-cube-dark.svg?fit=max&auto=format&n=7vz3-vtFbgxMiLvB&q=85&s=153fe437f13ff92708bd46d90181e66b" alt="A glowing EXIT sign frozen in a melting ice cube, representing bitcoin that stays spendable while queued for exit" className="hidden dark:block" width="1920" height="1288" data-path="images/exit-ice-cube-dark.svg" />

  <Warning>
    **Breaking changes**

    * **[Spend VTXOs queued for exit](#spend-vtxos-queued-for-exit):** Finish any in-progress mainnet exit on a non-sqlite backend before upgrading.
    * **[Simpler wallet setup API](#simpler-wallet-setup-api):** the `Wallet::open` / `Wallet::create` variants are unified and `WalletSeed` / `Config` construction changed.
    * **[Maintenance refresh survives a rejected VTXO](#maintenance-refresh-survives-a-rejected-vtxo):** `Wallet::maybe_schedule_maintenance_refresh` was removed.
  </Warning>

  ### <Icon icon="mobile-screen-button" /> Spend VTXOs queued for exit

  Starting an emergency exit no longer freezes the bitcoin behind it. A VTXO stays spendable (you can refresh it, send it, or otherwise use it) right up until its exit transactions confirm on-chain, and if you spend it off-chain first the queued exit notices and cancels itself cleanly. This removes the old trap where queuing an exit locked up bitcoin you hadn't committed to moving on-chain yet. \[[2117](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2117)]

  ### <Icon icon="gear" /> Lightning receives protected from forced exit

  A Lightning receive can no longer be force-exited by the server. Bark now claims incoming payments behind a checkpoint that gives the server's watchman a place to stop, so a parent VTXO being dragged on-chain no longer takes your freshly claimed bitcoin with it. \[[2214](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2214)]

  ### <Icon icon="mobile-screen-button" /> Automatic recovery of force-exited VTXOs

  VTXOs that get pushed on-chain by the watchman progressing a shared exit tree or another exit dragging a parent on-chain no longer get stuck. Each sync now detects forced exits and automatically routes them into the claim flow. \[[2208](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2208)]

  ### <Icon icon="mobile-screen-button" /> Pay LNURL links

  Bark can now pay bech32 LNURL-pay links (`lnurl1…`) anywhere it already accepts a Lightning address, across the SDK, the CLI (`bark pay`), and the REST API. `Wallet::parse_payment_request` recognises them and resolves the link to an invoice before paying; as with Lightning addresses, an amount is required. \[[2176](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2176)]

  ### <Icon icon="mobile-screen-button" /> Maintenance refresh survives a rejected VTXO

  A single unusable input no longer sinks an entire maintenance refresh. Previously one VTXO the server rejected failed the whole atomic batch every run, so healthy VTXOs nearing expiry never refreshed and slid into exit-only territory. Maintenance now drops the rejected inputs and retries with the rest. Explicit developer-initiated refreshes still fail wholesale rather than dropping a caller's selection. \[[2217](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2217)]

  ### <Icon icon="mobile-screen-button" /> Simpler wallet setup API

  Opening and creating wallets is now a single, consistent flow. The many `Wallet::open*` and `Wallet::create*` variants collapse into one `Wallet::open` and one `Wallet::create` taking optional arguments, persistence picks a per-platform default (sqlite natively, IndexedDB on wasm), and seed construction splits into clearer `new_from_seed` and `new_from_mnemonic`. \[[2076](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2076)]

  ### <Icon icon="server" /> Per-client server metrics

  Operators can now break server traffic down by client. Bark sends an `x-user-agent` header on every Ark RPC, and the server tags its gRPC metrics with the originating client, so board, Lightning, and round volume can be split per app on a dashboard. Integrators can set their own identifier via the new `Config.user_agent` field. \[[2170](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2170)]

  ### <Icon icon="mobile-screen-button" /> Additional improvements

  * Arkade addresses now produce a clear "Ark address is for different server" message instead of a generic failure. \[[2220](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2220)]
  * An Ark payment receive processed by several consumers at once is now recorded exactly once in wallet history instead of being double-counted. \[[2168](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2168)]
  * Streaming connections to the Ark server now stay open for up to an hour, fixing a disconnect every 10 minutes. \[[2213](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2213)]
  * REST VTXO listings regained their `exit_depth` field. \[[2225](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2225)]
  * The server now allows a 5-second leeway on mailbox auth expiry, so a client with minor clock skew is no longer rejected. \[[2199](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2199)]

  [Full release notes in the repo](https://gitlab.com/ark-bitcoin/bark/-/blob/master/CHANGELOG.md?ref_type=heads).
</Update>

***

<Update
  label="12 June 2026"
  description="0.2.5"
  rss={{
title: "0.2.5 - 12 June 2026",
description: "Security hardening from privately disclosed vulnerabilities, plus server feerate fixes."
}}
>
  ### <Icon icon="gear" /> Security hardening

  This release fixes several privately disclosed vulnerabilities and hardens bark against malformed data from a misbehaving server: out-of-range VTXO output indices are now rejected, bad round data can no longer panic the wallet or bring down the daemon, and a failed save after round signing can no longer lead to nonce reuse. We're grateful to [instagibbs](https://x.com/theinstagibbs/status/2065776599727841413) and [Floppy](https://x.com/1440000bytes/status/2065704186982154704) for responsibly disclosing these in private. \[[2181](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2181)] \[[2182](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2182)] \[[2183](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2183)]

  ### <Icon icon="server" /> Additional improvements

  * The server now correctly validates the user-provided HTLC expiry on Lightning receives. \[[2184](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2184)]
  * Several feerate fixes on the server: correct max-fee-rate clamping, no double update on fallback, and economical rather than conservative estimates. \[[2185](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2185)]

  [Full release notes in the repo](https://gitlab.com/ark-bitcoin/bark/-/blob/master/CHANGELOG.md?ref_type=heads).
</Update>

***

<Update
  label="11 June 2026"
  description="0.2.4"
  rss={{
title: "0.2.4 - 11 June 2026",
description: "Server-side address blocklisting, a no-auth mode for running barkd as a web app, and Lightning receives that stay retryable."
}}
>
  ### <Icon icon="server" /> Address blocklist

  Server operators can now block bitcoin moving to or from specific addresses. New `bitcoin_address_blocklist` options on `captaind` and `watchmand` point at a file of addresses loaded at startup; offboards to a blocked address, and boards funded from one, are rejected. \[[2155](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2155)]

  ### <Icon icon="server" /> Run barkd as a web app

  barkd can now run without authentication via `--no-auth`, which, paired with the CORS setting, makes it practical to ship barkd inside a container as a web application. \[[2157](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2157)]

  ### <Icon icon="mobile-screen-button" /> Lightning receives stay retryable

  A Lightning receive whose claim fails, for example after transient server errors exhaust the retry budget, no longer triggers an automatic on-chain exit. The receive stays pending so it can be retried, and you can still fall back to an explicit on-chain exit with `Wallet::attempt_lightning_receive_exit` when you choose to. \[[2174](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2174)]

  ### <Icon icon="mobile-screen-button" /> Claimable exits visible in balance

  Emergency exits that have reached the claimable stage now count toward the reported pending-exit balance, so that bitcoin stays visible to users until it's actually spent on-chain. \[[2161](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2161)]

  ### <Icon icon="mobile-screen-button" /> Additional improvements

  * Added a `max_fee_rate` server option to guard against fee estimators returning absurd rates. \[[2154](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2154)]
  * Fixed multi-input offboards, including a fixup for older clients that got stuck. \[[2175](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2175)]
  * Oversized BOLT11 invoice descriptions are now rejected with `badarg` instead of logging a spurious error. \[[2164](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2164)]

  [Full release notes in the repo](https://gitlab.com/ark-bitcoin/bark/-/blob/master/CHANGELOG.md?ref_type=heads).
</Update>

***

<Update
  label="9 June 2026"
  description="0.2.3"
  rss={{
title: "0.2.3 - 9 June 2026",
description: "Developer control over Lightning auto-exits and smoother on-chain exit claims."
}}
>
  <Warning>
    **Breaking changes**

    * **[Developer control over Lightning auto-exits](#developer-control-over-lightning-auto-exits):** the Lightning send state machine gains a `Progress::RevocationStuck` variant and `LightningSend` an `allow_exit_of_htlcs` field.
  </Warning>

  ### <Icon icon="mobile-screen-button" /> Developer control over Lightning auto-exits

  Bark no longer force-exits the HTLC VTXOs behind an unfinished Lightning receive or a failed Lightning send on its own; that decision now sits with you. Stuck receives and sends stay put so they can be inspected and retried, with `Wallet::attempt_lightning_receive_exit` and `Wallet::allow_lightning_send_to_exit` to opt an individual payment into exiting on your terms. This follows a few cases where incoming payments were exited unnecessarily. \[[2152](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2152)] \[[2153](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2153)]

  ### <Icon icon="mobile-screen-button" /> Smoother exit claims

  Exit claim transactions are now standard v2 transactions rather than v3 (TRUC). The v3 form added restrictions to the claim process that weren't needed, and dropping it makes claiming an exit simpler and less constrained. \[[2149](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2149)]

  ### <Icon icon="mobile-screen-button" /> Additional improvements

  * Added a `sqlite-bundled` compile feature to build bark with SQLite bundled in. \[[2122](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2122)]

  [Full release notes in the repo](https://gitlab.com/ark-bitcoin/bark/-/blob/master/CHANGELOG.md?ref_type=heads).
</Update>

***

<Update
  label="4 June 2026"
  description="0.2.2"
  rss={{
title: "0.2.2 - 4 June 2026",
description: "Crash-safe Lightning sends with local invoice-paid lookups, a wallet mnemonic backup endpoint, a more resilient emergency exit, and a flag for internal fee-bump transactions."
}}
>
  <img src="https://mintcdn.com/second-0659a37d/NQAV5SiWmpS7hL7Y/images/lightning-seatbelt-light.svg?fit=max&auto=format&n=NQAV5SiWmpS7hL7Y&q=85&s=9d987e2ac56a4ee445f9c52330904918" alt="A seatbelt buckled across a Lightning bolt, representing crash-safe Lightning sends" className="block dark:hidden" width="1920" height="1221" data-path="images/lightning-seatbelt-light.svg" />

  <img src="https://mintcdn.com/second-0659a37d/NQAV5SiWmpS7hL7Y/images/lightning-seatbelt-dark.svg?fit=max&auto=format&n=NQAV5SiWmpS7hL7Y&q=85&s=6c1d9253f5f39e5461eaa79115de3992" alt="A seatbelt buckled across a Lightning bolt, representing crash-safe Lightning sends" className="hidden dark:block" width="1920" height="1221" data-path="images/lightning-seatbelt-dark.svg" />

  <Warning>
    **Breaking changes**

    * **[Lightning send API](#crash-safe-lightning-sends):** `Wallet::check_lightning_payment` now takes a `wait` parameter and returns `LightningSendState`, and the pay methods take a new `wait` parameter.
    * **[REST server construction](#wallet-mnemonic-backup-endpoint):** `RestServer::start` now takes a `ServerState` built via its builder.
    * **[Onchain transactions JSON](#flag-internal-fee-bump-transactions):** `bark onchain transactions` output changes to the richer `WalletTxInfo` shape.
  </Warning>

  ### <Icon icon="mobile-screen-button" /> Crash-safe Lightning sends

  Outgoing Lightning sends are now checkpointed, so a crash mid-send no longer leaves a payment stuck. Settled invoices are also recorded permanently, so the wallet can always confirm whether an invoice was already paid (`Wallet::is_invoice_paid`) without asking the server, and won't pay it twice. Paying now takes a `wait` flag: block until the send finishes, or return immediately and poll `Wallet::lightning_send_state`. \[[2062](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2062)]

  ### <Icon icon="server" /> Wallet mnemonic backup endpoint

  A new `GET /api/v1/wallet/mnemonic` endpoint returns the wallet's BIP-39 seed phrase, so a wallet built on barkd can show it to the user to write down instead of making them dig it out of the filesystem. It's on by default; set `BARKD_EXPOSE_MNEMONIC=false` to disable it (the endpoint then returns 404). Embedders that mount bark-rest themselves now build the server with `ServerState::builder()`. \[[2114](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2114)]

  ### <Icon icon="mobile-screen-button" /> Resilient emergency exit progress

  One transaction failing to update its on-chain status no longer aborts the whole emergency exit run: the rest carry on and the next sync retries the failed one. Broader failures, like the chain source going unreachable, now come back as a clear `error` field in the exit progress response instead of an error printed to the console, so your app can spot a temporary problem and decide whether to retry. \[[2120](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2120)]

  ### <Icon icon="mobile-screen-button" /> Just-in-time refresh rounds

  Wallet maintenance now locks VTXOs only once a refresh round actually starts, so funds stay spendable during the wait instead of being tied up early. Any stuck pending round is cleared first. \[[2113](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2113)]

  ### <Icon icon="mobile-screen-button" /> Flag internal fee-bump transactions

  Transaction listings now carry an `is_cpfp` flag marking the wallet's own fee-bump transactions, the internal children that speed up an emergency exit. Use it to hide or label them so they don't show up as confusing stray entries in a user's history. The flag is on `GET /api/v1/onchain/transactions`, and `bark onchain transactions` now returns the same richer shape. \[[2119](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2119)]

  ### <Icon icon="mobile-screen-button" /> Additional improvements

  * Swagger UI can now be compiled out via the `barkd-swagger-ui` feature, though it stays on by default. \[[2123](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2123)]
  * The bitcoind client (`bitcoind_async_client`) log level is now set to DEBUG. \[[2126](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2126)]

  [Full release notes in the repo](https://gitlab.com/ark-bitcoin/bark/-/blob/master/CHANGELOG.md?ref_type=heads).
</Update>

<Update
  label="29 May 2026"
  description="0.2.1"
  rss={{
title: "0.2.1 - 29 May 2026",
description: "Emergency exit becomes wallet-agnostic so third-party wallets can drive CPFP fee-bumping with their own signer, plus a BIP 321 payment URI builder and a handful of reliability fixes."
}}
>
  <img src="https://mintcdn.com/second-0659a37d/n4ZI5y_rTKWaCO_M/images/emergency-exit-agnostic-light.svg?fit=max&auto=format&n=n4ZI5y_rTKWaCO_M&q=85&s=47a76f37a2447808a19abf1e80d7eb37" alt="An emergency exit door with a network port for plugging in your own wallet" className="block dark:hidden" width="1920" height="1072" data-path="images/emergency-exit-agnostic-light.svg" />

  <img src="https://mintcdn.com/second-0659a37d/n4ZI5y_rTKWaCO_M/images/emergency-exit-agnostic-dark.svg?fit=max&auto=format&n=n4ZI5y_rTKWaCO_M&q=85&s=e57765f8d2d93e746b1452058b67a8b4" alt="An emergency exit door with a network port for plugging in your own wallet" className="hidden dark:block" width="1920" height="1072" data-path="images/emergency-exit-agnostic-dark.svg" />

  <Warning>
    **Breaking changes**

    * **[Wallet-agnostic emergency exit](#wallet-agnostic-emergency-exit):** Exit status, error, and origin types are reshaped; integrators driving exits must adopt the new CPFP request flow.
  </Warning>

  ### <Icon icon="mobile-screen-button" /> Wallet-agnostic emergency exit

  Third-party wallets can now drive an emergency exit with their own fee policy and signer, rather than relying on bark's bundled on-chain wallet. The exit state machine pauses at each fee-bumping (CPFP) boundary and hands control back to the caller, so emergency exit fits a wallet that already manages its own UTXOs and broadcasting. Integrators on bark's bundled BDK wallet keep the previous one-shot behaviour. Thanks to external contributor [Íñigo Aréjula Aísa](https://github.com/arejula27) for this work. \[[2032](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2032)]

  ### <Icon icon="mobile-screen-button" /> BIP 321 payment URI builder

  Building on the `bip321` crate from 0.2.0, Bark wallets can now assemble a single `bitcoin:` payment URI that bundles Ark, Lightning, and on-chain destinations into one request via `Wallet::bip321_uri`. A new `GetAddress` trait abstracts on-chain address generation, so you can plug in any on-chain wallet backend. \[[1997](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1997)]

  ### <Icon icon="mobile-screen-button" /> Additional improvements

  * Exit CPFP RBF no longer silently downgrades a freshly broadcast high-fee replacement to a stale lower-fee child returned by a lagging esplora-electrs indexer. \[[2032](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2032)]
  * Terminal log timestamps now include the UTC offset. \[[2083](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2083)]
  * Fixed a panic when an exit transaction failed to download. \[[2087](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2087)]
  * Corrected the OpenAPI spec for `GET /api/v1/history`, which previously advertised a trailing-slash path and broke generated clients. \[[2099](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2099)]

  [Full release notes in the repo](https://gitlab.com/ark-bitcoin/bark/-/blob/master/CHANGELOG.md?ref_type=heads).
</Update>

<Update
  label="27 May 2026"
  description="0.2.0"
  rss={{
title: "0.2.0 - 27 May 2026",
description: "VTXO storage slimmed down, custom metadata on wallet history, split board flow for external wallets, retried Lightning receive claims, push notifications for Lightning send completion, and a new BIP 321 crate. Plus security hardening across VTXO policy decoding."
}}
>
  <img src="https://mintcdn.com/second-0659a37d/Qt0tuwylqYkC_GbL/images/thin-vtxo-storage-light.svg?fit=max&auto=format&n=Qt0tuwylqYkC_GbL&q=85&s=48afd1ba8a20ee2709437f7095518586" alt="Slim VTXO storage" className="block dark:hidden" width="1920" height="1072" data-path="images/thin-vtxo-storage-light.svg" />

  <img src="https://mintcdn.com/second-0659a37d/Qt0tuwylqYkC_GbL/images/thin-vtxo-storage-dark.svg?fit=max&auto=format&n=Qt0tuwylqYkC_GbL&q=85&s=31dc5b4f40b7217294ef19e99d08ebfd" alt="Slim VTXO storage" className="hidden dark:block" width="1920" height="1072" data-path="images/thin-vtxo-storage-dark.svg" />

  <Warning>
    **Breaking changes**

    * **[Slim VTXO storage](#slim-vtxo-storage):** `WalletVtxo` now holds `Vtxo<Bare>`; a migration splits existing VTXO storage.
    * **[Custom metadata on wallet history](#custom-metadata-on-wallet-history):** `Movement.metadata` changes type and the history endpoint moves.
    * **[LockManager](#lockmanager-for-cross-process-locks):** wallet constructors gain a `lock_manager` parameter.
    * **[Wallet API ergonomics](#wallet-api-ergonomics):** constructors return a `Wallet`, no longer an `Arc`.
  </Warning>

  ### <Icon icon="mobile-screen-button" /> Slim VTXO storage

  Bark now keeps each VTXO in a slim "bare" form and loads only that for listings, balance, coin selection, and refresh checks: around 200 bytes per VTXO regardless of exit depth, a 20–100x cut in memory for wallets with many or deep VTXOs. `WalletVtxo` now holds `Vtxo<Bare>`; reach for `Wallet::get_full_vtxo` when you need the full exit chain. The release ships a migration that splits existing storage into bare and genesis blobs. \[[2050](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2050)]

  ### <Icon icon="mobile-screen-button" /> Custom metadata on wallet history

  You can now attach custom JSON to any movement (refund references, customer or order IDs, internal notes) without maintaining a parallel store keyed by movement ID. Use `Wallet::update_history_metadata` or `POST /api/v1/history/{id}/metadata`, which take a JSON merge patch. The history listing also moves to `GET /api/v1/history`; the old path stays but is deprecated. \[[2079](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2079)]

  ### <Icon icon="mobile-screen-button" /> Split board flow for external wallets

  External wallets can now build and sign the board funding transaction themselves, then complete the board by submitting a pre-signed PSBT, which the server validates before broadcast. The flow splits into `board_funding_address` and `board_tx`. \[[1766](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1766)]

  ### <Icon icon="mobile-screen-button" /> Lightning receive claims retry before falling back to on-chain

  A transient failure during an inbound Lightning claim (a server restart or brief network blip) no longer forces an immediate on-chain exit of the HTLC VTXOs. Bark now retries the claim with backoff before falling back on-chain, with the budget set by `Config::lightning_receive_claim_retries`. Retrying is safe because the server's claim is idempotent. \[[2061](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2061)]

  ### <Icon icon="server" /> Push notifications for Lightning send completion

  The server now notifies Bark clients via the mailbox when a Lightning send completes, success or failure, so the wallet handles the result without polling. \[[1889](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1889)]

  ### <Icon icon="gear" /> VTXO policy decoding hardened against malicious servers

  `Vtxo::decode` and `VtxoPolicy::decode` now reject out-of-range expiry and delta values that a malicious server could previously use to panic or overflow the client. The same bounds are exposed in `ark::vtxo::policy` for reuse at other deserialization boundaries, and the server applies the same checks at its gRPC and Postgres boundaries. \[[2046](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2046)]

  ### <Icon icon="mobile-screen-button" /> BIP 321 crate for bitcoin payment URIs

  A new `bip321` crate parses and serializes `bitcoin:` payment URIs for encoding payment instructions in clickable links and QR codes. It covers the standard payment parameters and exposes a pluggable `ExtensionHandler` trait for custom or wallet-specific parameters. \[[1921](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1921)]

  ### <Icon icon="mobile-screen-button" /> Graceful reconnection on idle stream timeouts

  Mailbox and round-event streams killed by a proxy idle timeout are now silently reconnected instead of treated as server failures, so the daemon no longer gives up on the mailbox after prolonged idle periods. \[[2040](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2040)]

  ### <Icon icon="mobile-screen-button" /> LockManager for cross-process locks

  A new `LockManager` provides named cross-process locks so two tasks or processes can't race on the same wallet. `lock_manager::platform_default` picks a sensible implementation per platform, including a Web Locks-backed manager that stops multiple browser tabs racing each other, and integrators can supply their own. Wallet constructors gain a `lock_manager` parameter, replacing the removed `pid-lock` feature. \[[2042](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2042)]

  ### <Icon icon="mobile-screen-button" /> Wallet API ergonomics

  `Wallet` now wraps an `Arc` internally, so it is cheap to clone and constructors return a `Wallet` directly rather than an `Arc<Wallet>`. A few public fields move to getter methods (`chain()`, `exit_mgr()`, `movements_mgr()`). \[[2052](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2052)]

  ### <Icon icon="mobile-screen-button" /> Additional improvements

  * Bark can fetch the current mempool fee rate via a dedicated `GetOffboardFeeRate` RPC instead of re-fetching all of `ArkInfo`. \[[2029](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2029)]
  * `GET /onchain/transactions` now returns `onchain_fee_sat`, `balance_change_sat`, and `confirmation` alongside `txid` and `tx`. \[[2060](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/2060)]

  [Full release notes in the repo](https://gitlab.com/ark-bitcoin/bark/-/blob/master/CHANGELOG.md?ref_type=heads).
</Update>

<Update
  label="28 April 2026"
  description="0.1.4"
  rss={{
title: "0.1.4 - 28 April 2026",
description: "Websocket gateway for real-time wallet notifications, Lightning invoice descriptions, offline address generation, and a wallet that owns its own daemon. Plus a RegisterVtxos RPC rename."
}}
>
  <Warning>
    **Breaking changes**

    * **[Wallet owns its daemon handle](#wallet-owns-its-daemon-handle):** `Wallet::open` no longer returns the `DaemonHandle`.
    * **[Lightning invoice descriptions](#lightning-invoice-descriptions):** `Wallet::bolt11_invoice` gains a `description` parameter.
    * **[`RegisterVtxos` RPC renamed](#registervtxos-rpc-renamed):** `register_vtxos_with_server` is now `register_vtxo_transactions_with_server`.
  </Warning>

  ### <Icon icon="server" /> Websocket gateway for real-time notifications

  `bark-rest` exposes a websocket gateway for the `WalletNotification` stream introduced in 0.1.0. Clients request a short-lived ticket, then upgrade to a long-lived connection to receive notifications as they're emitted instead of polling REST endpoints. \[[1929](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1929)]

  ### <Icon icon="mobile-screen-button" /> Lightning invoice descriptions

  `bark lightning invoice` accepts a `--description` flag (and the REST endpoint a `description` field) that is embedded in the generated BOLT11 invoice as its memo, giving senders context about the payment. `Wallet::bolt11_invoice` gains a `description` parameter; pass `None` to preserve previous behaviour. \[[1950](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1950)]

  ### <Icon icon="mobile-screen-button" /> `bark address` works offline

  The server public key and mailbox public key are persisted in the local database after the first connection, so address generation no longer requires a live connection to the Ark server. \[[1868](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1868)]

  ### <Icon icon="mobile-screen-button" /> Wallet owns its daemon handle

  The `DaemonHandle` is now kept inside the `Wallet`, so the background daemon stops automatically when the wallet is dropped. `Wallet::stop_daemon` shuts it down explicitly, and the idempotent `Wallet::start_daemon` replaces the deprecated `run_daemon`. As a result, `Wallet::open` no longer returns the handle. \[[1971](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1971)], \[[1974](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1974)]

  ### <Icon icon="server" /> `RegisterVtxos` RPC renamed

  The `RegisterVtxos` RPC is renamed to `RegisterVtxoTransactions`: the old name implied it created VTXOs server-side, but it only attaches signed transaction chains to existing ones. The old method path stays as a deprecated alias, and the Bark wrapper `register_vtxos_with_server` becomes `register_vtxo_transactions_with_server`. \[[1972](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1972)]

  ### <Icon icon="mobile-screen-button" /> Type-sharing crates compile without a transport backend

  `bark-wallet`, `bark-json`, `bark-rest`, and `bark-server-rpc` no longer implicitly select a transport backend, so consumers that just want the shared types can depend on them cleanly. Server-backed operations return a clear error pointing to the right feature flag when no transport is compiled in. \[[1872](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1872)]

  [Full release notes in the repo](https://gitlab.com/ark-bitcoin/bark/-/blob/master/CHANGELOG.md?ref_type=heads).
</Update>

<Update
  label="20 April 2026"
  description="0.1.3"
  rss={{
title: "0.1.3 - 20 April 2026",
description: "IndexedDB persistence adaptor unlocks browser wallets. Private server access tokens, cancelable Lightning receives, and a CLI watch command."
}}
>
  <img src="https://mintcdn.com/second-0659a37d/DAkXBVOix6pE6vb6/images/wasm-support.svg?fit=max&auto=format&n=DAkXBVOix6pE6vb6&q=85&s=4d70181f79d19273d7d9d39afae61480" alt="Wasm support" className="block dark:hidden" width="1920" height="1081" data-path="images/wasm-support.svg" />

  <img src="https://mintcdn.com/second-0659a37d/DAkXBVOix6pE6vb6/images/wasm-support-dark.svg?fit=max&auto=format&n=DAkXBVOix6pE6vb6&q=85&s=f826c7981e66687df366aea87c6b33df" alt="Wasm support" className="hidden dark:block" width="1920" height="1081" data-path="images/wasm-support-dark.svg" />

  ### <Icon icon="mobile-screen-button" /> IndexedDB persistence adaptor

  Bark ships a new `IndexedDb` `StorageAdaptor`, the missing piece for browser-based wallets. Combined with the Wasm compilation and gRPC-web support added in 0.1.0, integrators can now build Ark wallets that run entirely in the browser with persistent state. \[[1776](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1776)]

  ### <Icon icon="mobile-screen-button" /> Private server access tokens

  Bark can now connect to access-controlled Ark servers by sending a bearer token on every request. Set `server_access_token` in config, pass `--access-token` to `bark create`, or configure the `ark-access-token` HTTP header directly. You know what this means. \[[1927](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1927)]

  ### <Icon icon="mobile-screen-button" /> Cancel pending Lightning receives

  A new `Wallet::cancel_lightning_receive` method (and `bark lightning receive cancel` CLI command) cancels an in-flight inbound Lightning payment before it settles. \[[1824](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1824)]

  ### <Icon icon="mobile-screen-button" /> Additional improvements

  * Fee estimation methods now return an error when the requested amount falls outside the server's allowed range, instead of quoting a fee for an unachievable operation. \[[1932](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1932)]
  * New `bark watch` command subscribes to `WalletNotification` events and streams them to stdout, useful for debugging event-driven integrations. \[[1809](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1809)]

  [Full release notes in the repo](https://gitlab.com/ark-bitcoin/bark/-/blob/master/CHANGELOG.md?ref_type=heads).
</Update>

<Update
  label="4 April 2026"
  description="0.1.0"
  rss={{
title: "0.1.0 - 4 April 2026",
description: "Bark drops the beta tag. Highlights: event-driven notifications, fee estimation API, Tor connectivity, Barkd security hardening, and Wasm compilation progress."
}}
>
  <img src="https://mintcdn.com/second-0659a37d/L_nNx3I4J5d_HUSW/images/2026-notifications.svg?fit=max&auto=format&n=L_nNx3I4J5d_HUSW&q=85&s=ff382b577eaea31d8677664682f8865f" alt="A notification bell ringing" className="block dark:hidden" width="2752" height="1536" data-path="images/2026-notifications.svg" />

  <img src="https://mintcdn.com/second-0659a37d/L_nNx3I4J5d_HUSW/images/2026-notifications-dark.svg?fit=max&auto=format&n=L_nNx3I4J5d_HUSW&q=85&s=17c9f03a6a103a888107d81a823a5bc5" alt="A notification bell ringing" className="hidden dark:block" width="2752" height="1536" data-path="images/2026-notifications-dark.svg" />

  You know we're getting closer to mainnet when the "beta" tag is dropped. This changelog update covers two releases—0.1.0-beta.9 and 0.1.0.

  <Warning>
    **Breaking changes**

    This release includes several breaking changes: Barkd's REST API now requires auth tokens, CORS defaults to deny-all, the `StorageAdaptor` trait has renamed and new methods, arkoor attestation is mandatory, and Cargo feature flags have been restructured for Wasm support. See below for details.
  </Warning>

  ### <Icon icon="mobile-screen-button" /> Event-driven notifications

  Bark replaces polling with push-based notifications. The wallet gains `Wallet::subscribe_notifications`, returning a stream of `WalletNotification` events (`MovementCreated` and `MovementUpdated`) so your app can react to balance changes in real time. \[[1793](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1793)], \[[1807](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1807)]

  On the server side, Lightning receive events and non-interactive round completions now flow through the mailbox system. Bark subscribes to the server mailbox stream for real-time arkoor delivery, and the daemon processes `RoundVtxos` messages to progress delegated round participations automatically. \[[1792](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1792)], \[[1779](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1779)], \[[1613](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1613)], \[[1845](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1845)]

  ### <Icon icon="mobile-screen-button" /> Fee estimation API

  New `/api/v1/fees/` endpoints let integrators estimate fees for all operation types—boarding, on-chain sends, offboards, and Lightning—and query current network feerates. Estimation also works when the wallet has no funds, returning a worst-case estimate so your app can display fees before the user has funded their wallet. \[[1787](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1787)], \[[1790](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1790)]

  ### <Icon icon="mobile-screen-button" /> Tor connectivity

  A new `socks5-proxy` feature routes traffic through a SOCKS5 proxy for Tor connectivity, covering Ark gRPC connections, esplora HTTP calls, and bitcoind RPC. Local addresses automatically bypass the proxy. \[[1720](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1720)]

  ### <Icon icon="mobile-screen-button" /> Barkd security hardening

  Barkd now generates an auth token on first start and requires it for all REST API calls. Use `barkd secret refresh` to regenerate or set a custom token. Cross-origin requests are also denied by default—configure `--allowed-origins` or `BARKD_ALLOWED_ORIGINS` to whitelist specific origins for browser-based clients. \[[1756](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1756)], \[[1808](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1808)]

  ### <Icon icon="server" /> HTLC preimage recovery from on-chain exits

  When a user performs an emergency exit of an HTLC VTXO, the preimage is revealed in the on-chain spending witness. The server now extracts this preimage and settles the corresponding CLN hold invoice automatically, preventing stuck invoices in Lightning-to-Ark payment flows. \[[1706](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1706)]

  ### <Icon icon="gear" /> Mandatory arkoor ownership attestation

  Arkoor and Lightning send cosign requests now require a signed ownership attestation, preventing a malicious user from locking someone else's VTXOs. The previously optional `ArkoorCosignRequest.attestation` field is now required, and the deprecated `PaymentStatus` enum and `LightningPaymentResult` gRPC message have been removed. \[[1735](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1735)], \[[1834](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1834)]

  ### <Icon icon="gear" /> Wasm and browser support progress

  Bark now compiles to `wasm32-unknown-unknown`, which is a key step towards enabling browser-based Ark wallets. The server gains a gRPC-web layer so browser clients can connect directly without a proxy. \[[1709](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1709)], \[[1749](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1749)]

  `sqlite` is no longer a default feature—enable it explicitly if needed. The `onchain_bdk` feature has been renamed to `onchain-bdk`. Once persistence is solved, you'll be able to start shipping Bark wallets in browsers!

  ### <Icon icon="mobile-screen-button" /> StorageAdaptor trait changes

  `StorageAdaptor::query` is renamed to `query_sorted` and now requires an explicit sort key range. A new `get_all` method retrieves all unordered records in a partition. Custom `StorageAdaptor` implementations must be updated. \[[1786](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1786)]

  ### <Icon icon="mobile-screen-button" /> Additional improvements

  * VTXOs can now be retrieved in hex-serialized form via `GET /vtxos/{id}/encoded` for export and import between wallets. \[[1800](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1800)]
  * Movement lookup by payment method via `Wallet::history_by_payment_method()` and by Ark address via CLI `bark address lookup --address <addr>`. \[[1798](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1798)]
  * Wallet deletion via `DELETE /api/v1/wallet` stops background tasks and wipes the wallet directory. \[[1663](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1663)]
  * Configurable daemon sync intervals via `config.toml` or `BARK_` environment variables. \[[1810](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1810)]
  * `try_claim_all_lightning_receives` now returns the list of claimed receives instead of `()`. \[[1773](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1773)]
  * Offboard movements now remain pending until the transaction confirms on-chain, allowing recovery if the transaction fails to confirm. \[[1618](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1618)]
  * `ln status` split into `ln pay status` (outgoing) and `ln receive status` (incoming) with dedicated output types. \[[1466](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1466)]
  * Operators can ban/unban VTXOs by duration or block count via `captaind rpc ban`. \[[1733](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1733)]

  [Full release notes in the repo](https://gitlab.com/ark-bitcoin/bark/-/blob/master/CHANGELOG.md?ref_type=heads).
</Update>

<Update
  label="9 March 2026"
  description="0.1.0-beta.8"
  rss={{
title: "0.1.0-beta.8 - 9 March 2026",
description: "Breaking changes: API field renames and removed legacy endpoints. New: comprehensive fee schedule, MIT relicensing, Watchman sweeper, server pubkey pinning, dynamic on-chain fees, resilient maintenance, idempotent Lightning receive."
}}
>
  <img src="https://mintcdn.com/second-0659a37d/Z3_V3Q8tQFA902bN/images/2026-fees.jpg?fit=max&auto=format&n=Z3_V3Q8tQFA902bN&q=85&s=4cc1bfd791556482b02ec6f0691f48f1" alt="Fees" width="1920" height="1080" data-path="images/2026-fees.jpg" />

  <Warning>
    **Breaking changes**

    There are several breaking changes in this update, including fee schedule restructuring, removed legacy address delivery and gRPC methods, renamed balance and feerate fields, and Lightning receive nullability changes. See below for details.
  </Warning>

  ### <Icon icon="gear" /> Fee schedule for all operations

  The Bark server now includes a granular fee configuration system that lets server operators define fee schedules using a combination of flat fees, percentage-based rates, and dynamic rates tied to VTXO lifetime. Second has also published the [fee schedule](/docs/learn/fees) for the Ark server we operate. And a new fee estimation API lets your app calculate and display fees before users commit to an operation. \[[1500](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1500)]

  ### <Icon icon="server" /> Dynamic fees for on-chain sends and offboards

  Fees for on-chain sends and offboards now adjust based on current network conditions. The server communicates the applicable feerate via `ArkInfo` and accepts any feerate valid within a recent historical window, so clients aren't penalized for brief fluctuations between quote and submission. \[[1509](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1509)]

  ### <Icon icon="server" /> Introducing the Watchman

  A new Watchman component unifies coin sweeping and forfeit handling into a single, block-synchronized process. It maintains a continuously updated view of all VTXOs that need monitoring and decides the appropriate action for each: wait, CPFP, or claim to the round wallet. This replaces the previous forfeit watcher and sweeper. \[[1560](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1560)], \[[1698](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1698)]

  ### <Icon icon="mobile-screen-button" /> Server pubkey pinning

  The wallet now stores the server's public key on first connection and verifies it on every subsequent connection. If the pubkey changes unexpectedly, the wallet blocks further interaction and advises the user to recover funds via an emergency exit. \[[1611](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1611)]

  ### <Icon icon="mobile-screen-button" /> Resilient maintenance with exit progression

  Maintenance tasks no longer bail on the first error—all steps now run to completion regardless of individual failures. Each maintenance run also actively progresses pending exits, broadcasting TRUC packages instead of merely syncing state. \[[1592](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1592)]

  ### <Icon icon="server" /> Idempotent Lightning receive claims

  The server's `claim_lightning_receive` is now idempotent—if a claim is interrupted by a network failure or timeout, Bark can safely retry without risking duplicate state or forced on-chain exits. This is a meaningful reliability improvement for mobile integrations where transient connectivity issues are common. \[[1605](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1605)]

  ### <Icon icon="server" /> Round event replay for late subscribers

  Clients subscribing to round events now receive the current `Attempt` event if sign-up is still open, fixing a race condition that caused mobile wallets to miss rounds. When a push notification wakes a phone and triggers a refresh, the wallet can now join rounds that are already in progress rather than waiting for the next one. \[[1572](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1572)]

  ### <Icon icon="mobile-screen-button" /> VTXO import for recovery

  You can now manually import serialized VTXOs into a wallet via `bark dev vtxo import` or the `/import-vtxo` REST endpoint. This is useful for recovering VTXOs that were lost from a wallet database but still exist on-chain—for example, after a database corruption or when migrating between wallet instances. \[[1607](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1607)]

  ### <Icon icon="mobile-screen-button" /> Exclusive datadir access with PidLock

  A new `PidLock` utility prevents multiple processes from operating on the same wallet datadir concurrently. When `barkd` or `bark` starts, it writes a lock file that blocks other instances from accessing the same data, preventing the subtle corruption that can occur when two processes modify wallet state simultaneously. Available behind the `pid_lock` feature flag. \[[1651](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1651)]

  ### <Icon icon="mobile-screen-button" /> Smarter refresh with dust detection

  The refresh strategy gains two new variants—`should_refresh_exclusive` and `should_refresh_if_must`—for more granular control over which VTXOs participate in a round. VTXOs with amounts below the P2TR dust threshold are now automatically flagged for refresh, preventing tiny outputs from accumulating and causing issues during transaction construction. \[[1614](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1614)]

  ### <Icon icon="server" /> Recursive trust model for balance reporting

  The server now walks the full transaction ancestry to classify unconfirmed UTXOs, replacing BDK's shallow heuristic that only checked immediate inputs. This prevents external deposits from being incorrectly treated as trusted across balance reporting, telemetry, and CPFP funds checks. \[[1705](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1705)], \[[1692](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1692)]

  ### <Icon icon="mobile-screen-button" /> Legacy address delivery removed

  All VTXO delivery now uses `ServerMailbox`, completing the migration started in beta.7. Addresses generated with the old delivery method are no longer valid. The legacy gRPC methods `PostArkoorPackageMailbox` and `EmptyArkoorMailbox` have also been removed. \[[1502](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1502)]

  ### <Icon icon="mobile-screen-button" /> Feerate field renames

  All feerate fields in CLI and REST JSON output have been renamed with a `_sat_per_kvb` suffix and now express values in satoshis per kilovirtual byte. The old field names are still present but deprecated. \[[1654](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1654)]

  ### <Icon icon="mobile-screen-button" /> Lightning receive nullability

  The `htlc_vtxos` field in `LightningReceive` (and `LightningReceiveInfo` in the REST API) is now always a list. Previously it was nullable—`null` when no VTXOs were present—which required special handling in client code. It now returns `[]` instead. \[[1669](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1669)]

  ### Additional improvements

  * Round states are now locked in memory during processing, fixing a race condition that could cause concurrent tasks to interfere with each other. \[[1671](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1671)]
  * Lightning receive overpayment from the server is now accepted instead of rejected, improving reliability. \[[1685](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1685)]
  * Lightning send and receive movements now include the preimage when known. \[[1579](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1579)]
  * `received_on` field is now populated for arkoor receive movements, showing which addresses received funds. \[[1610](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1610)]
  * Dust VTXOs are rejected early during refresh and exit, providing immediate feedback instead of waiting for round rejection. \[[1576](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1576)], \[[1580](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1580)]
  * Zero-sat Lightning invoices are now rejected at creation and payment time. \[[1577](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1577)]
  * `bark --version` now returns `DIRTY` with the commit hash when not built from a release tag. \[[1653](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1653)]
  * Round failures and cancellations are now properly reported as errors in the CLI. \[[1640](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1640)]
  * Server no longer schedules a round immediately after startup, waiting for the first interval to pass. \[[1643](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1643)]
  * Default required confirmations for round transactions reduced to 2 (1 on signet). \[[1586](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1586)]
  * All Bark crates have been relicensed from their previous license to the MIT license, making it easier to integrate Bark into commercial and open-source projects alike. \[[1621](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1621)]

  [Full release notes in the repo](https://gitlab.com/ark-bitcoin/bark/-/blob/master/CHANGELOG.md?ref_type=heads).
</Update>

<Update
  label="28 January 2026"
  description="0.1.0-beta.7"
  rss={{
title: "0.1.0-beta.7 - 28 January 2026",
description: "Breaking changes: requires upgrading captaind and bark together. New: unified mailbox, non-blocking maintenance, environment variable config, next round timing, improved Lightning monitoring."
}}
>
  <img src="https://mintcdn.com/second-0659a37d/8VZedF7eKiQd6Pfy/images/2026-mailbox.jpg?fit=max&auto=format&n=8VZedF7eKiQd6Pfy&q=85&s=4dcee4210934e758d30f000cc3bd1020" alt="Unified mailbox" width="2260" height="1346" data-path="images/2026-mailbox.jpg" />

  <Warning>
    **Breaking changes**

    This release includes multiple low-level protocol encoding changes that require upgrading both `captaind` and `bark` together with fresh databases. Wallets and server databases from previous versions are not compatible—you must create new instances before upgrading. See the related changes: \[[1396](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1396)], \[[1550](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1550)], \[[1551](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1551)], \[[1552](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1552)], \[[1412](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1412)]
  </Warning>

  ### <Icon icon="mobile-screen-button" /> Unified mailbox for VTXO delivery

  Bark now uses a unified mailbox system for receiving VTXOs, consolidating multiple delivery paths into a single, reliable channel. Incoming VTXOs now arrive at your mailbox address regardless of source—arkoor payments, Lightning receives, or round outputs.

  For app integrators, this is a foundational step toward push notifications. With all incoming VTXOs flowing through a single mailbox, you can build notification infrastructure that alerts users when they receive funds. \[[1412](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1412)]

  ### <Icon icon="mobile-screen-button" /> Non-blocking maintenance and refresh

  We've added delegated variants of the maintenance and refresh APIs that return immediately instead of blocking until round completion. The new methods—`maintenance_delegated`, `refresh_vtxos_delegated`, and `join_next_round_delegated`—return a pending movement you can track via `sync()`.

  This is useful for mobile apps where blocking during round participation hurts UX. Kick off a refresh, let users continue interacting, and update the UI when the round completes. The CLI also gains a `--delegated` flag for `maintain` and `refresh`. \[[1566](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1566)]

  ### <Icon icon="mobile-screen-button" /> Environment variable configuration

  Bark configuration values can now be set via `BARK_*` environment variables, with a clear priority hierarchy: CLI args > env vars > `config.toml` > defaults. Useful for containerized deployments and CI/CD pipelines. \[[1558](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1558)]

  ### <Icon icon="server" /> Query next round timing

  The server now exposes a `NextRoundTime` endpoint, and Bark's `Wallet` gains a `next_round_start_time()` method. Build UIs that show users when the next round occurs, or schedule background operations around round timing. \[[1559](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1559)]

  ### <Icon icon="server" /> Improved Lightning invoice monitoring

  Lightning invoice status tracking has migrated from polling to stream-based monitoring using TrackAll. This provides real-time updates with automatic recovery after disconnections, reducing latency and resource consumption. \[[1453](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1453)]

  [Full release notes in the repo](https://gitlab.com/ark-bitcoin/bark/-/blob/master/CHANGELOG.md?ref_type=heads).
</Update>

<Update
  label="23 January 2026"
  description="0.1.0-beta.6"
  rss={{
title: "0.1.0-beta.6 - 23 January 2026",
description: "Breaking changes: wallet migration required, custom BarkPersister implementations, server config, gRPC API changes. New: hArk non-interactive rounds, wallet seed security, offboard restored, crash recovery, full async API, dynamic fee estimation, dust VTXO support."
}}
>
  <img src="https://mintcdn.com/second-0659a37d/8VZedF7eKiQd6Pfy/images/2026-hark.jpg?fit=max&auto=format&n=8VZedF7eKiQd6Pfy&q=85&s=fd579d584898a681d1b6643926be6479" alt="hArk protocol" width="1920" height="1080" data-path="images/2026-hark.jpg" />

  <Warning>
    **Breaking changes**

    * **[Wallet migration required](#wallet-seed-security-upgrade):** Wallets created before this release will not load. Create a new wallet and transfer funds before upgrading.
    * **[Custom BarkPersister implementations](#crash-recovery-for-vtxo-storage):** Update `store_vtxos` to be idempotent.
    * **[Server configuration](#dynamic-fee-estimation):** Fee-related config options replaced with `[fee_estimator]` section.
    * **[gRPC API](#grpc-api-changes):** Multiple endpoints added, renamed, or removed.
  </Warning>

  ### <Icon icon="gear" /> Introducing hArk—non-interactive rounds

  We've implemented hArk (Hash-lock Ark), a major protocol evolution that eliminates synchronous interactivity during rounds. In the standard Ark protocol, all round participants receiving new VTXOs must be online simultaneously to sign intermediate transactions in the VTXO tree. hArk removes this requirement through a secret-based mechanism: the server generates a unique secret for each new VTXO, and participants can claim their VTXOs asynchronously by signing a forfeit transaction and receiving their secret from the server.

  This change brings several benefits:

  * Round participants no longer need to coordinate their online presence—the round can complete without requiring synchronous signing from all parties
  * Enables efficient consolidation of multiple VTXOs into a single output, addressing a significant constraint in the previous design where multi-input operations were problematic
  * Reduces server costs during malicious exit scenarios, eliminating attacks that were cheap for adversaries but expensive for the server to counter \[[1440](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1440)]

  ### <Icon icon="mobile-screen-button" /> Wallet seed security upgrade

  We've replaced `VtxoSeed` with `WalletSeed` to support deriving dedicated keys for mailbox functionality. As part of this change, normal key derivations have been replaced with hardened derivations, which provide stronger security guarantees by preventing parent key exposure from compromising child keys. Wallets created before this release will not load—you must create a new wallet and transfer your funds before upgrading. \[[1452](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1452)]

  ### <Icon icon="mobile-screen-button" /> Offboard and send-onchain restored

  After temporarily disabling offboard functionality during the hArk transition, we've re-enabled it with improvements. The `bark send-onchain` command now returns the offboard transaction ID, and using offboard swaps, the transaction is broadcast instantly. The REST API endpoints for `offboard_vtxos` and `offboard_all` are also restored, now returning a simple `TxId`. \[[1531](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1531)], \[[1534](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1534)]

  ### <Icon icon="mobile-screen-button" /> Crash recovery for VTXO storage

  VTXO storage operations are now idempotent, enabling reliable crash recovery. Previously, if your wallet crashed during `persist_round_success`—after storing new VTXOs but before cleanup—subsequent sync attempts would fail on duplicate database inserts, leaving your wallet stuck. Now, `store_vtxos` succeeds without modification if a VTXO already exists, and `mark_vtxos_as_spent` succeeds if a VTXO is already spent. If you've implemented a custom `BarkPersister`, you must update `store_vtxos` to be idempotent. \[[1528](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1528)]

  ### <Icon icon="mobile-screen-button" /> Full async API

  The entire `BarkPersister` API is now async, and most of Bark's API has become async as a result. This enables non-blocking I/O operations for better resource utilization and scalability, particularly beneficial for applications handling concurrent wallet operations. \[[1485](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1485)]

  ### <Icon icon="server" /> Dynamic fee estimation

  The server now uses a centralized `FeeEstimator` that queries bitcoind for current fee estimates instead of relying on hardcoded fallback rates. The estimator provides three fee tiers: fast (1-block target), regular (3-block target), and slow (6-block target), falling back to configurable rates when estimation fails.

  The `round_tx_feerate`, `[vtxo_sweeper] sweep_tx_fallback_feerate`, `[forfeit_watcher] claim_fallback_feerate`, and `[vtxopool] issue_tx_fallback_feerate` config options have been removed. Replace them with the new `[fee_estimator]` section: \[[1496](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1496)]

  ```toml theme={"theme":{"light":"github-light","dark":"github-dark"}}
  [fee_estimator]
  update_interval = "60s"
  fallback_fee_rate_fast = 10      # sat/vB for 1-block target
  fallback_fee_rate_regular = 5    # sat/vB for 3-block target
  fallback_fee_rate_slow = 2       # sat/vB for 6-block target
  ```

  ### <Icon icon="mobile-screen-button" /> Dust VTXO support

  Bark now supports sending and receiving dust VTXOs (very small amounts), with dust isolation ensuring these small outputs don't cause issues with transaction construction. This applies to both direct sends and Lightning operations. The server adds a new `max_arkoor_fanout` config option to control the maximum number of arkoor outputs. \[[1440](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1440)]

  ### <Icon icon="server" /> Board registration security

  The server now validates the board server pubkey during registration, rejecting boards signed with a different server pubkey. This prevents potential double-spend attacks where a malicious party could register boards from a different server. The `BoardBuilder::new_from_vtxo` method also validates that server pubkey, funding txid, and VTXO ID match expected values. \[[1472](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1472)]

  ### <Icon icon="mobile-screen-button" /> Improved Lightning receive claiming

  The `Wallet::try_claim_all_lightning_receives` behavior has been improved to be more resilient. Previously, it would bail on the first error; now it continues attempting to claim all pending receives. It returns success if at least one pending receive is claimed (or if there are none to claim), only returning an error if all claims fail. \[[1516](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1516)]

  ### <Icon icon="server" /> Block-based sync infrastructure

  We've introduced `SyncManager` and `BlockIndex` utilities for block-based synchronization, replacing the previous `TipFetcher`. Configure how frequently the sync manager polls with the new `sync_manager_block_poll_interval` config option. The `bitcoin-ext` crate also adds `get_block_by_height` for fetching blocks by height from bitcoind. \[[1471](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1471)]

  ### <Icon icon="server" /> Configuration naming consistency

  We've renamed `hodl` references to `hold` throughout configuration and code, fixing the inconsistent spelling that could cause confusion. Update any configuration or code that uses `hodl` terminology. \[[1478](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1478)]

  ### <Icon icon="gear" /> gRPC API changes

  The hArk transition introduces new gRPC endpoints for non-interactive round participation:

  * `SubmitRoundParticipation`
  * `RoundParticipationStatus`
  * `RequestLeafVtxoCosign`
  * `RequestForfeitNonces`
  * `ForfeitVtxos`

  The existing `SubmitPayment` endpoint now returns an `unlock_hash`.

  Several methods and types have also been renamed:

  * `CheckpointedCosignOor` → `RequestArkoorCosign`
  * `CheckpointedPackageCosignRequest` → `ArkoorPackageCosignRequest`
  * `CheckpointedPackageCosignResponse` → `ArkoorPackageCosignResponse`
  * `VtxoRequest` → `ArkoorDestination` (in arkoor context)
  * `RequestLightningPayHtlcCosign` now returns `ArkoorPackageCosignResponse`
  * `RequestLightningPayHtlcRevocation` now takes `ArkoorPackageCosignRequest`
  * `ClaimLightningReceiveRequest` now includes `ArkoorPackageCosignRequest`

  The following have been removed:

  * `PostArkoorPackageMailbox` gRPC method
  * `start_lightning_payment`, `finish_lightning_payment`, `revoke_lightning_payment` methods
  * `wait` field from `InitiateLightningPaymentRequest`
  * `max_arkoor_depth` field from `ArkInfo` \[[1440](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1440)], \[[1499](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1499)], \[[1501](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1501)]

  [Full release notes in the repo](https://gitlab.com/ark-bitcoin/bark/-/blob/master/CHANGELOG.md?ref_type=heads).
</Update>

<Update
  label="8 January 2026"
  description="0.1.0-beta.3 to beta.5"
  rss={{
title: "0.1.0-beta.3 to beta.5 - 8 January 2026",
description: "Highlights: Barkd daemon wallet with REST API, ark-lib browser compatibility, checkpoints replace arkoor-depth, comprehensive wallet history, round participation control, Lightning reliability."
}}
>
  <img src="https://mintcdn.com/second-0659a37d/8VZedF7eKiQd6Pfy/images/2026-20250108-barkd.jpg?fit=max&auto=format&n=8VZedF7eKiQd6Pfy&q=85&s=8bb46e71ab5db50811ff7a01592cece1" alt="Barkd" width="1920" height="1080" data-path="images/2026-20250108-barkd.jpg" />

  Highlights from our recent beta releases, including a daemon-based wallet with REST API, browser compatibility for ark-lib, and a comprehensive wallet history system.

  ### <Icon icon="mobile-screen-button" /> Introducing Barkd—a daemon wallet with REST API

  We've launched Barkd, a wallet that runs as a daemon with a RESTful API. This is the solution for node runners or business owners who want to implement simple automation on their wallet. Client libraries are available in [multiple languages](https://gitlab.com/ark-bitcoin/barkd-clients) to get you started quickly. \[[1297](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1297)], \[[1291](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1291)]

  ### <Icon icon="gear" /> ark-lib now runs in the browser

  We've made ark-lib Wasm-compatible, enabling address inspection and VTXO hex deserialization directly in web environments. \[[1363](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1363)]

  ### <Icon icon="gear" /> Checkpoints replace arkoor-depth limitation

  The arkoor-depth limitation was necessary to protect the server but resulted in bad UX. We've replaced it with checkpoints—a new protection mechanism that removes the depth restriction while maintaining security. \[[1310](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1310)], \[[1342](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1342)], \[[1343](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1343)], \[[1394](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1394)]

  ### <Icon icon="mobile-screen-button" /> Comprehensive wallet history

  The new `bark history` command provides a complete overview of all cases where bitcoin goes in or out of your wallet—boards, arkoor transactions, round participation, and Lightning payments. \[[1455](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1455)], \[[1362](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1362)], \[[1355](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1355)], \[[1354](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1354)], \[[1414](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1414)], \[[1275](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1275)]

  ### <Icon icon="mobile-screen-button" /> More control over round participation

  You can now pick into ongoing rounds and control when they finish, with better status reporting through typed enums. We've also worked hard to ensure that when a round goes wrong, you won't feel any pain. \[[1328](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1328)], \[[1445](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1445)]

  ### <Icon icon="server" /> Lightning payment reliability

  Lightning sends and receives are *even faster and more robust*. We've stress-tested the implementation and fixed various edge cases including overpaying invoices, HTLC timeout handling, and users not appearing to claim funds. \[[1401](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1401)], \[[1331](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1331)], \[[1419](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1419)], \[[1398](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1398)], \[[1414](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1414)]

  You can find more detailed release notes in the [repo](https://gitlab.com/ark-bitcoin/bark/-/blob/master/CHANGELOG.md?ref_type=heads).
</Update>

<Update
  label="4 November 2025"
  description="0.1.0-beta.2"
  rss={{
title: "0.1.0-beta.2 - 4 November 2025",
description: "Breaking changes: VTXO state simplification and BlockRef representation. New: immediate VTXO usage, streamlined state management, non-mutable wallet API, Lightning receive security, dust handling, network-specific timeouts."
}}
>
  <img src="https://mintcdn.com/second-0659a37d/8VZedF7eKiQd6Pfy/images/2025-byte-at-work.jpg?fit=max&auto=format&n=8VZedF7eKiQd6Pfy&q=85&s=73d3c4081ef12d9f738631233c8e0c89" alt="Byte at work" width="1920" height="1080" data-path="images/2025-byte-at-work.jpg" />

  Our second beta release simplifies VTXO state management, enhances the user experience with immediate VTXO availability, and makes wallet integration easier with non-mutable API methods.

  <Warning>
    **Breaking changes**

    The VTXO state simplification and `BlockRef` representation changes may require code updates if you're building on the bark API or CLI.
  </Warning>

  ### <Icon icon="mobile-screen-button" /> Immediate VTXO usage in rounds

  Bark now uses newly issued VTXOs within the same round they're created, eliminating the previous requirement to wait for funding transaction confirmations. No more frustrating waits between receiving bitcoin and being able to spend it. Your users can participate in the next action immediately, making Ark feel more responsive and intuitive. \[[1261](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1261)]

  ### <Icon icon="gear" /> Streamlined VTXO state management

  We've dramatically simplified the VTXO state system. Previously, the number of VTXO states started exploding and it was hard to keep track of them. We've reduced them down to just three: `Spendable`, `Locked`, and `Spent`. This makes it much easier to reason about which VTXOs can be used in your app, reducing cognitive load and potential bugs. \[[1222](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1222)]

  ### <Icon icon="mobile-screen-button" /> Non-mutable wallet API methods

  The bark API now makes nearly all methods on the `Wallet` struct non-mutable, letting the library handle internal locking and state management for you. This is a major ergonomic improvement—you no longer need to juggle mutable references or worry about concurrent access patterns. The API is now more intuitive and less error-prone, making integration significantly smoother. \[[1194](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1194)], \[[1161](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1161)], \[[1152](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1152)], \[[1171](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1171)]

  ### <Icon icon="mobile-screen-button" /> Enhanced Lightning receive security and speed

  The Lightning receive functionality received a comprehensive security audit and makeover. We now ensure all timeouts are sensible and valid, eliminating potential edge cases that could compromise safety. A key benefit is support for shorter `min_final_cltv_delta` values on invoices without sacrificing security—your users get faster Lightning receives while maintaining the same safety guarantees. \[[832](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/832)]

  ### <Icon icon="gear" /> Minimum board amount

  Servers can now enforce a minimum board amount, giving operators better control over liquidity management and preventing dust-sized boards that create operational inefficiencies. App developers can retrieve this limit from the `ArkInfo` structure, allowing you to provide appropriate feedback to users before they attempt to board. \[[1257](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1257)]

  ### <Icon icon="mobile-screen-button" /> Intelligent on-chain spends that refresh VTXOs automatically

  On-chain spends now include `should_refresh_vtxos` by default, making the process more efficient. When you make an on-chain spend from your Ark balance, Bark automatically refreshes any VTXOs that are uneconomical to exit or soon-to-expire within the same round participation. This should reduce the need for separate, dedicated refresh operations. \[[1224](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1224)]

  ### <Icon icon="mobile-screen-button" /> Reorganized crate structure for cleaner dependencies

  The `bark` binary has moved to the `bark-cli` crate, which now contains all CLI binaries. If you're a Rust developer using the `bark-wallet` crate, you'll benefit from a more minimal and focused set of default features—smaller compile times, cleaner dependency trees, and less bloat in your final binaries. \[[1233](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1233)]

  ### <Icon icon="mobile-screen-button" /> Simplified VTXO filtering

  The VTXO filter trait has been streamlined, making it significantly easier to implement custom VTXO filters. The interface is now more focused and intuitive, reducing the boilerplate needed to control which VTXOs your application considers for spending. \[[1250](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1250)]

  ### <Icon icon="mobile-screen-button" /> Network-specific timeouts for faster development

  Bark API defaults are now network-aware, automatically using shorter timeouts on test networks. This makes development and testing cycles faster and more responsive, while maintaining conservative timeouts on mainnet for production safety. \[[1167](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1167)]

  ### <Icon icon="mobile-screen-button" /> Re-exported essential crates

  The `bdk` and `bip39` crates are now re-exported directly from Bark, eliminating version mismatches and making integration smoother. You no longer need to manually ensure you're using compatible versions of these dependencies. \[[1241](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1241)], \[[1205](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1205)]

  ### <Icon icon="mobile-screen-button" /> Improved CLI usability

  Several CLI improvements enhance day-to-day development workflows:

  * **Readable block references:** `BlockRef` is now displayed as `<string:height>` in bark-cli, making output far more readable for humans. Note this is a breaking change for scripts parsing bark-cli output. \[[1232](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1232)]
  * **Cleaner VTXO display:** `bark vtxos` now shows only unspent VTXOs by default, reducing visual noise. Run `bark vtxos --all` when you need comprehensive information. \[[1214](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1214)]
  * **Complete transaction history:** `bark onchain transaction` lists all on-chain transactions with pagination removed for a streamlined view. \[[1148](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1148)]
  * **Safer VTXO management:** The command to drop VTXOs from the database has been moved to `bark dev` with explicit danger warnings—you must acknowledge the risk of bitcoin loss before proceeding. \[[1215](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1215)]

  ### <Icon icon="mobile-screen-button" /> Standardized Lightning invoice queries

  APIs for querying Lightning invoice status now uniformly accept a `PaymentHash`, providing a consistent interface across all Lightning-related operations and eliminating confusion about which identifier to use. \[[1164](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1164)]

  ### <Icon icon="mobile-screen-button" /> Better error messages for chain source issues

  When esplora is misconfigured, Bark now provides clear, actionable error messages instead of dumping invalid hex values. This makes troubleshooting connection issues significantly faster and less frustrating. \[[1211](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1211)]
</Update>

<Update
  label="14 October 2025"
  description="0.1.0-beta.1"
  rss={{
title: "0.1.0-beta.1 - 14 October 2025",
description: "First beta release: published on crates.io, enhanced Lightning receives, wallet liveness management, comprehensive state inspection, developer tooling, explicit maintenance, optimized dev network defaults."
}}
>
  <img src="https://mintcdn.com/second-0659a37d/8VZedF7eKiQd6Pfy/images/2025-now-in-beta.jpg?fit=max&auto=format&n=8VZedF7eKiQd6Pfy&q=85&s=472084c1a13b10823dc1beb102cf059a" alt="Ark is now in beta" width="1920" height="1024" data-path="images/2025-now-in-beta.jpg" />

  Here comes our **first beta release**—reflecting out switch from "move fast and break things" mode to "move fast and break less things" mode as we get closer to having our Ark implementation ready for you on mainnet. From here out, the API should be a lot more stable for you to build on.

  This release also marks our first publication on [crates.io](https://crates.io/crates/bark-wallet) and [docs.rs](https://docs.rs/bark-wallet/latest/bark/), providing production-ready tooling and comprehensive documentation for developers building on the Ark protocol.

  <Warning>
    **Breaking changes**

    `bark-0.1.0-beta.1` is only compatible with `captaind-0.1.0-beta.1`. There is no upgrade path from alpha versions—you must drain your wallet and create a new one.
  </Warning>

  ### <Icon icon="mobile-screen-button" /> Enhanced Lightning receive functionality

  We've significantly improved the reliability and efficiency of Lightning receives, rebuilding the feature from the ground up. Instead of requiring an inbound Lightning payment to be confirmed in-round (resulting in a long "pending" status for senders), we now use arkoor, ensuring senders get fast confirmations while HTLCs ensure the received sats are under the receiver's control. It results in a bit more temporary trust, but we think it's worth it to yield a much better UX for users. \[[974](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/974)]

  ### <Icon icon="mobile-screen-button" /> Lightning receive CLI improvements

  We've added two QOL improvements for managing Lightning receives. First, you can now claim all outstanding Lightning receives with a single command by omitting the invoice argument from `bark lightning claim`—perfect for batch processing and wallet maintenance scripts. Second, the new `--wait` flag lets you await invoice payment upon creation, eliminating the need to poll for payment status and enabling more responsive payment flows in your applications. \[[1119](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1119)], \[[984](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/984)]

  ### <Icon icon="mobile-screen-button" /> Wallet liveness management for mobile apps

  Understanding when your wallet needs to wake up is critical for mobile apps. We've added methods that determine precisely when the next refresh is required, enabling mobile wallet developers to meet Ark's liveness requirements efficiently without draining battery life. \[[1096](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1096)]

  ### <Icon icon="mobile-screen-button" /> Comprehensive wallet state inspection

  We've expanded wallet inspection capabilities far beyond basic balance checking. Developers can now view the complete state of their wallet, including not only spendable VTXOs but also those that are already spent or currently being processed. \[[1107](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1107)]

  ### <Icon icon="mobile-screen-button" /> Developer tooling and debugging capabilities

  We've added a dedicated `dev` CLI command that provides deep visibility into wallet status and operations. This developer-focused tooling facilitates even deeper monitoring and debugging during integration and testing phases. \[[1082](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1082)]

  ### <Icon icon="mobile-screen-button" /> Explicit wallet maintenance operations

  Ark wallets require periodic maintenance—syncing with the chain, refreshing VTXOs, and checking for new bitcoin. We've consolidated these operations into a clear, explicit `maintain` command that makes wallet upkeep straightforward and predictable. This is particularly valuable for systems that need deterministic maintenance scheduling. \[[1088](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1088)]

  ### <Icon icon="mobile-screen-button" /> Streamlined Lightning commands

  For developers working extensively with Lightning, we've introduced the `bark ln` alias as a shorthand for `bark lightning` commands. \[[1114](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1114)]

  ### <Icon icon="mobile-screen-button" /> Optimized development network defaults

  We've configured sensible defaults for development networks, including a default esplora backend and optimized refresh thresholds. These improvements reduce configuration overhead and help developers get up and running quickly. We've also added support for [Mutinynet](https://github.com/MutinyWallet/mutiny-net), expanding your testing options. \[[1092](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1092)], \[[1031](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1031)]

  ### <Icon icon="mobile-screen-button" /> Customizable logging and verbosity

  Environment flags now control verbosity levels, giving developers precise control over logging output during development and debugging. This makes it easier to diagnose issues without being overwhelmed by unnecessary log noise. \[[1014](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1014)]

  ### <Icon icon="mobile-screen-button" /> Critical bug fixes

  Several important bug fixes enhance the reliability of core operations:

  * **Deterministic VTXO ordering:** Input VTXOs are now ordered deterministically when passed to arkoor packages, ensuring consistent transaction processing across all platforms \[[1094](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1094)]
  * **Faster wallet initialization:** Creating new wallets with bitcoind no longer triggers unnecessary full syncs, dramatically reducing setup time \[[1063](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1063)]
  * **Safer board registration:** Boards are only registered after achieving sufficient confirmations, preventing premature registrations that could cause issues \[[1069](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1069)]
  * **Subdust change handling:** The wallet now properly discards subdust change outputs, preventing transaction inefficiencies \[[1043](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1043)]

  ### <Icon icon="gear" /> Improved code clarity through refactoring

  We've made several naming improvements to enhance code readability and maintainability:

  * Renamed `ChainSourceClient` to `ChainSource` for clearer semantics \[[1099](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1099)]
  * Renamed `round_tx` to `funding_tx` to better reflect its purpose \[[991](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/991)]

  ### <Icon icon="gear" /> Comprehensive documentation

  In addition to publishing on crates.io and docs.rs, we've significantly expanded our inline documentation across all major components:

  * Wallet struct \[[1059](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1059)]
  * On-chain wallet \[[1058](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1058)]
  * Persist module \[[1056](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1056)], \[[1055](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1055)]
  * Round module \[[1057](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1057)]
  * Server module \[[1022](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1022)]
  * Config struct \[[1020](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1020)]
  * VtxoState \[[1019](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1019)]
  * Exit module \[[1018](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1018)]
  * VTXO selection \[[1017](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/1017)]
</Update>

<Update
  label="10 September 2025"
  description="0.0.0-alpha.19"
  rss={{
title: "0.0.0-alpha.19 - 10 September 2025",
description: "Breaking changes: aspd renamed to captaind, bark crate renamed to bark-wallet. New: BOLT-12 offers, RBF for exits, enhanced addresses, bulletproof rounds, opt-in on-chain wallet, mobile support, gRPC separation."
}}
>
  <img src="https://mintcdn.com/second-0659a37d/8VZedF7eKiQd6Pfy/images/2025-captains-hat.png?fit=max&auto=format&n=8VZedF7eKiQd6Pfy&q=85&s=c9dcb6272e1aceec40d6b235c5cf239f" alt="A captain's hat (aspd got renamed to captaind)" width="1920" height="1080" data-path="images/2025-captains-hat.png" />

  We've moved to numbered releases to provide better version tracking and compatibility guarantees. This changelog covers updates from `captaind-0.0.0-alpha.19` and `bark-0.0.0-alpha.19`.

  <Warning>
    **Breaking changes**

    These releases include significant breaking changes:

    * `aspd` has been renamed to `captaind` with no migration path from alpha.18
    * `bark-0.0.0-alpha.19` is only compatible with `captaind-0.0.0-alpha.19`
    * If you're using older versions, you must drain your wallet and create a new one
    * The bark crate has been renamed from `bark-client` to `bark-wallet`
  </Warning>

  ### <Icon icon="server" /> Major rename—aspd is now captaind

  We've renamed `aspd` to `captaind` to better reflect the Ark server's role as the captain of your Ark operations. **Important:** There is no migration path from `aspd-0.0.0-alpha.18`—it's recommended to drain bitcoin from old instances and start fresh with `captaind`. In addition, all instances of `asp` have been renamed to `ark_server` throughout the codebase, and the bark crate has been renamed from `bark-client` to `bark-wallet`. This provides better clarity on what each component is doing! \[[900](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/900)]

  ### <Icon icon="mobile-screen-button" /> Support for BOLT-12 offers

  Ark now supports paying BOLT-12 offers, bringing you improved privacy and reusability on Lightning. This addition makes Ark compatible with the next generation of Lightning invoices, providing better user experiences for recurring payments and static payment codes. \[[867](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/867)], \[[807](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/807)]

  ### <Icon icon="mobile-screen-button" /> RBF support for stuck exits

  We've implemented Replace-By-Fee (RBF) functionality in the exit system, allowing you to increase fee rates if an exit transaction gets stuck in the mempool. This gives you more control over your exit timing and ensures your bitcoin is never trapped due to low fee rates during high-traffic periods. \[[896](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/896)]

  ### <Icon icon="mobile-screen-button" /> Enhanced Ark addresses with delivery mechanisms

  Ark addresses now include delivery mechanisms, providing more flexibility with various wallet interfaces and payment flows when sharing payment information. \[[894](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/894)]

  ### <Icon icon="mobile-screen-button" /> Bulletproof round participation

  Bark now responds defensively when an Ark server misbehaves during a round. This critical reliability improvement ensures your bitcoin remains safe even if the server encounters issues or acts maliciously during round processing. \[[564](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/564)]

  ### <Icon icon="mobile-screen-button" /> Opt-in on-chain wallet

  The BDK wallet is now optional, allowing developers using alternative on-chain wallet solutions to integrate Ark without compiling BDK dependencies. This reduces binary size and compilation time for projects that already have their own wallet infrastructure. \[[923](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/923)]

  ### <Icon icon="server" /> Enhanced mobile wallet support

  The server now returns the last round on subscription, helping mobile wallets participate in rounds after being woken up by notification servers. This improvement ensures mobile users don't miss rounds due to background app limitations and provides better overall mobile experience. \[[898](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/898)]

  ### <Icon icon="server" /> Granular admin control with gRPC service separation

  We've split up the admin gRPC services and provided tighter control over which services to expose, giving server operators more flexibility in managing access to administrative functions. This security enhancement allows for more granular permission management.

  ### <Icon icon="mobile-screen-button" /> Significant CLI improvements

  The `bark` CLI now includes several developer-friendly enhancements:

  * Support for `BARK_DATADIR` environment variable for easier config management \[[946](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/946)]
  * `bark wallet create --force` command to create wallets when the Ark server isn't available \[[922](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/922)]
  * Added more details to the display of on-chain balances for improved visibility \[[870](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/870)]

  ### <Icon icon="mobile-screen-button" /> Faster round synchronization

  We've parallelized the round-sync process, significantly improving sync performance and reducing the time needed to catch up with the latest Ark state. This enhancement is particularly beneficial for wallets that have been offline for extended periods. \[[912](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/912)]

  ### <Icon icon="server" /> Enhanced operational reliability

  Several improvements enhance server stability and observability:

  * Consistent use of `DateTime<Local>` over `DateTime<UTC>` for better handling of (the dreaded) timezones \[[861](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/861)]
  * Various telemetry fixes and improvements for better monitoring \[[890](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/890)]
  * Better error messages throughout the system \[[914](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/914)]
  * Removal of secrets from logs for improved security \[[915](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/915)]

  ### <Icon icon="mobile-screen-button" /> Improved wallet reliability

  Additional fixes ensure better wallet behavior:

  * Fixed early bailout issues in sync process \[[884](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/884)]
  * Correct fee application when claiming exits \[[887](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/887)]
  * Support for Lightning payments requiring multiple input VTXOs
  * `bark config` now outputs proper JSON format \[[911](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/911)]
  * Various fixes to the exit system for improved reliability \[[896](https://gitlab.com/ark-bitcoin/bark)]
</Update>

<Update label="5 August 2025">
  <img src="https://mintcdn.com/second-0659a37d/8VZedF7eKiQd6Pfy/images/2025-ark-address-scan.jpg?fit=max&auto=format&n=8VZedF7eKiQd6Pfy&q=85&s=10fdd411561f334806e04dd324c0f05d" alt="Byte scanning a QR code using our new Ark address format with a smartphone" width="1536" height="1024" data-path="images/2025-ark-address-scan.jpg" />

  ### <Icon icon="gear" /> Finally, an Ark address format!

  We've introduced a new address format specifically designed for payments within the Ark. This makes it much easier to send and receive bitcoin using Ark, providing a familiar address-based experience similar to regular bitcoin transactions. This was also an opportunity to launch [our new BOAT (Basis Of Ark Technology) specifications](https://github.com/ark-protocol/boats/). \[[842](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/842)]

  ### <Icon icon="mobile-screen-button" /> Hefty Lightning receive fees eliminated

  We've removed the default 350 satoshi fee that was previously charged for every Lightning receive operation. Lightning receives now use child-pays-for-parent (CPFP) to confirm transactions instead of requiring direct fees. This makes receiving Lightning payments through Ark completely free until we implement our fee schedule (WIP). Make those free signet payments while you still can!

  ### <Icon icon="mobile-screen-button" /> Lightning invoice management

  Bark now allows you to request and view all generated Lightning invoices through both the API and CLI. This gives you complete visibility into your Lightning payment history, making it easier to track incoming payments. \[[850](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/850)]

  ### <Icon icon="gear" /> Protocol version negotiation

  Our implementation of the Ark protocol now has a proper version system that allows bark and Ark servers to negotiate compatibility automatically. This ensures smooth communication between different versions and provides a foundation for future protocol upgrades. \[[847](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/847)], \[[837](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/837)]

  ### <Icon icon="server" /> Enhanced error reporting for missing VTXOs

  The Ark server now provides comprehensive error reporting, showing all missing VTXOs instead of stopping at the first one. This makes debugging and troubleshooting much more efficient for both developers and server operators. \[[819](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/819)]

  ### <Icon icon="mobile-screen-button" /> Simplified wallet architecture

  We've split the on-chain wallet from the Ark wallet, making it easier to integrate Ark into applications that already have existing on-chain wallet functionality. Developers can now use the `OffchainWallet` as a default implementation while maintaining full control over their on-chain operations. Note that you must now explicitly sync both wallets.

  ### <Icon icon="mobile-screen-button" /> Cleaner API naming conventions

  We've standardized on using `lightning_receive` consistently throughout the codebase and API, replacing the previous mix of `bolt11_board` and `offchain_board` terminology. Less confusing and more intuitive! \[[852](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/852)]

  ### <Icon icon="mobile-screen-button" /> Enhanced type safety for payments

  Bark now uses proper `PaymentHash` and `PaymentPreimage` types instead of generic byte arrays, providing better type safety and making the codebase more maintainable for developers building on Ark.

  ### <Icon icon="mobile-screen-button" /> Simplified keychain management

  We've removed the internal/external keychain concept that provided limited benefits for Ark wallets, streamlining the wallet architecture and reducing complexity for developers. \[[840](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/840)]

  ### <Icon icon="code-branch" /> Improved chain source configuration

  The `ChainSourceClient` now supports network configuration and validation, with built-in fee caching and memory functionality. This provides more reliable chain interactions and better resource management.

  ### <Icon icon="code-branch" /> Optimized binary sizes for API users

  When building bark, the resulting binaries are now significantly smaller, reducing deployment overhead and making it easier to integrate Ark into resource-constrained environments. \[[832](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/832)]

  ### <Icon icon="server" /> Reduced memory footprint for transaction indexing

  We've optimized the memory usage of the TxIndex system, making Ark servers more efficient and capable of handling larger transaction volumes with less resource consumption. \[[817](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/817)]

  ### <Icon icon="server" /> Telemetry stability improvements

  Fixed an issue that occasionally caused the telemetry system to crash, improving the overall stability and observability of Ark server operations. \[[853](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/853)]

  <Warning>
    **Breaking changes**

    This release is only compatible with aspd-0.0.0-alpha.18 and requires upgrading both bark and the Ark server in lockstep. There is no smooth upgrade path from bark-0.0.0-alpha.17—you must drain your wallet and create a new one.
  </Warning>
</Update>

<Update label="4 July 2025">
  <img src="https://mintcdn.com/second-0659a37d/8VZedF7eKiQd6Pfy/images/2025-pay2anchor.jpg?fit=max&auto=format&n=8VZedF7eKiQd6Pfy&q=85&s=8bdb308c638f55419e0435759b785c67" alt="Pay2Anchor has dropped on Ark" width="1536" height="1024" data-path="images/2025-pay2anchor.jpg" />

  ### <Icon icon="gear" /> Cheaper emergency exits with Pay2Anchor

  Leaning on our addition of Pay2Anchor support to the rust-bitcoin dependency, we've now integrated P2A directly into Ark itself, switching from P2WSH OP\_TRUE outputs. This significantly reduces the cost of emergency exits, making it cheaper and more efficient when you need to exit the Ark in an emergency. \[[565](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/565)]

  ### <Icon icon="mobile-screen-button" /> More ergonomic bark API

  We've made the bark API more developer-friendly, providing a better experience for wallet developers using the Rust crate to build on Ark. \[[623](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/623)], \[[615](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/615)]

  ### <Icon icon="gear" /> Enhanced security with single-input arkoor

  We've removed support for multi-input arkoor transactions, reducing the liquidity burden on Ark servers and implementing important mitigations against partial exit attacks. \[[658](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/658)], \[[707](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/707)]

  ### <Icon icon="gear" /> Simplified arkoor and Lightning payments

  We've done a major cleanup of arkoor and Lightning payment code, making it much easier to read and maintain while providing a cleaner API for external developers building on Ark. \[[686](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/686)], \[[682](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/682)]

  ### <Icon icon="server" /> Advanced Lightning payment infrastructure

  We've implemented sophisticated fail-over mechanisms and enhanced error recovery logic for Lightning payments. This goes beyond our previous send implementation fixes, providing comprehensive infrastructure-level resilience for Lightning payment routing and execution. \[[580](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/580)], \[[625](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/625)]

  ### <Icon icon="mobile-screen-button" /> Enhanced privacy with unique public keys

  Bark now avoids reusing public keys when receiving bitcoin, providing similar privacy benefits to avoiding address reuse in regular bitcoin transactions. \[[586](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/586)]

  ### <Icon icon="mobile-screen-button" /> Completely rewritten emergency exit

  We've rewritten the emergency exit functionality from the ground up, providing better debugging tools, status reporting, and more granular control over the exit process. \[[729](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/729)]

  ### <Icon icon="gear" /> VTXO amount limits for better liquidity management

  We've implemented limits on VTXO amounts to prevent a single user from consuming all of the server's liquidity, ensuring fair access and better resource distribution across all users. \[[583](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/583)]

  ### <Icon icon="gear" /> Streamlined boarding flow architecture

  Beyond our May improvements to boarding reliability and recovery mechanisms, we've now refactored the board flow architecture to make the process even more reliable. \[[718](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/718)]

  ### <Icon icon="server" /> Enhanced Docker deployment experience across architectures

  We've significantly improved the Docker deployment experience across all supported platforms. These enhancements make it much easier for developers to spin up an Ark server locally for testing and development purposes, regardless of their hardware architecture. \[[717](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/717)], \[[711](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/711)], \[[680](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/680)], \[[653](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/653)]

  ### <Icon icon="server" /> More efficient transaction indexing

  We've improved the efficiency of our TxIndex system, reducing resource consumption and fixing a bug that prevented the Ark server from shutting down gracefully in certain scenarios. \[[710](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/710)], \[[647](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/647)]

  ### <Icon icon="code-branch" /> Updated to bitcoin 29.0

  We've updated our dependencies to support bitcoin 29.0, ensuring Ark stays current with the latest bitcoin protocol improvements. \[[559](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/559)]

  ### <Icon icon="code-branch" /> Cleaner dependency management

  We've eliminated our reliance on custom forks and are now using published and peer-reviewed dependencies, making Ark more stable and easier to maintain. \[[705](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/705)]

  ### <Icon icon="code-branch" /> Enhanced testing infrastructure

  We've introduced flake\_finder to handle intermittent test failures and split up our test directory for better organization when running tests with different chain backends. \[[592](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/592)], \[[661](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/661)]
</Update>

<Update label="6 May 2025">
  <img src="https://mintcdn.com/second-0659a37d/8VZedF7eKiQd6Pfy/images/2025-mobile-lightning.jpg?fit=max&auto=format&n=8VZedF7eKiQd6Pfy&q=85&s=a314e553d3bbacc698300f21b3502561" alt="Lightning payments being blasted out from a mobile device using Ark" width="1536" height="1024" data-path="images/2025-mobile-lightning.jpg" />

  ### <Icon icon="server" /> Enhanced Lightning payment reliability

  We've significantly improved our Lightning send implementation with more robust logic and implemented revocation of failed Lightning payments, making the entire Lightning payment process more reliable and secure. \[[533](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/533)], \[[434](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/434)]

  ### <Icon icon="mobile-screen-button" /> Lightning command for invoice payments

  Bark now includes a dedicated Lightning sub-command that can be used to pay Lightning invoices directly, making it easier than ever to use Ark for Lightning payments. \[[540](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/540)]

  ### <Icon icon="server" /> Improved on-chain wallet management

  We've completely restructured the Ark server's on-chain wallet management to address unexpected challenges with conflicting transactions. By splitting the wallet into different parts, we've eliminated these issues for good. \[[523](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/523)]

  ### <Icon icon="server" /> Runtime task management system

  A new runtime manager was introduced to coordinate all background tasks such as VTXO sweeping and round creation, bringing more stability and reliability to Ark server operations. \[[521](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/521)]

  ### <Icon icon="gear" /> Docker images for multiple architectures

  We've released Docker images for various architectures, making it significantly easier to spin up an Ark server locally for development and testing. \[[525](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/525)]

  ### <Icon icon="server" /> Fixed round participation issue

  We resolved a bug where the server would incorrectly refuse to serve a VTXO because it falsely believed the VTXO was already participating in another round, improving overall reliability. \[[527](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/527)]

  ### <Icon icon="server" /> Enhanced transaction confirmation checks

  The Ark server now performs more thorough checks on chain confirmations and will not accept board VTXOs for which the funding transaction hasn't been confirmed on-chain, improving security. \[[519](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/519)], \[[534](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/534)]

  ### <Icon icon="server" /> Graceful shutdown handling

  Ark server now captures and handles SIGTERM correctly, ensuring a graceful shutdown when the server is stopped or restarted using systemctl. \[[524](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/524)]

  ### <Icon icon="mobile-screen-button" /> Improved boarding reliability

  Bark can now recover from partially registered boards and re-attempt on failure, making the boarding process more resilient. \[[518](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/518)]

  ### <Icon icon="server" /> Improved VTXO registration resilience

  When a user boards the Ark it will register the newly created VTXO with the server. The registration command has been made idempotent. \[[518](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/518)]

  ### <Icon icon="server" /> Enhanced wallet balance telemetry

  We've added improved telemetry for node operators about wallet balance, making it easier to monitor and manage Ark server operations. \[[531](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/531)]
</Update>

<Update label="8 April 2025">
  <img src="https://mintcdn.com/second-0659a37d/8VZedF7eKiQd6Pfy/images/2025-signet-launch.jpg?fit=max&auto=format&n=8VZedF7eKiQd6Pfy&q=85&s=fd7b7fd10af611717cdbc99e80c67b90" alt="Byte the dog connecting an Ark server to a signet testnet server" width="1920" height="1077" data-path="images/2025-signet-launch.jpg" />

  ### <Icon icon="gear" /> Launch on signet

  We're excited to announce that Ark is now available on signet! You can use bark to send signet coins to friends and family, making it easier than ever to test and experiment with the protocol.

  ### <Icon icon="server" /> Enhanced server-client communication

  We've implemented a connection handshake between bark and Ark Server that ensures version compatibility and enables public service announcements. \[[384](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/384)], \[[514](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/514)]

  ### <Icon icon="server" /> Forfeit transaction management

  The Ark server now automatically handles forfeit transactions when clients refresh sats in a round. We've implemented chain monitoring and automated publishing of forfeit transactions through an updated TxIndex system. \[[416](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/416)], \[[417](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/417)], \[[423](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/423)], \[[415](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/415)], \[[449](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/449)], \[[450](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/450)], \[[512](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/512)]

  ### <Icon icon="server" /> Improved observability

  We've enhanced visibility into Ark's internal operations with structured logging and comprehensive telemetry. Track wallet balances, client versions, and other key metrics in a dedicated log file. \[[442](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/442)], \[[441](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/441)], \[[433](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/433)]

  ### <Icon icon="server" /> Stability improvements

  Several critical fixes have been implemented to improve system stability:

  * Graceful handling of insufficient offboard amounts \[[471](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/471)]
  * Eliminated panics during rounds \[[495](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/495)]
  * Support for repeated client onboarding \[[516](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/516)]

  ### <Icon icon="mobile-screen-button" /> Bark usability enhancements

  We've made bark more intuitive and user-friendly:

  * Simplified wallet creation by removing explicit HTTPS requirement \[[382](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/382)]
  * Added `ark-info` command to query server settings \[[412](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/412)]
  * Improved amount and unit specification hints \[[487](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/487)]
  * New utilities for draining on-chain wallets \[[472](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/472)]

  ### <Icon icon="mobile-screen-button" /> Lightning payment improvements

  We've resolved several Lightning-related issues, including prevention of duplicate invoice payments and implementation of intermediate state exits. \[[389](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/389)], \[[409](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/409)], \[[459](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/459)], \[[470](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/470)], \[[490](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/490)]
</Update>

<Update label="6 March 2025">
  <img src="https://mintcdn.com/second-0659a37d/8VZedF7eKiQd6Pfy/images/2025-alpha1.jpg?fit=max&auto=format&n=8VZedF7eKiQd6Pfy&q=85&s=87c5cdf7db155c0203369db6841ec085" alt="Ark's latest alpha version: 0.0.0-alpha.1" width="1920" height="1080" data-path="images/2025-alpha1.jpg" />

  ### <Icon icon="gear" /> Ark in alpha

  We have released version 0.0.0-alpha.1 of bark and aspd. Note, that this is an alpha version with known bugs and vulnerabilities that will result in loss of funds.

  ### <Icon icon="server" /> Smoother Ark server configurations

  Configuring an Ark server is now a breeze, with the option of using toml file or environment variables. This will help developers who want to quickly spin up an Ark server for testing purposes (and Ark server operators!). \[[380](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/380)]

  ### <Icon icon="server" /> Ark server database got an upgrade

  We migrated the Ark server database from RocksDB to Postgres. Postgres is proven to be a reliable database that powers many critical systems in various industries.
  \[[314](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/314)]
  \[[358](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/358)]
  \[[368](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/368)]
  \[[372](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/372)]
  \[[373](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/373)]
  \[[383](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/383)]

  ### <Icon icon="server" /> Sandboxed server secrets

  Keeping the mnemonic secret is crucial to securing an Ark server. We split the mnemonic from the database to ensure operators have full control on how and where their mnemonic is stored.
  \[[366](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/366)]

  ### <Icon icon="server" /> Network validation

  Connecting a mainnet Ark Server to a signet network is a bit of a footgun. The Ark server will now validate the network before connecting.
  We reduced the binary size of aspd from 200MB to 30MB. \[[325](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/325)]

  ### <Icon icon="server" /> Improved error messages

  As a developer you deserve proper error messages when things go wrong. We made various improvements to ensure that you will get error messages that help you out.
  \[[334](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/334)]
  \[[345](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/345/commits)]
  \[[350](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/350)]

  ### <Icon icon="mobile-screen-button" /> A couple of exit improvements

  We simplified the API and ensured that the exit works if esplora is used as a chain source.
  \[[362](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/362)]
  \[[385](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/385)]

  ### <Icon icon="mobile-screen-button" /> Multi-threading support

  The bark API now works in multi-threaded applications (it didn't previously).
  \[[378](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/378)]

  ### <Icon icon="code-branch" /> Reducing the cost of emergency exits with Pay2Anchor

  A new output type called Pay2Anchor was introduced in bitcoin 28.0. It is more efficient than a traditional fee anchor which helps to reduce the cost of an emergency exit. We have implemented the PayToAnchor output in rust-bitcoin.
  \[[4111](https://github.com/rust-bitcoin/rust-bitcoin/pull/4111)]

  ### <Icon icon="code-branch" /> Preventing double spends

  We have implemented a new feature in BDK that allows us to spend only confirmed UTXOs. This will help us to ensure we never double-spend a counterparty by accident.
  \[[1855](https://github.com/bitcoindevkit/bdk/pull/1855)]
</Update>

<Update label="9 February 2025">
  <img src="https://mintcdn.com/second-0659a37d/8VZedF7eKiQd6Pfy/images/2025-multi-os.jpg?fit=max&auto=format&n=8VZedF7eKiQd6Pfy&q=85&s=88e04867bb330e3fcb8212848c5133fc" alt="Byte bowing to all three desktop operating systems: Windows, macOS, and Linux" width="1920" height="1080" data-path="images/2025-multi-os.jpg" />

  ### <Icon icon="code-branch" /> First major release of BDK

  Bark's on-chain wallet got even more stable thanks to the release of BDK 1.0.0. We've been excited (and waiting!) for this for a long time—huge thanks to the BDK team for rolling it out, and to new contributor [@jirijakes](https://codeberg.org/jirijakes) for adding it to bark! 👏 \[[252](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/252)]

  ### <Icon icon="mobile-screen-button" /> No Linux, no problem

  Bitcoin works on any desktop device and now so does our Ark client, bark. A few adjustments have been made by our non-Linux colleagues to ensure that bark works across Linux, macOS, and Windows. \[[203](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/203)],\[[275](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/275)],\[[276](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/276)]

  ### <Icon icon="mobile-screen-button" /> Track your regret

  Want to know where you spent all your sats? Bark will now maintain a history of all transactions in and out of your wallet. \[[212](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/212)]

  ### <Icon icon="mobile-screen-button" /> All the JSON, all the time

  Bark will now always return outputs in JSON format. A consistent output format makes it much easier to develop scripts on bark. \[[305](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/305)]
</Update>

<Update label="18 December 2024">
  <img src="https://mintcdn.com/second-0659a37d/8VZedF7eKiQd6Pfy/images/2024-arkoor-standard.jpg?fit=max&auto=format&n=8VZedF7eKiQd6Pfy&q=85&s=30d5361cfcc582e134ce43744cca5890" alt="Arkoor is now the standard" width="1600" height="900" data-path="images/2024-arkoor-standard.jpg" />

  ### <Icon icon="gear" /> All payments are now arkoor by default

  We've made a big shift in Ark payment policy: all payments will now be arkoor, and in-round transactions are reserved for refreshing VTXOs only.

  This took a massive refactor, but the payoff is huge: Ark rounds are now way more reliable thanks to reduced interactivity requirements, and Ark wallets consume fewer resources across devices (mobile users won't have to worry about killing their batteries anymore!).

  Importantly, the change gives users far more control over their preferred fees and security model.

  For a deep dive on the change, see our [recent blog article](https://blog.second.tech/the-arkoor-standard/).

  ### <Icon icon="gear" /> Zero-fee transactions

  Bitcoind 28.0 brought zero-fee VTXOs to Ark. By using child-pays-for-parent to confirm transactions instead, your Ark payments will now be even cheaper and even more reliable—especially for exits (but hopefully you'll never need those).

  ### <Icon icon="server" /> Structured logging

  The ASP daemon now comes with structured logging. Parsing logs, building dashboards, testing, and setting alerts for ASP operations will now be way easier.

  ### <Icon icon="gear" /> VTXOs and UTXOs stored together in the same database

  In October, we replaced the VTXO database with SQLite. And now, thanks to BDK's native SQLite support, your on-chain UTXOs are stored in the same database.

  ### <Icon icon="code-branch" /> Rustls encryption

  We've switched out OpenSSL in favour of Rustls. In our opinion, Rustls is a higher quality implementation that will make Ark more secure and easier to build upon.
</Update>

<Update label="31 October 2024">
  ### <Icon icon="mobile-screen-button" /> Database now running on SQLite

  Our biggest update this month was migrating [bark](https://gitlab.com/ark-bitcoin/bark) to an SQLite database. We chose SQLite because it's ridiculously stable, works on a wide range of hardware, and is easy for any developer to pick up because it's been around for so long. SQLite is what you use when you don't want to lose important data, and there's little data more important than bitcoin data!

  <img src="https://mintcdn.com/second-0659a37d/8VZedF7eKiQd6Pfy/images/2024-sqlitebrowser.png?fit=max&auto=format&n=8VZedF7eKiQd6Pfy&q=85&s=8a1409f00713d80069e5ad90f41b5f67" alt="Screenshot of SQLite database in use" width="2302" height="1062" data-path="images/2024-sqlitebrowser.png" />

  ### <Icon icon="code-branch" /> Updated to BDK beta 4

  In October, we integrated two successive releases of [BDK](https://bitcoindevkit.org), going from beta2 to beta4. BDK is central to bark, our Ark client implementation. It enables us to quickly and easily build a fully-fledged bitcoin wallet, literally doing everything out-of-the-box. So we continue to look forward to the upcoming stable 1.0 release. You know what to do, Spiral!

  ### <Icon icon="mobile-screen-button" /> On-demand syncing

  Bark now only does an on-chain sync when it's actually required. This ensures bark loads faster and feels a lot more snappy.

  ### <Icon icon="gear" /> Contributor shoutouts

  We also want to give a shoutout to three first-time contributors:

  * **adbd7e7** added a very necessary fallbackfee to our demo script. \[[110](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/110)]
  * **Acidbunny21** made it easy to offboard specific VTXOs without leaving dust inside the ASP. \[[87](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/87)]
  * **kevkevinpal** added some very helpful aspd commands to the documentation. \[[103](https://gitlab.com/ark-bitcoin/bark/-/merge_requests/103)]

  Thank you for your contributions!
</Update>