BSV Mobile Wallet Toolkit 0.24.0 Releases Linked-Payment Fix and Backup Safeguards

Wallets & Identity / Payments Infrastructure

In Brief

A new release of BSV Wallet’s mobile toolkit fixes a problem that could leave earlier transactions out when an application submitted several linked payments together. Version 0.24.0 also includes the backup-restoration safeguard reported by BSV TIMES on November 9, bringing that protection into a published developer package.

The package is available now, but application developers must integrate it and rebuild their mobile apps. Publication does not establish that existing app installations have received these changes.

News Report

The npm package @bsv/expo-wallet-toolbox 0.24.0 was published on November 10, 2026, at 00:03 UTC. It supplies wallet screens and payment functionality for applications built with Expo and React Native.

Sending Payments in the Right Order

Consider a wallet making one payment and then spending its change in a second payment before either is mined. The network needs the earlier transaction to understand where the second payment’s funds came from.

According to the release notes, two broadcasting integrations previously converted a package of linked transactions into just one transaction. Earlier transactions could reach the network only if another provider handled the whole package.

The updated toolkit submits every unconfirmed transaction in dependency order, sending the earlier payment before the one that spends its change. If the earlier transaction is not accepted, the dependent payment is held back and reported as retryable.

BSV Broadcaster becomes the primary service for submitting payments and receiving status updates. Other supported providers remain available as fallbacks.

Yesterday’s Safeguard Reaches a Published Package

The release includes the change that holds unfinished PeerPay payments imported from a wallet database backup. The owner must review each payment and separately approve sending it, preventing restoration alone from reviving an old payment instruction.

This advances the availability reported on November 9: the safeguard is now included in the published toolkit. Confirmation of delivery through a downloadable mobile app remains separate.

The release also includes other security changes, including checks on wallet connections and payment proofs, and requiring an enrolled hardware key to demonstrate control before a new vault deposit is funded.

What Developers Must Do

Version 0.24.0 introduces a native component that limits the size of certain downloaded responses before they reach the application’s JavaScript code. Developers must rebuild their Android and iOS applications; a JavaScript-only update is insufficient.

The release pull request also identifies a compatibility gap: version 0.1.0 of the separate Android and Safari wallet-bridge packages does not declare compatibility with toolkit 0.24.0 and needs its own update.

For the broadcasting change, the contributor reports 8,385 automated tests passing across 516 suites. The pull request still lists a physical-device test of linked payments on testnet as outstanding. Those automated results should therefore be read alongside that testing limit.

BSV TIMES Read

For a customer, several linked transactions may sit behind one ordinary payment action. Getting their order right helps applications complete that action reliably. The release also illustrates why availability needs careful wording: a published component gives developers something they can adopt, while users receive the benefit through the applications built with it.

Developer Context

GitHub contributor sirdeggen authored the broadcasting update and release preparation. Siggi, who contributes as icellan, authored the imported-payment safeguard included in this version.

Source Links

Posted on November 10, 2026 (UTC)