Changelog

Keep up to date with our progress on building the Ark protocol.

Follow us on X to hear about the changes first.

Changelog categories: General, Ark server, Bark, Upstream

---

0.1.0-beta.2

4th November 2025

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.

Breaking changes

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

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]

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]

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], [1161], [1152], [1171]

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]

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]

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]

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]

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]

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]

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], [1205]

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]
• 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]
• Complete transaction history: bark onchain transaction lists all on-chain transactions with pagination removed for a streamlined view. [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]

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]

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]

---

0.1.0-beta.1

14th October 2025

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 and docs.rs, providing production-ready tooling and comprehensive documentation for developers building on the Ark protocol.

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.

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]

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], [984]

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]

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]

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]

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]

Streamlined Lightning commands

For developers working extensively with Lightning, we've introduced the bark ln alias as a shorthand for bark lightning commands. [1114]

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, expanding your testing options. [1092], [1031]

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]

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]
• Faster wallet initialization: Creating new wallets with bitcoind no longer triggers unnecessary full syncs, dramatically reducing setup time [1063]
• Safer board registration: Boards are only registered after achieving sufficient confirmations, preventing premature registrations that could cause issues [1069]
• Subdust change handling: The wallet now properly discards subdust change outputs, preventing transaction inefficiencies [1043]

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]
• Renamed round_tx to funding_tx to better reflect its purpose [991]

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]
• On-chain wallet [1058]
• Persist module [1056], [1055]
• Round module [1057]
• Server module [1022]
• Config struct [1020]
• VtxoState [1019]
• Exit module [1018]
• VTXO selection [1017]

---

0.0.0-alpha.19

10th September 2025

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.

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

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]

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], [807]

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]

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]

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]

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]

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]

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.

Significant CLI improvements

The bark CLI now includes several developer-friendly enhancements:

• Support for BARK_DATADIR environment variable for easier config management [946]
• bark wallet create --force command to create wallets when the Ark server isn't available [922]
• Added more details to the display of on-chain balances for improved visibility [870]

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]

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]
• Various telemetry fixes and improvements for better monitoring [890]
• Better error messages throughout the system [914]
• Removal of secrets from logs for improved security [915]

Improved wallet reliability

Additional fixes ensure better wallet behavior:

• Fixed early bailout issues in sync process [884]
• Correct fee application when claiming exits [887]
• Support for Lightning payments requiring multiple input VTXOs
• bark config now outputs proper JSON format [911]
• Various fixes to the exit system for improved reliability [896]

---

05 August 2025

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. [842]

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!

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]

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], [837]

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]

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.

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]

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.

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]

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.

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]

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]

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]

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.

04 July 2025

Cheaper unilateral 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 unilateral exits, making it cheaper and more efficient when you need to exit the Ark unilaterally. [565]

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], [615]

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], [707]

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], [682]

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], [625]

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]

Completely rewritten unilateral exit

We've rewritten the unilateral exit functionality from the ground up, providing better debugging tools, status reporting, and more granular control over the exit process. [729]

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]

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]

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], [711], [680], [653]

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], [647]

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]

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]

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], [661]

06 May 2025

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], [434]

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]

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]

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]

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]

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]

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], [534]

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]

Improved boarding reliability

Bark can now recover from partially registered boards and re-attempt on failure, making the boarding process more resilient. [518]

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]

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]

08 April 2025

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.

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], [514]

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], [417], [423], [415], [449], [450], [512]

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], [441], [433]

Stability improvements

Several critical fixes have been implemented to improve system stability:

• Graceful handling of insufficient offboard amounts [471]
• Eliminated panics during rounds [495]
• Support for repeated client onboarding [516]

Bark usability enhancements

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

• Simplified wallet creation by removing explicit HTTPS requirement [382]
• Added ark-info command to query server settings [412]
• Improved amount and unit specification hints [487]
• New utilities for draining on-chain wallets [472]

Lightning payment improvements

We've resolved several Lightning-related issues, including prevention of duplicate invoice payments and implementation of intermediate state exits. [389], [409], [459], [470], [490]

---

06 March 2025

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.

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]

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] [358] [368] [372] [373] [383]

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]

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]

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] [345] [350]

A couple of exit improvements

We simplified the API and ensured that the exit works if esplora is used as a chain source. [362] [385]

Multi-threading support

The bark API now works in multi-threaded applications (it didn't previously). [378]

Reducing the cost of unilateral 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 a unilateral exit. We have implemented the PayToAnchor output in rust-bitcoin. [4111]

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]

---

09 February 2025

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 for adding it to bark! 👏 [252]

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],[275],[276]

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]

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]

---

18 December 2024

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.

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).

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.

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.

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.

---

31 October 2024

Database now running on SQLite

Our biggest update this month was migrating 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!

Updated to BDK beta 4

In October, we integrated two successive releases of BDK, 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!

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.

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]
• Acidbunny21 made it easy to offboard specific VTXOs without leaving dust inside the ASP. [87]
• kevkevinpal added some very helpful aspd commands to the documentation. [103]

Thank you for your contributions!