Why is a transaction list not a complete accounting population for ETH?

Because withdrawals and internal transfers are not in it. A validator withdrawal arrives as a gasless system-level credit with no hash, and a contract-driven movement is visible only by tracing. The closing balance has to be proved by roll-forward from the opening balance plus every movement, against a balance read at a finalized block, never by adding up transactions.

Should a period-end ETH balance be read at head or at a finalized block?

At a finalized block, with the block number retained. Software that reads the chain at head reads a state that may be revised, and ethereum.org says justified blocks are unlikely to be reverted but can be under certain conditions. The record should say the balance at block n, which was finalized, rather than the balance on 31 December.

Can per-epoch validator reward detail be recovered after the close?

Usually not. An ordinary node discards it within minutes, and a live test on 25 August 2026 asking for rewards six epochs back returned a missing-state error. A validator balance is a net figure of rewards, penalties and withdrawals that cannot be decomposed after the fact, so an entity must capture the detail contemporaneously, run an archive node, or buy it, and a purchased decomposition is the vendor's work product.

How should gas be reconciled at an Ethereum close?

As a quantity population, not only as an expense total. The execution fee is gas used times effective gas price, both taken from the receipt, with any blob fee captured separately and the block's base fee used to split the number into its burned and paid components. Status 0 failures stay in the population, because the ETH is gone all the same and whether that is an expense, a loss, or nothing is a named guidance gap.

Is a block explorer page audit evidence?

It is a convenient view, not a subledger and not proof of ownership. Address labels, entity names and fiat values are a third party's work product, internal transactions are a reconstruction by re-execution, and an explorer screenshot mixes self-proving, privileged and third-party evidence with no visual distinction between them.

Ethereum Accounting Controls: Records and Reconciliation

Ethereum accounting fails operationally long before it fails conceptually. A policy can be correct and the books can still be wrong, and Ethereum accounting controls are what stand between the two. The close breaks in the plumbing, not the framework, when the subledger has:

rounded ETH to eight decimals;
dropped failed transactions;
missed contract-driven ETH movements;
treated a validator withdrawal as an ordinary transaction;
failed to retain historical validator reward data;
used a head balance instead of finalized evidence;
lost the mapping between validators and withdrawal credentials; or
reconciled wallet balances without the consensus-layer position.

Ethereum accounting controls for native ETH should therefore be organized around:

the data source, then what it proves, then what it cannot prove, then the required control, then the reconciliation step

This article is an operational close manual. It assumes the accounting policies themselves have already been established in the framework and tax articles.

Evidence hierarchy

Each block commits to a defined set of records: the transactions, one receipt per transaction (carrying status, gasUsed, effectiveGasPrice and any logs), the resulting account states, header fields including baseFeePerGas, gasUsed, gasLimit and timestamp, the block's fee recipient, and, since April 2023, a separate list of withdrawals.

A node is a computer running Ethereum's software that holds the chain and can answer questions about it. A block explorer is a website that queries a node and presents the answers, adding a great deal of its own. Everything else that appears on a block-explorer page is somebody's work product. Address labels and entity names are not in the account state. There is no name field. US dollar values are a third party's valuation at that third party's chosen timestamp. "Internal transactions" are a reconstruction by re-execution. Token balances are read out of another contract's storage. ethereum.org's own description of block explorers illustrates the risk: it describes the "Transaction fee" a user sees as "The amount paid to the validator to process the transaction (calculated by gas price*gas used)", a description that is wrong for the burned portion, which no validator receives.

Three tiers of evidence follow, and they should be labelled differently in a working paper:

Self-proving. Committed to a block hash and reproducible from any full node: transactions, receipts, logs, header fields, withdrawals, and balances, though reading one at a past block needs a node that has kept the relevant state.
Reproducible but privileged. Traces of internal transfers are reproducible in principle, but only from a node that has kept the relevant state, in a format nobody has standardised. The specification even defines an error for the common case: 4444 Pruned history unavailable. Public endpoints frequently refuse: one returns "Archive requests require a personal token."
Third-party assertion. Labels, entity groupings, fiat values, annualised yields. Useful, not evidence.

An explorer screenshot mixes all three with no visual distinction between them.

Cutoff: timestamp is protocol time

