BSV Wallet Toolbox 2.14.9 Adds Duplicate-Receipt Protection for SQL Wallet Storage

Wallet Infrastructure Watch / Developer Tools

In Brief

BSV Wallet Toolbox 2.14.9 has been published with a correction for overlapping payment receipts that could count the same transaction output twice in a recipient’s SQL-backed wallet records.

The release also fixes an internal error that could be returned after broadcasting. The documented duplicate-credit reproduction used synthetic payments and affected the wallet’s recorded balance; it did not create additional funds on BSV Blockchain.

News Report

Version 2.14.9 reached the npm registry late on October 13 UTC across the main, browser/client and mobile Wallet Toolbox packages.

BSV TIMES checked all three registry records and inspected the published main package. Its compiled code includes the receipt-coordination changes and the accompanying database migration.

The update follows the broadcasting and storage corrections in Wallet Toolbox 2.14.7, covered by BSV TIMES on October 11. The new release addresses what happens when different storage instances or background workers process the same received transaction at overlapping times.

When One Payment Appears Twice

A wallet must record a received payment without treating repeated delivery of the same transaction as another payment.

The earlier SQL implementation checked whether a transaction already existed before opening the database transaction that would store it. Two storage instances could therefore both find no existing record and proceed to record the same recipient’s output.

According to the fix’s pull request, a synthetic test using two MySQL connections reproduced the problem with one mined payment of 5,000 satoshis. Both receipt attempts were accepted, and the local wallet balance became 10,000 satoshis.

That result represented duplicate accounting for one payment. It was not a second on-chain payment or a blockchain double-spend.

A related timing problem could allow a second receipt attempt to credit an output while the first attempt’s broadcast was still pending, even if that broadcast subsequently failed.

Coordinating Receipt Processing

Version 2.14.9 adds a database-backed receipt claim keyed to the recipient and transaction ID. This coordinates processing before an instance selects the transaction record it will use.

The claim includes an expiry mechanism so that interrupted work can be recovered. An older process that has lost ownership cannot subsequently complete the receipt.

Recording the recipient’s outputs and completing the claim happen together. The completed claim remains available to coordinate later attempts to receive the same transaction.

In the maintainer’s corrected synthetic MySQL tests, overlapping receipts produced one new acceptance and one repeat handled as a merge: one transaction, one output and the correct 5,000-satoshi balance.

Returning the Actual Broadcast Result

The second correction concerns the response returned to the caller.

A background worker could advance a transaction’s stored status before the foreground receipt operation finished collecting its broadcast result. The earlier code preserved that newer status but could omit the provider’s result from the response, leading to an internal unknown error.

The release now copies the broadcast result before preserving the advanced stored state.

Negative provider results still reject the receipt without crediting new recipient outputs. A retry after a failed first broadcast must attempt broadcasting again before crediting the payment. Valid payments already carrying a mining proof continue through the proof-based path.

Published Packages, Separate Deployment Requirements

The package release makes the correction available to developers and operators. Applying it to running wallet services requires updating the active storage implementation.

The SQL migration adds a receipt-claim table. It preserves existing transaction and output records, including historical duplicates. It does not automatically reconcile earlier duplicate credits or repair partial receipts.

Release guidance calls for a consistent database backup and coordinated replacement of older serving storage instances, which do not honor the new claims. Updating an application alone does not update its remote storage server.

The fix’s documentation also distinguishes local MySQL testing from qualification on a production database cluster, including multiple writers and failover. The subsequent publication record retains a separate staging-first deployment process.

Browser IndexedDB does not use the SQL receipt-claim mechanism. The release introduces no public API or wire-format change.

BSV TIMES Read

Wallet reliability includes keeping local records accurate when a payment is retried, delivered repeatedly or processed concurrently.

Our reading is that 2.14.9 strengthens that part of the payment lifecycle. Its practical value lies in preventing overlapping receipt attempts from turning one output into multiple local credits, while returning a broadcast result that reflects what the provider reported.

The distinction from the earlier 2.14.7 update is meaningful: initiating the required broadcast and coordinating concurrent receipt processing are separate responsibilities.

For operators, the remaining work is adoption and verification in their own storage environment. Existing financial records remain a separate reconciliation concern.

Developer Context

Brayden Langley, using the GitHub account BraydenLangley, authored the receipt-coordination and broadcast-result correction in pull request #1066.

He is also a coauthor of BRC-100, the wallet-to-application interface standard, alongside Ty Everett and Tone Engel. His contribution here concerns the storage and receipt behavior supporting wallet operations.

Source Links

Posted on October 14, 2026