Key Takeaways
- What it is: Two ways of recording who owns what: a set of discrete unspent outputs, or a table of account balances.
- The asymmetry: Each model makes one class of query free and the other expensive, and the two classes are swapped between models.
- Core expressions: UTXO balance = the sum of every unspent output paying to the address. Account balance = one stored field read at a block height.
- Best use: Expect coin-age metrics where outputs carry creation heights and balance metrics where accounts carry balances.
- Main limitation: A reconstructed metric rests on an assumed accounting convention, and first-in-first-out, last-in-first-out, and pooled averaging give different answers from identical history.
- Practical rule: Before comparing a same-named metric across models, establish which side is reading stored data and which side is running a reconstruction.
Who This Guide Is For
Most cross-chain metric comparisons break at the ledger layer, before any provider or definitional question arises. Read this page if you have wondered why the coin-age charts in circulation are almost all Bitcoin charts and the total-value-locked charts are almost all account-chain charts.
Educational content. Not individualized financial advice.
What Does UTXO vs. Account Model Measure?
An unspent-output ledger stores discrete outputs. Each carries a value, a spending condition, and the height of the block that created it. Ownership is the set of outputs a key can unlock, and a transaction destroys some outputs and creates others. An account ledger stores accounts. Each carries a balance, a nonce, and on some accounts code and storage. Ownership is a number in a table, and a transaction edits two numbers.
Plain-language definition
A UTXO chain records individual coins with birthdays. An account chain records balances with no birthdays. Getting an age out of the first is a lookup; getting one out of the second is a reconstruction.
Why the asymmetry exists
An output carries per-unit provenance and a balance field does not. An output knows when it came into existence. A balance field knows only its current value, and the history behind that value is scattered across every transaction that ever touched the account.
How Is UTXO vs. Account Model Constructed?
Reading a balance
On an account chain the balance is a stored field, so the answer is one read at a stated block height. On a UTXO chain no balance exists anywhere in the state. It exists only as the sum of the unspent outputs paying to a given script, and a base node keys its unspent set by each output identifier rather than by address, so anyone who wants address balances has to build and maintain a separate address-to-output index first.
Reading an age
On a UTXO chain the creation height is written into the output, so age at any block height is one subtraction. Coin days destroyed on a spend is the value of each consumed output multiplied by the days it was held, and the transaction names exactly which outputs were consumed, so the calculation has no free parameters. See Bitcoin Developer Guide: Transactions for how inputs reference the outputs they spend.
On an account chain none of this exists. The state holds no lots, so age has to be reconstructed by replaying every credit and debit in order and deciding, at each debit, which units left.
Change outputs, a UTXO-only artifact
An output cannot be partially spent. Spending one consumes all of it, so a transaction paying less than its input value returns the remainder to the sender as a change output, structurally identical to a payment. A naive count of everything paid to a wallet therefore counts the wallet's own change as incoming value. Adjusted series exist for that reason; the measurement side belongs to on-chain transfer volume. Account chains have no equivalent, because a debit reduces a balance by exactly the amount sent.
Contract accounts, an account-only complication
An account chain lets an address hold code. A contract account has a real balance field, so ledger-level queries treat it like a user account, but the beneficial owners sit inside the contract's own storage under a layout specific to that contract. A pool holding a large balance is one account and an unknown number of owners. See Ethereum.org: Technical Introduction for the account types and state model. At the base protocol level a transaction is signed by a key-controlled account, so a contract never originates one. Counting transaction senders and counting every account whose balance changed therefore diverge here, with no UTXO analogue.
Formula and Measurement Logic
UTXO balance of A at height h = the sum of value(o) over every output o unspent at h whose spending condition pays to A.
Account balance of A at height h = the balance field stored for A in the state at h.
Age is a stored property of an output. On an account it is a function of the transfer history and an assumed lot-selection convention.
| Quantity | UTXO ledger | Account ledger |
|---|---|---|
| Balance of an address | Reconstructed: sum every unspent output paying to it, via an address index | Native: one stored field |
| Age of held units | Native: current height minus creation height, per output | Reconstructed: replay all transfers under an assumed convention |
| Cost basis of held units | Native: price at each output's creation height | Reconstructed: the same replay, the same assumption |
| Coin days destroyed on a spend | Native: the transaction names the consumed outputs | Reconstructed: not recorded at all |
| Balance held by code | Not applicable | Native as a field, opaque as to ownership |
| Count of owned objects | Native: the unspent output count | Not defined: an account is one object |
A reconstruction is not merely slower: it needs an input the chain does not supply, so two competent analysts working from the same complete history can produce different numbers and both be right about their own stated method.
How Should UTXO vs. Account Model Be Interpreted?
Why the published metric mix looks the way it does
Coin days destroyed, holding-period waves, spent-output profit ratio, and realized capitalization are all functions of per-output creation heights, so they are cheap to publish for a UTXO chain and expensive anywhere else. Total value locked, contract call counts, token holder counts, and active account counts are all functions of stored balances and contract state, so they are cheap on an account chain and largely undefined on a UTXO chain. The pattern is a map of what each data structure gives away for free, and Coin Metrics: Valuation Metrics documents how the first group is put together.
What neither model can answer in one step
- How many people are behind the balance. A UTXO wallet spreads one owner across many outputs; a contract account collapses many owners into one. Both need an inference layer, covered in address labeling and entity clustering.
- Why the units moved. Neither ledger records intent, and a consolidating sweep looks like a spend while a contract call looks like a transfer.
Step-by-Step Workflow
- Identify the executing layer's ledger model first, since rollups inherit the model of their execution environment.
- Classify the metric as native or reconstructed on that model.
- For a reconstructed metric, obtain the lot-selection convention and confirm it is applied consistently across the whole history.
- For a UTXO balance or volume series, confirm how change outputs were treated.
- For an account chain, confirm whether contract accounts are included and whether internal calls were traced.
- Recompute a reconstructed metric under at least two conventions and treat the spread as its error bar.
- Label any cross-model chart with which side is a reading and which side is an estimate.
Worked Hypothetical Scenario
This example is hypothetical. One wallet with an identical economic history is placed on both ledger models, and each is asked for the balance and for the value-weighted age of that balance. The history is forty incoming payments over eighteen months and twelve outgoing payments, leaving 5.0 units on both models.
On the UTXO ledger
Each incoming payment created an output paying to the wallet, and each outgoing transaction consumed some outputs and returned change. Assume every outgoing transaction consumed two inputs. The wallet has been paid by 40 + 12 = 52 outputs, of which 12 x 2 = 24 have been spent, leaving 28 unspent.
The balance is the sum of those 28 values, 5.0 units, and reaching it required knowing which 28 outputs they are. The age is free: group them by creation height and subtract.
| Vintage | Outputs | Units | Days since creation | Unit-days |
|---|---|---|---|---|
| Oldest | 6 | 2.0 | 400 | 800 |
| Middle | 10 | 1.5 | 150 | 225 |
| Newest | 12 | 1.5 | 30 | 45 |
| Total | 28 | 5.0 | 1,070 |
The value-weighted average age is 1,070 / 5.0 = 214 days, and nothing was assumed to get there. If the oldest vintage were spent today, coin days destroyed would be 2.0 x 400 = 800 coin-days, read from the transaction's input list. Note also that a naive count of everything paid to this wallet returns 52 receipts against 40 real payments, a 30 percent overstatement caused entirely by change.
On the account ledger
The balance is one field. Read it: 5.0 units.
The age does not exist. Producing a comparable number means replaying the 40 credits and 12 debits in order and deciding at each debit which units left. Reduce the history to four events so the arithmetic is visible.
| Event | Day | Change | Running balance |
|---|---|---|---|
| Credit | 0 | +3.0 | 3.0 |
| Credit | 200 | +2.0 | 5.0 |
| Credit | 340 | +2.0 | 7.0 |
| Debit | 360 | -2.0 | 5.0 |
Observe at day 400. Under first-in-first-out the debit removed 2.0 from the day-0 credit, leaving lots of 1.0 aged 400 days, 2.0 aged 200 days, and 2.0 aged 60 days. The value-weighted age is (1.0 x 400 + 2.0 x 200 + 2.0 x 60) / 5.0 = 920 / 5.0 = 184 days.
Under last-in-first-out the debit removed the whole day-340 credit, leaving 3.0 aged 400 days and 2.0 aged 200 days. The value-weighted age is (3.0 x 400 + 2.0 x 200) / 5.0 = 1,600 / 5.0 = 320 days.
Same ledger, same balance, same complete history, and the two answers differ by 136 days, which is 74 percent of the first-in-first-out figure. A pooled-average convention produces a third answer. Nothing in the chain state selects between them.
What Can Make the Interpretation Wrong?
- Treating a reconstructed age as a measured one. An account-chain coin-age series is a model output whose convention is a free parameter, and the convention is rarely printed.
- Comparing a native metric against a reconstructed one under the same name. Realized capitalization on the two models is two different computations sharing a label.
- Counting change as received value. A wallet's own change inflates naive receipt counts and gross output sums, at 30 percent in the worked example.
- Treating a contract balance as a holder. One contract account can stand for thousands of beneficial owners, resolvable only by decoding its storage.
- Assuming address means the same object. On a UTXO chain it is a spending condition with no ledger existence of its own; on an account chain it is a stateful record.
- Ignoring wallet coin-selection policy. UTXO age is truthful about which outputs were spent, which is not the same claim as which units were economically oldest.
- Missing internal transfers on account chains. A contract call can move value without appearing as a top-level transaction, so tracing is required rather than optional.
Cross-Network and Provider Comparison
Hybrid designs are common: some chains keep an unspent-output ledger with extra per-output fields, some account chains add native token accounts alongside the base account, and rollups inherit the model of their execution environment rather than of the chain they settle to.
Where a provider publishes an age-based or cost-basis metric for an account chain, ask which convention was used, whether it is applied consistently, and whether contract-held balances are inside or outside the population. Where a provider publishes an address-balance distribution for a UTXO chain, ask how change outputs were handled and whether outputs were grouped by address or by inferred entity.
Cohort work sits directly on top of this split, since an age band is trivially available on one model and a modeled quantity on the other: see on-chain cohort analysis. Holding two providers against each other belongs to on-chain data quality methodology.
Advanced Analytical Methods
Address-to-output indexing
The index that makes UTXO balance queries fast is a one-time infrastructure decision with ongoing maintenance, and it has to be repaired after a reorganization.
Convention as a parameter
Build the account-chain reconstruction so the lot-selection convention is an input rather than a constant, then publish the metric under all three conventions together. The spread is an honest error bar, and in the reduced history above it was 136 days.
Contract storage decoding
Resolving beneficial ownership inside a contract account requires that contract's storage layout and produces code that does not port to the next contract. It is the only route from an account-chain balance to a holder distribution, and its coverage stops at the contracts someone has decoded.
Unspent-output set statistics
The size and value distribution of the unspent output set is a native measure with no account-model equivalent. It responds to fee levels, consolidation behavior, and dust, which makes it information about wallet operations rather than about ownership.
Swoopr Investment Tool: Ledger Model Comparator
Recommended tool: a comparator that takes a metric name and returns, for each ledger model, whether the metric is read from stored state or reconstructed, and what assumption any reconstruction requires.
Inputs would be the metric, the network, and for reconstructed metrics the lot-selection convention. Outputs would expose the classification, the ledger fields the computation reads, the assumption inserted wherever the chain is silent, and a sensitivity band showing how far the answer moves across conventions.
Practical Checklist
- I identified the ledger model of the layer that executes, not the layer that settles.
- I obtained the lot-selection convention for every reconstructed figure.
- I know how change outputs were treated in any UTXO balance or volume series.
- I know whether contract accounts are included, excluded, or reported separately.
- I know whether internal calls were traced on the account chain.
- I labeled readings and estimates separately, and avoided individualized financial advice.
Frequently Asked Questions
Why is coin age easy to compute on a UTXO chain and hard on an account chain?
A UTXO stores the height of the block that created it, so age is one subtraction per output and the data is already present. An account stores a balance with no lots and no dates, so age has to be reconstructed by replaying every credit and debit and deciding which units left at each one. The chain never records that decision.
Does the accounting convention really change the answer?
Yes, substantially. In the reduced hypothetical on this page, three credits and one debit give a value-weighted age of 184 days under first-in-first-out and 320 days under last-in-first-out, a gap of 136 days on identical history. A pooled-average convention gives a third answer.
Is realized capitalization computable on both ledger models?
It is defined on both and computed differently. On a UTXO chain it sums each unspent output at the price when that output was created, which the ledger supports directly. On an account chain the same figure needs the full replay and an assumed convention, making it a model output rather than a reading.
Does UTXO coin age show which units are economically oldest?
Not exactly. It shows which outputs a wallet chose to spend, because the transaction input list records that choice. Coin selection is a wallet software policy, so a wallet that preferentially spends new outputs produces an age profile that is truthfully recorded and unrepresentative of its owner.
Why does a change output inflate raw transfer volume?
Spending a UTXO consumes it entirely, so a payment smaller than the input returns the remainder to the sender as a change output. That returned amount is recorded as value moved even though it never left the sender. Raw transaction volume on a UTXO chain therefore counts change alongside genuine payments, and the inflation can be large when inputs are much bigger than payments. Adjusted volume estimates attempt to identify and subtract change, using heuristics that are reliable in common cases and defeated by careful construction.
How is a transaction fee represented differently in the two models?
On a UTXO chain the fee is implicit: it is whatever remains after subtracting the outputs from the inputs, and no output records it. On an account chain the fee is computed from a gas amount multiplied by a price and deducted from the sender's balance as part of execution, with the parameters recorded in the transaction. That difference matters for reconstruction, since fee revenue on a UTXO chain must be derived rather than read, and a metric that sums outputs alone will not account for it.
Why does an account-model chain need traces to see all value movement?
Because a transaction on an account chain is an instruction to execute code, and the code can move value in ways that do not appear in the transaction's own fields. A single transaction can trigger a cascade of contract calls, each moving funds, and only the outermost call is recorded as a transaction. Reconstructing the rest requires re-executing the transaction and capturing the internal calls. Any analysis of value flow on such a chain built from transaction records alone is systematically incomplete.
How does a contract holding tokens appear in each model?
On an account chain a contract has an address and a balance exactly like a user account, so a contract holding a large amount is indistinguishable from a holder unless it is labelled as a contract. On a UTXO chain there are no contract accounts in the same sense, and comparable functionality is expressed through spending conditions attached to outputs. The practical consequence is that holder and concentration statistics on an account chain must actively exclude contracts, a step with no direct equivalent on a UTXO chain.
Which model makes total supply easier to audit?
The UTXO model, because supply is the sum of all unspent outputs and that set is enumerable directly from the chain's own state. Verifying it requires no assumptions beyond the validation rules. On an account chain, native supply is likewise derivable, but token supply lives inside individual contracts and depends on each contract's own logic, so auditing a token's supply means reading that contract rather than querying a shared structure. Contracts with mint functions or upgradeable logic complicate the answer further.
References
These sources should be reviewed during editorial verification. They support data structures and methods, not the hypothetical conclusion. Provider formulas, chain rules, and APIs can change. Confirm current documentation before publication.
- Bitcoin Developer Guide: Transactions: Inputs, outputs, spending conditions, and change, the objects every UTXO-native metric reads.
- Bitcoin Developer Guide: Block Chain: Block structure and height, the stamp an output carries and the basis of every coin-age calculation.
- Ethereum.org: Technical Introduction: Account state and contract accounts, and what a balance field does not record.
- Ethereum.org: Transactions: Account-model transaction fields and receipts, which define what a replay walks through.
- Coin Metrics: Network Data Glossary: Cross-network ledger, account, and UTXO definitions used when one metric name spans both models.
- Coin Metrics: Valuation Metrics: Realized capitalization construction, the clearest case of one name and two computations.