What Does the Holder of an ERC-20 Token Actually Own?

A wallet can show 1,000 LINK. So what does the holder of an ERC-20 token own? A balance is one contract's record against one address, and the accounting answer turns on what resource the entity controls, what rights attach to it, and whether another party is obliged to deliver anything.

What does the holder of an ERC-20 token own, if the wallet balance is not the answer?

A wallet can show "1,000 LINK". That statement reports a quantity attributed to an address by one contract, 0x514910771AF9Ca656af840dff83E8264EcF986CA on Ethereum mainnet. It does not, by itself, establish what the reporting entity owns in legal or accounting terms.

The accounting question is broader:

What resource does the entity control, what rights attach to that resource, and is there another party obligated to deliver cash, goods, services, or another asset?

That question separates a plain fungible token from many instruments that look identical in a portfolio application.

Start with the technical position

For a self-custodied plain token, the on-chain position is straightforward.

A token contract records a balance against an address. Whoever can validly exercise the relevant private key can normally originate transactions from that address, a private key being the secret number that produces the signature the network requires before it will execute a transaction from an address. The token contract then applies its code to determine whether and how balances change.

That gives the key holder practical power to initiate transfers, but it does not automatically prove legal ownership by a reporting entity. An employee, custodian, insolvency estate, trustee, attacker, or other person may control a key while legal and beneficial rights sit elsewhere.

The chain proves control of credentials and state. Legal ownership and accounting control require additional evidence.

A token is not automatically a receivable

What does the holder of an ERC-20 token own when no issuer has promised anything? For a plain fungible token, the most important negative fact is often the absence of a counterparty obligation.

A token may have been deployed by a foundation, company, protocol team, or individual. The existence of a deployer does not automatically mean the deployer owes the holder cash or redemption value.

To determine whether the token is a claim, inspect:

• the contract code
• the issuer's or project's governing documentation
• token sale or issuance terms
• redemption terms, if any
• custody or platform terms
• side agreements
• applicable law

For the reference token, the first of those is not a matter of opinion. The complete function surface of the LINK contract was extracted from its deployed bytecode at block 25,942,576 on 9 September 2026 and comes to thirteen entry points: name, symbol, decimals, totalSupply, balanceOf, allowance, approve, increaseApproval, decreaseApproval, transfer, transferFrom, transferAndCall, and a callback the contract invokes on a receiving contract rather than exposing to a caller. There is no redeem, no claim, no withdraw, no burn, no mint, no owner, no pause, no blacklist, and no setFee. Simulated calls to owner(), paused(), claim(), and withdraw() each revert.

That is a verified negative about one contract at one block, not a general truth about tokens. It is the form the evidence should take: a statement of what was read, where, and when.

Utility is not the same as a contractual claim

A token can be useful without being a receivable.

It may be accepted within a protocol, used to pay for services, posted as collateral, delegated, voted, traded, or used as part of an incentive mechanism. None of those facts automatically creates a contractual right against an issuer.

Accountants should therefore separate two questions:

1. Can the token be used for something?
2. Does the holder have an enforceable right against another party?

The first is an economic-use question. The second is a legal-rights and classification question.

Under IFRS the second question has a specific home. IAS 32 paragraph 11 defines a financial asset by reference to cash, an equity instrument of another entity, a contractual right to receive cash or another financial asset, and certain contracts settled in the entity's own equity instruments. The word doing the work is contractual, and IAS 32 paragraph 13 defines it as "an agreement between two or more parties that has clear economic consequences that the parties have little, if any, discretion to avoid, usually because the agreement is enforceable by law". IAS 32 paragraph AG4 states the symmetry: "one party's contractual right to receive (or obligation to pay) cash is matched by the other party's corresponding obligation to pay (or right to receive)." Where no party carries the matching obligation, there is no financial asset to find.

