If a screen says ETH, is the position native ETH?

Not necessarily. The label is evidence only of what a system calls the position, and it is not a recognition conclusion. A wrapped token, a bridged balance, a liquid staking token or an exchange credit can track ETH economically without being the same asset, so the position has to be identified from control, claims, restrictions and instrument identity rather than from the ticker.

Does holding the private key prove the entity owns the ETH?

No. Private-key control is powerful evidence, but it is not a complete legal ownership test. An employee, a custodian, an insolvency estate or a thief can control a key, and Ethereum contains no employment agreements, trust terms, custody contracts, board mandates or insolvency law. Those off-chain records can be load-bearing evidence even when the on-chain balance is undisputed.

Is ETH on Arbitrum, Optimism or Base the same asset as mainnet ETH?

No. Bridging does not move ether. The ETH is locked in a contract on Ethereum mainnet and a corresponding balance is credited on the other chain, and Optimism's documentation states that different bridged representations of the same native token are considered entirely independent tokens. Bridging out is therefore a derecognition question, and an ETH ledger reconciles to one chain.

Which address decides where a validator's balance is paid?

The withdrawal credential address, which is set once, permanently. If it names somebody else's address, the ETH is theirs on withdrawal and there is no protocol remedy. The fee recipient is only suggested to the node rather than enforced, and the validator's signing key can attest, propose blocks and broadcast a voluntary exit but cannot change where the balance is paid.

What Do You Own When You Hold ETH? Native ETH Ownership

Q: Does depositing 32 ETH into a validator dispose of the ETH?

Not by itself. Making the protocol deposit does not automatically introduce an issuer or a borrower, and a protocol restriction does not, by itself, prove derecognition. In the holder-operated fact pattern used throughout this series, the reporting analysis starts by considering continued recognition together with the nature of the restriction, and the applicable accounting framework still determines presentation and disclosure.

An account screen can display the word ETH while the holder's legal and economic position is completely different from native ETH in self-custody. So native ETH ownership is not settled by the ticker, and the correct starting question is not "How much ETH does the screen show?" It is:

What does the holder control, what claim exists against another party, what restricts transfer, and is the position still native ETH?

Those four questions are the structure of this article. They matter because native ETH has no issuer and no redemption promise, while an exchange balance, a lending position, a wrapped token, a bridged balance, or a liquid staking token can introduce contractual rights, smart-contract dependencies, counterparties, or different assets.

For accounting, the label is evidence only of what a system calls the position. It is not a recognition conclusion.

The four-question test

For every position labelled ETH, answer all four:

Question	Why it matters
1. What does the holder control?	A private key, a multisig policy, withdrawal credentials, a custodial account, a contractual right, or something else?
2. What claim exists, and against whom?	Native ETH normally has no issuer or debtor. A custodian or borrower may create a contractual claim.
3. What restricts transfer?	A protocol queue, smart-contract rule, pledge, legal agreement, custody term, or loss of a key are not the same restriction.
4. Is this still native ETH?	WETH, bridged ETH, liquid staking tokens, and exchange credits may track ETH economically without being the same asset.

The analysis below assumes Ethereum mainnet mechanics reviewed through 31 August 2026.

What position does the holder actually have?

A ticker is not an ownership conclusion.

ControlWho can move it?
ClaimAgainst whom, if anyone?
RestrictionProtocol or contract?
Instrument identityStill native ETH?

Ask all four questions every time a screen says ETH.

Native ETH ownership starts with control, not a claim

Native ETH is an asset.

A holder with effective control can authorise transfers from an address and exclude everyone else from doing so. That ability has economic value. ETH is not a share in Ethereum, a deposit, or a contractual right to dollars, goods or services. There is no issuer, no promise, and no identified counterparty that owes redemption. If the price falls there is nobody to make the holder whole. If the protocol continues there is nobody whose insolvency cancels native ETH.

The chain cannot identify the legal owner. A key may be held by the entity, by an employee, by several directors under a multi-signature arrangement, by a custodian, by an insolvency estate or by a thief. Since the Pectra upgrade an address may also have delegated its execution to a contract, so the party that can move the ETH today is not necessarily the party that could when the address was created. Financial-statement recognition follows enforceable rights and control under the applicable framework, not the label on an explorer page.

Legal ownership and cryptographic control are not synonyms

Private-key control is powerful evidence of native ETH ownership, but it is not a complete legal ownership test.

An employee can possess a key for an entity-owned wallet without personally owning the ETH. A custodian can possess the operative keys while the customer retains beneficial rights under the custody agreement. A thief can control a stolen key without that fact alone resolving title. A multisig can require several people to cooperate even though the asset belongs to one legal entity.