Under proof of stake nobody chooses a block's timestamp. Through the Fulu upgrade, the consensus specification requires that the execution payload's timestamp equal the time computed for its slot:

# Verify timestamp
assert payload.timestamp == compute_time_at_slot(state, state.slot)

and compute_time_at_slot is arithmetic: genesis time plus slot number times 12 seconds. The block timestamp is therefore a slot clock reading, accurate to the protocol's own schedule and useless as a business clock. Three limits matter for cut-off:

Granularity. Every transaction in a block shares one timestamp. Hundreds of transactions can carry the same instant, and their order within the block is the choice of whoever assembled it, often a specialist builder (a firm that constructs blocks and sells them to validators), and that choice is economic, not chronological.
It is not the event time. The gap between signing a transaction and its inclusion is invisible on-chain. A payment authorised before a period end can land after it.
Slots can be empty. ethereum.org notes that "occasionally validators might be offline when called to propose a block, meaning slots can sometimes go empty", so consecutive block timestamps differ by a multiple of 12 seconds, not always 12.

Cutoff: finalized state is stronger evidence

Ethereum finalises in two stages. The first block of each epoch is a checkpoint. A checkpoint becomes justified when validators holding two-thirds of the ETH staked on the network vote for it, and finalised when a later checkpoint is justified on top of it. Finalisation is processed at every epoch boundary (every 6.4 minutes), and what gets finalised there is the checkpoint from two epochs earlier. A live query on 25 August 2026, at head slot 15,067,723 in epoch 470,866, returned a finalized checkpoint at epoch 470,864, exactly two epochs behind.

An ordinary transaction is not a checkpoint, so it waits slightly longer: it becomes final when the next checkpoint descending from its block is finalised, which is two to three epochs, 12.8 to 19.2 minutes. The Ethereum Foundation's own current wording rounds this to "It takes about 15 minutes for an Ethereum block to finalize." The "12.8 minutes" figure that circulates is the lower end of that checkpoint arithmetic and is the best case only, available to a transaction that lands in the first slot of an epoch. Quoted as the typical wait for a transaction, it is too fast.

Before finality, history can change. ethereum.org's description of the consensus mechanism says so directly: "Justified blocks are unlikely to be reverted, but they can be under certain conditions."

The control implication is concrete. Software that reads the chain at head reads a state that may be revised. Software that reads at finalized does not. For a period-end balance that will be audited, the query should be pinned to a finalized block, and the block number retained: not "the balance on 31 December", but "the balance at block n, which was finalized". A reorganisation discovered after booking is then corrected as a data defect rather than a new transaction: re-read the affected addresses at a finalized block, establish which transactions survived and which were dropped, and correct quantity, fee and lot consumption together.

Can one economic event produce multiple disconnected records?

Constantly. This is the defining reconciliation problem for ETH, and it is worse than Bitcoin's because the records sit on two different ledgers with different identifiers.

One economic event	Record 1	Record 2	What links them
Proposing a block	Consensus-layer proposal reward credited to the validator balance	Execution-layer priority fees, or a builder's payment transaction to the fee recipient	Nothing on-chain. The slot number and the entity's own records
Requesting a partial withdrawal	An EIP-7002 request transaction, with a hash and a gas cost	A gasless system-level withdrawal credit days later, with no hash	Nothing. The validator index and the entity's records
Creating a validator	A deposit transaction on the execution layer	The validator appearing, later, in the consensus-layer registry	The deposit data, matched by hand
Depositing ETH at an exchange	An on-chain transfer	A credit on the exchange's private ledger	The exchange's statement
A batched transaction under EIP-7702	One transaction hash	Several economically distinct transfers inside it, visible only by tracing	The trace

The evidence has a shelf life

One further constraint has no analogue in traditional records and it catches entities out at year-end. Per-epoch reward detail is not retained indefinitely by an ordinary node. A live test on 25 August 2026 requested attestation rewards for epoch 470,860 (six epochs, under 40 minutes, in the past) and received {"code":404,"message":"NOT_FOUND: missing state at slot 15067583"}, while a query four epochs later succeeded.

Under native staking, a validator's balance is a net figure: rewards, penalties and withdrawals collapsed into one number. It cannot be decomposed after the fact. An entity that wants an annual analysis of its native staking income by component must either run an archive node, one that keeps every historical state instead of pruning it away, capture the data contemporaneously, or buy it from a third party. The third party's decomposition is that party's work product, not a protocol record.