Two further paragraphs close the remaining doors. IAS 32 paragraph AG11 states that assets "for which the future economic benefit is the receipt of goods or services, rather than the right to receive cash or another financial asset, are not financial assets", so a token accepted in payment for a service is not a financial asset on that account. And IAS 32 paragraph AG10 observes that control of an intangible asset "creates an opportunity to generate an inflow of cash or another financial asset, but it does not give rise to a present right to receive cash or another financial asset".

The first limb of the definition fails for the same reason. IAS 32 paragraph AG3 explains that currency is a financial asset "because it represents the medium of exchange and is therefore the basis on which all transactions are measured and recognised in financial statements". No entity keeps its books in a plain fungible token and no goods are priced in it, so the token is not cash either.

Confusing use with entitlement can therefore move an asset into the wrong accounting standard.

Four economically different things can carry the same ticker

One ticker can sit on four different arrangements, so what does the holder of an ERC-20 token own in each of them? A portfolio system may use the same symbol for positions that are legally and economically different.

1. Self-custodied token

The entity controls an address and the token contract reports a balance to that address.

This is the cleanest case for analysing the token itself.

Evidence should include:

• address ownership or control evidence
• chain ID
• contract address
• block-pinned balanceOf result
• transaction history and reconciliation
• legal and contractual review of the token

2. Token balance on an exchange or custodian

The customer may see "1,000 LINK" on a platform, but the platform can be recording an internal liability or entitlement rather than assigning a dedicated on-chain balance to the customer.

The test is direct. Ask for the on-chain address and call balanceOf on it. Where the entity cannot produce an address it controls, the chain cannot confirm that the entity holds the token at all.

Whether the entity then holds the token or a right to receive it from the custodian turns on control under the custody terms and the applicable law. The AICPA's digital assets practice aid treats this as a facts-and-circumstances assessment at its Q&A 10, and that document says on its own face that it provides nonauthoritative guidance, so it is an interpretation and never a rule.

The consequence of getting it wrong is set out by the custodians themselves. Coinbase Global, Inc. states in its Form 10-K for the year ended 31 December 2025 that "because custodially held crypto assets may be considered to be the property of a bankruptcy estate, in the event of a bankruptcy, the crypto assets we hold in custody on behalf of our customers could be subject to bankruptcy proceedings and such customers could be treated as our general unsecured creditors".

For evidence, an accountant should obtain and review:

• custody terms
• segregation terms
• legal title provisions
• rehypothecation rights
• insolvency treatment
• on-chain addresses where relevant
• custodian confirmations

A screen balance alone is not enough.

3. A derivative referencing the token

A futures contract, perpetual contract, CFD, option, or other derivative can reference LINK without the holder owning LINK.

The economic exposure can be similar while the asset is completely different.

If settlement occurs in cash and no token is delivered, the reporting entity owns a derivative position, not the token itself.

4. A fund or ETP that holds the token

An investor may own shares, units, notes, or another security issued by a fund or exchange-traded product whose assets include LINK.

The investor owns the security. The fund or issuer owns or controls the underlying token through its custody arrangement.

The existence of token exposure does not collapse those two legal layers into one.

Chain identity matters as much as contract identity

A symbol can also appear on multiple networks. A token named LINK on Ethereum and a token named LINK on another network are not identified merely by their shared ticker. The opening article in this series prints the four LINK contracts, on four networks, that all return the name ChainLink Token, the symbol LINK, and 18 decimals while reporting four different total supplies, one of them under an administrator the other three do not have.

For accounting purposes, the minimum asset identifier should therefore be:

(chain ID, contract address)

A contract address without a chain is incomplete because the same hexadecimal address can exist on multiple networks.

Allowances create a special form of exposure

Owning a token does not mean only the holder can reduce the balance.

Under EIP-20, a holder can grant another address an allowance. The approved spender can later call transferFrom and move the holder's tokens. The standard's own security note records that an allowance lets the spender withdraw from the holder's account multiple times up to the approved value, and that a second call overwrites the first rather than adding to it.

This authority is economically significant because:

• the holder may not sign the later disposal
• the spender may pay the gas
• the holder's ETH balance can remain unchanged
• the token balance can fall while no outbound transaction appears in the holder's transaction-origin history

