BSV Broadcaster v0.20.0 Adds Live Receipt Notifications for Wallets

Payments Infrastructure / Developer Tools

In Brief

A wallet using BSV Broadcaster v0.20.0 can now receive a live notification as soon as the service records its transaction. The RECEIVED event gives the wallet a status it can display while it waits for network acceptance or inclusion in a block.

The release also improves how the service handles consecutive payments when the second spends unconfirmed change from the first. Operators can now assign API keys with different usage limits to their clients.

News Report

The project published v0.20.0 on November 3, 2026, at 17:54 UTC. It follows the October release in which Arcade took the BSV Broadcaster name.

What a Receipt Tells the Wallet

Previously, Broadcaster recorded a transaction’s arrival internally, but a wallet listening for updates could see ACCEPTED_BY_NETWORK as its first live event. Version 0.20.0 sends RECEIVED after storing a new transaction and before queuing it for propagation. At that point, the service can say it has the transaction; it cannot yet say a node has accepted it or a miner has included it in a block.

To see the submission from the start, a wallet opens the event stream before sending the transaction. Only the first submission generates a live receipt. Retrying does not generate another one, and if a later status reaches the stream first, Broadcaster suppresses the late receipt. This notification is available on the event stream, not through webhook callbacks.

Keeping a Payment With Its Unconfirmed Parent

Consider a wallet that pays one supplier and then uses the change to pay another. The second transaction depends on the first. Previously, separate submissions could reach different processing workers, leaving the second payment waiting for a parent transaction that another worker was already handling.

Version 0.20.0 can route the second transaction to the same worker while the parent is still in flight. That worker can hold the child behind its parent. If the parent is already waiting in the retry queue, the existing retry procedure still applies.

The contributor tested a chain of 50 transactions, submitted one at a time on a private regression-test network. At the 90-second check, 40 transactions on the earlier build were waiting for retry. With the change, all 50 had reached network acceptance or a later status within that window.

Operator Controls and Block Recovery

Operators can enable API keys and set limits on request rates, concurrent requests and batch size. These controls are off by default. They apply to the main API; the live event stream uses a separate listener and its own callback-token mechanism.

The release also addresses a recordkeeping problem after a block leaves the active chain. In an October 31 incident described by the contributor, roughly 8,750 transactions were mined again, but one Broadcaster instance still pointed to their former block. Version 0.20.0 asks Merkle Service to renew watches on affected transactions so it can learn where they are mined again.

For the SQL-backed installation described in the report, that recovery also depends on Merkle Service pull request #281, which remained open when checked on November 4. Upgrading Broadcaster alone does not repair records already left pointing to the old block.

BSV TIMES Read

A checkout can now display “submitted” as soon as Broadcaster acknowledges the transaction, then update the customer when the network reports a later status. If the connection drops, the application can use the transaction ID to recover the current status. A missing receipt is not, by itself, a reason to ask the customer to pay again.

Developer Context

GitHub contributor galt-tr, whose public profile gives the name Dylan, submitted the receipt notification, chained-payment routing, API-key controls and transaction-watch changes. The contributor’s test reports distinguish observations from a hosted service from results reproduced on a private test network.

Source Links

Posted on November 4, 2026 (UTC)