Evidence rule. A block explorer is a convenient view, not a subledger and not proof of ownership. For ETH, retain execution-layer node or explorer data and consensus-layer validator records, together with wallet descriptors and control evidence, exchange and custodian statements, contracts, invoices, and the valuation record. Balances must be proved by roll-forward against the account balance at a finalized block, never by adding up a transaction list.

Records and evidence required

An ETH ledger is supportable only when execution-layer data, consensus-layer data and business evidence are kept together. The chain can prove that balances changed. It cannot prove why, for whom, under what contract, or at what cost.

Minimum transaction record

For each material ETH event, retain the fields that apply. The rows in bold are the ones that do not exist for a UTXO-based asset and are routinely missing from ETH subledgers.

Field	Why it matters for native ETH
Asset and network	Distinguishes native ETH on Ethereum mainnet from an exchange claim, a wrapped or bridged representation, or a testnet balance
Address	The account whose balance changed
Address type at the reporting date	Empty code, a 23-byte `0xef0100` delegation, or a contract. This can change after onboarding
Transaction hash, where one exists	Identifies the execution-layer transaction
Record type	Transaction, internal transfer, withdrawal, or fee-recipient credit. Only the first has a hash
Receipt status	1 or 0. A status-0 transaction consumed ETH with nothing received: whether that is an expense, a loss, or nothing is a named guidance gap
Gas used	From the receipt, not the transaction's gas limit
Effective gas price	From the receipt: "The actual value per gas deducted from the sender's account" (execution API receipt schema)
Base fee per gas for the block	Needed to split the fee into the burned and paid components
Fee burned, and fee credited to the block's fee recipient	Two economically different amounts inside one number. The recipient is whoever the block names, which under MEV-Boost is normally the builder rather than the validator, who is then paid by a transfer at the end of the block that carries its own hash. Some builders instead name the validator's own address, so the same income arrives with no transaction and no hash; which route predominates is not documented, and the close has to handle both
Blob fee, where a type-3 transaction is involved	A second fee, entirely burned, and not inside `gasUsed × effectiveGasPrice`
Quantity before and after, in wei	Eight decimal places will not reconcile
Block number and whether that block was finalized	Inclusion is not finality
Event timestamp and timezone	The block timestamp is a slot clock reading, shared by every transaction in the block
Accounting recognition timestamp	Where the business event differs from the protocol event
Counterparty, if known	The chain supplies an address, never an identity
Economic purpose	Purchase, sale, customer receipt, compensation, staking deposit, staking reward, fee, internal transfer, loan or other
Self-transfer flag	Prevents an internal move becoming a false disposal
Fee purpose and allocation	Determines whether gas is expense, acquisition cost, selling cost or nothing capitalisable
Functional-currency price, source and valuation timestamp	Makes the measurement reproducible
Accounting-lot reference	Preserves book history, which the chain does not hold
Tax-lot reference	Preserves the jurisdiction-specific history separately
Beneficial ownership and control conclusion	Determines whether the recorded ETH is the holder's asset
Custody status	Self-custody, segregated custody, or a contractual claim
Linked records for one economic event	Withdrawal request to withdrawal credit, block proposal to builder payment, exchange transfer to trade
Supporting-document reference	Invoice, contract, statement, approval

For a validator run by the entity itself, add a second record set that has no equivalent for a non-staking holder:

Field	Why it matters
Validator index and public key	The identifier on the consensus layer. There is no address
Withdrawal credential type and address	`0x00` means nothing can ever be withdrawn until it is upgraded. The address named is the only place the balance can go
Fee recipient address configured, and when it changed	Execution-layer rewards go wherever this points. The protocol keeps no record of what was intended
Deposit transaction hash and activation date	Two dates, two ledgers, one event
Validator balance, in gwei, at each period end	The balance that grows
Effective balance	Protocol input to reward calculation, not a measure of the asset
Status	Pending, active, exiting, slashed, withdrawable
Reward detail by component, captured contemporaneously	An ordinary node discards per-epoch reward data within minutes
Penalties, inactivity-leak amounts, slashing events	Quantity reductions with no transaction
Withdrawal index, amount in gwei, and destination	Withdrawals have no hash. The global index is the only document number available
Exit and withdrawability dates, and queue position	The basis for any restriction disclosure

