UTXO vs account model: which explorer should you use?

Two ways to model who has what

Every blockchain has to track ownership somehow. There are two dominant approaches, and the choice ripples through every layer of the protocol - addresses, transactions, fees, smart contracts, and especially block explorers.

• UTXO model - the chain stores a set of unspent transaction outputs. To spend, you consume specific outputs as inputs and create new outputs. Bitcoin, Litecoin, Dogecoin, Bitcoin Cash, Dash, Zcash, and Cardano use UTXO or an EUTXO variant.
• Account model - the chain stores account states with running balances. To spend, you decrement one account and increment another. Ethereum, every EVM chain, Solana, TON, Aptos, Sui, and NEAR use account-style models.

The same on-chain action looks very different in each.

How the UTXO model works

In a UTXO chain, the ledger is a big bag of unspent outputs. Each output has a value and a locking script (or address) that describes who can spend it. To make a payment, your wallet:

1. picks one or more UTXOs that together cover the amount plus fee;
2. constructs a transaction that consumes those UTXOs as inputs;
3. creates new outputs - one to the recipient, one for change back to you;
4. signs each input with the key that controls it.

After the block confirms, the consumed UTXOs vanish from the unspent set, and the new outputs join it. There is no concept of "balance" in the protocol. A balance is whatever sum you compute over the UTXOs locked to your addresses.

Two practical effects:

• Addresses are receipt slots, not accounts. Each Bitcoin transaction can produce outputs to fresh addresses for privacy. A wallet often holds many addresses, and a single "wallet" balance is the sum across them.
• History is a tree, not a ledger. Tracing where coins came from means walking back through the chain of inputs - "this UTXO came from that transaction, whose inputs came from these earlier UTXOs". Explorers like mempool.space and Blockchair surface this directly.

How the account model works

In an account chain, the ledger is a key-value map: address -> account state. Account state typically includes a nonce, a native balance, and, for contracts, code and storage.

To make a payment, your wallet:

1. constructs a transaction specifying the recipient and amount;
2. signs it with the key that controls the sender account;
3. broadcasts it.

When the block confirms, the chain decrements the sender's balance and increments the recipient's. The sender's nonce ticks up by one. That is it - no input selection, no change output.

Two practical effects:

• An address has a persistent identity. Your Ethereum address is the place where your funds live. You can receive to it forever, and the balance accumulates.
• Smart contracts have state. A contract is an account with code. It holds its own balance and its own storage slots, and explorers can show both. Token balances live as entries in token-contract storage, not as native balances.

What this means for explorers

A Bitcoin explorer page for an address shows:

• a list of UTXOs locked to that address, each with a value and a "spent / unspent" status;
• the history of transactions that paid into the address;
• the history of transactions that consumed UTXOs from it as inputs;
• a derived balance, computed by summing unspent outputs.

A Bitcoin explorer page for a transaction shows a list of inputs (each referencing a specific previous output) and a list of outputs (each going to a new address or script). The "fee" is the difference between input value and output value, since UTXO chains do not have an explicit gas field.

An Ethereum explorer page for an address shows:

• a single native ETH balance, read directly from the account state;
• a list of inbound and outbound native transactions;
• separate tabs for ERC-20 token transfers, ERC-721 NFT activity, internal transactions (contract-to-contract calls), and approvals;
• for contracts, the verified source code, ABI, read-only view of state, and a UI to write to the contract.

An Ethereum explorer page for a transaction shows a single sender, a single recipient (which may be a contract), the value transferred, the gas used, the gas price, the function called (when the contract is verified), and the event logs emitted during execution.

Switching between the two feels like switching languages. Both describe ownership; they just describe it at different layers of the stack.

Address semantics differ too

UTXO addresses are scripts in disguise. A 1..., 3..., or bc1... Bitcoin address encodes a particular kind of locking script (P2PKH, P2SH, P2WPKH, etc.). Spending requires producing inputs that satisfy that script. Different address types unlock different validation logic.

Account addresses are pointers to a row in the state trie. The semantics are uniform - "anyone with the right key can spend from this address" - and the only distinction between externally-owned accounts and contract accounts is whether the address has associated code.

This is why an EVM address looks the same whether it is a user wallet or a multi-million-dollar contract: the format does not carry that information. You have to ask the chain.

Hybrid and adjacent models

A few chains do not fit cleanly:

• Cardano uses Extended UTXO (EUTXO), where outputs can carry datums and validators - giving the model some smart-contract-style flexibility while keeping UTXO semantics.
• Solana is account-style, but accounts are typed and programs (contracts) are stored in separate executable accounts. Token balances live in associated token accounts rather than inside the token program's own storage.
• Sui and Aptos use object-centric models. Sui in particular structures the entire state as a graph of objects owned by addresses, which is closer to UTXO in spirit than to Ethereum's account map.

Explorers for these chains build their own conventions on top.

Which explorer to use

For UTXO chains, explorers focus on inputs, outputs, and the mempool. mempool.space leans into this for Bitcoin. Blockchair generalises it across many UTXO chains. Litecoin Space mirrors mempool.space for Litecoin. The UTXO graph view is the killer feature.

For account chains, explorers focus on address state, transaction receipts, and decoded contract calls. The Etherscan family dominates EVM, with Solscan, Tonviewer, SuiVision, Aptos Explorer, and others filling the same niche on non-EVM accounts.

tx.taxi picks the right one per chain so you do not have to memorise the split. Paste a value, get redirected to the explorer that matches the chain's model.