Ethereum for Accountants: The Concepts You Actually Need

If an accountant understands only one technical idea about Ethereum, it should be this: Ethereum does not record ETH as separate coins or accounting lots. It records a balance. Ethereum for accountants begins with an integer number of wei attached to an account, and nothing in that integer says when the ETH was acquired or what it cost.

Nothing in that integer says why the ETH arrived either, or which book lot should leave when ETH is spent. That single difference explains much of Ethereum accounting. The chain can prove quantities and protocol events extremely well. It cannot supply the entity's cost basis, legal ownership conclusion, business purpose, accounting classification, or tax lot history. Native staking adds a second complication: the holder can have ETH represented in execution-layer account state and in consensus-layer validator state at the same time.

This article gives the minimum Ethereum knowledge needed to read the rest of the series. Ethereum for accountants stops there: it does not try to turn an accountant into an Ethereum developer.

Protocol date: Ethereum mainnet mechanics in this article were reviewed through 31 August 2026. The deployed network reflects the Fusaka-era rules. Ethereum.org describes Glamsterdam as an upcoming upgrade planned for Q4 2026, but the Glamsterdam Meta EIP still contains no mainnet activation epoch or timestamp. Future mechanics should therefore not be written as though they are already live.

Ethereum and Bitcoin: the accounting-level difference

The table is intentionally narrow. The point is not that one network is "better". The point is that an accountant cannot reuse a Bitcoin subledger model and merely rename BTC to ETH. Ethereum for accountants starts from the account model, and everything below follows from that.

Ethereum for accountants: what native ETH actually is

Ether is the asset that Ethereum's own rules create and consume. Its unit is written ETH. Native ETH means the asset recorded on the Ethereum network itself, held at an address the holder controls, or staked by the holder in a validator the holder operates. That second case is native staking, and it is the only kind of staking this article covers.

Ethereum was built to answer a different question from Bitcoin's. Bitcoin asks how one person can send digital value to another without a bank. Ethereum asks what happens if the same shared, publicly verifiable record can also run programs. A program that lives on the network is called a smart contract: code stored at its own address that anyone can call, that runs the same way for everyone, and that no single party can quietly amend (ethereum.org, smart contracts). Ether is what makes that possible in practice. It pays for the computation, it is the reward the network pays the computers that keep it honest, and it is the collateral those computers must post.

That triple role is the whole reason this article is longer than a "what is a coin" explainer. ETH is simultaneously:

• an asset a holder can buy, hold, receive, spend and sell
• the fuel consumed by every transaction, including transactions that fail and produce nothing
• the bond a holder posts to become a validator, which then produces a balance that grows on a ledger the holder's wallet software cannot see, which the article calls native staking.

An accountant may meet ETH as an investment, a treasury asset, customer consideration, compensation, collateral, or the output of native staking. Those uses do not turn ETH itself into cash, revenue, inventory, a receivable or a liability. The transaction facts and the reporting framework decide what is recognised.

One ETH divides into 1,000,000,000,000,000,000 units called wei. That is 10¹⁸, eighteen decimal places. An intermediate unit, the gwei, is 1,000,000,000 wei, and gas prices are conventionally quoted in gwei. Simply holding ETH does not make the quantity grow: there is no issuer paying interest, no balance that rebases, no conversion rate underneath the unit. Native staking is different, and Ethereum Staking Rewards explains why.

Scope boundary. This article covers native ETH on Ethereum mainnet, held either at an address the holder controls or staked in a validator the holder operates. Staking here always means native staking, in which the holder runs the validator and holds its withdrawal credentials. ethereum.org calls this home staking, having renamed it from "solo staking" at some point between May 2024 and January 2025. Its own site navigation still carries the old label and the page URL still ends in /solo/, so a reader will meet all three words. This article says native staking, because the distinction that decides the accounting is whether the ETH is the holder's own on the protocol or a claim on somebody else, not where the hardware sits. Pooled staking, staking as a service, liquid staking and restaking are different token types and are covered elsewhere in this series. Where this article says ETH is staked, it never means a claim on a pool or a provider.

Several things carry the word "ETH" and are different token types, each belonging to its own article in this series. An "ETH" balance credited by an exchange or custodian. Wrapped ether (WETH). Liquid staking tokens such as stETH, rETH and cbETH. ETH bridged to a layer-2 network such as Arbitrum, Optimism or Base. Spot ether exchange-traded products. ETH futures, options and contracts for difference. Ether on a test network or a fork chain such as Ethereum Classic. Different rights, different counterparties, different evidence, and usually a different accounting answer. Nothing in this article carries across to them, and What Do You Actually Own When You Hold ETH? works through the positions one by one.

