Token Standard

What Is a Token Standard?

A token standard is a formal specification that defines how a digital token behaves on a blockchain. It describes the functions a token contract must implement, the events it must emit, and the rules it must follow for transfers, approvals, and balance tracking. Think of it as a shared language: if every token speaks the same language, any wallet, exchange, or decentralized application can understand and interact with it.

Without standards, every token would require bespoke integration. A wallet would need custom code for each token it supports. An exchange would need to understand each token's unique transfer mechanism. Standards eliminate this friction by guaranteeing a predictable interface. When a developer deploys a token that conforms to ERC-20, for example, it immediately works with MetaMask, Uniswap, Aave, and thousands of other tools that already understand the ERC-20 interface.

The concept emerged on Ethereum in 2015 with the Ethereum Request for Comments (ERC) process, modeled after internet standards like RFCs. Since then, multiple blockchains have adopted their own token standard frameworks, and Bitcoin has developed entirely different approaches to tokenization that reflect its UTXO-based architecture.

How It Works

A token standard works by defining a contract interface: a set of functions and events that every compliant token must implement. Any external software interacting with the token can call these functions knowing the exact input parameters and return values. This predictability is what makes the ecosystem composable.

The ERC-20 Interface

ERC-20, the most widely adopted token standard, defines six required functions and two events. Every fungible token on Ethereum implements this interface:

// ERC-20 Required Interface
interface IERC20 {
    // Returns the total supply of the token
    function totalSupply() external view returns (uint256);

    // Returns the balance of a specific account
    function balanceOf(address account) external view returns (uint256);

    // Transfers tokens from the caller to a recipient
    function transfer(address to, uint256 amount) external returns (bool);

    // Returns the remaining allowance granted to a spender
    function allowance(address owner, address spender) external view returns (uint256);

    // Grants a spender permission to transfer up to a specified amount
    function approve(address spender, uint256 amount) external returns (bool);

    // Transfers tokens on behalf of another address (requires prior approval)
    function transferFrom(address from, address to, uint256 amount) external returns (bool);

    // Events
    event Transfer(address indexed from, address indexed to, uint256 value);
    event Approval(address indexed owner, address indexed spender, uint256 value);
}

The approve and transferFrom pattern is particularly important: it enables third-party contracts (like DEXs or lending protocols) to move tokens on a user's behalf after receiving explicit permission. This two-step pattern underpins most of DeFi.

Non-Fungible Tokens: ERC-721

While ERC-20 handles fungible tokens (where each unit is identical), ERC-721 introduced a standard for non-fungible tokens (NFTs) where each token has a unique identifier. The interface adds ownership tracking per token ID:

// ERC-721 Core Interface (simplified)
interface IERC721 {
    function balanceOf(address owner) external view returns (uint256);
    function ownerOf(uint256 tokenId) external view returns (address);
    function transferFrom(address from, address to, uint256 tokenId) external;
    function approve(address to, uint256 tokenId) external;
    function safeTransferFrom(address from, address to, uint256 tokenId) external;
}

ERC-721 introduced safeTransferFrom, which checks whether the recipient contract can handle NFTs before sending. This prevents tokens from being permanently locked in contracts that have no mechanism to transfer them out.

Common Extensions

Token standards often include optional extensions that add functionality beyond the base interface:

• ERC-2612 (Permit): allows approvals via off-chain signatures instead of on-chain transactions, reducing gas costs and improving UX by combining approve and transfer into a single transaction
• ERC-3156 (Flash Mint): enables uncollateralized token minting within a single transaction, provided the tokens are returned before the transaction completes
• ERC-1155 (Multi-Token): combines fungible and non-fungible tokens in a single contract, useful for gaming and applications that manage many token types simultaneously
• ERC-4626 (Tokenized Vault): standardizes yield-bearing token vaults, making it possible for any protocol to integrate with any vault using the same interface

Token Standards on Bitcoin

Bitcoin's architecture differs fundamentally from Ethereum's. Ethereum has a built-in virtual machine that executes arbitrary smart contract code, making it straightforward to define token interfaces as contract standards. Bitcoin lacks this general-purpose programmability. Its scripting language is intentionally limited, and its UTXO model tracks unspent transaction outputs rather than account balances.

Despite these constraints, several approaches to tokenization have emerged on Bitcoin, each with different tradeoffs:

BRC-20

BRC-20 tokens use Ordinals inscriptions to embed JSON data into Bitcoin transactions. The "standard" is a set of conventions around JSON formatting rather than an enforced contract interface. A BRC-20 deploy inscription looks like this:

{
  "p": "brc-20",
  "op": "deploy",
  "tick": "ordi",
  "max": "21000000",
  "lim": "1000"
}

Because Bitcoin has no virtual machine to enforce these rules, BRC-20 relies on off-chain indexers to parse inscriptions and track balances. Different indexers must agree on the same parsing rules for the system to work, which creates fragility: indexer bugs or disagreements can cause balance discrepancies.

