
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
technical_editor
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:
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:
But in the explorer, you might see more structure:
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:
Only after converting the hex back to text can you see the original message.
For example:
Corresponds to the ASCII text:
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:
When you later learn SPV, you will further understand:
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
BlockchainMay 20, 2026
WIFs, Mnemonic Phrases, and HD Wallets: An Introduction to Key Management in BSV Wallets
WIFs, mnemonic phrases, and HD wallets all relate to key storage, recovery, and derivation, but they mean different things. This article explains their differences, the role of xpubs, and security practices for BSV wallets and application development.
BlockchainJun 16, 2026
Writing Data to the BSV Blockchain: From OP_RETURN to Application Protocols
BSV transactions can do more than transfer satoshis. By including data outputs, you can record text, hashes, or business events on-chain. This article starts with the first Hello BSV transaction, explains the difference between data outputs and payment outputs, how to construct an OP_RETURN using the SDK, the reason for hex encoding, and how to move toward structured protocol design.
BlockchainJun 15, 2026
Auto-Select Inputs, Change, and Fees: How the Wallet Builds a Complete Transaction for You
When using the high-level SDK, the wallet automatically selects spendable UTXOs, generates change outputs, and calculates fees. This article explains how this process works, its benefits, and potential risks.