How does it actually work?

An account is a row, not a container

A private key is a randomly chosen secret number. Software generates it, but the number itself is independent of that software: it can be exported, backed up on paper, and imported into different software, and it still controls exactly the same holdings. A wallet is software or hardware that generates, protects and uses keys. It is not a box holding coins, and the wallet provider holds nothing. ethereum.org is explicit that "wallet providers don't have custody of your funds", and its accounts documentation adds that "an account is not a wallet". Holding the key is what confers control, because only the key can produce a valid digital signature, the proof the network requires that a proposed instruction came from the key's holder. The signature does not reveal the key. The address that key controls is a 20-byte identifier computed from the key's public half, conventionally written as 42 characters beginning 0x.

Ethereum keeps, for every address, a small record called the account state. The Ethereum Yellow Paper, the network's formal specification, puts it plainly: "The account state, σ[a], comprises the following four fields", which are the nonce, the balance, the storage root and the code hash. Of those, the accountant only needs two:

• the balance, which the Yellow Paper defines as "A scalar value equal to the number of Wei owned by this address", and
• the nonce, a counter that increments with every transaction the address sends, which stops the same signed instruction being replayed.

There are two kinds of account. An externally owned account, or EOA, is "controlled by anyone with the private keys". A contract account is "a smart contract deployed to the network, controlled by code" and, critically, contract accounts "don't have private keys". A contract account can hold ETH and move it, but only when something calls it: it "can only send messages in response to receiving a transaction".

What changes such a row is a transaction: a signed instruction naming a destination, a value in wei to move, and the most the sender will pay for the work it causes. Ethereum meters that work in units of gas, which the sender pays for in ETH. Once a transaction has been included in a block, the block also commits to a receipt for it, recording whether it succeeded and how much gas it actually used.

Read the balance definition again, because the accounting consequence is immediate and permanent. The balance is one number. It carries no acquisition date, no cost, no counterparty, no lot identity and no history. Ethereum records what an address has, never how it got it or what it cost. Every cost-basis layer an accountant builds is a construction that exists only in the entity's own records. The chain can corroborate a total. It can never corroborate which units were disposed of.

Execution layer and consensus layer

Everything above happens on what Ethereum calls the execution layer (accounts, balances, transactions, gas). Since September 2022 the network has been secured by a second, parallel ledger: the consensus layer, also called the beacon chain.

The consensus layer runs on a clock. Time is cut into slots of 12 seconds and epochs of 32 slots, which is 6.4 minutes. ethereum.org states it as "Time in proof-of-stake Ethereum is divided into slots (12 seconds) and epochs (32 slots)". In each slot one validator is chosen to propose a block and a committee of validators votes on it, each validator voting once per epoch rather than once per slot. A validator is not a machine. It is an entry in a registry, identified by a public key, carrying its own balance, denominated in gwei.

This article covers native staking only, meaning the holder runs their own validator and holds their own withdrawal credentials. To create a validator, such a holder sends 32 ETH to a specific contract at address 0x00000000219ab540356cBB839Cbe05303d7705Fa and supplies the validator's public key together with withdrawal credentials, a commitment naming where the ETH may eventually be paid out. That deposit contract has exactly four external functions: deposit, get_deposit_root, get_deposit_count and supportsInterface. There is no withdraw function, no owner and no upgrade path. ETH goes in through the execution layer and can only come back out through the consensus layer's own withdrawal machinery.

Two precisions matter for record-keeping. The contract itself does not enforce 32 ETH: it requires only that a deposit be at least 1 ETH and a whole number of gwei. The 32 ETH figure is a consensus-layer rule. A validator is not activated, and earns nothing, until its balance reaches it, so a short deposit simply sits there. And since the Pectra upgrade, deposits are queued rather than applied immediately. The date of the deposit transaction and the date the validator starts earning are different dates, recorded on different ledgers, and both belong in the records.

From that moment the holder has two balances in two ledgers, and only one of them is visible to ordinary wallet software:

ethereum.org describes the separation exactly: "Validator rewards continue to accrue to validator balances that are managed within the consensus layer", and those "are separate Ethereum accounts cannot transact freely with other Ethereum accounts. Funds in these accounts can only be withdrawn to a single specified execution address." The dropped word in that second sentence is the source's own.

That is the sentence to reread before designing an ETH subledger. The ETH of an entity staking natively is split across two record systems with different units, different identifiers, different tooling and different retention characteristics, and the balance that grows is the one no block explorer will show.

Store quantities in wei, not rounded ETH

