Token standards on the Internet Computer

Which standards ICP tokens support

We asked the ledger of every token listed on ICP Tokens which standards it implements, using icrc1_supported_standards, on October 14, 2026. XTC and PEPE did not answer, so they appear in no count. 83 of the 142 tokens implement all three core standards.

The three core standards

They stack: ICRC-2 requires ICRC-1, and ICRC-3’s block types describe ICRC-1 and ICRC-2 operations. A ledger tells the world which ones it implements throughicrc1_supported_standards — which is exactly what we read for the table above.

Extensions: ICRC-10, ICRC-21, ICRC-103, ICRC-106, ICRC-107

Modern ledgers — including ckBTC, ckETH, the ckERC20 tokens and every SNS ledger listed here — announce more than the core three. Here is what each extension does and how far it is in the standards process.

ICRC-21: consent messages — see what you sign

Status: approved. Listed tokens: 78 (55%), including the ICP ledger itself.

Calls to a canister can move funds, but their arguments are technical. ICRC-21 defines how a canister produces a human-readable consent message for a call, which a signer (the wallet that holds your keys) shows you before you approve. The app that asks for the signature — the “relying party” — is explicitly not trusted, so the message comes from the target canister through icrc21_canister_call_consent_message. The call must work without authentication so that offline “cold” signers can use it too.

ICRC-103: list every allowance you have given

Status: draft. Listed tokens: 61 (43%).

ICRC-2’s icrc2_allowance only answers for one known spender. Finding all open approvals of an account would otherwise mean walking the whole ledger history. ICRC-103 adds icrc103_get_allowances, which returns the outstanding allowances page by page. A ledger states in its metadata whether the list is public (icrc103:public_allowances = "true") or only visible to the owner, and the maximum page size (icrc103:max_take_value).

ICRC-106: where to find a token’s index canister

Status: draft. Listed tokens: 61 (43%).

Wallets need your transaction history per account, which an index canister provides. Before ICRC-106 there was no standard way to find a token’s index. Now the ledger publishes it in the metadata entry icrc106:index_principal and through icrc106_get_index_principal, and the draft documents a minimal interface for the index itself. It complements ICRC-3, which covers the ledger’s raw block log.

ICRC-10: discover the standards of any canister

Status: accepted (NNS proposal 129625). Listed tokens: 60 (42%).

icrc1_supported_standards exists only on token ledgers. ICRC-10 generalises it: any canister can implement icrc10_supported_standards and return the same{ name; url } records. ICRC standards use the name ICRC-X, where X is the issue number assigned in the dfinity/ICRC repository; other standards should use a namespace unlikely to collide.

ICRC-107: who receives the fees

Status: draft, extends ICRC-3. Listed tokens: 2.

ICRC-1 says fees are burnt, but ledgers handle them differently in practice. The draft names ckBTC as an example of inconsistent handling: some ledgers send transfer fees to a fee collector but burn the fees of approvals. ICRC-107 records one global fee-collector setting on-chain in a new 107feecol block, so wallets and explorers can tell exactly where each fee goes. It is backward compatible: until a ledger uses the new block, its legacy rules apply.

ICRC-4 and ICRC-130: announced, not specified

ICRC-4: batch transfers

4 listed ledgers announce ICRC-4. In the dfinity/ICRC repository, number 4 is a reserved issue titled “ICRC-4: Batch Transfers”, and there is no published ICRC-4 specification there. Treat it as the ledger’s own claim of supporting batch transfers, and check the project’s documentation for the exact interface.

ICRC-130

1 listed ledger announces ICRC-130. Its issue is titled “Azel Reproducible Build” with the description “TBD”; no specification is published.

Older standards: DIP20, DRC20 and EXT

Outside the ICRC family there are older community token standards — DIP20, DRC20 and EXT among them. ICPSwap still supports DIP20 and EXT next to ICRC-1, ICRC-2 and ICP. On ICP Tokens, 1 listed ledger announces DIP20 and DRC20 together with ICRC-1 and ICRC-2. XTC and PEPE did not answer icrc1_supported_standards at all.

NFT standards: ICRC-7 and ICRC-37

The same family covers non-fungible tokens. ICRC-7 is the minimal NFT standard (accepted, NNS proposal 129626): a ledger hosts a collection of NFTs. Like ICRC-1, it leaves approvals out; ICRC-37 adds approve and transfer-from for NFTs (accepted, NNS proposal 129640). ICP Tokens tracks fungible tokens; for NFTs see our overview of ICP NFT marketplaces.

Chain-key tokens: ckBTC, ckETH, ckUSDC and more

DFINITY describes chain-key tokens as a safer alternative to wrapped tokens: each one is backed 1:1 by the native asset, held 100% on-chain by an ICP smart contract, using chain-key cryptography such as threshold signing — with no intermediaries or centralized bridges. They are ICRC tokens: ckBTC implements ICRC-1 and ICRC-2, and all chain-key ledgers listed here announce ICRC-1, -2, -3, -10, -21, -103 and -106.

What makes a token “chain-key”

The DFINITY developer docs set these requirements:

• It follows an ICRC token standard.
• It is a true digital twin: anyone can convert the native token to the chain-key token and back, paying only transfer and conversion fees — so it must be fully backed at all times.
• All conversions are transparent and traceable on-chain.
• The canister handling conversions manages the native asset with chain-key signatures and reads the other chain in a decentralized way.
• All code is open source, builds are reproducible, and the canisters are immutable or controlled by a DAO.

