Token Standards for Accountants

Token standards are standardized smart contract interfaces that define whether a digital asset is fungible, non-fungible, or semi-fungible — directly determining asset classification, valuation methodology, and journal entry structure in crypto accounting systems. Three dominant token standards — ERC-20, ERC-721, and ERC-1155 — account for over 99% of token transaction volume on EVM-compatible chains, with cross-chain equivalents (BEP-20 on BNB Chain, SPL on Solana) following identical classification logic. The token standard is the first classification decision a crypto subledger applies when ingesting a new digital asset.

What Are Token Standards and Why Do They Affect Accounting?

Token standards affect accounting because the standard applied to a digital asset determines 3 classification properties. As a core domain within crypto fundamentals for finance teams, token standards govern: fungibility (interchangeable or unique), tracking granularity (quantity-based or item-based), and valuation method (market price or individual fair value assessment).

How Does Fungibility Determine Asset Classification?

Fungibility determines asset classification by establishing whether each token unit is interchangeable or unique — a distinction that propagates through every downstream accounting decision.

Fungible tokens (ERC-20) are interchangeable units — 1 USDC equals any other 1 USDC, and 1 LINK equals any other 1 LINK. Fungible token accounting tracks aggregate balances with lot-level cost basis, where each acquisition creates a new lot with a distinct cost basis and acquisition date. The subledger applies cost basis methods (FIFO, LIFO, HIFO, specific identification) to determine which lots are disposed of during sales and swaps.

Non-fungible tokens (ERC-721) are unique items — each token carries a distinct tokenId that represents a singular asset. Non-fungible token accounting tracks individual asset records, where each tokenId has a unique cost basis, acquisition date, and metadata reference. No lot-based cost basis methods apply, because each token is inherently distinct.

Semi-fungible tokens (ERC-1155) present a hybrid classification — fungibility varies by token ID within the same contract. A single ERC-1155 contract may contain token IDs with a supply of 1 (non-fungible) alongside token IDs with a supply of 1,000,000 (fungible), requiring the subledger to classify each token ID independently.

How Do Token Standards Determine Valuation Methodology?

Token standards determine valuation methodology through the fungibility classification — fungible tokens support market-price-based valuation, while non-fungible tokens require individual fair value assessment.

Fungible token valuation (ERC-20): market price × quantity at the transaction timestamp. Exchange rates from centralized exchanges (Coinbase, Binance, Kraken) and decentralized exchanges (Uniswap, Curve) provide continuous pricing data. Cost basis methods (FIFO, LIFO, HIFO, specific identification) determine which lots are used when calculating realized gains and losses on disposals.

Non-fungible token valuation (ERC-721): individual fair value assessment per token. Comparable sales on marketplaces such as OpenSea provide reference prices, but many non-fungible tokens lack liquid secondary markets. Floor price analysis — the lowest listed price in a collection — provides a conservative baseline, while third-party appraisal provides formal valuation evidence for audit purposes.

Under FASB ASU 2023-08, both fungible and in-scope non-fungible crypto assets are measured at fair value with changes flowing through net income each reporting period. Non-fungible tokens outside the ASU 2023-08 scope (e.g., tokens representing real-world assets or providing access rights) follow IAS 38 (intangible assets) or other applicable standards depending on the jurisdiction and business model.

How Does the ERC-20 Standard Work?

The ERC-20 (Ethereum Request for Comments 20) standard defines a 6-function interface for fungible tokens — tokens where every unit is interchangeable and carries identical economic value. ERC-20 is the dominant token standard, accounting for approximately 90% of all token transaction volume on Ethereum and EVM-compatible chains as of March 2026.

What Are the Core ERC-20 Interface Functions?

The 6 ERC-20 interface functions and the corresponding accounting implications are listed in the table below.

Function	Event Emitted	Accounting Implication
transfer(to, amount)	Transfer	Asset movement — acquisition or disposal depending on direction
approve(spender, amount)	Approval	No accounting event — authorization to spend, no asset movement
transferFrom(from, to, amount)	Transfer	Asset movement — delegated transfer on behalf of the token owner
balanceOf(account)	(read-only)	Balance verification for reconciliation — no on-chain event
totalSupply()	(read-only)	Token supply verification — no on-chain event
allowance(owner, spender)	(read-only)	Allowance verification — no on-chain event

Read-only functions (balanceOf, totalSupply, allowance) produce no on-chain events and require no journal entries — these functions serve reconciliation and verification purposes exclusively. The transfer and transferFrom functions produce the Transfer events that the subledger decodes into acquisition or disposal transactions based on the direction of token movement relative to the organization’s tracked wallets.

What Is the Accounting Treatment for ERC-20 Token Transactions?