Bitcoin's accounting problem is that a wallet balance is a sum of separate spendable pieces. Ethereum's is the opposite and, for an accountant, harder: there are no pieces at all. One address, one integer, no structure.

Balances are integers of wei. The Yellow Paper instructs that "any reference to value, in the context of Ether, currency, a balance or a payment, should be assumed to be counted in Wei." Nothing is rounded on-chain. Every rounding difference an accountant sees originated in the accountant's own systems, which is a useful diagnostic: if a reconciliation is out by a fraction of a wei, the chain is not the suspect.

The practical consequence is that a subledger must reconcile in wei even when it reports in ETH. Eight decimal places, the habit imported from Bitcoin, silently truncates ten digits.

Time, blocks, and finality

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.

Inclusion is not finality

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".

Accounts can now be delegated

Until 2025 a simple test distinguished a person's wallet from a program: if an address had no code, it was controlled by keys. The Pectra upgrade ended that. EIP-7702 "allows Externally Owned Accounts (EOAs) to set the code in their account" by signing an authorisation, after which "a delegation indicator (0xef0100 || address) is written to the authorizing account's code" and "All code executing operations must load and execute the code pointed to by the delegation."

The motivations are ordinary conveniences (the EIP lists "Batching", "Sponsorship: account X pays for a transaction on behalf of account Y", and "Privilege de-escalation"), but each changes something an accountant relies on. Batching means one transaction hash can carry many economic events. Sponsorship means the address in the from field may not be the party that bore the cost. And delegation is a security surface the EIP itself flags: "A poorly implemented delegate can allow a malicious actor to take near complete control over a signer's EOA."

Two limits stop this being alarming. Nobody can do it to an address they do not control: the delegation is written only after the account's own private key signs the authorisation. And it is revocable by that same key, by re-authorising to the zero address.

Two features make it matter anyway. The delegation persists across transactions until it is changed (it is not per-transaction), and it is not rolled back by a failed transaction: the EIP states that "if transaction execution results in failure (e.g. any exceptional condition or code reverting), the processed delegation indicators is not rolled back."

A delegated account is visible: its code is exactly 23 bytes, beginning 0xef0100 and followed by the delegate's address. A live example on 25 August 2026 is 0xd2548e8b448a1efe923c0091abcb9deec817bf5a. Read its code yourself with eth_getCode rather than trusting a figure printed here. During the drafting of this article that account re-authorised to a different delegate within the hour, which is exactly the point. The control conclusion for an address is therefore a reporting-date question, not an onboarding question, and the test now has three answers: empty code means a plain EOA, 23 bytes starting 0xef0100 means a delegated EOA, anything else means a contract. An address that has behaved as a simple wallet for years can begin behaving as a programmable contract wallet from one transaction onwards.

Nonces and replacement transactions

A pending transaction can be replaced by sending another with the same nonce and a higher fee, the familiar "speed up" and "cancel" buttons. Only one can ever execute, because only one transaction per nonce is valid for an account. The replaced transaction is not recorded anywhere on the chain. It existed only in nodes' pending-transaction pools, which are local and not part of consensus.

Two consequences follow. Only one fee was ever paid, so a ledger built from a wallet interface that lists both the original and the replacement will double-count. And a "cancel" is a real expense, 21,000 gas for a transaction that deliberately does nothing.

Where new ETH comes from

Ethereum has no corporate issuer and no supply cap. New ETH is issued by the protocol to validators as a reward for securing the network. ethereum.org states the absence of an issuer plainly: "The underlying Ethereum protocol creates the new ether, and it is not possible for a user to create ether", and ether "is minted as a reward for each block proposed and at every epoch checkpoint for other validator activity related to reaching consensus". ETH is destroyed by the base-fee burn described in Ethereum Gas Fee Accounting. Net supply is the difference, and it can be negative.

Issuance is formula-driven, not discretionary. The Altair consensus specification computes a base reward per unit of stake as EFFECTIVE_BALANCE_INCREMENT * BASE_REWARD_FACTOR // integer_squareroot(get_total_active_balance(state)), with the factor set to 64. Because the divisor is a square root, total issuance rises with the square root of the amount staked while the yield per validator falls as more ETH is staked. Nothing about that is contractual: no rate is promised to anyone, and the rate changes as other people's staking decisions change.

Execution-layer issuance is zero. ethereum.org: "Execution layer issuance since The Merge is zero." Every ETH an execution-layer address receives came from somewhere else in the system.

Native staking in one page

