By Eco research. Updated Apr 2026.
​

ERC-6909 is a minimal multi-token interface for Ethereum that manages multiple token types within a single contract. Proposed in April 2023 by JT Riley, Dillon, Sara, Vectorized, and Neodaoist, it strips out the mandatory callbacks and batch operations that ERC-1155 requires, producing a smaller, cheaper contract with a hybrid per-ID allowance and global operator permission model. Uniswap v4 adopted ERC-6909 as its internal settlement layer when it launched in 2024.
​

ERC-6909 is a standards-track ERC proposing a minimal interface for contracts that issue multiple token types identified by a uint256 ID. It defines seven functions covering balance queries, allowance queries, direct transfers, delegated transfers, per-token approvals, and global operator permissions. The interface ID is 0x0f632fb3. Unlike ERC-1155, ERC-6909 imposes no mandatory callbacks, no batching, and no "safe" naming convention on transfer functions.
​

The specification was authored by JT Riley (@jtriley2p), Dillon (@d1ll0n), Sara (@snreynolds), Vectorized (@Vectorized), and Neodaoist (@neodaoist), and published to the official EIPs repository on April 19, 2023. The proposal grew out of observations that ERC-1155's callbacks added unnecessary cost and complexity to contracts where the consuming protocol controlled token recipients and had no use for receiver notifications.
​

ERC-6909 differs from ERC-20 in that a single deployed contract tracks many token IDs simultaneously, avoiding the per-token deployment cost that makes ERC-20 expensive for protocols issuing dozens or hundreds of distinct assets. It differs from ERC-1155 by treating callbacks as an optional implementor choice rather than a protocol requirement.
​

ERC-6909 stores balances in a nested mapping keyed first by owner address, then by token ID: mapping(address owner => mapping(uint256 id => uint256)). This layout differs from ERC-1155's inverse ordering (ID first, then owner) and is optimized for per-owner queries rather than per-ID global scans. Allowances follow the same three-layer structure: owner, spender, then ID.
​

Transfer authorization works through two complementary mechanisms. An allowance grants a spender a specific transfer ceiling on a specific token ID, checked and decremented on every transferFrom call. An operator grant (setOperator) gives a spender unlimited transfer rights across all token IDs for that owner, bypassing the per-ID allowance check. A transfer is authorized if either the caller is the token owner, the caller has a sufficient per-ID allowance, or the caller is an approved operator. This hybrid model solves the coarseness problem in ERC-1155, which only offered operator-level (all-or-nothing) approval, while retaining operator delegation for protocols that legitimately need blanket access.
​

The seven interface functions map clearly to their roles:

Three events complete the interface: Transfer fires on every movement (mints use address-zero as sender; burns use address-zero as receiver), Approval fires when an allowance is set, and OperatorSet fires when operator status changes. The ERC-6909 GitHub source contains the full ABI and reference implementation.
​

Three optional extensions are defined but not required: a Metadata extension that adds name, symbol, and decimals per token ID; a Content URI extension that adds contractURI and tokenURI; and a Token Supply extension that adds totalSupply per ID. Protocols that need metadata or supply tracking include the relevant extension interface IDs; protocols that do not can skip them entirely.
​

ERC-6909 and ERC-1155 both manage multiple fungible token types in one contract, but they differ significantly in interface complexity, gas cost, and integration requirements. The table below covers the most consequential dimensions for contract developers and protocol designers.
​

The callback removal in ERC-6909 is the largest practical difference. ERC-1155's safeTransferFrom requires that any recipient smart contract implement onERC1155Received and return the 4-byte magic value 0xf23a6e61 before the transfer finalizes. This adds a cross-contract call, a return-value check, and a minimum code requirement to every ERC-1155 transfer targeting a contract address. ERC-6909 removes this entirely. The protocol that deploys ERC-6909 tokens knows what its recipients are; it does not need the standard to enforce a callback it will never use.
​

The mandatory batch function in ERC-1155 adds deployment bytecode even in contracts that never batch. The ERC-6909 rationale, published in the Ethereum Magicians forum thread from April 2023, notes that "different applications need different calldata optimizations" and that a single mandated batch function cannot serve rollup-optimized calldata compression, flash accounting, or lock-based settlement simultaneously.
​

Uniswap v4 uses ERC-6909 as the internal token accounting layer for its singleton PoolManager contract. The PoolManager holds all pool balances centrally rather than deploying a new contract per pool. Users who want to avoid paying ERC-20 transfer costs on every swap can deposit tokens once and receive ERC-6909 claim tokens representing their balance inside the protocol. Those claim tokens are then used for subsequent swaps, liquidity additions, and removals entirely through internal accounting, with no cross-contract ERC-20 calls until final withdrawal.
​