Supporting evidence

For the execution layer: balances read at a finalized block with the block number recorded, raw transactions and receipts, block headers for base fees, trace output where internal transfers are involved, wallet descriptors and labels, and evidence that the entity controls the keys. Auditors of listed ETH holders are testing this directly. One filing describes it as obtaining evidence of control "through a combination of decoding cryptographic messages signed using selected private keys or through observing the movement of selected crypto assets" (Coinbase Global, Inc., Form 10-K for FY2025). A screenshot of a balance is not that.

For the consensus layer: validator records, balance history, reward detail captured as it happens, withdrawal records, and the deposit data linking the validator to the entity. Remember the retention problem from Why the Ethereum Blockchain Is Not an Accounting Ledger: per-epoch reward detail is gone from an ordinary node within minutes. An entity that wants that analysis at year-end must capture it during the year, run an archive node, or buy it. A purchased decomposition is the vendor's work product.

For exchanges and custodians: statements, trade ledgers, deposit and withdrawal ledgers, custody terms, and whatever bears on segregation, reuse rights and insolvency treatment. A balance labelled "ETH" does not decide whether the entity owns ETH or owns a claim.

For valuation: the raw price response and the exact request URL, the venue and product, the timestamp and timezone, the retrieval date, the principal-market conclusion and the documented fallback.

For the business: contracts, invoices, payroll records, bank statements, loan and collateral terms, gift documentation, insurance and legal correspondence.

Evidence rule. An Ethereum transaction proves a protocol event. It does not, by itself, prove legal ownership, business purpose, tax residence, invoice timing, accounting classification or tax treatment. No regulator or court has stated that proposition in those words. The closest support is the Law Commission of England and Wales, which observes that "there are situations in which superior legal title (sometimes referred to as 'ownership') to a digital object can be separated from (factual) control over that digital object", and the Celsius bankruptcy court, which decided ownership by reading the contract and reached the opposite answer to what the customers' account screens showed.

Period-end close and reconciliation

The close is where Ethereum accounting controls are actually exercised. Reconcile quantity, rights, carrying amount and tax history separately. Agreement in one dimension proves nothing about the others.

Prove the execution-layer quantity at a finalized block. Read the balance at a specific block, record the block number, and confirm it was finalized. Do not close on latest.
Prove the consensus-layer quantity. Reconcile every validator balance the entity claims to control, and confirm the withdrawal credential type and address for each.
Roll forward, do not add up. Prove the closing balance from the opening balance plus every movement. A transaction list is not a complete population: withdrawals and internal transfers are not in it. The event map in How to Account for Ethereum Transactions sets out what that population has to contain.
Recompute every fee from the receipt. Fee equals gas used times effective gas price. Split it into the burned and paid components using the block's base fee.
Capture failed transactions. Filter for receipt status 0. The ETH is gone all the same, and whether that is an expense, a loss, or nothing is a named guidance gap.
Match internal transfers. Where a contract moved ETH to or from the entity, obtain the trace and retain it. The format is not standardised and the source may not keep the data.
Separate own-address movements from disposals. Deposits to the entity's own validator, withdrawals from it, and transfers between the entity's addresses are not sales of the quantity moved. The gas each one costs is still a disposal of the fee ETH; both halves have to stay together.
Recognise reward accrual through the period end under the documented aggregation and measurement policy, and reconcile it to the validator balance movement.
Investigate every balance increase with no transaction. It is a withdrawal, an internal transfer, or a block reward. Otherwise it is something that needs explaining before the books close.
Confirm which lot left. For withdrawals and disposals, apply the documented lot policy explicitly. The protocol expresses no view.
Review penalties and slashing. Remember that one slashing event produces a second, separate charge about eighteen days later (negligible for a lone validator, but approaching the whole stake in a correlated event), and that the balance does not become withdrawable until about thirty-six days after the event.
Confirm restrictions. Queue positions, exit timing, credential type and any encumbrance. Date them, because a queue is a network condition, not a term.
Review control changes. Delegation set or revoked, fee recipient changed, credentials upgraded, keys rotated, custody arrangements amended.
Review loss events. Lost keys, theft, misdirected transfers, failed custodians, defaults.
Apply the documented valuation policy (venue, minute, timezone, fallback) and retain the raw responses.
Book the framework close. IAS 38 and IAS 36, IAS 2, or ASC 350-60 fair value, with the impairment unit of account applied as documented.
Reconcile book basis to tax basis separately, under each jurisdiction's own lot rules.
Assess current and deferred tax under IAS 12 or ASC 740.
Review presentation, cash flows and disclosures, remembering that ETH-only activity is non-cash.
Freeze the evidence package, including the block numbers everything was proved at.