Runes

Runes, introduced by Ordinals creator Casey Rodarmor in 2024, takes a different approach. Instead of inscribing JSON data, Runes encodes token operations directly into OP_RETURN outputs using a compact binary format. This makes Runes more efficient than BRC-20: it produces fewer unnecessary UTXOs and uses less block space per operation.

Runes leverages Bitcoin's native UTXO model, meaning token balances are tied directly to UTXOs rather than tracked through JSON inscriptions. This makes the protocol more aligned with Bitcoin's architecture, and validation requires only parsing transaction outputs rather than scanning witness data for inscription content.

Colored Coins and OP_RETURN

Before Ordinals and Runes, earlier token approaches on Bitcoin included Colored Coins (marking specific satoshis as representing external assets) and Counterparty (embedding data in transactions). These protocols demonstrated the demand for Bitcoin-native tokens but were limited by block space constraints and the lack of expressive scripting. Many of the tokens built with these earlier methods functioned as wrapped assets, representing value from other chains or real-world assets on Bitcoin's ledger.

Why Standards Matter

Wallet Compatibility

When a token follows a recognized standard, wallets can display it automatically. A wallet that supports ERC-20 can show the balance of any ERC-20 token without requiring a software update. Users simply add the token's contract address, and the wallet queries balanceOf and symbol to display the correct information. Without a standard, the wallet would need token-specific logic for each asset.

Exchange Listing

Exchanges integrate tokens programmatically. A standard interface means an exchange can support a new ERC-20 token by simply adding its contract address to a configuration file: deposits use the Transfer event, withdrawals use the transfer function, and balance checks use balanceOf. Non-standard tokens require custom integration work, which significantly raises the barrier to listing.

Composability

Composability is the ability for protocols to interoperate without direct coordination. A lending protocol can accept any ERC-20 as collateral. A DEX can create a trading pair for any ERC-20. A yield aggregator can deposit into any ERC-4626 vault. This is possible only because every token exposes the same interface. The Taproot upgrade brought similar composability improvements to Bitcoin by enabling more complex spending conditions.

Use Cases

• Stablecoins: tokens like USDC and USDT follow ERC-20, making them instantly usable across DeFi protocols. On Bitcoin, stablecoins like USDB bring dollar-denominated value to the Bitcoin ecosystem through platforms like Spark
• Governance: protocols issue ERC-20 governance tokens that integrate with voting contracts, delegation systems, and treasury management tools because they all share the same transfer and approval interface
• NFTs and digital collectibles: ERC-721 and ERC-1155 power marketplaces like OpenSea, gaming assets, and digital art, with each token uniquely identifiable and transferable through a common interface
• Tokenized real-world assets: securities, real estate fractions, and commodity tokens use ERC-20 (often with extensions for compliance like transfer restrictions) to represent off-chain assets on-chain
• Bitcoin-native tokens: BRC-20 and Runes enable fungible tokens on Bitcoin without requiring a separate chain, expanding Bitcoin's utility beyond simple value transfer

Risks and Considerations

Standard Proliferation

The growing number of token standards creates fragmentation. On Ethereum alone, developers must choose between ERC-20, ERC-777, ERC-1155, and various extensions. Each standard has different security properties and integration requirements. On Bitcoin, the competition between BRC-20, Runes, RGB, and Taproot Assets means the ecosystem hasn't converged on a single approach, splitting liquidity and tooling across multiple incompatible systems.

Security Vulnerabilities

Token standards define interfaces, not implementations. A token can conform to ERC-20 while containing malicious code in its transfer logic: hidden fees, transfer blocks, or backdoor minting functions. The standard guarantees the function signatures exist but not that the implementation is safe. Users and protocols must audit individual token contracts rather than trusting compliance with a standard as proof of safety.

The ERC-20 approve pattern also introduces a known vulnerability: if a user changes an existing approval, a race condition allows the spender to use both the old and new allowance. The recommended mitigation is to set the allowance to zero before changing it to a new value, or to use the ERC-2612 permit extension instead.

Bitcoin Indexer Dependency

Bitcoin token standards like BRC-20 rely on off-chain indexers to determine token balances and validate transfers. Unlike Ethereum, where the virtual machine enforces token rules at the protocol level, Bitcoin's consensus layer has no awareness of these token protocols. If indexers disagree on parsing rules or contain bugs, users may see inconsistent balances across different wallets and marketplaces. This creates a trust assumption that does not exist with Ethereum-native token standards.

Upgrade and Migration Challenges

Once a token standard is widely adopted, changing it becomes extremely difficult. ERC-20's known issues (the approve race condition, the lack of transfer callbacks) persist because billions of dollars in tokens use the original interface. Newer standards like ERC-777 attempted to fix these problems but introduced new attack vectors through reentrancy in transfer hooks. Migrating existing tokens to a new standard typically requires deploying a new contract and coordinating a token swap, which fragments liquidity and confuses users.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.