Using EVM addresses with HashPack

At HashPack, we recently added support for sending HBAR and tokens to public keys and EVM addresses. There are several benefits to this approach. When a user sends HBAR or tokens to a public key or EVM address of an account that does not exist, it will be created with the corresponding public/private key. It also enables compatibility with other networks. For example, this feature would enable a user to use their Metamask address on Hedera by creating an account with this feature because the key pair would be the same and have an alias. One other benefit of this approach is that it 'creates' the account without actually creating it. Wallet providers can make the account and when the user sends HBAR or tokens to it, the account is created on the network. This 'lazy create' approach may simplify some use cases for wallet providers.

This functionality was introduced in HIP-32 and has steadily been refined and augmented to support more features^1,2. This is a departure from the way things have worked on Hedera since the beginning in terms of address structure. This article will talk about some of the concepts surrounding this feature. It will also talk about how to prevent mishaps that happen as a result of using it.

EVM address

An Ethereum Virtual Machine (EVM) address is a unique identifier that is used to send and receive funds or execute smart contracts³. EVM addresses are 20-byte hexadecimal values that are represented in the form of a string of 40 characters, such as "0x1aD2B053b8c6b1592cB645DEfadf105F34d8C6e1". These addresses are generated through a one-way cryptographic hash function, which ensures their uniqueness and tamper-resistance. This was first introduced on the Ethereum network, but Hedera has recently taken steps to match this pattern.

One important aspect of EVM addresses is that they do not have any inherent meaning or association with a particular user or entity. Instead, they are generated randomly or through a specific algorithm, and are typically managed through a user's private key. This means that the owner of a particular address can only access and control the funds or smart contracts associated with that address if they have access to the private key.

Mishaps

Now that an EVM address has been defined, it's time to address some potential issues HashPack users may face as a result of this new feature. These are very common issues that other networks have faced. Since support has only recently been added for EVM addresses, the Hedera network has just begun to have these issues.

In some cases, there are the same tokens on multiple networks. These tokens may have the same name and token symbol and sometimes even the same EVM address on multiple networks. One such token is USDC (United States Dollar Coin). There are multiple chains that support this coin, but they are all native to their respective chains. When depositing USDC to a centralized exchange (CEX), a user may try to deposit to the address of the exchange for a different chain. If they do this, then their coins will go to an address for which they will not have the key and will be lost forever.

For example, a user wants to send 100 USDC to a CEX of their choice. If this user does this with the Ethereum chain selected, the address will be one that the CEX uses to receive ERC20 USDC on Ethereum. If the USDC held in the user's wallet was on the Ethereum chain, this would be completely fine. However, when a user tries to deposit from Hedera to Ethereum (i.e. HashPack to the CEX's Ethereum USDC account), this is when the problem arises. If the account corresponding to that EVM address does not exist on Hedera, the account will be created with the EVM address' corresponding public/private key. If a user did not generate the keys for this address, there is no way to recover these funds.

In some cases, a CEX may use an EVM address to receive HBAR or HTS tokens. To prevent an error from happening, users should ensure that they only send to Hedera addresses (0.0.123456) or that the CEX EVM address listed is specifically for Hedera. This can be done by carefully checking the deposit information on the CEX. EVM addresses can also be checked by pasting the address into Hashscan⁴. If no account exists that corresponds to the pasted address, then this account is incorrect.

Conclusion

HashPack's recent addition of support for sending HBAR and tokens to public keys and EVM addresses offers a range of benefits, including the creation of accounts with corresponding public/private keys and compatibility with other networks. This new feature is a departure from the way things have worked on Hedera, but it has been steadily refined to support more features. The EVM address may feel familiar to people that may consider Hedera a new home for the dApp. However, it is important for users to be aware of the potential mishaps that may occur, such as depositing funds to an incorrect EVM address, which may lead to the loss of funds. As with any new technology, it is crucial to exercise caution and ensure that proper due diligence is taken before executing any transactions. Overall, this feature has the potential to simplify use cases for wallet providers and improve user experience on the Hedera network.

—
This article was published by Nick Hanna, HashPack CISO.

References

<sup>1. https://hips.hedera.com/hip/hip-32
2. https://hedera.com/blog/auto-create-a-hedera-account-with-hbar-and-token-transfers
3. https://ethereum.github.io/yellowpaper/paper.pdf
4. https://hashscan.io</sup>