docs: token standards reference

[marc0olo]

Summary

• Reference page for ICRC token and wallet signer standards
• Covers ICRC-1 (fungible tokens), ICRC-2 (approve/transfer-from), ICRC-3 (transaction log with archive model), ICRC-7 (NFTs), ICRC-37 (NFT approvals), and wallet signer standards (ICRC-21/25/27/29/49)
• Includes Candid type definitions, method signatures, metadata entries, and canonical canister IDs for DFINITY-maintained ledgers
• ICRC-3 section covers the archive canister model, adopted block types, and proposed block types (ICRC-122/123/124/152/153/154)
• Links to ICP Dashboard for comprehensive token registry beyond the listed DFINITY-maintained tokens

Sync recommendation

informed by dfinity/portal — docs/defi/token-standards/index.mdx, icrc-1.mdx, icrc-2.mdx, icrc-7.mdx, icrc-37.mdx; dfinity/icskills — skills/icrc-ledger/SKILL.md, skills/wallet-integration/SKILL.md

[marc0olo]

Review

Must-fix

1. icrc3_get_transactions is not an ICRC-3 method — This method does not exist in the ICRC-3 standard. ICRC-3 defines only three methods: icrc3_get_blocks, icrc3_get_tip_certificate, and icrc3_supported_block_types. The get_transactions endpoint is a legacy, ledger-specific method and is not part of the ICRC-3 spec. Confirmed by searching all of .sources/ — icrc3_get_transactions appears nowhere. Must be removed from the table.

Suggestions

1. ICRC-3 block type strings unverified — 1xfer, 1burn, 1mint, 2approve, 2xfer could not be verified against .sources/. Consider adding a <!-- Needs human verification --> comment or linking to the ICRC-3 spec.

2. ICRC-3 DataCertificate return type unverified — The type name for icrc3_get_tip_certificate couldn't be confirmed from spec sources. Low risk since it matches existing implementations.

3. Content brief gap: compliance requirements — The stub asked for "compliance requirements" (which methods are required vs optional per standard). Not covered. Nice-to-have.

4. Opening paragraph could be more scannable — Leads with governance process rather than what developers need to know. Consider leading with "ICRC = token standards family" and making governance secondary.

5. No mention of ICRC-3 archive canisters — The archive canister model (older blocks moved to archives, icrc3_get_blocks returns callbacks) is a key architectural detail developers encounter.

Verified

• All 3 internal links resolve
• All 6 anchor links match heading slugs
• No dfx references, no old docs links, plain .md
• Frontmatter correct, <!-- Upstream: --> present with icskills listed, PR has ## Sync recommendation
• Canister IDs verified against icskills (ICP, ckBTC, ckETH + index canisters)
• Fee values verified (ICP 10,000 e8s, ckBTC 10 sat, ckETH 2T wei)
• ICRC-1 and ICRC-2 Candid types verified against icrc-ledger skill
• ICRC-7 metadata entries and icrc7_transfer signature verified against portal and examples
• ICRC-37 metadata entries verified
• Wallet signer standards (ICRC-21/25/27/29/49) match wallet-integration skill
• Deduplication window (24h) matches skill
• Build passes, Diataxis reference pattern respected

[marc0olo]

Feedback addressed:

• Removed non-existent icrc3_get_transactions (confirmed against ICRC-3 spec)
• Added missing icrc3_get_archives method
• Added archive canister model explanation (blocks distributed across archive canisters)
• Added proposed block types table: ICRC-122, ICRC-123, ICRC-124, ICRC-152, ICRC-153, ICRC-154 with links to their PRs
• Noted that anyone can define custom ICRC-3 block types following the naming convention
• Renamed "Canonical ledger canister IDs" to "Common ICRC-1 ledgers" with honest framing (DFINITY-maintained, not exhaustive)
• Added link to ICP Dashboard token list for comprehensive registry
• Added dynamic fee note: always call icrc1_fee rather than hardcoding
• Reordered opening paragraph to lead with developer context before governance process
• Verified ICRC-3 block type strings (1xfer, 1burn, 1mint, 2approve, 2xfer) and DataCertificate type against the ICRC-3 Candid interface
• Rebased on main