The efficiency case is direct: ERC-20 token transfers invoke an external smart contract call. Tokens with additional logic such as USDC's blocked-address check add further overhead on each transfer. Minting or burning ERC-6909 claim tokens inside the PoolManager involves a single storage write and emits one event. For high-frequency traders and MEV bots executing multiple swaps in the same block, the gas savings from eliminating repeated ERC-20 round-trips are substantial across a full transaction batch.
​

Uniswap v4's choice was documented in the GitHub issue "Replace ERC-1155 With ERC-6909 For Multi-Token Accounting" filed against the v4-core repository. The team concluded that ERC-1155's callback requirement would add unnecessary overhead to the PoolManager's tight accounting loop. The ETHGlobal research project Uniswap V4 6909 measured a 5.6x improvement in burn-operation gas costs when switching from ERC-1155 to ERC-6909 in a comparable implementation.
​

The Uniswap v4 developer documentation describes the two-step ERC-6909 flow: deposit ERC-20 tokens and receive ERC-6909 claim tokens; later burn those claim tokens to settle obligations. Between deposit and redemption, users trade entirely within the protocol's internal ledger. This is analogous to a netting settlement layer where gross external transfers are replaced by internal book entries until the final net position is settled.
​

ERC-6909 is the better choice when the protocol controls all token recipients, has no use for receiver callbacks, and wants the smallest possible contract interface. It suits DeFi settlement layers, AMM pool accounting, rollup bridge accounting, and any protocol that issues dozens of fungible position tokens from a single contract. ERC-1155 remains appropriate when backward compatibility with OpenSea's metadata standard, ERC-1155 marketplace support, or the safe-transfer callback is a hard requirement.
​

The three-question checklist for ERC-6909 adoption:

Three "yes" answers point to ERC-6909. A "no" on callbacks typically means ERC-1155 is the safer default because its safety properties are well-tested across years of production use. The OpenZeppelin ERC-6909 implementation, added in OpenZeppelin Contracts 5.x, provides a reference that passes the full test suite including edge cases around allowance underflow and operator conflicts.
​

As of April 2026, ERC-6909 remains on the Standards Track as a Draft. Uniswap v4's production adoption gives it significant de facto stability, but it has not yet reached Final status in the formal EIP process. Developers relying on ERC-6909 should pin to a specific interface version and monitor the EIP-6909 specification page for status changes.
​

Most NFT marketplaces are built around ERC-721 and ERC-1155. ERC-6909 tokens are not directly supported by OpenSea as of Q1 2026. The interface ID (0x0f632fb3) differs from ERC-1155's, so existing ERC-1155 marketplace integrations cannot automatically detect ERC-6909 contracts. Marketplaces would need to add explicit ERC-6909 support via ERC-165 interface detection.
​

ERC-6909 uses address-zero as a sentinel in the Transfer event. A mint is a transfer where the sender is address zero; a burn is a transfer where the receiver is address zero. The specification does not define explicit mint or burn functions, giving implementors flexibility to design their issuance and redemption logic without conforming to a fixed function signature.
​

Not in protocols where the recipient logic is controlled by the same team that deploys the token contract. ERC-1155's callback exists to prevent tokens from being sent to contracts that cannot process them, which is a relevant safety concern in open marketplaces. In a closed-loop DeFi protocol where the only recipients are known smart contracts, the callback adds cost without adding safety. ERC-6909 moves the safety responsibility to the application layer, which is appropriate for that context.
​

The ERC-6909 interface ID is 0x0f632fb3, calculated from the XOR of the function selectors for all seven mandatory functions. A contract can expose this via supportsInterface(bytes4) following ERC-165, allowing downstream protocols to detect ERC-6909 support onchain without off-chain configuration.
​

Sources and methodology. EIP specification sourced from eips.ethereum.org/EIPS/eip-6909 (created April 19, 2023). Uniswap v4 ERC-6909 integration details from Uniswap v4 developer documentation. Gas comparison figure (5.6x burn cost improvement) from the ETHGlobal project "Uniswap V4 6909." OpenZeppelin Contracts 5.x reference implementation verified at docs.openzeppelin.com. Interface ID 0x0f632fb3 verified against the EIP specification.
​

Eco Routes settles stablecoin transfers across EVM chains including those where Uniswap v4 pools are active. As ERC-6909 claim tokens become a standard way to hold positions inside onchain protocols, cross-chain settlement infrastructure that can net and clear underlying stablecoin obligations connects directly to the settlement mechanics ERC-6909 enables.
​