A validator is created by depositing to the deposit contract with 32 ETH and a set of withdrawal credentials. Under native staking those credentials name an address the holder controls, which is what separates it from a pooled position. Three types exist and they are not interchangeable:

Credentials are set once. ethereum.org says of the process that it "is a one-time process, and cannot be changed once submitted", and of the one upgrade it does describe, from what it calls Type 1 to Type 2 - 0x01 to 0x02 - that "Converting from Type 1 to Type 2 withdrawal credentials is irreversible." That page touches 0x00 only in passing - "A 0x00 prefix indicates the account needs upgrading before withdrawals are enabled" - and never describes the upgrade itself. Reading the three types together, the only direction of travel is 0x00 → 0x01 → 0x02, and that reading is this article's own, not a sentence on that page. Credential type is a mandatory field in any staking asset register, not a technical footnote. The difference is not theoretical. On 25 August 2026 the validator registry held 902,701 active validators, of which 875,763 carried 0x01 credentials, 17,877 carried 0x02, and 9,061 still carried 0x00. Those 9,061 held 335,817.66 ETH between them, a mean of 37.06 ETH each: principal, plus the rewards that have piled up on top of it because such validators are never swept. Piled up, not compounded: without an execution withdrawal credential the effective balance stays capped at MIN_ACTIVATION_BALANCE, so the excess earns nothing at all. None of it can be paid out to anyone until their operators sign a credential change. That is a census rather than a sample, and the point is that anyone can take it: the whole registry comes back from a beacon node in a single unauthenticated call, so an entity can count its own 0x00 exposure, and the network's, without a data vendor's permission. The ETH exists. It is not currently recoverable. Those are different assertions, and an existence test that does not check credential type will not notice the difference.

What an accountant actually needs to remember

Ethereum for accountants reduces, in the end, to a short list. For ordinary ETH held at an execution-layer address, the minimum operational model is compact:

1. The address has one integer balance in wei.
2. The wallet is a key-management tool, not a container of coins.
3. A transaction can change the balance through both its value and its fee.
4. Contract execution can move ETH in ways that a simple transaction list does not show.
5. A receipt tells you whether an included transaction succeeded and how much gas it used.
6. A nonce prevents two transactions from the same account from both executing at the same sequence number.
7. Finalized chain state is stronger period-end evidence than whatever a block explorer happens to show at the current head.
8. Native staking moves the holder into a second record system, with validator balances in gwei and different identifiers and evidence.

Everything more specialized belongs elsewhere. The treatment of gas is developed in Ethereum Gas Fee Accounting. The evidence problem is developed in Why the Ethereum Blockchain Is Not an Accounting Ledger. Reward recognition belongs in Ethereum Staking Rewards. The event-by-event procedure is in How to Account for Ethereum Transactions.

The key discipline in Ethereum for accountants is to keep protocol quantity, economic meaning, and accounting measurement separate. Ethereum supplies the first. The accountant must establish the other two from the entity's facts and the applicable reporting framework.

How Tokenbooks helps with the Ethereum mechanics that reach the ledger

Tokenbooks syncs Ethereum mainnet at the level that list describes. Every transfer is ingested, native ETH and ERC-20, ERC-721 and ERC-1155 alike, and each non-fungible token is kept as its own asset rather than collapsed into a fungible balance. Contract-internal ETH transfers are captured as well, so value that moves inside a contract call rather than as a top-level transaction still reaches the books instead of appearing later as an unexplained balance difference.

Each transaction is then assigned an explicit operation type from an enumerated taxonomy, so whether an event was a purchase, a disposal, an internal move, a fee or a protocol interaction becomes a recorded field rather than something a reviewer infers from the direction a transfer happened to travel. The interpretation is stored beside its evidence, with the source transaction, its individual transfers, the event logs and the decoded contract call kept in a raw transactions view, so a posting can be traced back to what the chain actually said.

The mechanics the sync covers are set out on the Ethereum integration page.

More in this series

Accounting Token Anatomy: Native ETH. This article stands alone, but the series builds in order.

Next (01.2.2): What Do You Actually Own When You Hold ETH?

Sources and authority map

• Ethereum Yellow Paper. ethereum.github.io/yellowpaper
• ethereum.org, "Ethereum wallets". wallets
• ethereum.org, "Accounts". ethereum.org
• ethereum.org, "Technical intro to ether". ethereum.org
• Ethereum consensus specifications. github.com/ethereum/consensus-specs
• ethereum.org, "Nodes and clients". ethereum.org
• ethereum.org, proof-of-stake pages. proof of stake
• ethereum.org, staking pages. staking
• Ethereum Foundation, history and upgrade announcements. ethereum-forks

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.