For an accounting file, keep at least three questions separate:

Who can technically authorise movement right now?
For whose benefit is that authority exercised under the legal arrangement?
What right would be enforceable if the parties disagreed or an intermediary became insolvent?

Ethereum answers the first question only indirectly through signatures, account code and protocol state. It does not contain employment agreements, trust terms, custody contracts, board mandates or insolvency law. Those off-chain records can therefore be load-bearing evidence even when the on-chain balance is undisputed.

This distinction also prevents a common error with collateral. If ETH is pledged but the pledgor retains the asset subject to enforceable restrictions, the restriction is not automatically a transfer of ownership. If the arrangement instead transfers title or permits the counterparty to reuse the ETH while owing equivalent ETH back, the economic position can be materially different. The contract, not the ticker, decides which case exists.

Position 1: self-custodied native ETH

When the holder controls the only usable keys, the honest answer is that it owns no claim against anyone. It controls a scarce protocol-native resource. The absence of a counterparty removes credit and redemption risk. It also removes recourse. There is no chargeback, no reversal, no ombudsman and no issuer to sue.

Position 2: native ETH in the holder's own validator

A holder that deposits 32 ETH into the deposit contract and runs its own validator has not, merely by making the protocol deposit, introduced an issuer or borrower. No other party automatically gains a contractual right to sell, lend, pledge or redirect that ETH. Withdrawal authority depends on the validator's credential type: legacy 0x00 credentials commit to a withdrawal key and must be upgraded before execution-layer withdrawals are possible, while 0x01 and 0x02 credentials identify an execution-layer withdrawal address. The position is therefore still native ETH represented in consensus-layer state rather than a newly issued instrument. Four attributes of it change, and each has to be recorded somewhere:

It cannot be transferred. Consensus-layer balances "cannot transact freely with other Ethereum accounts". Getting the principal back requires exiting or requesting a withdrawal and then waiting, though under 0x01 credentials the balance above 32 ETH is swept out automatically, with no request and no transaction.
It is exposed to a new loss mechanism. Slashing and the inactivity leak reduce the balance. This is not credit risk, because there is no debtor, and it is not market risk. It is operational risk crystallising as a reduction in the quantity of the asset itself.
The quantity changes without any action by the holder. Every epoch.
The exit is queued and the queue is not a term of anything. Nobody promised a withdrawal date and nobody can be held to one.

A protocol restriction does not, by itself, prove derecognition. In the holder-operated fact pattern used throughout this series, the reporting analysis therefore starts by considering continued recognition together with the nature of the restriction, rather than assuming that entering a validator created a disposal. The applicable accounting framework still determines presentation and disclosure. Slashing requires a separate policy analysis because it reduces the ETH quantity itself. Ethereum Accounting Under US GAAP develops the first. On the second, What Accounting Standards Still Do Not Answer About Ethereum records that no framework in the reviewed set addresses how a slashing loss is measured or where it goes.

Funding, withdrawal, and fee-recipient control

A holder staking natively has to be able to answer, for each of three addresses, "is this ours, and how do we know?"

Address	What it does	What goes wrong
The funding address	Sends the deposit and pays gas	Ordinary control question
The withdrawal credential address	The only address the validator's balance can ever be paid to	Set once, permanently. If it names somebody else's address, the ETH is theirs on withdrawal, and there is no protocol remedy
The fee recipient address	Receives execution-layer rewards from proposed blocks	Suggested to the node, not enforced. The consensus layer keeps no record of what the holder intended, so a misdirected block reward leaves no evidence of the mistake

The withdrawal address and the fee recipient are different addresses, and none of the three can be verified as the entity's from chain data alone.

A fourth control point is not an address at all. The validator's signing key attests, proposes blocks and can broadcast a voluntary exit, but it cannot change where the balance is paid. The withdrawal credentials decide that, and since Pectra they can trigger an exit or a withdrawal from the execution layer themselves. An operator can therefore hold the signing key while the entity keeps withdrawal control, which is what makes delegated operation possible without handing over the asset. Signing-key custody and withdrawal control are separate questions and need separate evidence.

Position 3: ETH held through a custodian or exchange

Sending ETH to an exchange or custodian creates a balance controlled by that intermediary and a credit on its private ledger. Whether the customer still recognises ETH depends on the contract and the applicable law: are specific units segregated, can the intermediary use them, who bears gains and losses, and what would the customer recover in an insolvency? Some arrangements preserve beneficial ownership. Others replace ETH with an unsecured contractual claim. The exchange screen calls both "ETH".