ERC-20 accounting treatment follows lot-based cost basis tracking — each acquisition creates a new lot with a distinct cost basis (price per unit × quantity) and acquisition date. Disposal transactions (sales, swaps) consume lots according to the selected cost basis method: FIFO (first in, first out), LIFO (last in, first out), HIFO (highest in, first out), or specific identification.

ERC-20 tokens on Ethereum include USDC, LINK, UNI, AAVE, MKR, and approximately 450,000 other deployed contracts as of March 2026. Each ERC-20 token follows identical accounting treatment regardless of the token’s purpose, market capitalization, or issuing organization.

The journal entry above records a swap of USDC for LINK on a decentralized exchange. The disposal of USDC (credit $10,005) and the acquisition of LINK (debit $10,005) occur in a single atomic on-chain transaction. The LINK acquisition creates a new cost basis lot: 667 units at $15.00/LINK, timestamped at the block confirmation time.

How Does the ERC-721 Standard Work?

The ERC-721 standard defines non-fungible tokens (NFTs) — digital assets where each token carries a unique tokenId that distinguishes the asset from every other token in the same contract. ERC-721 was formalized in January 2018 (EIP-721) and is the standard behind CryptoPunks, Bored Ape Yacht Club, Art Blocks, and the majority of digital collectible and digital art projects.

What Are the Core ERC-721 Interface Functions?

ERC-721 interface functions center on ownership tracking and transfer authorization rather than balance management:

1. ownerOf(tokenId) — returns the current owner address for a specific token ID. The primary function for ownership reconciliation.
2. safeTransferFrom(from, to, tokenId) — transfers ownership with a safety check ensuring the receiving address supports ERC-721 tokens.
3. transferFrom(from, to, tokenId) — transfers ownership without the safety check.
4. approve(to, tokenId) — authorizes a specific address to transfer a specific token ID.
5. setApprovalForAll(operator, approved) — authorizes an operator address to transfer all tokens owned by the caller.
6. tokenURI(tokenId) — returns the metadata URI containing the token name, image, attributes, and description, typically stored on IPFS or Arweave.

The tokenURI function provides the metadata link that associates a token ID with descriptive attributes — collection name, rarity traits, and visual representation. Metadata is stored off-chain (IPFS, Arweave, or centralized servers) and referenced by the on-chain token ID, creating a split data model that the subledger reconciles between on-chain ownership and off-chain descriptive data.

What Is the Accounting Treatment for ERC-721 Tokens?

ERC-721 accounting treatment tracks individual asset records per tokenId — each non-fungible token has a unique cost basis, acquisition date, and metadata reference. No lot-based cost basis methods apply because each token is inherently unique and non-interchangeable.

Valuation of ERC-721 tokens presents a distinct challenge: no continuous liquid market price exists for most non-fungible tokens. Comparable sales on marketplaces such as OpenSea, Blur, and LooksRare provide reference prices, but transaction frequency varies dramatically by collection and rarity tier. Floor price analysis — the lowest listed price in a collection — provides a conservative baseline that auditors reference for impairment testing.

