BSV Wallet Toolbox 2.14.7 Corrects Payment Broadcasting and Storage Behavior

Wallet Infrastructure Watch / Developer Tools

In Brief

The BSV TypeScript stack has published Wallet Toolbox 2.14.7 across its main, browser/client and mobile packages.

The update addresses received transactions that could be recorded as spendable without being broadcast, alongside fixes for protected-transaction funding, proof-data transport and browser storage queries.

News Report

Wallet Toolbox 2.14.7 was published on October 11, bringing four fixes into the shared tooling used to build BRC-100 wallets on BSV Blockchain.

BSV TIMES checked the npm registry records for @bsv/wallet-toolbox, @bsv/wallet-toolbox-client and @bsv/wallet-toolbox-mobile. All three listed 2.14.7 as their latest release, with publication recorded between 00:40 and 00:42 UTC.

The release workflow completed successfully. The four changes had originally been proposed between October 3 and October 6 before their October 10–11 merges.

Broadcasting Before Recording Recipient Outputs

The most consequential correction concerns internalizeAction, the operation through which a wallet accepts a transaction into its records.

The previous implementation checked a flag that its storage lookup did not set. Consequently, the intended broadcast step could be skipped while recipient outputs were still recorded as spendable.

Shared storage exposed a particular failure: a sender could prepare a transaction with broadcasting deferred, and a recipient using the same storage could accept it without either path submitting it to the network.

The corrected path attempts broadcasting when a transaction is new to the receiving user and has no mining proof. A rejected broadcast returns an error without storing the recipient outputs. Transactions already backed by a mining proof follow the existing path without rebroadcasting.

BSV TIMES also inspected the published main package and confirmed that it contains the corrected condition.

Funding Both Delivery and Reclaim

A second change addresses BRC-177 protected transactions, which use a designated funding output, or anchor.

That anchor must fund the intended transaction while also supporting a possible reclaim transaction. Previously, a transaction needing little funding could fail construction because the anchor did not leave enough value for the reclaim.

Version 2.14.7 sizes the anchor to cover whichever requirement is larger.

When reclaimability requires more funding than delivery, the protected transaction pays the bounded difference as a miner fee. This allows construction without introducing wallet change, which the protected flow prohibits.

The extra fee comes from the wallet owner’s funding. Ordinary transaction change planning retains its existing behavior.

Carrying Transaction Proof Data as Bytes

The release also corrects how wallet clients and storage servers exchange BEEF, the format used to carry transactions and supporting proof information.

Some large fields were still represented as JSON arrays of numbers even when both sides had negotiated compact binary encoding. This could cause requests to hit an array-length limit.

The updated implementation passes the relevant fields as bytes so that the existing binary transport can handle them.

Peers using the older encoding continue receiving numeric arrays. Authentication and overall payload limits remain in place.

Consistent Browser Storage Queries

The fourth fix aligns IndexedDB, used for browser storage, with the toolkit’s Knex database implementation.

Empty optional filter arrays could previously exclude every result. This affected certificate, transaction-status and output-tag queries; a certificate lookup by type could therefore return nothing.

Empty arrays now mean that the corresponding optional filter is omitted. Other query conditions and restrictions on which user’s records can be accessed still apply.

Operators Must Deploy the Update

The packages are available, but publication does not update running wallets or storage services automatically.

The release guidance calls for upgrading active storage implementations as well as relevant clients. No database-schema migration is required for these changes.

BSV TIMES Read

For wallet infrastructure, a payment has several distinct stages: construction, delivery, acceptance into local records, broadcast and confirmation in a block.

Our reading of this release is that it strengthens the transitions between those stages. A wallet’s internal record of a received output needs to reflect what happened when the underlying transaction was submitted. Successful broadcasting remains separate from mining confirmation.

The other corrections address the same practical requirement for dependable wallet behavior: sufficient funding for the intended operation, compatible transport of transaction evidence and consistent results across storage implementations.

The significance of 2.14.7 lies in making these fixes available together for wallet builders and service operators to adopt.

Developer Context

David Case, using the GitHub account shruggr, authored the four original fix pull requests. His public repositories also include 1Sat Indexer and ORDFS Server.

Ty Everett reviewed and merged the changes and triggered the release workflow in the BSV TypeScript stack.

Source Links

Posted on October 11, 2026