# hidden ERC standard callbacks create reentrancy surface developers do not recognize as hookable The classic reentrancy mental model focuses on explicit external calls like `address.call{value: x}("")`. This model fails when the external call is embedded inside a standard library function. The developer thinks "I am minting tokens," not "I am making an external call," while the ERC specification mandates a callback into an attacker-controlled address before returning. Three ERC standards create this hidden surface. ERC-721's `safeTransferFrom` calls `onERC721Received`. ERC-777's `transfer`/`transferFrom` call `tokensReceived` on registered hooks. ERC-1155's `_mintBatch` and `safeTransferFrom` call `onERC1155BatchReceived`. In every case, the callback fires before the function returns, so any state write after the library call is unsettled when the attacker's hook runs. The audit heuristic: whenever a function calls any ERC operation accepting a recipient address, ask "does this standard require a callback?" If yes, treat it identically to an explicit external call. Since [[checks-effects-interactions pattern prevents reentrancy by updating state before external calls]], state must be fully settled before the callback fires. Since [[reentrancy is possible whenever external calls precede state updates]] captures the underlying principle, this note adds the surface where developers systematically miss it. The Hypercerts finding ([[ERC-1155 mintBatch callback creates reentrancy before valueLeft storage write enabling unlimited token fraction splitting]]) illustrates how a library call becomes the reentrancy entry point. Within [[reentrancy variant evolution outpaces defense adoption because each variant exploits a different assumption about where external calls occur]], this generalizes variant 6 across all callback-bearing standards. The cognitive failure matches [[developer subconscious assumptions about prior state create systematic input validation gaps auditors must explicitly hunt]]. ERC-777 deepens the risk: since [[ERC-777 arbitrary hook assignment via ERC-1820 registry enables attacker-controlled callbacks on victim contracts]], attackers can forcibly register hooks through a separate registry transaction. Since [[ERC-777 tokensToSend hook enables pre-transfer reentrancy by executing attacker-controlled code before the sender balance is debited]], the pre-debit hook catches protocols that correctly implement CEI for post-credit callbacks. Relevant Notes: - [[reentrancy is possible whenever external calls precede state updates]]: the parent pattern this extends with the hidden-callback dimension - [[checks-effects-interactions pattern prevents reentrancy by updating state before external calls]]: the defense: apply CEI treating implicit ERC callbacks identically to explicit external calls - [[ERC-1155 mintBatch callback creates reentrancy before valueLeft storage write enabling unlimited token fraction splitting]]: concrete ERC-1155 example - [[ERC-721 safeTransferFrom and ERC-777 tokensReceived callbacks create reentrancy entry points in any protocol handling these token standards]]: sibling: ERC-721 and ERC-777 post-credit examples - [[reentrancy variant evolution outpaces defense adoption because each variant exploits a different assumption about where external calls occur]]: contextualizes this pattern as variant 6 in the reentrancy taxonomy - [[developer subconscious assumptions about prior state create systematic input validation gaps auditors must explicitly hunt]]: the cognitive failure this pattern exploits: "minting" not recognized as "external call" - [[ERC-777 arbitrary hook assignment via ERC-1820 registry enables attacker-controlled callbacks on victim contracts]]: escalation: attacker can forcibly register hooks, making the hidden callback surface attacker-controlled - [[ERC-777 tokensToSend hook enables pre-transfer reentrancy by executing attacker-controlled code before the sender balance is debited]]: extends: pre-debit direction creates hidden callback in opposite timing, bypassing CEI designed for post-credit Topics: - [[vulnerability-patterns]]