Every action on QRL 2.0, from a simple transfer to a contract deployment, is recorded as a transaction. The ZondScan transaction page collects everything the network knows about one of them: who sent it, where it went, what it cost, and what it changed.

This guide walks through the page field by field. You will learn how to find a transaction, how to read its status and confirmation count, how value and fees are denominated, and what the decoded panels for token transfers, event logs, and internal calls are telling you.

Everything here applies to the current QRL 2.0 public testnet, where coins have no monetary value. That makes it a safe place to practice: grab some testnet Quanta from the faucet, send yourself a transfer, and follow along on a real page.

Find the transaction

There are three common ways to land on a transaction page.

Search for it directly
Paste the transaction hash into the search bar at the top of any ZondScan page. The search accepts addresses, transaction hashes, and block numbers. A transaction hash starts with 0x followed by 64 hexadecimal characters.
Browse from an address page
If you know the sender or recipient, open their address page and use the Transactions tab. The Internal Txns tab lists calls that reached the address from inside contract execution.
Browse recent network activity
The transactions list shows recently confirmed transactions across the whole chain, and the pending list shows what is currently waiting in the mempool.

Status and confirmations

The badge at the top of the page gives you the verdict at a glance. You will see one of three states:

Confirmed: the transaction is included in a block and executed successfully.
Pending: the transaction is known to the network and has no block yet.
Reverted: the transaction made it into a block, then the EVM rolled it back. Any state changes it attempted were discarded. The gas consumed by the partial execution is still paid, so a reverted transaction has a real fee.

Next to the status badge is the confirmation count. A transaction has one confirmation the moment it lands in a block, and the count grows by one with every block produced after it. For recent transactions the page updates the count live, stopping once it passes a couple dozen. The Block row links to the block that included the transaction, and the Timestamp row shows when that block was produced, in UTC.

From, to, and value

From is the Q-prefixed address that signed the transaction, and To is its target. Both link to the corresponding address pages and have copy buttons.

Value is the amount of native coin the transaction moved, displayed in Quanta. One Quanta is 10^9 Shor and 10^18 Planck; the chain stores the raw Planck integer and the explorer converts it for display. The unit converter does exact math between all three units, and the units article explains where each one is used.

Gas and the transaction fee

QRL 2.0 uses the EVM gas model. Three numbers determine what a transaction costs:

Gas limit: the maximum amount of computation the sender authorized. While a transaction is pending, ZondScan shows this as its own row.
Gas used: how much of that budget execution actually consumed. A plain transfer uses a small fixed amount; contract calls use more.
Gas price: what the sender offered to pay per unit of gas, quoted in Shor.

On the confirmed transaction page these fold into the Transaction Fee row: gas used multiplied by gas price, displayed in Quanta. When a market price is available the page adds an approximate USD equivalent next to it. For a live view of what the network is currently charging, the Gas Tracker summarizes recent gas prices in Shor and the estimated cost of a simple transfer.

Decoded token transfers

When a transaction moves tokens, ZondScan decodes the transfer events and renders one card per transfer. For a QRC-20 transfer the card shows the token name and symbol linked to the token contract, the amount formatted with the token's own decimals, and the sender and recipient. NFT transfers get the same treatment with a Token ID row, labeled QRC-721 for single tokens and QRC-1155 for multi-token contracts. A single transaction can emit several transfer events, for example a swap, so cards can stack.

Two badges are worth knowing. Mint means the transfer came from the zero address, so new tokens were created. Burn means the transfer went to the zero address, so tokens were destroyed.

Below the transfer cards, the Event Logs panel lists every log the transaction emitted. Well-known token events are decoded inline, and events from verified contracts are decoded through their published ABI with labeled arguments. Anything else is shown as raw topics and data you can copy into an external decoder.

Internal transactions

A transaction targeting a contract can trigger further calls while it executes, and some of those calls move coins of their own. ZondScan records the nested call frames that moved native value, plus any contract creations, as internal transactions; they appear in the Internal Transactions panel, one row per call frame, with the call type, the from and to addresses, the gas the frame used, and the native value it carried. Nested calls are indented to show depth.

The panel only appears when there is something to show; simple transfers have no internal transactions. The same rows also surface on the affected address pages under the Internal Txns tab.

Pending transactions and the inclusion ETA

Before a transaction is mined it sits in the mempool, and ZondScan gives it a dedicated live view. The pending transactions list refreshes every five seconds and marks each entry pending, mined, or dropped. Opening a pending transaction shows how long it has been waiting, an estimated time to inclusion, the current mempool depth, and whether its gas price sits above or below the mempool median.

The pending page decodes token transfer calldata before confirmation, so you can already see what a QRC-20 transfer intends to do. Once the transaction is included in a block, the page navigates to the confirmed view on its own. If it disappears from the mempool without being mined, the page reports it as dropped or replaced; the usual cause is a second transaction with the same nonce and a higher gas price.

What a contract deployment looks like

A contract deployment is a transaction with no recipient. The sender publishes bytecode, and the network derives a fresh address for the new contract. On ZondScan the To row shows a Contract Createdlabel with the new contract's address, and a dedicated Contract Created card repeats the address with more detail. When the deployed contract is a token, the card adds a standard badge (QRC-20, QRC-721, or QRC-1155) and the token name and symbol.

If you want to produce one of these yourself, the deploy and verify tutorial walks through compiling, deploying to the testnet, and publishing verified source. Deployed contracts are browsable on the contracts page.

FAQ

Why does my transaction show Reverted?

It was included in a block and its execution failed, so the EVM discarded every state change it attempted. Common causes are a failed require check, an insufficient token balance, or running out of gas. The fee for the gas consumed up to the failure point is still paid.

How many confirmations should I wait for?

Each confirmation is one more block built on top of the one containing your transaction, so deeper means harder to reorder. ZondScan stops refining the live count after a couple dozen confirmations, the range most chain interfaces treat as effectively final.

Why does the To field show a Contract Created label?

That transaction deployed a contract. Deployments carry no recipient; the network assigns the new contract an address when the transaction executes, and ZondScan links that address in place of the empty field.

What do the Mint and Burn badges on a token transfer mean?

Token standards represent creation and destruction as transfers involving the zero address. A transfer from the zero address minted new tokens, and a transfer to the zero address burned them, so ZondScan replaces the address with a badge.

Why does the Input Data panel show raw hex?

The calldata matched none of the well-known token methods and the target contract has no verified ABI on ZondScan. Verifying the contract on the verify contract page lets the explorer decode the method name and arguments for everyone.