The same question, asked about staking, produces the sharpest distinction in this article. Staking through a pool or a liquid-staking protocol usually means the withdrawal credentials point at the protocol's contracts rather than at the holder. At that point the holder no longer has beacon-chain ETH. It has a claim, and a different article's worth of analysis applies.

Boundary position: ETH on another network

A holder who uses Arbitrum, Optimism or Base will see a balance labelled "ETH" there and will pay gas in it. It is not the asset this article covers, and the difference is an accounting difference rather than a technical curiosity.

Bridging does not move ether. The ETH is locked in a contract on Ethereum mainnet and a corresponding balance is credited on the other chain. Optimism's documentation describes the mechanism as "lock-and-mint", where "native tokens are locked into the Standard Bridge on one side, after which bridged tokens are minted on the other side", and states the consequence plainly: "Different bridged representations of the same native token are considered entirely independent tokens." (Optimism Docs, Standard Bridge) Arbitrum describes the same thing: deposited "funds are held in the Arbitrum Bridge contract on the parent chain" while the bridge "credits the deposited amount to your address on the child chain".

Three consequences follow, and each is a decision an accountant has to make rather than a fact to note:

Bridging out is a derecognition question. The entity no longer controls ETH on mainnet. It holds a balance on another chain whose backing is a contract. Whether that is a disposal, and what is recognised in its place, is the first question, and it has a gain or loss attached.
The replacement may not be measured the same way. The IFRS Interpretations Committee's agenda decision covers assets that give rise to no contract with another party, and ASC 350-60 excludes anything that provides "enforceable rights to or claims on underlying goods, services, or other assets" (FASB ASU 2023-08). A bridged balance backed by an escrow contract has a real prospect of failing both, and the measurement consequence is not the same on each side. Which answer follows is decided in Ethereum Accounting Under US GAAP, not here.
The reconciliation breaks silently. Portfolio software aggregates mainnet ETH and every layer-2 "ETH" into a single figure. That figure will never agree to the mainnet account balance, and gas paid on a layer 2 is paid in the other asset.

The rule for this article is simple: an ETH ledger reconciles to one chain. Each network the entity uses needs its own quantity ledger, its own price convention and its own recognition conclusion. The treatment of bridged ETH itself is a separate token type and a separate article.

Position 4: lending, borrowing, and collateral

If a lender transfers ETH and the borrower may sell or reuse it while owing only equivalent ETH later, the lender may no longer hold ETH. It may hold a receivable exposed to that borrower. The borrower may recognise both ETH as an asset and an obligation to return ETH, a liability, even though a portfolio application shows the borrowed units as a positive balance. Principal, interest and collateral must not be netted merely because they are denominated in the same unit.

Failure analysis. A lost key is an access problem. A slashing event is a protocol-penalty problem that reduces the asset itself. A custodian failure is a legal-rights and credit problem. A borrower default is a receivable problem. A mistyped fee-recipient address is a pure loss with no counterparty to pursue. All five can leave a screen showing a number that looks similar, and none of them is the same event.

Position 5: deposited but not yet activated

A native staking deposit is an unusual intermediate state. The execution-layer deposit transaction has already occurred, but the validator has not necessarily become active.

The ETH has not "disappeared". The accounting file should instead document:

the deposit transaction and amount;
the validator public key and eventual validator index;
the withdrawal credentials;
the entity's control of the withdrawal address or key;
the consensus-layer state showing that the deposit is pending;
the activation date when the validator actually becomes active.

The important distinction is between location and restriction on one side and ownership or derecognition on the other. A queue can restrict use without creating a new counterparty or a new instrument. Whether financial reporting requires a reclassification or disclosure is a framework question.

Position 6: exited but not yet withdrawn

A validator can stop participating before the balance reaches the execution-layer withdrawal address. That state also should not be treated as though the ETH ceased to exist.

The position remains represented in consensus-layer state. What has changed is the validator's lifecycle status and the path to liquidity. The close file should distinguish:

the exit request or protocol-triggered exit;
the validator's exit epoch;
the point at which the balance becomes withdrawable; and
the later system-level withdrawal that credits the execution-layer address.

A withdrawal is not a new acquisition merely because ETH becomes visible in a wallet again. If rewards were recognised earlier, booking the later sweep or full withdrawal as fresh income would double count them.

Position 7: multisig and smart-contract wallets

Control can be distributed rather than held by one key. A multisignature wallet may require several approvals. A smart-contract wallet may enforce spending limits, recovery rules, modules, or role-based permissions.