A useful diagnostic order:

quantity wrong at the wallet: inspect internal transfers, withdrawals, failed-transaction gas and replaced transactions
wallet right but total quantity wrong: inspect the validator
quantity right but lot ledger wrong: inspect reward aggregation and which lot the withdrawal took
lot ledger right but economic position wrong: inspect custody, credentials and encumbrances
quantity right but carrying value wrong: inspect the price convention and the impairment unit of account
carrying amount right but tax result wrong: inspect taxpayer classification, tax basis and the jurisdiction's lot rules.

Ethereum accounting controls: the control matrix

Each row pairs a data source with what it settles, what it cannot settle, and the control that closes the gap.

Data source	What it proves	What it cannot prove	Required control
Finalized execution-layer balance	ETH quantity at one address at a specific finalized state	Legal owner, acquisition basis, business purpose	Address registry plus lot reconciliation
Transaction	Sender instruction, destination, value, nonce, fee parameters	Final success, internal transfers	Join to receipt and block
Receipt	Status, gas used, effective gas price, logs	Business purpose, complete native-ETH internal movement	Economic-event mapping plus tracing where needed
Trace	Reconstructed execution call frames and internal value movement	A standardised committed transfer ledger	Provider or node validation plus retained raw output
Withdrawal list	Validator index, recipient address, amount, withdrawal index	Why the withdrawal occurred, which book lot moved	Validator mapping plus lot policy
Consensus validator state	Validator balance, status and credentials	Entity ownership	Validator register plus credential-control evidence
Custodian statement	Private-ledger activity	Whether native ETH remains legally owned by customer	Contract review plus reconciliation to custodian terms
Price feed	Observed price under source methodology	Whether source is the principal market	Valuation policy plus raw evidence retention
Book-lot ledger	Carrying amount and internal lot history	On-chain existence	Reconcile to protocol quantity
Tax-lot ledger	Jurisdictional basis	Financial-reporting carrying amount	Separate book-to-tax reconciliation

Own-address registry

The entity should maintain an effective-dated registry of every address it treats as its own.

Minimum fields include:

address;
network;
purpose;
owner or entity;
key or signer control model;
multisig threshold where applicable;
custodian or wallet technology;
EIP-7702 delegation status where relevant;
active-from and active-to dates;
approval evidence.

Without an own-address registry, an internal transfer is indistinguishable from a disposal or a third-party payment at the point the raw transaction is ingested.

Validator register

For every native validator, retain:

validator public key;
validator index;
deposit transaction;
deposit date;
activation date;
withdrawal credential prefix;
withdrawal address or BLS credential evidence;
signing-key custody;
fee-recipient address;
operator or service arrangement;
current validator status;
exit request and exit epoch if applicable;
withdrawable epoch;
withdrawal records.

A current validator balance without those links is not a complete accounting record.

Gas reconciliation

Gas should be reconciled as a quantity population, not only as an expense total.

For each outgoing included transaction:

execution fee = gasUsed × effectiveGasPrice

Then:

capture any blob fee separately;
verify the total wei quantity removed;
classify the cost by transaction purpose;
consume the applicable book lot;
consume the applicable tax lot under the separate jurisdictional method;
retain status, including 0 failures.

A materiality threshold can control financial-statement presentation. It should not cause the quantity subledger to stop tying to the chain.

Reward reconciliation

A staking close needs at least four separate movements:

opening validator balance;
gross consensus rewards;
protocol penalties or other reductions;
withdrawals and other protocol movements.

The result should reconcile to closing validator balance.

Execution-layer validator income is separate again. Reconcile the fee-recipient address for priority-fee or builder-related receipts and link those events to the relevant proposed blocks where material.