The journal entry records the NFT acquisition at the fair market value of the ETH paid (2.0 ETH × $3,500 = $7,000). The asset account includes the specific token identifier (CryptoPunk #7804) because non-fungible token accounting tracks each item individually. The ETH disposal creates a separate gain/loss calculation based on the ETH cost basis lots consumed — if the 2.0 ETH had a cost basis of $6,000, a realized gain of $1,000 would be recognized on the ETH disposal leg.

How Does the ERC-1155 Standard Work?

The ERC-1155 standard combines fungible and non-fungible token functionality in a single smart contract — each token ID within the contract is classified independently based on total supply. ERC-1155 was proposed by Enjin in June 2018 (EIP-1155) and is the standard behind gaming assets, event ticketing systems, and loyalty programs where both fungible and non-fungible items coexist within a single contract.

What Are the Primary ERC-1155 Use Cases?

ERC-1155 use cases span 3 primary categories where mixed fungibility within a single contract provides operational efficiency.

1. Gaming platforms — Enjin-powered games use ERC-1155 for in-game economies: fungible gold coins (token ID 1, supply 10,000,000) coexist with unique legendary weapons (token ID 42, supply 1) in the same contract. The subledger classifies each token ID independently.
2. Event ticketing — Fungible general admission tickets (token ID 100, supply 5,000) alongside non-fungible VIP seat assignments (token ID 201, supply 1) in a single contract. Each ticket type follows different accounting treatment based on the supply count.
3. Loyalty programs — Fungible reward points (token ID 1, supply unlimited) alongside non-fungible membership tier badges (token ID 10, supply 1 per member). The reward points follow lot-based tracking; the tier badges follow individual asset records.

How Is ERC-1155 Accounting Complexity Resolved?

ERC-1155 accounting complexity is resolved through a per-token-ID classification workflow — the subledger evaluates each token ID independently and applies the accounting treatment matching the fungibility classification.

The ERC-1155 classification decision matrix determines the accounting treatment per token ID based on 3 attributes, as listed in the table below.

Token ID Example	Total Supply	Classification	Valuation Method	Tracking Granularity
ID 1 (Gold Coins)	1,000,000	Fungible	Market price × quantity	Lot-based cost basis
ID 42 (Legendary Sword)	1	Non-fungible	Individual fair value	Item-based record
ID 100 (Event Badges)	50	Semi-fungible	Market price if liquid, individual if illiquid	Lot-based or item-based

The semi-fungible classification (supply between 2 and approximately 100) requires a liquidity assessment — tokens with active secondary market trading follow fungible accounting treatment, while tokens without liquid markets follow non-fungible treatment. The organization’s crypto accounting policy should document the liquidity threshold that triggers the classification change.

How Do Cross-Chain Token Standards Compare?

Cross-chain token standards — BEP-20 (BNB Chain), SPL (Solana), TRC-20 (Tron), and ARC-20 (Avalanche) — are functional equivalents of ERC-20 that follow identical fungible accounting treatment. The cross-chain equivalency matrix for the 5 primary fungible token standards is listed below.

Standard	Blockchain	EVM Compatible	Equivalent To	Accounting Treatment
ERC-20	Ethereum, Polygon, Arbitrum, Optimism, Base	Yes	(baseline)	Fungible lot-based
BEP-20	BNB Chain	Yes	ERC-20	Fungible lot-based
TRC-20	Tron	No	ERC-20	Fungible lot-based
SPL	Solana	No	ERC-20	Fungible lot-based
ARC-20	Avalanche C-Chain	Yes	ERC-20	Fungible lot-based

The accounting classification logic is standard-agnostic — the blockchain determines which data collection pipeline ingests the transaction, while the standard determines the asset classification applied by the crypto subledger. A USDC token on Ethereum (ERC-20), BNB Chain (BEP-20), Solana (SPL), and Tron (TRC-20) all receive identical fungible lot-based accounting treatment despite operating on different blockchain networks with different consensus mechanisms and fee structures.

Non-fungible and semi-fungible token standards also have cross-chain equivalents — Solana’s Metaplex NFT standard and BNB Chain’s BEP-721 follow the same item-based accounting treatment as ERC-721 on Ethereum. Crypto wallets custody tokens across all standards, and the wallet type (custodial, non-custodial, multi-signature) determines the data extraction method — not the accounting classification.

How Do Token Standards Affect Reconciliation and Reporting?

Token standards affect reconciliation by determining the reconciliation method — ERC-20 tokens use balance-based reconciliation (on-chain balance vs subledger aggregate), while ERC-721 tokens use ownership-based reconciliation (on-chain ownerOf vs subledger item record).

What Is the Reconciliation Method for Each Token Standard?

ERC-20 reconciliation compares the on-chain balanceOf() return value against the subledger sum of all lot quantities for each token per wallet address. Variances exceeding 0.01% are flagged as reconciliation exceptions. Common causes of ERC-20 balance variances include missed transactions (data source gap), duplicate ingestion (same transaction recorded twice), and incorrect decimal handling (ERC-20 tokens use 6-18 decimal places depending on the contract).

ERC-721 reconciliation verifies that the on-chain ownerOf(tokenId) matches the subledger ownership record for each individual token. Any mismatch between on-chain ownership and subledger records represents a reconciliation exception — there is no tolerance threshold for non-fungible token ownership because ownership is binary (owned or not owned).

ERC-1155 reconciliation applies both methods per token ID: balance-based reconciliation for fungible token IDs (balanceOf(account, tokenId)) and ownership-based reconciliation for non-fungible token IDs. The subledger references the per-token-ID classification to select the appropriate reconciliation method automatically.

DeFi accounting introduces specialized token types — LP tokens, wrapped tokens, and governance tokens — that follow the standard token classification rules but require protocol-level reconciliation to verify the underlying asset positions. LP tokens are ERC-20 (fungible) but represent proportional claims on a liquidity pool, adding a layer of derived valuation beyond simple market price.

Token Transfer events map directly to the blockchain transaction types taxonomy — each Transfer event is classified as a transfer, acquisition, or disposal based on the direction of token movement and the relationship between the sender and receiver addresses. The token standard determines the reconciliation method; the transaction type determines the journal entry structure.