The standard treats the resulting exposure as a live hazard rather than a formality. EIP-20 carries a note advising that user interfaces should set an allowance to zero before setting it to another value for the same spender, to prevent a known attack, while declining to make the contract enforce it.

An allowance does not necessarily mean the holder has lost ownership. It does mean another party holds a technical power to move the asset, and that power is standing, revocable only by a further transaction, and typically granted without an expiry date.

This article's view is that the standing allowance is the single most under-recorded exposure in this asset class. It moves no balance, so it produces no journal entry. It is granted once, so it does not recur in a transaction listing. It appears in no financial statement line, in no confirmation, and in no reconciliation that keys on quantity. A period-end control should therefore identify material allowances, the approved spender, the authorised amount, the business purpose, and whether the authority remains necessary. The article on why a token balance is not an accounting record sets out why that register has to be built forward from each grant and read live at the reporting block rather than reconstructed from an event history.

Permit signatures widen the evidence gap

The gap was left open by the standard itself. EIP-20 conditions transferFrom only on the _from account having "deliberately authorized the sender of the message via some mechanism", and says nothing about that mechanism being on chain.

Some ERC-20 tokens implement EIP-2612 or related permit functionality. A holder can sign an off-chain message authorising an allowance, and another party can submit the signature later. Between signature and on-chain submission, the blockchain shows no record of that authorisation at all.

Whether a given token exposes that path is testable in two calls, and the answer differs between tokens an entity is likely to hold at the same time. Called on 9 September 2026, DOMAIN_SEPARATOR() and nonces(address) both return values on USDC and both revert on LINK, USDT, and BAT. Where permit exists, a standing authorisation can exist with no transaction, no gas, and no on-chain record until somebody uses it. Where it does not, every allowance had to be granted by a transaction and every allowance is therefore discoverable.

Two features of EIP-2612 bound the exposure where it does exist, and both belong in the workpaper. Every permit carries a deadline, and the specification accepts the signature only where "the current blocktime is less than or equal to deadline", so a signature expires. Every permit also carries a sequential nonce, and the specification accepts the signature only where "nonces[owner] (before the state update) is equal to nonce", incrementing the stored nonce by one on use, so any later permit the holder signs for that token invalidates an older unused one.

An outstanding permit signature is therefore a dated, single-use authority rather than an open-ended one. At the reporting date the two questions are which signatures the entity has issued that have not expired, and what nonces(holder) the token contract returns at the reporting block.

Not every enforceable or usable authority over a token is visible on chain at the reporting date, but its outer limit usually is. The practical lesson is broader than one EIP. Public-chain evidence can be complete as to public-chain state and still incomplete as to off-chain commitments, signatures, contracts, or custody arrangements.

Tokens the holder cannot refuse

An address can receive an ERC-20 token without the recipient signing anything, and there is no mechanism by which it could refuse.

That is a verified negative rather than an observation about practice. Searched on 16 September 2026, the complete canonical text of EIP-20 contains no occurrence of "receive", "hook", "callback", "notify", "accept", or "reject". A transfer writes the two balance entries and emits an event. The recipient's code never runs. A contract cannot detect an incoming ERC-20 transfer at the moment it happens, cannot refuse it, and cannot react to it. Native ether behaves differently, because an ordinary payment to a contract invokes that contract's own code, which can reject the payment.

The consequence for accounting is that the entity's on-chain position can change without its consent or even its awareness. Airdropped, spam, counterfeit, or zero-value tokens may appear in address history, and none of them was accepted by anybody.

The chain can establish that a contract now reports a positive quantity. It cannot decide whether the token meets the accounting definition of an asset, whether it has measurable fair value, whether income should be recognised, or whether the position is economically meaningless.

Those are accounting-policy questions that depend on the framework and facts, and the entity still has to record that the token arrived, because both completeness and any later disposal depend on it.

What happens if the token's original deployer disappears

