BSV TIMES — Under the Surface

Under the Surface looks at projects, standards, experiments, and community activity that may not rise to the level of a headline but are still worth noticing. Some are new, some are continuing work, and some are quieter developments that help show what is taking shape across the BSV community.

Developer Tools / Transaction Monitoring

A public BSV Blockchain repository provides a useful reference implementation for something many applications eventually need to do: determine what happened to a transaction after it was created.

bsv-address-tracker is an educational system for monitoring selected BSV addresses and following related transactions through their confirmation lifecycle.

It deliberately does not attempt to become a wallet, payment system, balance service, or full block explorer.

Instead, it isolates the monitoring problem.

An application first registers one or more addresses through the tracker’s API. The service then listens to an SV Node’s real-time ZeroMQ transaction feed and checks incoming transactions for activity involving those addresses.

Once a relevant transaction is detected, the tracker begins following its status.

New block notifications arrive through a separate ZeroMQ feed. The service then uses the node’s getrawtransaction RPC method to obtain updated confirmation information, including the block hash, block height and time associated with the transaction.

That creates a continuing lifecycle rather than a one-time lookup.

A transaction can first appear as newly detected, move through successive confirmations as blocks are added, and eventually be transferred from the active collection into an archive after reaching 144 confirmations.

Applications do not have to continually poll the tracker to notice those changes.

The reference implementation also provides webhooks for lifecycle events, including the first detection of a transaction, changes in its confirmation count, and final archival.

That means an application could react when something changes rather than repeatedly asking whether anything has changed.

Live monitoring and historical recovery are separated

The project also shows one way of combining direct node access with external historical data.

Real-time transaction detection and confirmation tracking come from the operator’s own SV Node through ZeroMQ and RPC.

When a new address is first registered, however, the service can request its earlier transaction history from WhatsOnChain. That gives the tracker a starting history before it continues monitoring new activity directly.

The distinction is useful.

A third-party data service can help fill an application’s historical view without necessarily becoming the continuing source of truth for every new transaction and confirmation event.

The running system can instead observe current activity through its own node connection.

The scope is intentionally narrow

One of the more useful aspects of the repository is what it leaves out.

The tracker records transaction IDs and their relationship to monitored addresses, but it intentionally does not calculate balances, keep transaction amounts, implement wallet functionality, process payments, or apply application-specific business rules.

Those responsibilities are left for systems built above it.

That narrow scope makes the repository easier to read as a reference architecture.

A developer can see the separate pieces involved in transaction monitoring: address registration, real-time detection, historical initialization, confirmation checking, retries, storage, APIs, webhook notifications and eventual archival.

The repository also includes MongoDB persistence, Docker deployment, optional API authentication, retry handling and concurrency controls, making the example substantial enough to run rather than remaining only a code fragment.

Why transaction lifecycle matters

For users, a transaction often appears to have only two states: sent or completed.

Applications need considerably more information.

They may need to know that a transaction has first appeared, whether it has entered a block, how many confirmations it has accumulated, whether a previous lookup failed temporarily, and when the record can be treated as sufficiently settled for that application’s purpose.

Different applications can attach different business meaning to those states.

A notification system may react immediately. An archival system may wait much longer. Another application may use confirmation state merely as one piece of evidence alongside SPV proofs or other transaction data.

BSV Address Tracker does not dictate those policies.

It demonstrates the lower-level plumbing needed to observe the transaction lifecycle so that applications can apply their own rules above it.

That makes it useful less as a finished product than as an inspectable example of how a BSV application can move beyond asking an explorer for a transaction and instead maintain its own continuing view of activity relevant to the addresses it watches.

Source: BSV Address Tracker — GitHub

Update — September 9, 2026