Automatically merged updates to draft EIP(s) 998

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:
Nick Mudge 2018-08-14 09:12:04 -07:00 committed by EIP Automerge Bot
parent e4eac92a06
commit a14968b64e
1 changed files with 26 additions and 0 deletions

View File

@ -90,6 +90,32 @@ The rootOwner of a composable is gotten by calling `rootOwnerOf(uint256 _tokenId
ERC998ERC721 top-down and bottom-up composables are interoperable with each other. It is possible for a top-down composable to own a bottom-up composable or for a top-down composable to own an ERC721 token that owns a bottom-up token. In any configuration calling `rootOwnerOf(uint256 _tokenID)` on a composable will return the root owner address at the top of the ownership tree.
It is important to get the traversal logic of `rootOwnerOf` right. The logic for `rootOwnerOf` is the same whether or not a composable is bottom-up or top-down or both.
Here is the logic:
```
Logic for rootOwnerOf(uint256 _tokenId)
If the token is a bottom-up composable and has a parent token then call rootOwnerOf for the parent token.
If the call was successful then the returned address is the rootOwner.
Otherwise call rootOwnerOfChild for the parent token.
If the call was successful then the returned address is the rootOwner.
Otherwise get the owner address of the token and that is the rootOwner.
Otherwise call rootOwnerOfChild for the token
If the call was successful then the returned address is the rootOwner.
Otherwise get the owner address of the token and that is the rootOwner.
```
Calling `rootOwnerOfChild` for a token means the following logic:
```solidity
// Logic for calling rootOwnerOfChild for a tokenId
address tokenOwner = ownerOf(tokenId);
address childContract = address(this);
bytes32 rootOwner = ERC998ERC721(tokenOwner).rootOwnerOfChild(childContract, tokenId);
```
But understand that the real call to `rootOwnerOfChild` should be made with assembly so that the code can check if the call failed and so that the `staticcall` opcode is used to ensure that no state is modified.
Tokens/contracts that implement the above authentication and traversal functionality are "composable aware".
### Composable Transfer Function Parameter Format