status-im/EIPs
2
0
Fork 0
mirror of https://github.com/status-im/EIPs.git synced 2025-01-14 17:04:11 +00:00
Code Issues Projects Releases Wiki Activity

Automatically merged updates to draft EIP(s) 721

Browse Source 
Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing
This commit is contained in:
Maciej Górski 2018-06-18 21:22:59 +02:00 committed by EIP Automerge Bot
parent b582c6579b
commit ac657ad49b
1 changed files with 4 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
EIPS/eip-721.md
View File

@ -156,6 +156,8 @@ A wallet/broker/auction application MUST implement the **wallet interface** if i
```solidity
/// @dev Note: the ERC-165 identifier for this interface is 0xf0b9e5ba
/// @dev Note: the application will get the prior owner of the token
/// via _from parameter -- but it will NOT see who called safeTransferFrom.
interface ERC721TokenReceiver {
/// @notice Handle the receipt of an NFT
/// @dev The ERC721 smart contract calls this function on the recipient
@ -295,6 +297,8 @@ Failed transactions will throw, a best practice identified in ERC-223, ERC-677,
Creating of NFTs ("minting") and destruction NFTs ("burning") is not included in the specification. Your contract may implement these by other means. Please see the `event` documentation for your responsibilities when creating or destroying NFTs.
We considered adding an operator parameter to `onERC721Received`. This would allow you be to approved for a token and then send it to a wallet/broken/auction application, then that application could recognize you as the one that sent it. Instead, we opted to not add an operator parameter. If you want to take a token from somebody else and send it to these applications on your behalf then you should use two transactions. People writing wallet/broken/auction should recognize that the from address they receive is the previous token owner from the perspective of the ERC-721 contract. Those applications may have a different concept of ownership (beneficial ownership) that they need to consider.
*Alternatives considered: only allow two-step ERC-20 style transaction, require that transfer functions never throw, require all functions to return a boolean indicating the success of the operation.*
**ERC-165 Interface**