ckBTC

Chain-key Bitcoin is backed 1:1 by BTC. Its minter canister mints ckBTC when you send bitcoin to a Bitcoin address under the minter’s control (after enough confirmations, and after a check of the sending address), and burns ckBTC before sending BTC back. The ledger keeps balances. A ckBTC transfer costs 10 satoshis (0.0000001 ckBTC) and settles in seconds.

ckETH and ckERC20 (ckUSDC, ckUSDT, …)

ckETH is backed 1:1 by ETH. You deposit through a helper contract on Ethereum, and the ckETH minter mints after reading the event from several Ethereum RPC providers. To withdraw, you give the minter an ICRC-2 approval and call withdraw_eth; it burns the ckETH and sends ETH. ckERC20 tokens work the same way for ERC-20 tokens. Their ledgers are created and upgraded by the ledger suite orchestrator, and every new ckERC20 token needs an NNS proposal.

All chain-key tokens

The ckERC20 rows below are exactly what the orchestrator (vxkom-oyaaa-aaaar-qafda-cai) returned on October 14, 2026: 12 tokens, all backed by Ethereum mainnet contracts. Tokens marked Listed link to their live price on ICP Tokens; the others link to the ICP Dashboard.

SNS DAO tokens

An SNS (Service Nervous System) is a DAO provided by the Internet Computer protocol. A project hands its app to an SNS, and from then on neither the developers nor anyone else alone controls it: the SNS community does. On ICP Tokens these tokens carry an SNS badge.

How an SNS is launched

1. The project proposes the token name, symbol and transfer fee, the tokenomics, how governance will work, and the conditions of the decentralization swap — including the minimum and maximum ICP to raise.
2. The developers add the NNS root canister as co-controller of their app, signalling the handover.
3. One NNS proposal decides. If it is adopted, the SNS-W canister creates the SNS canisters — governance, ledger, root, swap and more — and makes the SNS root the sole controller of the app.
4. The decentralization swap sells tokens for ICP to the community; after a successful swap the DAO is fully launched.

How an SNS is governed

Anyone with an SNS neuron (staked tokens) can submit a proposal to change the app or a governance parameter; if the majority agrees, the proposal is executed automatically on-chain. SNS canisters can only be upgraded to code versions approved by the NNS, while each community chooses its own configuration. The community also has to keep its canisters topped up with cycles — including the ledger’s archives, or the block history could be lost.

SNS tokens on ICP Tokens

The SNS-W registry lists 55 deployed SNSes. 36 of their tokens are listed on ICP Tokens (checked on-chain on October 14, 2026); every one of these SNS ledgers announces ICRC-1, -2, -3, -10, -21, -103 and -106.

How an ICRC standard becomes official

1. A number is assigned: an ICRC standard is named after its issue number in the dfinity/ICRC repository.
2. A technical working group — open to anyone, with DFINITY and community members — drafts it on GitHub, the forum and in calls, looking for “rough consensus”, a method borrowed from the IETF.
3. The core members of the working group vote; acceptance needs two thirds of the votes cast.
4. The NNS votes on making it official (process described in ICRC-0, itself still a draft). ICRC-1, -2, -3, -7, -10 and -37 were accepted this way; their proposal numbers are on this page and in the specifications.

That is why a ledger may already implement a draft such as ICRC-103: implementations often run ahead of the formal vote.

Check a token yourself

You do not have to trust us. With dfx installed, two commands tell you what a token is:

dfx canister --network ic call ryjl3-tyaaa-aaaaa-aaaba-cai icrc1_supported_standards

dfx canister --network ic info mxzaz-hqaaa-aaaar-qaada-cai

Replace the canister ID with the one you want to check. Every token page on ICP Tokens shows the ledger canister ID under Contract — start from the token list.

FAQ

Sources

Everything on this page is checked against these primary sources. Token data was read on-chain on October 14, 2026.

• ICRC-1, ICRC-2, ICRC-3 specifications — dfinity/ICRC-1
• ICRC-0: working group operation and governance — dfinity/ICRC
• ICRC-10 supported standards — dfinity/ICRC
• ICRC-21 canister call consent messages — dfinity/ICRC
• ICRC-103 allowance listing (draft) — dfinity/ICRC
• ICRC-106 index canisters (draft) — dfinity/ICRC
• ICRC-107 fee management (draft) — dfinity/ICRC
• ICRC-4 issue (reserved) — dfinity/ICRC
• ICRC-130 issue — dfinity/ICRC
• ICRC-7 and ICRC-37 NFT standards — dfinity/ICRC
• DFINITY docs: chain-key tokens
• DFINITY docs: ckBTC
• DFINITY docs: ckETH
• DFINITY docs: ckERC20
• DFINITY docs: launching an SNS
• DFINITY docs: managing an SNS
• ICPSwap docs: supported token standards

Keep exploring

• ICRC-1 →The base standard: accounts, transfers, fees
• ICRC-2 →Approve and transfer-from, used by DEXes
• ICRC-3 →The verifiable block log
• All ICP token prices →Live prices, volume and liquidity of every listed token
• ICPSwap pools →Every active pool, sorted by 24h volume
• ICP wallets →Which wallets hold ICRC tokens
• Free chart widget →A live price chart of any token for your website