ERC1155 Explained in Detail
ERC1155 uses token IDs with per-ID balances. One ID can behave like a fungible token, another can behave like a unique NFT, and both can live in the same contract.
The standard also supports batch operations. Batch transfers are useful, but they create extra validation requirements around array lengths, duplicate IDs, receiver hooks, and per-ID accounting.
Smart contract example
function safeBatchTransferFrom(
address from,
address to,
uint256[] calldata ids,
uint256[] calldata amounts,
bytes calldata data
) external;
ids.length and amounts.length must match, and each token ID must update the correct balance.
ERC1155 in Auditing
ERC1155 contracts combine token accounting, operator approvals, batch loops, and receiver callbacks. A bug in one ID or one array element can affect many assets at once.
Auditors review ERC1155 transfers as both accounting code and external call code because safe transfers call receiver hooks on contracts.
Red flags in code
-
Batch transfer arrays are not length-checked.
-
Duplicate IDs in a batch break accounting assumptions.
-
Operator approvals are treated as per-token approvals.
-
Receiver hook return values are ignored.
-
Mint and burn events do not match balance changes.
How to test or review it
-
Test single and batch mint, transfer, and burn flows.
-
Use mismatched arrays, empty arrays, duplicate IDs, and large batches.
-
Transfer to accepting, rejecting, reverting, and reentrant receivers.
-
Check unauthorized operator transfers.
-
Assert per-ID total supply or balance invariants if the contract tracks supply.