ERC6909 Explained in Detail
ERC6909 defines a minimal multi-token model. One contract can hold many token IDs, and each ID can have its own balances and allowances.
It is similar in purpose to ERC1155, but it avoids required receiver callbacks and batch-transfer semantics.
Smart contract example
allowance[owner][spender][id];
isOperator[owner][spender];
ERC6909 combines per-ID allowances with global operator approvals.
ERC6909 in Auditing
ERC6909 authorization is easy to get subtly wrong. A spender may have permission for one token ID, all token IDs, or no token IDs, depending on allowance and operator state.
Auditors trace each transfer path by token ID, caller, owner, spender, and operator.
Red flags in code
-
transferortransferFromdoes not returntrue. -
Allowance is decremented for owners, operators, or infinite allowance cases incorrectly.
-
Operator approval applies more broadly than intended.
-
ERC165 support for the ERC6909 interface is missing or wrong.
-
Integrations assume ERC1155 receiver hooks or batch behavior.
How to test or review it
-
Test owner transfers, approved spender transfers, operator transfers, and revoked operators.
-
Fuzz token ID, amount, owner, spender, and operator combinations.
-
Check per-ID supply, balance, allowance, and event behavior.
-
Verify supportsInterface answers.
-
Review mint and burn access control per token ID.
Keep learning this topic
ERC1155
ERC1155 is a multi-token standard that supports many fungible and non-fungible token IDs in one contract.
ERC165
ERC165 is the Ethereum standard for interface detection through supportsInterface(bytes4).
Allowance
Allowance is the ERC20 amount an owner permits a spender to transfer from the owner's balance through transferFrom.
Practice this in real audit scenarios
Definitions help, but auditors need reps. SCH turns concepts like ERC6909 into exploit labs, code review habits, and report-writing practice.
Start the free trial or see the full smart contract auditing course.