For a truly plain, immutable token, the disappearance of the original deployer may not cause the token balance to vanish. The contract can continue to execute according to its deployed code as long as the network runs and users continue to interact with it.

That does not mean the token retains economic value. Market value may collapse if the surrounding ecosystem, development effort, exchange support, or economic use disappears.

The accounting distinction is:

• technical persistence: the contract and balances may still exist
• economic viability: the market or use case may disappear
• legal claim: there may be no issuer obligation to rescue or redeem the holder

These are separate facts, and what the deployer does not owe can matter as much as what it does. For a plain token, a preparer should be able to state positively what evidence was reviewed and negatively what was not found, for example:

• no redemption function identified in the contract, with the block and date of the read recorded
• no contractual promise to redeem for cash or another asset identified in governing documents reviewed
• no claim on specified underlying assets identified
• no issuer obligation inferred merely from the existence of a deployer

Negative conclusions should be scoped carefully. "No redemption right identified in the documents reviewed" is defensible. "No redemption right exists anywhere" is a much broader claim and requires broader legal work.

Lending can convert the token into a different asset

Suppose an entity transfers tokens to a borrower who can sell or reuse them, while the borrower has only an obligation to return equivalent units later.

The lender may no longer control the original token. It may instead hold a receivable from the borrower.

The borrower may have an asset consisting of the tokens received, and a liability to return equivalent tokens.

A wallet application that shows a positive token balance cannot establish whether that balance is owned free and clear, borrowed, pledged, or owed back.

The token contract itself cannot record a negative balance. Liabilities denominated in tokens live in separate legal or smart-contract arrangements.

Control of the key and ownership of the asset are related but not identical

Private-key control is strong evidence of practical ability to transact. It is not a universal legal-title rule.

Consider three cases:

• A company director personally holds the key to a corporate treasury address. The director can sign, but the company may own the assets.
• A qualified custodian holds keys for segregated client assets. The custodian can operate the keys under the agreement, but the customer may retain beneficial rights.
• A thief obtains a seed phrase. The thief can sign valid transactions, but whether that technical control carries legal title is a question for the applicable law of property and not one the chain answers. In most systems the analysis starts from the position that a thief acquires no title, and the preparer should obtain a legal view rather than infer ownership from key control. That is this article's own analysis, not a rule stated by any accounting standard.

For accounting, the chain should be paired with governance and legal evidence such as board approvals, custody contracts, key-control matrices, and signed ownership confirmations.

Collateral can preserve ownership while restricting use

A token can remain the entity's asset while being pledged as collateral, depending on the arrangement. The accounting analysis must inspect whether control transferred, whether the counterparty can rehypothecate or dispose of the token, and whether derecognition criteria are met under the applicable framework.

A block explorer cannot answer those questions. It may show the token sitting in a smart contract or another address while the economic and legal rights are defined by the collateral agreement.

The subledger should therefore distinguish at least:

available
pledged
lent
borrowed
custodied
locked

Those labels are accounting metadata, not facts supplied by ERC-20.

A practical ownership evidence hierarchy

For a plain token, a strong file normally combines the following layers.

Layer 1, token identity: chain ID, contract address, token decimals, code and proxy status.

Layer 2, on-chain quantity: block-pinned balanceOf, transaction receipts, relevant logs, ETH fee records.

Layer 3, key or custody control: signed challenge from self-custodied addresses, key-management records, custody confirmations, authorised-user lists.

Layer 4, legal rights: custody agreements, token terms, sale agreements, lending or collateral agreements, side letters or other enforceable arrangements.

Layer 5, accounting conclusion: what asset or liability is recognised, which accounting standard applies, the measurement basis, presentation and disclosure, and tax treatment.

No single layer substitutes for the others.

Why this ownership analysis changes the accounting scope

