# Sending an NFT to a contract: why safe transfers can fail

ERC-721 safeTransferFrom checks whether a contract recipient implements the required receiver response; otherwise the transfer reverts. ERC-1155 has corresponding receiver rules. “Safe” describes this contract-compatibility check. It does not confirm the recipient’s identity, promise the NFT can later be withdrawn or protect against sending to the wrong ordinary account.

Evidence: [ERC-721 NFT standard](https://eips.ethereum.org/EIPS/eip-721); [ERC-1155 multi-token standard](https://eips.ethereum.org/EIPS/eip-1155)

Canonical: https://degreesofsatoshi.com/encyclopedia/nft-safe-transfers/
Published: 2026-10-02
Substantively modified: 2026-10-02
Independently verified by an automated reviewer: 2026-10-02T19:27:58.939Z
Data current through: 2026-10-02

AI-assisted research and drafting with a separate automated source-verification pass; no external expert or named human review is implied.

## Key facts

- **ERC-721 hook:** A contract recipient must return the expected onERC721Received response. ([ERC-721 NFT standard](https://eips.ethereum.org/EIPS/eip-721))
- **ERC-1155 hook:** Single and batch transfers use corresponding receiver callbacks. ([ERC-1155 multi-token standard](https://eips.ethereum.org/EIPS/eip-1155))
- **Identity:** The receiver check concerns contract behavior, not a person’s identity. ([ERC-721 NFT standard](https://eips.ethereum.org/EIPS/eip-721))

## A contract needs a way to acknowledge receipt

Contracts can receive assets without having a useful way to manage them. The safe-transfer interfaces require an appropriate receiver response when the destination is a contract under the standard’s rules. A missing or incorrect response causes the transfer to revert.

ERC-721’s plain transferFrom lacks this receiver handshake. Choosing it to bypass an error can leave the token at a contract that cannot return it.

Evidence: [ERC-721 NFT standard](https://eips.ethereum.org/EIPS/eip-721); [ERC-1155 multi-token standard](https://eips.ethereum.org/EIPS/eip-1155)

## A treasury must support the token standard

Imagine sending an ERC-721 token to a treasury contract that accepts ERC-1155 callbacks but has no ERC-721 receiver implementation. The ERC-721 safe transfer can fail even though the treasury handles other NFTs.

The useful next check is the treasury’s supported receipt and withdrawal behavior, not trying a less protective transfer method.

Evidence: [ERC-721 NFT standard](https://eips.ethereum.org/EIPS/eip-721); [ERC-1155 multi-token standard](https://eips.ethereum.org/EIPS/eip-1155)

## Accepted does not mean recoverable

A contract can return the receiver response while applying restrictive or malicious logic. A successful handshake therefore does not prove the intended owner can withdraw the NFT later.

For an ordinary account, safe transfer does not check whether you typed the intended person’s address. Verify chain, recipient, collection and token ID before signing.

Evidence: [ERC-721 NFT standard](https://eips.ethereum.org/EIPS/eip-721)

## Questions

### Can a safe transfer to the wrong ordinary address still succeed?

Yes. The standard’s special receiver check is for contract compatibility. It does not establish that the address belongs to your intended recipient.

Evidence: [ERC-721 NFT standard](https://eips.ethereum.org/EIPS/eip-721)

### Should I use transferFrom when safeTransferFrom fails?

First determine why the recipient rejected the token. Bypassing the receiver check can place the NFT in a contract with no usable recovery path.

Evidence: [ERC-721 NFT standard](https://eips.ethereum.org/EIPS/eip-721)

## Claims and scope

### nft-safe-transfers-quick-answer

ERC-721 safeTransferFrom checks whether a contract recipient implements the required receiver response; otherwise the transfer reverts. ERC-1155 has corresponding receiver rules. “Safe” describes this contract-compatibility check. It does not confirm the recipient’s identity, promise the NFT can later be withdrawn or protect against sending to the wrong ordinary account.

Scope: {"collection":"ethereum","dataAsOf":"2026-10-02","blockHeight":null}

### nft-safe-transfers-fact-erc-721-hook

ERC-721 hook: A contract recipient must return the expected onERC721Received response.

Scope: {"collection":"ethereum","dataAsOf":"2026-10-02","blockHeight":null}

### nft-safe-transfers-fact-erc-1155-hook

ERC-1155 hook: Single and batch transfers use corresponding receiver callbacks.

Scope: {"collection":"ethereum","dataAsOf":"2026-10-02","blockHeight":null}

### nft-safe-transfers-fact-identity

Identity: The receiver check concerns contract behavior, not a person’s identity.

Scope: {"collection":"ethereum","dataAsOf":"2026-10-02","blockHeight":null}

## Sources

- [ERC-721 NFT standard](https://eips.ethereum.org/EIPS/eip-721) — Ethereum Improvement Proposals. Ownership, receiver checks, token-level and operator approvals, mint/burn event semantics. Locator: safeTransferFrom; approve; setApprovalForAll; Transfer; metadata. Retrieved: 2026-10-02T18:55:25.399Z.
- [ERC-1155 multi-token standard](https://eips.ethereum.org/EIPS/eip-1155) — Ethereum Improvement Proposals. Receiver acceptance, collection-wide operators, balance accounting and burn events. Locator: Safe transfer rules; operator approvals; minting and burning. Retrieved: 2026-10-02T18:55:25.400Z.

## Revision history

- 2026-10-02: First publication after primary-source research and separate automated verification.

## Cite this entry

Degrees of Satoshi editorial project. “Sending an NFT to a contract: why safe transfers can fail.” Published 2026-10-02; updated 2026-10-02. https://degreesofsatoshi.com/encyclopedia/nft-safe-transfers/