`v2.2/:address/nft/transfers` returns ERC165 as the contract type

[ray]

Get NFT transfers by wallet | Moralis Web3 Documentation

Is it an intended outcome that the contract_type of the NFT Transfer result contains ERC165?
I think it would be intuitive to only include ERC721, ERC1155 in that field.

[johnversus]

Hi @ray, ERC165 is a valid contract standard. So it is expected to be in the resposne.

[ray]

Thanks for the reply @johnversus.
Yes, of course it is a contract standard, but I don’t know if it should be included in the NFT Transfer result.
If the contract has implemented ERC-721 and ERC-165, I think showing ERC-721 is the correct result.

[johnversus]

Thanks for the response.

Do you know how we can test and verify that? If there is any documentation I can share it with the API team.

[ray]

{
  "block_number": "23431445",
  "block_timestamp": "2022-11-28T00:47:38.000Z",
  "block_hash": "0xdaa82b9e3c7f1a8b1e8205f8954b4431a50af93db247279103d5197fc9714f36",
  "transaction_hash": "0x09fcf7add5bb80696a0a34e19910fab0e870b6052c0147a59614506bb79a47ef",
  "transaction_index": 10,
  "log_index": 20,
  "value": "5717977414434480582",
  "contract_type": "ERC165",
  "transaction_type": "Single",
  "token_address": "0x2223bf1d7c19ef7c06dab88938ec7b85952ccd89",
  "token_id": "5717977414434480582",
  "from_address": "0x4f76093a28655c8329295eae352d21fd2e27ca4b",
  "from_address_label": null,
  "to_address": "0x70ba719600d51215d3c2b14dcfa986b557a39b96",
  "to_address_label": null,
  "amount": "1",
  "verified": 1,
  "operator": null,
  "possible_spam": false,
  "verified_collection": false
}

The result above is one of the results of the v2.2/:address/nft/transfers API request I posted in my original post.
If you enter BNB explorer with that transaction hash value, the event is shown below.

If you go into the CA information, you’ll see that the contract implements ERC-20 and ERC-165.
This means that an ERC-20 transfer is being delivered for an ERC-721 transfer, and the status of the token_id, amount, and value in the API results are also strange.

[johnversus]

It seems that bscscan does not necessarily show the correct contract type. For instance bscscan shows erc721A contract as erc20.

The contract interface is not purely a standard ERC20 so using ERC-165 is a better way to identify it. Since this can be combined with ERC20 too.

[ray]

Thanks for your research!
If ERC-165 is passed as a result of the nft/transfers API, does the caller need to check if it is ERC-20, ERC-721, or ERC-1155? If it was a /:address/transfers API, it would make some sense, but I think it would be better to pass an unambiguous contract type.

[johnversus]

What would be the use case for checking this🤔

[ray]

When implementing an EVM-based wallet, there are separate tabs for held tokens and held NFTs. Because these are separate APIs, each call has completely separate logic implemented to handle tokens and NFTs.
Imagine calling the NFT transfer API to get an ERC-165, then checking the contract’s standard directly to get an ERC-20. All you can do is ignore it, and that’s why I think it’s better to categorize them in the Moralis API.

[johnversus]

Ahh ok Thanks. I can share this with the team as a feature request