status-im
/
EIPs
mirror of https://github.com/status-im/EIPs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Automatically merged updates to draft EIP(s) 1155 (#2017) 

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:
Ronan Sandford 2019-05-13 20:51:21 +01:00 committed by EIP Automerge Bot
parent 6b301b54ae
commit da4c47ef2e
1 changed files with 5 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
EIPS/eip-1155.md
View File

@ -189,7 +189,7 @@ interface ERC1155TokenReceiver {
/**
@notice Indicates whether a contract implements the `ERC1155TokenReceiver` functions and so can accept ERC1155 token types.
@dev This function MUST return `bytes4(keccak256("isERC1155TokenReceiver()"))` (i.e. 0x0d912442).
@dev This function MUST return `bytes4(keccak256("isERC1155TokenReceiver()"))` (i.e. 0x0d912442). and MUST not consume more than 5,000 gas.
@return `bytes4(keccak256("isERC1155TokenReceiver()"))`
*/
function isERC1155TokenReceiver() external pure returns (bytes4);
@ -317,7 +317,9 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op
return 0x0d912442; // bytes4(keccak256("isERC1155TokenReceiver()"))
}
```
* The implementation MAY differ from the above but it MUST return the same value.
* The implementation MAY differ from the above but :
- it MUST return the same value.
- it MUST not spend more than 5,000 gas
**_Implementation specific transfer api rules:_**
* If implementation specific api functions are used to transfer 1155 tokens to a contract, the safeTransferFrom, or safeBatchTransferFrom (as appropriate) rules MUST be followed.
@ -333,7 +335,7 @@ To cater for this scenario, there is some leeway with the rejection logic should
Hence in a hybrid 1155 contract implementation an extra call MUST be made on the recipient contract and checked before any hook calls to `onERC1155Received` or `onERC1155BatchReceived` are made.
Order of operation MUST therefore be:
1. The implementation MUST call the function `isERC1155TokenReceiver` on the recipient.
1. The implementation MUST call the function `isERC1155TokenReceiver` on the recipient, providing at least 5,000 gas.
2. If the function call succeeds and the return value is `bytes4(keccak256("isERC1155TokenReceiver()"))` the implementation proceeds as a regular 1155 implementation, with the call(s) to the `onERC1155Received` or `onERC1155BatchReceived` hooks and rules associated.
3. If the function call fails or the return value is NOT `bytes4(keccak256("isERC1155TokenReceiver()"))` the implementation can assume the contract recipient is not an `ERC1155TokenReceiver` and follow its other standard's rules for transfers.