Transaction decoding: ERC-721 Non-fungible tokens

Consensys / ethql

A GraphQL interface to Ethereum :fire:

Apache License 2.0

623 stars 85 forks source link

Transaction decoding: ERC-721 Non-fungible tokens #33

Open raulk opened 6 years ago

raulk commented 6 years ago

Add support for decoding ERC-721 transactions.

[x] Import the ABI into the abi directory. Make sure the JSON is formatted.
[x] That ABI does not come from an official source, so check it against the expected interface.
[ ] Identify decodable transaction types, and start a discussion in this ticket. For each TX type, indicate the proposed fields and data types. Let's reach team consensus around our understanding.
[ ] Implement the decoding of each transaction type, as well as associated queries (e.g. symbol, token supply, etc.)

jonathan-buhler commented 6 years ago

From the expected interface of ERC-721:

safeTransferFrom: sender(address), from (address), to (address), tokenID (Int) and perhaps data (bytes, but not sure how GraphQL handles those)
transferFrom: sender (address), from (address), to (address), tokenID (Int)
approve: sender (address), approved (address), tokenID (Int)
setApprovalForAll: sender (address) operator (address), approved (Boolean)

raulk commented 6 years ago

LGTM. bytes can be returned as hex strings.

raulk commented 6 years ago

@jonathanBuhler Could you update this ticket with your findings and the blockers you're facing?

jonathan-buhler commented 6 years ago

Due to similarities in the ERC721 and ERC20 token, our current decoding system marks both as ERC20. Raul suggested using ERC165 to identify which interface the token implements, but I was not able to make much headway in that regard. This is the pull request in my own fork of the code as it currently stands.

For the most part my attempts to decode ERC721 mirrored the current implementation for ERC20, but with added fields for where 721 had functionality that 20 did not (setApprovalForAll, safeTransferFrom).