Normal behavior: Marketplaces should transfer NFTs with safeTransferFrom so that, when the recipient is a contract, the call reverts unless it implements IERC721Receiver. This prevents NFTs from becoming stuck in contracts that can’t handle ERC-721.
Issue: Both settlement and unlisting use plain transferFrom(...). Transfers to contracts without onERC721Received succeed silently, assigning ownership to an address that may not expose any method to move the NFT, effectively bricking the asset.
Likelihood:
Occurs whenever the recipient is a contract without onERC721Received (common for minimal wallets, proxy-less test contracts, or third-party integrations).
Impact:
Asset lock/bricking: NFT ownership moves to a contract that cannot forward/operate it.
Operational breakage: Users cannot reclaim or resell; support burden and reputational risk.
Goal: Show that selling/unlisting to a non-receiver contract “succeeds” yet leaves the NFT stuck.
Explanation: Pre-fix, transferFrom happily moves the NFT to NonReceiver. Because the contract cannot receive (no hook) and exposes no method to forward, the asset is stuck. With safeTransferFrom, the transaction would revert, protecting users.
safeTransferFrom will revert when the recipient is a contract without onERC721Received, preventing accidental bricking.
No interface changes; settlement/unlist will fail fast in unsafe scenarios, keeping user assets safe.
If you intentionally allow raw transferFrom only to EOAs, add a guard:
require(to.code.length == 0, "recipient contract must implement IERC721Receiver"); (but safeTransferFrom is the standard, safer default).
Non-safe transferFrom calls can send NFTs to non-compliant contracts, potentially locking them permanently.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.