Do not use the closing validator balance as a substitute for historical reward evidence. A net balance does not reveal the path that produced it.

Book-to-tax reconciliation

The protocol quantity should be the common physical denominator. Book and tax amounts can legitimately differ.

A close file should therefore reconcile:

the same ETH quantity, then the book lot and carrying amount, then the tax lot and cost basis, then temporary differences where applicable

Do not force the tax ledger to mirror the financial-reporting lot policy. Canada, the United States, and the United Kingdom use materially different tax-basis mechanics.

Evidence package at period end

A repeatable evidence package should contain:

finalized block number used for execution-layer cutoff;
raw address balances at that block;
transaction and receipt population;
trace-derived movements and trace methodology where used;
EIP-4895 withdrawals;
validator state and balance evidence;
reward and penalty data;
own-address and validator registers;
custody statements and contracts;
price-source evidence;
book-lot rollforward;
tax-lot rollforward;
reconciliation exceptions and resolutions;
reviewer sign-off.

Ethereum close and reconciliation control chain

A transaction list alone is not a complete accounting population.

Source captureReceipts, traces and consensus-layer records, retained as captured.
Ownership registryAddresses, validators and withdrawal credentials, effective-dated.
Quantity reconciliationWallet and validator quantities together, proved in wei.
Valuation evidenceMarket, time and the documented fallback, with raw responses kept.
Book and tax bridgeLots, basis and adjustments, reconciled separately.

Retain enough execution and consensus evidence to reconstruct the close after public infrastructure has pruned historical detail.

The conceptual reason these data sets cannot be collapsed is explained in Why the Ethereum Blockchain Is Not an Accounting Ledger. Ethereum accounting controls exist to keep them apart and to prove each one against its own evidence, and our crypto accounting guide covers the wider close workflow they sit in.

How Tokenbooks helps with records, controls and the close

Tokenbooks makes reconciliation a number rather than a status light. The assets view shows the balance computed from transaction history, the balance the last sync observed, and the difference between them. The period-close screen lists balance mismatches and on-chain reconciliation mismatches per asset, with booked, on-chain and difference columns, which is the quantity proof this article puts at the centre of the close. Closing a period locks a contiguous range, records the debit and credit totals, and stores a hash of the source transactions and a hash of the booked journals. Reopening is recorded with the actor and the reason, and the closed period stays as history. A raw transactions view keeps the source transaction, its transfers, the event logs and the decoded contract calls beside the accounting interpretation. Reports export to Excel and JSON.

What reaches that close from the chain is set out on the Ethereum integration page.

Sources and authority map

EIP-4895, "Beacon chain push withdrawals as operations". eips.ethereum.org
EIP-7708, "ETH transfers emit a log". eips.ethereum.org
Ethereum execution API specification. receipt schema
Go Ethereum documentation, tracing. debug namespace
ethereum.org, proof-of-stake pages. proof of stake
ethereum.org, staking pages. staking
Beacon API specification. ethereum.github.io/beacon-APIs
Live chain observations, 25 August 2026 UTC.
AICPA, "Accounting for and auditing of digital assets" practice aid. aicpa-cima.com
PCAOB Auditing Standard 3101, The Auditor's Report on an Audit of Financial Statements When the Auditor Expresses an Unqualified Opinion. pcaobus.org
Coinbase Global, Inc., Form 10-K for FY2025, including its auditor's critical audit matter on crypto assets held in cold storage. sec.gov
Coinbase Exchange candles endpoint documentation. docs.cdp.coinbase.com
Coinbase Exchange ETH-USD one-minute candles, the exact observations used in the worked pricing example in Ethereum Valuation for Accounting. 18 Mar 13:58
CRA, "Keeping books and records of crypto-assets for tax filing", and "Determining the value of crypto-assets for tax filing". books and records
Law Commission of England and Wales, "Digital assets: final report" (Law Com No 412). lawcom.gov.uk
In re Celsius Network LLC, memorandum opinion on ownership of Earn account assets, United States Bankruptcy Court, Southern District of New York, January 2023.

Research status. Protocol mechanics and published guidance were refreshed through 31 August 2026. Where a source is interpretive rather than authoritative, the text says so. This article is educational research, not accounting, tax, legal, valuation, or investment advice.