The accounting question is still the same: who can cause the ETH to move under the arrangement that exists at the reporting date? A contract address holding ETH is not evidence by itself that the entity controls the asset. The entity needs the contract terms, signer or role configuration, and evidence that the relevant permissions are its own.

Position 8: an EIP-7702 delegated account

Since Pectra, an externally owned account can set code through EIP-7702. The underlying private key still authorises the delegation, but execution behaviour can be routed through delegated code.

That creates two control questions instead of one:

who controls the private key that can authorise or revoke the delegation; and
what can the delegated code currently do?

A delegation can persist across transactions. A reporting-date control procedure therefore should not assume that an address that behaved like a plain EOA when it was onboarded still behaves that way now.

Position 9: sponsored transactions

EIP-7702 also enables sponsorship patterns in which one account can pay transaction costs for another account's activity. That breaks a common bookkeeping shortcut: the account initiating the economic action and the account bearing the gas cost need not be the same.

A sponsored transaction does not automatically change who owns the underlying ETH position. It does change which party incurred the network outflow and may create a separate reimbursement, service, or related-party question outside the chain.

Position 10: pledged ETH

Pledging does not necessarily transfer ownership. A holder may retain legal or beneficial ownership while its ability to transfer the ETH is restricted by contract or by a control arrangement.

The file therefore needs both pieces of evidence:

protocol control: who can actually authorise movement; and
legal restriction: what the pledge agreement permits or prohibits.

Do not infer the second from the first.

Decision table

Position	What the holder primarily has	Main restriction or dependency	Still native ETH?
Self-custodied mainnet ETH	Direct protocol control	Key-management risk	Yes
ETH in holder-operated validator	Consensus-layer ETH position controlled through withdrawal credentials	Protocol queues, withdrawal mechanics, slashing risk	Yes
Pending validator deposit	Consensus-layer staking position awaiting activation	Activation queue	Yes, assuming the holder retains relevant control
Exited but not yet withdrawn	Consensus-layer balance awaiting withdrawability/sweep	Protocol timing	Yes
Multisig or smart-contract wallet	Native ETH at an account whose spending rules are code	Signer or role configuration and the contract's terms	Yes, though control has to be evidenced from that configuration
EIP-7702 delegated account	Native ETH at an externally owned account that can execute delegated code	Delegation and revocation authority, and what the delegated code permits	Yes
Custodial "ETH" balance	Depends on contract and legal arrangement	Custodian solvency, contract, withdrawal terms	Maybe
ETH lent to another party	Often a contractual return claim, depending on terms	Borrower/counterparty risk	Potentially no longer the same recognised asset
ETH pledged as collateral	Often retained asset subject to restriction, facts dependent	Contractual restriction/liquidation rights	Usually yes until control or rights change
WETH	ERC-20 token redeemable through a smart contract	Wrapper contract	No
Bridged "ETH"	Representation on another network	Bridge and target-chain mechanics	No
Liquid staking token	Token or claim representing a staking arrangement	Protocol/provider/contract terms	No

The "maybe" rows are deliberate. Native ETH ownership and recognition cannot be decided from a ticker alone.

What this article does not decide

This article identifies the position. It does not decide whether IAS 38, IAS 2, IFRS 9, ASC 350-60, another US GAAP topic, or a tax rule applies. Those questions require the reporting framework and transaction facts, and they start from the native ETH ownership conclusion reached here.

For the reporting analysis, see Ethereum Accounting Under US GAAP. For the evidence needed to support the position, see Why the Ethereum Blockchain Is Not an Accounting Ledger. Our crypto accounting guide covers the wider close workflow those records sit in.

How Tokenbooks helps with knowing what the entity actually holds

Tokenbooks records the position rather than the ticker. Wallets on more than 50 blockchains and accounts at more than 80 exchange venues can be connected to one portfolio, so a custodial balance, a self-custodied mainnet address and a wrapped or bridged representation sit in one record instead of three spreadsheets. A transfer between two wallets in the same portfolio is recognised as a non-taxable move that carries lot identity across, bridges included. Behind each holding sits the material a control conclusion has to be built from, the source transaction with its individual transfers, its event logs and its decoded contract call, kept alongside the accounting interpretation instead of discarded once it has been read.

Coverage is listed on the Ethereum integration page.

Sources and authority map

ethereum.org, "Ethereum wallets". wallets
ethereum.org, "Accounts". ethereum.org
EIP-7702, "Set Code for EOAs". eips.ethereum.org
Ethereum consensus specifications. github.com/ethereum/consensus-specs
ethereum.org, staking pages. staking
ethereum.org, staking withdrawals and the issuance page. withdrawals
EIP-2982, "Serenity Phase 0". eips.ethereum.org
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.