> ## Documentation Index
> Fetch the complete documentation index at: https://docs.allium.so/llms.txt
> Use this file to discover all available pages before exploring further.

# Token standards

> ERC-20, ERC-721, ERC-1155, SPL, Token-2022 and the rest — what each standard specifies and why the differences make blockchain data hard.

A **token standard** is an agreed interface a token contract implements: which functions it exposes, which events it emits, and what those events mean. Standards are what let a wallet display a token it has never seen before, and what let an indexer interpret a transfer without reading the contract's source.

They are also the main reason blockchain data is harder than it looks. There is no single global token standard — each ecosystem has its own, several ecosystems have more than one, and plenty of real tokens follow none of them exactly.

## Ethereum and EVM chains

| Standard | Asset type | What it specifies | Notes |
| :- | :- | :- | :- |
| **ERC-20** | Fungible | `transfer`, `approve`, `balanceOf`, plus a `Transfer` event | The default for stablecoins, governance tokens, and wrapped assets |
| **ERC-721** | Non-fungible | One owner per `tokenId`, plus `Transfer` and `Approval` events | The default for NFT collections |
| **ERC-1155** | Both | Many token IDs per contract, batch transfers | Used by games and marketplaces; a single contract can hold fungible and non-fungible IDs |
| **ERC-4626** | Fungible | A standard interface for yield-bearing vault shares | Share balances are not asset balances; the exchange rate moves |
| **ERC-777, ERC-4337, ERC-8004** | — | Extensions: transfer hooks, account abstraction, agent identity | Increasingly common; each one adds an event shape to interpret |

ERC-20 and ERC-721 are the same standard family, and this causes real confusion: both emit an event called `Transfer`, with a third parameter that is an *amount* for ERC-20 and a *token ID* for ERC-721. Deciding which is which requires knowing the contract's type, which is metadata the event itself does not carry.

<Warning>
  Standards are conventions, not enforcement. A contract can call itself ERC-20 and behave differently. Fee-on-transfer tokens move less than the transferred amount; rebasing tokens change every holder's balance with no `Transfer` event at all; some tokens move value through internal calls and emit no event. Any dataset built purely from `Transfer` events will be wrong for these tokens — which is why Allium reconciles balances against onchain state rather than deriving them from events alone.
</Warning>

## Solana

Solana does not put token logic in per-token contracts. A single **Token Program** owns all token accounts, and each token is a *mint* account with its own supply and decimals.

| Standard | Asset type | Notes |
| :- | :- | :- |
| **SPL Token** | Fungible and non-fungible | The original token program. A holding lives in a separate token account owned by the wallet, not in the wallet address itself |
| **Token-2022** | Fungible and non-fungible | Successor program adding extensions: transfer fees, transfer hooks, confidential transfers, interest-bearing tokens |
| **Metaplex** | Non-fungible | The metadata standard layered on top of SPL for NFT names, images, and collections |
| **Compressed NFTs (cNFTs)** | Non-fungible | State stored in a Merkle tree rather than in accounts; cheap to mint at volume, and only readable with the tree's proof data |

The practical consequence: on Solana a wallet's holdings are spread across **associated token accounts**, so "the balance of this address" requires resolving account ownership rather than reading a single mapping. NFTs are just mints with a supply of one, so nothing in the token model itself tells you an asset is an NFT.

## Other ecosystems

| Ecosystem | Token model |
| :- | :- |
| **Bitcoin and UTXO chains** | No native token layer. Value is unspent outputs; token-like protocols (Ordinals, Runes, BRC-20) are conventions encoded in transaction data |
| **Cosmos** | Native denominations plus IBC-transferred denoms, and CosmWasm CW-20 contracts. Balances live in the bank module, not in contracts |
| **Move chains (Aptos, Sui)** | Tokens are typed resources or objects held directly by accounts. The type system enforces properties that EVM standards only suggest |
| **XRP Ledger, Stellar** | Issued assets defined at the ledger level, with trustlines controlling who may hold what |
| **TRON** | TRC-20, closely modelled on ERC-20 |

## Why Allium normalizes

Every one of those models answers "who holds what" differently. Reading them yourself means writing a distinct extraction path per ecosystem, then keeping each one correct as programs and standards change.

Allium's job is to collapse that into one shape:

| You want | Use |
| :- | :- |
| Transfers with a consistent schema across every chain and standard | [Token Transfers](/historical-data/token-transfers) |
| Holdings reconciled against onchain state, not derived from events | [Balances](/historical-data/balances) |
| Symbol, name, decimals, and supply per token | [Tokens](/historical-data/tokens/profile-beta) |
| NFT collections, mints, and sales | [NFTs](/historical-data/nft-trades) |
| Raw events and instructions, unnormalized, for your own logic | Each chain's `raw` schema in the [Data Catalog](/historical-data/overview) |

<Tip>
  When a number disagrees with a block explorer, check the token standard before checking the pipeline. Fee-on-transfer, rebasing, and compressed assets account for most apparent discrepancies. [Data caveats](/historical-data/overview/data-caveats) lists the known cases.
</Tip>

## Next steps

* [Fungible vs non-fungible](/guides/fungible-vs-non-fungible) — the underlying distinction
* [Balances](/historical-data/balances) — how holdings are modelled