ERC-6909: Minimal Multi-Token Interface and Why It Matters for Ethereum Projects

The reference implementation is taken from the ERC-6909 specification and simplified by me for quick understanding by developers. I recommend reviewing the reference first, then continuing with the rest of the article.

The balance storage structure is the first thing to pay attention to. Unlike ERC-1155, there are changes.

The mapping responsible for storing an account's balance starts with the owner's address, not the token ID.

This fundamentally only affects the interaction interface. To retrieve all user balances, you still need to implement additional functions in the smart contract or index the data off-chain. This is because you need to know all token IDs owned by the account, and the base implementation doesn’t store this information by default.

According to the ERC-1155 standard, a smart contract that acts as a token recipient must implement the ERC1155TokenReceiver interface.

This interface requires implementing one of the functions depending on the chosen token transfer method (single or batch):

In ERC-6909, developers can still use callbacks, but the implementation is entirely up to them and can be arbitrary.

ERC-6909 does not define a callback mechanism. This helps reduce the size of the base smart contract implementation and the number of operations during execution, making it more efficient in terms of gas and complexity.

Similar to callbacks, the standard takes the same approach with batch operations.

ERC-1155 requires the implementation of additional functions:

ERC-6909 no longer mandates batch operations and doesn’t require their implementation just for the sake of standard compliance.

Batch operations can be added at the developer's discretion and tailored to the specific needs of the project.

Token Transfer Functions

The transfer is as close as possible to the ERC-20 standard implementation, with slight modifications.

Sender and receiver are the familiar from and to. An id is added to specify the token identifier involved in the transfer. The addition of id is very reminiscent of ERC-721 and ERC-1155.

In ERC-1155, approvals can only be granted to an operator via a function call:

ERC-6909 introduces a hybrid approval system. There are two ways to grant approval:

• To an operator, allowing unlimited use of tokens on behalf of the user. The operator can manage any of the user’s tokens (with any id).
• To an arbitrary account, with a limit on the number of tokens it can use on behalf of the user.

Thus, the ERC-6909 interface provides two functions for implementing approval logic:

This mechanism is quite flexible, but there’s a nuance when an account is granted approval through both functions. In such cases, the standard performs checks in the following order:

1. Check if the account is an operator.
2. If not an operator, check the allowance granted via the approve() call.

Approval is only checked when using the transferFrom() function.

Thus, for an operator who has been granted a limited approval (via the approve() function), the allowance will not be changed.

With the ERC-6909 standard, you can implement both fungible and non-fungible tokens simultaneously.
The metadata implementation for such tokens is moved outside the core standard into a separate extension and is optional.

Why optional? The answer is simple: for managing LP tokens (or other types of tokens), properties like name, symbol, or URI might not be important. That’s why metadata is optional and excluded from the base implementation, but its usage is still standardized.

Currently, only the OpenZeppelin library implements metadata as an extension to the standard. (Solmate doesn’t have smart contracts for metadata, and in Solady the metadata is hardcoded into the base implementation).

Next, let’s take a look at how metadata smart contracts are implemented in OpenZeppelin.

Important! At the time of writing, everything related to ERC-6909 in OpenZeppelin is marked as draft.

ERC6909Metadata.sol

There are two things of interest here:

1. All functions — name(), symbol(), decimals() — take a single id argument. This means each token will have its own parameters.
2. OpenZeppelin uses a combination of mapping and struct to store data — a classic approach for optimizing data storage.

ERC6909TokenSupply.sol

Total supply, just like name, symbol, and so on, is individual for each token.

ERC6909ContentURI.sol

This contract stores metadata required for NFTs. contractURI is used to declare general collection data. tokenURI is used to declare individual metadata for each token.

Thus, by using a combination of metadata contract extensions — ERC6909Metadata, ERC6909TokenSupply, and ERC6909ContentURI — the standard can manage both fungible and non-fungible tokens at the same time.

The naming conventions safeTransfer() and safeTransferFrom() can be misleading, especially in the context of ERC-1155 and ERC-721 standards, since they require external calls to recipient addresses (if the recipient is a smart contract). This means control is passed to an arbitrary contract.

According to the ERC-6909 standard, removing the word "safe" from all function names is considered less misleading.

Unlike many proposed token standards, ERC-6909 was immediately tested in Uniswap v4.

ERC-6909 serves as proof of a user's assets within the protocol.

It works quite simply: after performing an operation (swap, removing liquidity), the user can leave their asset inside the protocol and receive an ERC-6909 token in return. Next time, to use the asset within the protocol, it's enough to burn the equivalent amount of ERC-6909.

For example, a user swaps USDT for USDC. They send USDT, but instead of receiving USDC, they mint an equivalent amount of ERC-6909. The USDC stays inside the protocol.
Later, the user decides to swap back to USDT using USDC. To do this, they simply burn the ERC-6909 token, and the protocol returns USDT.

In this way, ERC-6909 significantly reduces gas costs when moving assets.
Minting an ERC-6909 token is cheaper than transferring USDC in terms of gas. That’s because minting involves a single storage write and a Mint() event, while most tokens add extra checks during transfers—like whitelists or other custom logic.

This technology is especially useful for traders who perform many operations in a short period of time, and for liquidity providers who rebalance their positions.

More details in the official Uniswap documentation.

ERC-6909 is one of those rare standards that simplifies the system instead of making it more complex. Thanks to this simplification, any implementation of the standard is easier to understand, has a smaller footprint, and is cheaper to use with multiple tokens.

ERC-6909 is not backward compatible with ERC-1155!

That said, I want to highlight the ability to seamlessly combine management of both fungible and non-fungible tokens.
A single ERC-6909 smart contract can manage both ERC-20 tokens and NFTs.

Important! This comes with the caveat that all NFTs must be implemented within a single collection, since the contractURI() function does not support multiple collections.