> ## 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