ERC-6909 is a minimal multi-token standard: like ERC-1155, one contract tracks balances for many token IDs, but it removes mandatory receiver callbacks and batch functions, and adds ERC-20-style per-ID allowances alongside operators. The result is simpler, cheaper code with fewer re-entrancy concerns — attractive for protocols that manage many assets internally and for high-volume tokenized units.
Key takeaways
- Functions:
balanceOf(owner, id),allowance(owner, spender, id),isOperator(owner, spender),transfer,transferFrom,approve,setOperator. - No callbacks — transfers to contracts do not call
onReceivedhooks, removing a re-entrancy vector (and the safety check against lost tokens). - Granular approvals per ID plus all-ID operators.
- Supported by ERC-7943’s multi-token interface, so RWA compliance can be layered on top.
ERC-6909 vs ERC-1155
| Feature | ERC-1155 | ERC-6909 |
|---|---|---|
| Many IDs per contract | ✔ | ✔ |
| Receiver callbacks | Required for “safe” transfers | None |
| Batch transfers | Native | Not in spec (can be added) |
| Per-ID allowances | No | Yes |
| Operators | Yes | Yes |
| Metadata URI | Required pattern | Optional extensions |
| Gas & code size | Higher | Lower |
Where it fits
- Protocol accounting — DEXs and lending markets tracking claims for many assets.
- High-volume units — energy, carbon or loyalty units where callbacks add cost but little value.
- Internal ledgers for tokenization platforms where users interact via the platform rather than arbitrary contracts.
Where ERC-1155 may be better
- You need broad wallet and marketplace support today.
- You want batch transfers natively.
- You rely on receiver hooks to prevent tokens being sent to contracts that cannot handle them.
Compliance for RWAs
Like ERC-1155, ERC-6909 has no compliance features. Implement eligibility checks in transfer paths and expose canTransfer / freezing via ERC-7943’s multi-token interface for interoperability.
Interface at a glance
interface IERC6909 {
event Transfer(address caller, address indexed sender, address indexed receiver, uint256 indexed id, uint256 amount);
event OperatorSet(address indexed owner, address indexed spender, bool approved);
event Approval(address indexed owner, address indexed spender, uint256 indexed id, uint256 amount);
function balanceOf(address owner, uint256 id) external view returns (uint256);
function allowance(address owner, address spender, uint256 id) external view returns (uint256);
function isOperator(address owner, address spender) external view returns (bool);
function transfer(address receiver, uint256 id, uint256 amount) external returns (bool);
function transferFrom(address sender, address receiver, uint256 id, uint256 amount) external returns (bool);
function approve(address spender, uint256 id, uint256 amount) external returns (bool);
function setOperator(address spender, bool approved) external returns (bool);
}
Why granular approvals matter for financial assets
With ERC-1155, approving a marketplace means approving every token ID you hold. ERC-6909’s per-ID allowances let an investor approve a settlement contract to move exactly 1,000 units of carbon vintage 2025 — and nothing else. For regulated portfolios, that least-privilege model is a meaningful security improvement.
Example use: energy units without callbacks
In a high-frequency energy platform, minting and burning units per reading generates enormous volumes. Removing receiver callbacks avoids external calls on every mint and simplifies re-entrancy analysis. Where we used ERC-1155 for electricity tokens, ERC-6909 would be a reasonable alternative for internal settlement units that never leave the platform.
Frequently asked questions
It is an alternative optimised for simplicity and gas. ERC-1155 remains better supported by wallets and marketplaces.
Callbacks add gas and create re-entrancy risk. Many protocols do not need them.
Yes — an ID with a supply of one behaves as a non-fungible token, though NFT tooling is oriented to ERC-721/1155.
Not natively; add restrictions in your implementation or adopt the ERC-7943 interface.
Not in the core interface; implementations can add them as extensions.
Through optional metadata and content-URI extensions, or by publishing metadata off-chain keyed by ID.
NUVZ is the RWA and Web3 engineering brand of ESS ENN Associates (est. 1993). Our team has designed and shipped tokenization platforms for real estate, education loans, solar PPAs, energy, carbon credits, bank deposits and trade documents. About us · Case studies
This article is for general information only and is not legal, tax or investment advice. Token standards evolve — always confirm the current status of an ERC at eips.ethereum.org and take advice from qualified counsel in each jurisdiction before issuing tokens.
