docs: fix EVM account model content for hollow and long-zero accounts#657
docs: fix EVM account model content for hollow and long-zero accounts#657ayesigaisaac wants to merge 1 commit into
Conversation
|
|
||
| Hedera’s account model supports both ED25519 and ECDSA keys by identifying accounts by aliases instead of static addresses. This allows dynamic key rotation without changing an account’s ID, unlike EVM's static ECDSA-only approach. Signature validation varies accordingly: ED25519 keys use `isAuthorized` or `isAuthorizedRaw`, while Hedera's ECDSA accounts with aliases can still rely on `ECRECOVER`. | ||
|
|
||
| ### **Hollow Accounts and Long-Zero Addresses** |
There was a problem hiding this comment.
I don't think it makes sense to join these topics together.
|
|
||
| Hedera can create a **hollow account** when an EVM alias is used for account creation and the account has an ID but no key material yet. A hollow account can receive HBAR and tokens, but it cannot sign transactions or modify its account properties until the matching ECDSA key signs a transaction and the account is completed. | ||
|
|
||
| Hollow accounts are often created via auto account creation or when an account is initialized with an EVM address alias but no on-file key. Once the account is completed, it behaves like any regular Hedera account. For an example flow, see [Hedera Testnet Faucet](/evm/quickstart/get-test-hbar). |
There was a problem hiding this comment.
This is not a good explanation.
Something more along the lines of:
Hedera Auto Account Creation allows someone to receive HBAR or tokens without first creating a Hedera account. A user can generate a keypair or Ethereum address entirely offline and share that alias with others. No 0.0.x account number exists yet, and the user has never interacted with the network.
When someone sends HBAR or tokens to that alias, the Hedera consensus nodes check whether an account already exists for it. If no account is found, the network automatically creates a new Hedera account as part of processing the transfer. Internally, Hedera creates a child CryptoCreate transaction and assigns the recipient a new account number (for example, 0.0.1234567). The sender of the transfer pays both the transfer fee and the account creation fee.
If the transfer was sent to a public key alias (an ED25519 or ECDSA public key), the newly created account is immediately assigned that public key as its account key. The account can begin signing transactions and operating normally right away.
If the transfer was sent to an EVM address alias (an Ethereum address derived from an ECDSA public key), Hedera instead creates a hollow account. A hollow account has an account number and can receive assets, but it does not yet have an account key and therefore cannot sign transactions or move funds.
The hollow account becomes a fully functional Hedera account when it submits its first transaction as the payer and signs that transaction with the ECDSA private key corresponding to the EVM address. During processing of that transaction, Hedera automatically populates the account key and converts the hollow account into a regular account.
|
|
||
| Hollow accounts are often created via auto account creation or when an account is initialized with an EVM address alias but no on-file key. Once the account is completed, it behaves like any regular Hedera account. For an example flow, see [Hedera Testnet Faucet](/evm/quickstart/get-test-hbar). | ||
|
|
||
| Some Hedera accounts may also fall back to the **EVM Address from Account ID** when no public-key alias is set. This fallback is the “long-zero” form: 12 bytes of zero followed by the 8-byte account number. It is a valid 20-byte EVM address, but it is not derived from an ECDSA public key and therefore is not compatible with `ECRECOVER` the way a public-key-derived alias is. |
There was a problem hiding this comment.
Lets use the terminology "EVM Address from Pubic Key" and not public key alias.
|
|
||
| Some Hedera accounts may also fall back to the **EVM Address from Account ID** when no public-key alias is set. This fallback is the “long-zero” form: 12 bytes of zero followed by the 8-byte account number. It is a valid 20-byte EVM address, but it is not derived from an ECDSA public key and therefore is not compatible with `ECRECOVER` the way a public-key-derived alias is. | ||
|
|
||
| If you want full EVM tooling compatibility, prefer the **EVM Address from Public Key** by creating the account with an ECDSA alias or by completing a hollow account with the matching ECDSA key. Accounts created with `setKeyWithoutAlias()` or with no alias will be reachable via the long-zero EVM Address from Account ID instead. |
|
|
||
| To complete the account, use it as the **fee payer** in a transaction and sign with the **ECDSA private key** tied to the EVM address. Once completed, the account works like any regular Hedera account. | ||
|
|
||
| If the account is instead created without an alias, it falls back to the **EVM Address from Account ID** (the long-zero form). That long-zero address is still a 20-byte EVM address, but it is not derived from a public key and does not support `ECRECOVER` in the same way as the alias-based EVM Address from Public Key. |
There was a problem hiding this comment.
Lets use correct terminology - not just "alias"
|
|
||
| To complete the account, use it as the **fee payer** in a transaction and sign with the **ECDSA private key** tied to the EVM address. Once completed, the account works like any regular Hedera account. | ||
|
|
||
| If the account is instead created without an alias, it falls back to the **EVM Address from Account ID** (the long-zero form). That long-zero address is still a 20-byte EVM address, but it is not derived from a public key and does not support `ECRECOVER` in the same way as the alias-based EVM Address from Public Key. |
There was a problem hiding this comment.
do not use Long zero. Its either evm address from pubic key or evm address from accountid
| @@ -1,2 +1,2 @@ | |||
| --- | |||
| title: "Hedera Testnet Faucet" | |||
There was a problem hiding this comment.
Should we recreate this section or just link to where this already detailed in the docs.
Also should we detail the other way to get testnet HBAR - by creating a Portal account?
|
ok |
2 participants
PR title
docs: fix EVM account model content for hollow and long-zero accounts
Description
Summary
This PR updates EVM documentation to clarify Hedera account model behavior for hollow accounts and long-zero addresses.
What changed
Updated
evm/differences/accounts-and-keys.mdxEVM Address from Account ID/ long-zero formECRECOVERlike alias-based EVM addressesUpdated
evm/quickstart/get-test-hbar.mdxWhy
These docs were missing important account-model details that are critical for EVM developers:
ECRECOVERfails due to a long-zero address fallbackTesting
mint broken-linkspassed with no broken links found@joshmarinacci @akdev @Neurone @kierzniak please recview