Facilitating Seamless HTS Token Operations via EVM-Level IERC-20/721 Redirects

[mshakeg]

Summary

This proposal recommends an approach to enhance interaction with Hedera Token Service (HTS) tokens by modifying the Hedera EVM. It suggests that standard IERC20 and IERC721 function calls made to an adminKey contract should be directly interpreted as calls to its associated HTS token, under specific conditions outlined in this proposal.

Background

Interacting with contract-created HTS tokens in the current Hedera ecosystem often involves dealing with two distinct entity ids or addresses namely the contract that created an HTS token and the HTS token itself. This is particularly evident in cases where contracts, like a WHBAR contract(that also creates a WHBAR HTS token), implement additional functionalities not part of the standard ERC20/721 interfaces. This proposal aims to streamline these interactions, making the process more efficient and intuitive, akin to the seamless interactions observed on Ethereum.

Proposed Solution

The key proposition is to modify the Hedera EVM to automatically redirect IERC20/721 function calls (such as approve, transfer, transferFrom) made to an admin contract of an HTS token to the HTS token itself. This redirection will be activated under the following conditions:

1. The target contract is designated as an adminKey for an HTS token.
2. The HTS token is created with the enableAdminAsProxy flag set to true, a proposed addition to HTS tokens for this functionality.

This one-to-one relationship between the adminKey contract and the HTS token ensures that each IERC20/721 call can be redirected unambiguously to a single HTS token.

Example Use Case

Consider a WHBAR contract that creates a WHBAR HTS token and implements additional functions like deposit and withdraw. Under the current system, developers interact with the contract for these specific functions and with the HTS token for standard IERC20/721 functions. With the proposed solution, all interactions from the perspective of the user/developer, including standard ERC functions, would be directed to the WHBAR contract, but internally IERC20/721 calls would be redirected to the associated HTS token.

Technical Implementation

The implementation involves modifying the call handling mechanism of the Hedera EVM. When a standard ERC function call is detected on a contract that is an adminKey with enableAdminAsProxy enabled, the EVM will redirect this call to the associated HTS token.

Broader Ecosystem Impact

This change will apply only to new HTS tokens where the enableAdminAsProxy flag is set to true at token creation. Existing tokens, which will have this flag effectively set to false, will continue to operate under the current system. This ensures backward compatibility while offering enhanced functionality for future tokens.

Conclusion

This proposal aims to significantly improve the developer and user experience in the Hedera ecosystem by simplifying HTS token interactions. The introduction of the enableAdminAsProxy flag, along with the proposed EVM modifications, will allow for a more intuitive and efficient interaction model, closely aligning with established practices in typical EVM environments.

[Nana-EC]

Thanks for submission @mshakeg.
Starting up the new year and hoping to dig into this soon.
Thanks