Create a wallet page to provide wallet developers guidance about account creation

[SimiHunjan]

Problem

There are different ways wallets can create accounts for their users.

(1) Create account in batch -> update the key on the account when it assigned the user
(2) Create an account on demand

For each method we need to walk the developer through all the things they need to consider.

For (1) the recommendation is to create an account with an ECDSA key. Then when the account is assigned to the user the ECDSA key is updated and the EVM address is set. This depends on HIP-1082 to allow updating of aliases on accounts hiero-ledger/hiero-improvement-proposals#1082

For (2) the recommendation is to create accounts and set the evm address.

What other points need to be included in this document @gregscullard @serg?

Solution

see above

Alternatives

No response

[gregscullard]

I think we should call out the different key types (EC and ED) and caveats for using one or the other.
E.g.

• ED enables you to do everything, except use smart contracts that use ECRecover
• ED keys will not import into metamask
• An account set with an EC key and EVM address cannot rotate its keys
• Once an EVM address is set, it cannot be changed
• ...

We should also highlight the risks involved in key rotation/setting EVM Address (maybe in a separate section of docs) if the account having its key rotated or EVM address set has interacted with smart contracts.

[SimiHunjan]

Creating an issue for a separate doc on key rotation: https://github.com/hashgraph/hedera-docs/issues/858

[ty-swirldslabs]

I agree with @gregscullard , showing the attributes of key types is a good addition for users.

The one point I'm not sure about:

• An account set with an EC key and EVM address cannot rotate its keys

It's not that they can't, it's that they shouldn't. Unsure how hardened our language wants to be in this scenario. They can still execute a transaction to update the keys on that account.

[Nana-EC]

Agreed with @ty-swirldslabs .
I would even stress that it's not that they can't rotate, it's just that if they rotate keys they may lose the correlation between their public key and their evm address - if applicable.
Note: if you previously had a matching public key and evm address and then rotate keys, so far as you signed a future transaction with the ECDSA key that maps to the address ecrecover would still work

[gregscullard]

I think my own confusion here highlights the fact that we need to be explicit on this (imo), if you can do something that later will result in loss of assets, we should be clear about it.

[gregscullard]

Note: if you previously had a matching public key and evm address and then rotate keys, so far as you signed a future transaction with the ECDSA key that maps to the address ecrecover would still work

So, if I created an account with PrivateKeyA and EVMAddressA, then rotate to PrivateKeyB, ECRecover will work if I later sign a payload with PrivateKeyA right ?
If I sign the payload with PrivateKeyB, ECRecover will return the EVM derived from the PrivateKeyB signature which won't match EVMAddressA.

[ty-swirldslabs]

Here's a pass at creating a breakdown of the key types and EVM address combos with recommendations.
This structure should make it easier for wallets / developers to understand the pros and cons of each key type and EVM address combination, along with clear action points for developers and wallet providers.

Key Types and EVM Address Combos

Recommendations for the Community

1. New Accounts:

   • Use ECDSA keys with Standard EVM Addresses to ensure full compatibility with EVM-based smart contracts.
   • Avoid key rotation, it will remove ECRECOVER functionality and possibly cause other Smart Contract related issues.

2. Existing Accounts:

   • Consider transitioning from ED25519 by creating a new account with ECDSA keys with Standard EVM Addresses for full compatibility with EVM contracts.
   • Be aware of the risks to smart contracts that depend on pre-signed messages or mappings.

3. For Wallets:

   • Default to creating accounts with ECDSA keys and Standard EVM Addresses.
   • Implement clear messaging about the implications of key rotation and provide migration guidance.

---

ECDSA Key with Standard EVM Address (Derived from ECDSA Public Key, e.g., 0xFFFF...)

• Best Use Case:
  • Fully compatible EVM smart contracts, especially those relying on ECRECOVER.
  • Recommended for all account creations going forward.
• Implications:
  • Fully supports ECRECOVER, ensuring compatibility with most Ethereum contracts.
  • Key rotation is not advised, as it breaks mappings to the account’s EVM address.
  • Best practice for wallets and developers.

---

Auto-Created ECDSA Key (EVM Address Derived from Public Key)

• Best Use Case:
  • Wallets and applications using lazy account creation for seamless onboarding.
• Implications:
  • Automatically EVM-compatible.
  • Supports ECRECOVER by default.
  • Simplifies adoption for users and developers familiar with Ethereum standards.

---

ED25519 (No EVM Address or Alias)

• Best Use Case:
  • We do not recommend creating this wallet type.
  • Legacy Hedera applications or environments.
• Implications:
  • Not compatible with the ECRECOVER function, limiting its use in EVM-based smart contracts.
  • Custom contract handling is required for signature-related activities.
  • Key rotation is supported but can cause issues with smart contract compatibility.

---

ECDSA Key with Long Zero EVM Address (Derived from Hedera Account ID, e.g., 0x000...)

• Best Use Case:
  • Bridging Hedera-native applications with minimal EVM compatibility requirements.
• Implications:
  • ECRECOVER is not functional.
  • Complex to integrate with standard EVM tools and contracts.
  • Suitable for use cases that don’t rely on Ethereum-like functionality but still require EVM addresses.

---