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

[Nana-EC]

Hey @mshakeg , late on the response here.
Pretty cool idea, thanks for writing this up.

Firstly, would you say the devexp is still challenging here and the suggestion still desired?
If so could you expand more on the developer and user experience challenges so we have a better understanding.
I see the improvement but I want to clarify any current technical blockers or flow inefficiencies.

Secondly, my understanding of the proposal is that for any IERC20/721 method applicable calls to contractA, if contractA is listed as the admin on tokenB and enableAdminAsProxy on tokenB is true, then the system would execute the IERC20/721 method on tokenB?
Is that correct?
Example using the approval flow

• User submits a EthereumTransaction/ContractCall transaction submission to <contractAAddress>.approve(address token, address spender, uint256 amount)
• Assuming satisfying details
• HSCS logic would skip any contractA code content execution
• HSCS logic would execute a child CryptoApproveAllowance transaction?

If so is this not functionally the same as if contractA had implemented the same IERC20/721 methods and in those methods called the system contracts functions that expose IERC20/721 method on HTS tokens?

[mshakeg]

Hey @Nana-EC, better late than never! :)

---

Firstly, would you say the dev experience is still challenging here and the suggestion still desired?

Not really challenging, just a pain point, especially for developers porting over from EVM chains where the contract and the token are one and the same.

---

Your understanding of the proposal is correct.

---

If so, is this not functionally the same as if ContractA had implemented the same IERC20/721 methods and in those methods called the system contracts functions that expose IERC20/721 methods on HTS tokens?

I don't fully follow. Are you suggesting that the admin contract (i.e., ContractA) implements all IERC20/721 functions, such as IERC20.approve(address spender, uint256 amount), which then delegatecalls to IHederaTokenService.approve(address token, address spender, uint256 amount) as shown below? This approach would leak the msg.sender from ContractA.approve() to the HTS_SYSTEM_CONTRACT.

If so, this might work if the system contract can determine who performed the delegatecall to ensure that the delegatecaller is the admin for the specified tokenId. This might be feasible since it's a system contract, but it wouldn't be possible with an EVM contract, as there's no secure way (to my knowledge) for the contract being delegatecalled to determine who the delegatecaller is.

In any case, I don't favor this approach as it would require duplicating the same boilerplate code that implements these IERC20 -> delegatecall HTS_SYSTEM_CONTRACT functions for contracts like ContractA to inherit. This is in contrast to a simple enableAdminAsProxy flag, which the HSCS neatly handles under the hood.

contract ContractA is IERC20 {

    address public immutable TOKEN_ID;
    IHederaTokenService private constant HTS_SYSTEM_CONTRACT = IHederaTokenService(address(0x167));

    function approve(address spender, uint256 amount) external override returns (bool success) {
        bytes memory data = abi.encodeWithSelector(
            HTS_SYSTEM_CONTRACT.approve.selector,
            TOKEN_ID,
            spender,
            amount
        );
        
        // Perform delegatecall to HTS_SYSTEM_CONTRACT, leaking msg.sender to the system contract
        // This would work if the HTS_SYSTEM_CONTRACT can determine that ContractA is the admin for the specified TOKEN_ID
        (success, ) = address(HTS_SYSTEM_CONTRACT).delegatecall(data);
    }

    // Implement many other IERC20 functions ...

}