ERC-6909 Explained: Ethereum's Minimal Multi-Token Standard

ERC-6909 is Ethereum’s final minimal multi-token interface: one contract can track balances for many token IDs. Unlike ERC-1155, its core specification does not require batch-transfer methods or receiver callbacks; it combines per-ID allowances with operator-wide approvals. Uniswap v4 uses ERC-6909 balances as claims on tokens kept in its PoolManager, illustrating a use for internal accounting. It is a lean primitive, not a universal ERC-1155 replacement: teams must decide how to handle batching, recipient compatibility and delegated permissions.

What does ERC-6909 standardize?

ERC-6909 defines a shared interface for balances keyed by an account and a token ID. A contract can expose balanceOf(owner, id), transfer an amount of an ID, and let another account transfer on an owner’s behalf. Each ID can have its own balance ledger within the same contract.

The standard defines the transfer and permission interface, not what an ID means to an application. A project may use IDs for distinct assets, claim balances or other units; minting rules, business meaning and user experience remain implementation choices. ERC-6909 also specifies optional metadata, content-URI and token-supply extensions, so these should not be assumed to exist in every implementation.

For a broader comparison of Ethereum token formats, see our guide to ERC-721 and ERC-1155. A different pattern—fungible shares representing a vault position—is covered in our ERC-4626 guide.

ERC-6909 vs. ERC-1155

Both standards represent balances for multiple token IDs in a contract, but they make different interface trade-offs. The ERC-6909 specification describes itself as a simplified alternative to ERC-1155.

Design choice	ERC-6909	ERC-1155
Batch transfers	No required batch-transfer method in the core interface	Standardizes batch transfer methods
Contract-recipient callback	No required receiver callback	Safe transfers require the recipient contract to return the expected callback value
Delegated permissions	Per-ID allowance plus an operator permission covering all IDs	Operator approval across the owner’s token IDs
Compatibility	Not backward-compatible with ERC-1155; adapters or wrappers can be built	Its own interface and receiver expectations

This is a choice about required behavior, not a guarantee that one implementation will always cost less gas. ERC-6909 leaves batching to application-specific extensions or surrounding contracts. Omitting a mandatory receiver callback also means integrations cannot rely on the standard to ask a contract recipient whether it understands a token before the transfer completes.

Allowances and operators have different scope

ERC-6909 supports two ways to delegate transfers. An allowance assigns a spender a quantity for one token ID. An operator approval grants a spender authority to transfer any amount of any ID for that owner until the approval is revoked.

That flexibility is useful, but the scopes are not equivalent. The EIP warns that a spender can use its allowance until it is revoked, while an approved operator can move any of the owner’s IDs. Wallets and applications should explain which permission is being granted, and users should review and revoke permissions they no longer need.

Why Uniswap v4 uses ERC-6909 claims

Uniswap’s v4 documentation describes ERC-6909 as an option for token claims and redemptions in its PoolManager. Instead of repeatedly moving an underlying ERC-20 into or out of the PoolManager, a user can leave it there and receive an ERC-6909 balance representing a claim. Later interactions can consume that claim balance.

The example shows why a minimal multi-token ledger can be useful for internal settlement, not just for displaying collectibles. It is specific to Uniswap v4’s accounting design: ERC-6909 does not by itself make every transfer or application cheaper. Uniswap’s documentation also notes a storage-write trade-off for its totalSupply tracking; the EIP’s token-supply extension is optional, so implementations can differ.

When should a team choose ERC-6909?

Consider ERC-6909 when a contract needs balances for many IDs and the application benefits from a small core interface, per-ID allowances, or internal claim accounting. Consider ERC-1155 when the application depends on its standardized batch-transfer methods or receiver callbacks. Compare the actual contract and wallet requirements before choosing: the standards are not drop-in compatible, and a wrapper adds its own behavior and review burden.

Is ERC-6909 an NFT standard?

It is a multi-token interface, not a promise that each ID is a unique NFT. The standard tracks balances by ID; the application defines what each ID represents.

Does ERC-6909 replace ERC-1155?

No. ERC-6909 deliberately omits some ERC-1155 interface behavior and is not backward-compatible. Choose it only when its simpler required interface fits the application.

Why is ERC-6909 relevant to Uniswap v4?

Uniswap v4 uses ERC-6909 balances as claims on tokens held in its PoolManager. Users can use those claims in later interactions without repeating the same underlying-token transfer flow in every step.

Sources

Building a multi-token or settlement flow? Contact SignorCrypto to scope the smart-contract architecture and integration.