cryptoTransfer support for erc20 & erc721 tokens

[se7enarianelabs]

Problem

Currently, Hedera allows developers to treat HTS tokens as ERC20 and ERC721 tokens in smart contracts thanks to HIP-218. This has enabled us to port EVM contracts and support HTS tokens out-of-the-box.

Previously, supporting NFT royalty fees in NFT marketplaces was challenging. Consider this pseudocode:

erc721.transferFrom(_from, _to, serialNumber)
_to.call{value: msg.value}("");

This allows for a non-custodial NFT marketplace. However, from Hedera's perspective, we have one parent Ethereum transaction and within it, two child Ethereum transactions (for erc721.transferFrom and _to.call). NFT royalty fees are only applied if the NFT and value are exchanged in the same Hedera "child" transaction, so in our pseudocode, only NFT fallback fees will be applied.

With the upcoming support for HBAR allowance in cryptoTransfer, we will be able to support NFT royalty fees. This will require checking if the settlement involves HTS NFTs for HBAR and using cryptoTransfer with allowances. For any settlement involving ERC20 or ERC721 tokens, we still need to use the standard EVM method, as cryptoTransfer does not support "ERC" tokens.

Example:

// Check if HTS NFT and (HTS FT or HBAR) is part of the settlement
if (isToken(erc721) && (isToken(erc20) || erc20 == "0x")) {
    // Call crypto transfer
} else {
    erc721.transferFrom(_from, _to, serialNumber);
    _to.call{value: msg.value}("");
}

Currently, if we do not want to support NFT royalty fees, EVM developers can port existing NFT marketplace Solidity contracts. If they want a custom marketplace exclusively for HTS tokens, they can use cryptoTransfer. However, to support both ERC and HTS tokens with NFT royalty fees, they need to use both the Ethereum method and cryptoTransfer.

Solution

Our proposal is to implement something like cryptoTransferWithERCSupport, which would have the same interface as cryptoTransfer but would check if the addresses provided as parameters are HTS/HBAR or ERC. If they are ERC, it would redirect to the ERC contract implementation, similar to the redirectForToken mechanism in HIP-218.

Alternatives

No response