proposal: New HIP to augment HIP-218 to stipulate EIP-165 for HTS FungibleUnique tokens

[bguiz]

🤔 I see that EIP-721 specifies that EIP-165 should be implemented too:

function supportsInterface(bytes4 interfaceID) external view returns (bool);

... but HIP-218 does not for some reason.

❓ Is this omission intentional?

• I don't see this referenced under the "rejected ideas" or "backwards compatibility" sections.
• or is there another HIP which specifies this?

❓ regardless of mention/ non-mention in the HIP, is it implemented in HSCS/HTS?

[david-bakin-sl]

Should consider for all of HTS and HAS as well. Would be another approach to our issues with "versioning" our system contracts.

I wonder what the tool support is? (For example, given a (deployed) contract address and some method you want to call on an interface, will a tool check for you that that contract implements that interface?). And/or: Will a tool generate the supportsInterface method for you and keep it up-to-date?

[david-bakin-sl]

Ah, thank you for the clarification. Yes, it is independently valuable for specifically answering YES to EIP-20/-721.

[Nana-EC]

@bguiz thanks for the suggestion, are you proposing a smart contract should be able to call <evmAddressofHTSToken>.supportsInterface(erc721InterfaceID) i.e. 0x00....x.(0x80ac58cd) and the result should be

• true if there's a valid NFT token at that address
• false for all other cases?

Note, I left out ERC20 as there's no official interfaceID as it preceded EIP165. I'm not aware of ERC20's supporting this.

The implementation would be fairly straightforward in this case, which is to return the hardcoded signature/hash for EIP-20 ABI or EIP-721 ABI (when the redirect facade maps to HTS FungibleCommon and HTS NonFungibleUnique respectively).

This note is unclear as it seems like you're proposing a method signature different from EIP 165.
This seems like a suggestion on the IHTS system contract interface vs a face to expose ERC20/ERC721 methods on an HTS token.
Can you clarify this and maybe the smart contract flow you're referring to - maybe share a single function that shows how you expect usage.

[bguiz]

are you proposing a smart contract should be able to call

precisely!

[bguiz]

Note, I left out ERC20 as there's no official interfaceID as it preceded EIP165. I'm not aware of ERC20's supporting this.

Just double checked and the original ERC20 standard predates EIP-165, and has not been retrospectively updated to include it.

I also checked the OZ impl of ERC20,
which is one of the most popular ones in use out there, and that omits EIP-165 too.
Notably the OZ impl of ERC721
does explicitly include EIP-165 as part of its interface.

Keeping the above in mind, I'd say it is OK to update the facade redirect in HSCS for HTS NonFungibleUnique to include EIP-165,
but leave the HTS FungibleCommon ones as it is now.

[bguiz]

This note is unclear as it seems like you're proposing a method signature different from EIP 165.
This seems like a suggestion on the IHTS system contract interface vs a face to expose ERC20/ERC721 methods on an HTS token.
Can you clarify this and maybe the smart contract flow you're referring to - maybe share a single function that shows how you expect usage.

Just to be clear, this proposal is exactly what you have summarised here:

call .supportsInterface(erc721InterfaceID) i.e. 0x00....x.(0x80ac58cd) and the result should be
true if there's a valid NFT token at that address
false for all other cases?

My comment there was about EIP-165 in the broader context, which @david-bakin-sl discusses in his comments. That would only be related to in the context of forward compatibility (and I make the point that EIP-165 has already thought of this, and has a solution for it).. However, it is not relevant this specific context.