Coins, balances and accounts: why "how much do I have" has three different answers

Open a wallet that supports several chains and you'll notice something odd if you look closely. The Bitcoin balance and the Ethereum balance are both just numbers on a screen, but underneath they're computed in completely different ways — and on Solana there's a third arrangement again.

This isn't trivia. It explains why Bitcoin fees depend on your transaction history, why an Ethereum transaction can fail and still cost money, and why a Solana account can't simply be emptied to zero.

The UTXO model: you own coins, not a balance

Bitcoin has no accounts and stores no balances. What it stores is a set of unspent transaction outputs — UTXOs — each of which is a discrete chunk of value locked to some spending condition.

Think of physical cash. You don't have "£47" in your pocket; you have a £20 note, two £10s, a £5 and two £1 coins. To pay £23 you hand over a £20 and a £5 and get £2 back. You can't tear a note in half.

UTXOs work exactly like this. Each one must be spent whole. To pay 0.3 BTC from a 1 BTC output, your wallet consumes the entire 1 BTC and creates two new outputs: 0.3 to the recipient, and roughly 0.7 back to you as change. The 1 BTC UTXO ceases to exist.

Your "balance" is therefore a derived figure — your wallet scans the chain for outputs locked to conditions you can satisfy, and adds them up. Nowhere on the Bitcoin blockchain is there a record saying you have any particular amount.

Three consequences follow, and all three are practical:

Fees depend on your history, not just the amount. Fees are charged per byte, and every input you spend adds bytes. Paying £50 from one large UTXO is cheap; paying the same £50 by combining thirty tiny ones is expensive, because the transaction is physically bigger. This is why consolidating UTXOs when fees are low is worth doing.

Change is a real output that has to go somewhere. Every wallet handles this automatically, but it's the mechanism behind the change-address heuristics that chain analysts use to link your addresses together.

Spending is naturally parallel. Different UTXOs are independent, so nothing forces your transactions into a strict order.

Bitcoin, Litecoin, Dogecoin, Bitcoin Cash, Zcash, Ravencoin and Flux all work this way. It's the older model, and the one where "not your keys, not your coins" is most literally true — there is no account, only coins with conditions attached.

The account model: you own a balance, and a counter

Ethereum threw that away and used something closer to a bank ledger. The chain stores a state: a giant mapping from addresses to balances (and, for contracts, to stored data). Sending 0.3 ETH subtracts 0.3 from one number and adds it to another. No inputs, no outputs, no change.

That's simpler, and it's what makes smart contracts practical — a contract needs persistent storage it can read and write, which is awkward when the world is made of discrete coins.

But the account model introduces a problem UTXOs don't have. If a transaction is just "subtract 0.3 from Alice," anyone who sees it could rebroadcast it repeatedly and drain her account. The fix is the nonce: a per-account counter, included in every transaction, that must increment by exactly one. Transaction number 7 can only be mined after number 6, and only once.

The nonce is why EVM chains behave the way they do:

Your transactions are strictly ordered. One stuck transaction blocks every later one from the same address, because they can't be processed out of sequence.

Fees are paid even when a transaction fails. Gas pays for computation attempted, not computation succeeded. A reverted contract call still consumed the validators' work, so it still costs. This surprises people constantly, and it's a genuine difference from the UTXO world, where an invalid transaction simply never confirms and costs nothing.

Nonce management is real infrastructure. For a normal wallet this is invisible. For a multisig where two devices must agree on a transaction before it's broadcast, the nonce has to be reserved, tracked and released — which is why nonce handling is a recurring theme in two-device signing rather than an implementation detail.

Ethereum, Polygon, BSC, Avalanche, Base and XDC all use this model.

Solana: accounts that pay rent

Solana is account-based too, but with a twist that catches people out.

On Solana, essentially everything is an account — your wallet, each token you hold, each program's data. And because those accounts occupy validator memory, they must hold a minimum balance to remain alive. That's rent exemption: deposit enough and the account persists indefinitely; fall below and it can be reclaimed.

The practical effect is that holding an SPL token requires a separate token account, funded with a small amount of SOL, before anyone can send you that token at all. Receiving is not free. This is unusual and it is worth understanding before you need it, because "I sent you the tokens and nothing arrived" is often just a missing token account.

Why a multi-chain wallet has to model all three

A wallet supporting these chains cannot share one internal notion of "balance." It needs:

• For UTXO chains: a set of outputs, each with an amount and a script, plus coin selection logic deciding which to spend.
• For EVM chains: a single balance figure plus a nonce, and a queue that respects ordering.
• For Solana: a balance, a set of associated token accounts, and awareness of rent minimums.

The security architecture has to adapt too. On UTXO chains SSP's 2-of-2 is a script: a P2WSH output that requires two signatures to unlock, enforced by the chain's own scripting rules. On EVM chains there's no equivalent script system for ordinary accounts, so multisig is implemented through account abstraction — a smart contract account whose validation logic demands both signatures. On Solana it's a program-derived address, controlled by an on-chain program.

Three completely different mechanisms, one user-facing idea: nothing moves without both devices. That the underlying implementations look nothing alike is exactly why the guarantee has to be re-established, and re-audited, on each chain rather than assumed to carry over.

What this means for you

When Bitcoin fees seem high for a small payment, look at your inputs. The amount matters less than how many pieces it's made of.

When an Ethereum transaction is stuck, later ones from the same address are stuck behind it. That's the nonce, not a bug. Fixing the first unblocks the queue.

When a failed EVM transaction still charges you, that's the model working as designed. Simulation helps you avoid it — which is why simulating before signing is more valuable on account-based chains than on UTXO ones.

When a Solana token transfer "disappears," check for a token account. Nothing is lost; the destination may not have existed yet.

None of these are quirks of any particular wallet. They're consequences of a design decision each chain made years ago, and once you can see which model you're on, a lot of otherwise-baffling behaviour becomes predictable.