Under IFRS, the existence or absence of a contractual right decides the IAS 32 paragraph 11 analysis above. The IFRS Interpretations Committee's June 2019 agenda decision on holdings of cryptocurrencies dealt with a defined subset of cryptoassets, described in its own second paragraph as having three stated characteristics, one of which is that the thing is "not issued by a jurisdictional authority or other party". A plain ERC-20 token exists because somebody deployed a contract whose constructor assigned the supply. This article's reading is that the decision does not reach such a token on its own terms, so the destination is very probably still IAS 38 or IAS 2 while the route is the scope paragraphs themselves rather than a borrowed conclusion. That reading is this article's own analysis and not a requirement of any standard.

The route runs through a residual. IAS 38 paragraph 2 applies that Standard to all intangible assets except those "within the scope of another Standard" and except "financial assets, as defined in IAS 32", among two other exclusions. Establishing that the token is not a financial asset under the paragraphs above is therefore what puts it inside IAS 38 in the first place, which is why the legal-rights work has to be done before the measurement work rather than after it. Where the token is instead held for sale in the ordinary course of business, IAS 2 is the Standard that applies, and that is a question about the entity's business model rather than about the token.

Under US GAAP, the point is more explicit. ASC 350-60-15-1(b), introduced by ASU 2023-08, requires an in-scope crypto asset not to provide the holder with enforceable rights to or claims on underlying goods, services, or other assets. A token that is redeemable for another asset can therefore fail the crypto-asset scope test even though it is fungible, cryptographically secured, and recorded on a blockchain. The article on ERC-20 token scope works that scope test through on the cluster's own worked-example facts.

The legal-rights file is therefore part of the accounting file.

The core distinction

The most useful question for an accountant is not "is there a balance?"

It is:

What does that balance evidence, and against whom, if anyone, does the entity have an enforceable right?

For a plain self-custodied ERC-20 token, the answer may be a directly controlled intangible resource with no redemption claim against another party. For a custodian balance, derivative, fund interest, wrapped asset, stablecoin, lending receipt, or security token, the answer may be completely different even when the wallet or dashboard uses the same familiar language of "tokens".

So what does the holder of an ERC-20 token own? It depends on which of those arrangements the entity is actually in, and the accounting file has to say which one and show the evidence for it.

How Tokenbooks helps with ERC-20 ownership and classification

Token mechanics are typed rather than assumed. Rebasing liquid staking tokens, value-accruing shares, interest-bearing receipts, debt tokens and liquidity-pool shares are distinct kinds, so a receipt that represents something else is held as what it is.

Every transaction is then assigned an explicit operation type from an enumerated taxonomy: buy, sell, swap, expense, income, move, stake, unstake, protocol deposit and withdraw, liquidity in and out, vault, lend, borrow, repay, liquidation and intercompany. A raw transactions view holds the decoded contract calls and event logs alongside that interpretation, so the classification and the evidence for it are read together.

Behind the position, an inspectable lot ledger records each movement of every lot, which is the layer an evidence file asks for when a balance has to be explained rather than asserted.

See how that works on the Ethereum integration page.

More in this series

Accounting Token Anatomy: ERC-20 Tokens. This article stands alone, but the series builds in order.

Previous (02.1.1): ERC-20 Tokens for Accountants: Chain, Contract, Balance

Next (02.1.3): Why a Token Balance Is Not an Accounting Record

Sources and further reading

• EIP-20, Token Standard. eips.ethereum.org
• EIP-20, canonical source text. raw.githubusercontent.com
• EIP-2612, Permit extension for EIP-20 signed approvals. eips.ethereum.org
• IAS 32, Financial Instruments: Presentation. ifrs.org
• IAS 38, Intangible Assets. ifrs.org
• IAS 2, Inventories. ifrs.org
• IFRS Interpretations Committee, Holdings of Cryptocurrencies, June 2019. ifrs.org
• FASB ASU 2023-08. storage.fasb.org
• AICPA, Accounting for and Auditing of Digital Assets practice aid. assets.ctfassets.net
• Coinbase Global, Inc., Form 10-K for the year ended 31 December 2025. sec.gov This article is educational material, not legal, tax, investment, or accounting advice for a specific entity. Rights and classification depend on the contract, custody structure, applicable law, and reporting framework.