Bitcoin SV technical article cover image

Viewing BSV Transactions with WhatsOnChain: A Complete Guide from txid to On-Chain Structure

This article teaches you how to use the block explorer WhatsOnChain to view transaction details, understand core concepts like inputs, outputs, scripts, and fees, and leverage the explorer to infer the underlying logic of the SDK.

Ethan Lin

Ethan Lin

technical_editor

Published Jun 16, 20264 min read

At a Glance

WhatsOnChain is a commonly used BSV block explorer. Using a txid, you can view a transaction's inputs, outputs, scripts, amounts, fees, and confirmation status.

Your first transaction shouldn't just end with a console output. You need to correlate the txid returned by your code with the actual on-chain transaction to confirm what your transaction really looks like.

What Is a txid?

A txid is the transaction ID. It identifies a transaction and is also used by subsequent transactions to reference a specific output.

In SDK examples, the result of createAction() may contain a txid. If you have a txid, you can construct the explorer link:

TypeScript
1if (response.txid) {
2 console.log(`View on WhatsOnChain: https://whatsonchain.com/tx/${response.txid}`)
3}

Once you open that link, you see not the SDK's abstract objects but the browser's display of on-chain transaction data.

Which Fields Should You Look At?

1. Does the Transaction Exist?

If WhatsOnChain can't find it, it may mean the transaction wasn't broadcast successfully, hasn't been indexed by the explorer yet, the txid was copied incorrectly, or the transaction was rejected.

2. Confirmation Status

An unconfirmed transaction means it has been seen or propagated but not yet included in a block. A confirmed transaction shows the block height or number of confirmations. Different explorers may display this differently.

3. Inputs

Inputs reference previous UTXOs. Here you can see which old outputs this transaction is spending. For beginners, this helps understand that "wallet auto-selects inputs" is not just empty talk.

4. Outputs

Outputs are the new outputs created by this transaction. You can check if your OP_RETURN data output exists and also see the change output.

5. Scripts

If it's a data output, you may see OP_RETURN followed by hexadecimal data. Some explorers may also display the decoded text.

6. Fee

The fee is usually the total inputs minus total outputs. Some explorers show the fee directly; others require you to calculate it.

Using the Explorer to Reverse-Engineer the SDK

Suppose your code creates only one output:

TypeScript
1outputs: [{
2 satoshis: 100,
3 lockingScript: opReturnScript,
4 outputDescription: 'My first data output'
5}]

But in the explorer, you might see more structure:

TEXT
1input 1: some old UTXO selected by the wallet
2output 1: your OP_RETURN data output
3output 2: change output generated by the wallet
4fee: the difference between input and output totals

This shows that the SDK and wallet automatically handled the low-level work. You didn't manually write inputs, change, or fee, but the real transaction must have these structures.

How to View Data Outputs

If you wrote Hello BSV!, the explorer might display:

TEXT
1OP_RETURN <hex data>

Only after converting the hex back to text can you see the original message.

For example:

TEXT
148656c6c6f2042535621

Corresponds to the ASCII text:

TEXT
1Hello BSV!

Whether the explorer automatically parses this depends on the explorer's features and data format. Production applications should not rely on manual explorer inspection as the sole indexing method.

Browser Is Not SPV Verification

Position in the BSV Tech Stack

Block explorers are useful for development and debugging, but they are not a trust-minimized verification mechanism in the protocol sense.

An explorer tells you "what this service sees." SPV verification checks the transaction, Merkle proof, block headers, and the relationship to the chain of work.

At the beginner stage, you can use WhatsOnChain to build an intuitive understanding:

TEXT
1code returns txid
2 -> explorer looks up transaction
3 -> compare inputs / outputs / scripts / fee
4 -> understand SDK abstractions and on-chain structure

When you later learn SPV, you will further understand:

TEXT
1whether a transaction exists in a block
2 -> how the Merkle proof proves it
3 -> how block headers connect
4 -> why you don't need to trust the full block explorer

Common Checks During Debugging

  • If no txid is returned, first check the SDK result and error. The transaction may not have been created or processed.
  • If the txid exists but the explorer can't find it, wait a while and then confirm the transaction was broadcast successfully.
  • If the output data is wrong, check that the string was correctly converted to hex and that the script used OP_RETURN.
  • If the transaction fails, check wallet funds, fees, wallet connection, user authorization, and network status.
  • If the explorer shows a change output, don't mistake it for an unfamiliar payment. It is usually the wallet returning the remaining amount to itself.

Common Beginner Misunderstandings

  • A block explorer is not your application's backend database. Your app needs its own state management and query logic.
  • An unconfirmed status in the explorer doesn't mean final confirmation. Your app should decide based on business risk whether to wait for confirmation or proof.
  • Finding a txid doesn't mean you have verified the transaction. Explorer querying and SPV verification are different things.
  • Seeing OP_RETURN data doesn't mean the data is trustworthy. You still need to check the source, signature, and protocol format.
  • Not finding a transaction doesn't necessarily mean it doesn't exist. It could be due to explorer indexing delay or broadcast failure.

References

Recommended articles