Safe Transfer Explained in Detail
Safe transfer checks contract recipients before completing an NFT transfer. For ERC721 and ERC1155, the recipient contract must return the expected receiver selector.
This prevents accidental transfers to contracts that cannot handle the token, but it also introduces an external call.
Smart contract example
safeTransferFrom(from, to, tokenId);
If to is a contract, it must accept the transfer through the correct hook.
Safe Transfer in Auditing
Safe transfer combines authorization, state updates, event emission, and external callback logic. That combination is a common source of reentrancy bugs.
Auditors check the order of state updates and receiver calls.
Red flags in code
-
Receiver hook return value is ignored.
-
The hook is called before ownership or balances are updated.
-
Unsafe transfer is used for contract recipients without reason.
-
Reentrant receivers can call mint, transfer, claim, or withdraw.
-
ERC721 and ERC1155 selectors are confused.
How to test or review it
-
Transfer to an EOA, accepting contract, rejecting contract, and reverting contract.
-
Test receiver hooks that return the wrong selector.
-
Build a receiver that reenters during transfer.
-
Check checks-effects-interactions around transfer state.
-
Confirm unauthorized senders cannot trigger safe transfers.
Keep learning this topic
safeTransferFrom
safeTransferFrom is the ERC721 and ERC1155 transfer function that moves tokens and checks recipient contract acceptance.
onERC721Received
onERC721Received is the ERC721 receiver hook that a contract must implement to accept safe ERC721 transfers.
onERC1155Received
onERC1155Received is the ERC1155 receiver hook called when a contract receives a single ERC1155 token transfer.
Practice this in real audit scenarios
Definitions help, but auditors need reps. SCH turns concepts like Safe Transfer into exploit labs, code review habits, and report-writing practice.
Start the free trial or see the full smart contract auditing course.