Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 15 additions & 1 deletion evm/differences/accounts-and-keys.mdx
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
---
title: "Accounts, Signature Verification & Keys (ECDSA vs. ED25519)"
title: "Accounts, Signature Verification & Keys (ECDSA vs. ED25519)"
description: "Compare Hedera and Ethereum account models, ECDSA vs ED25519 keys, alias handling, and ECRECOVER/isAuthorized signature verification on the EVM."
---

Expand All @@ -14,6 +14,20 @@ This section helps you navigate ECDSA and ED25519 signature workflows, introduce

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**

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


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.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lets use the terminology "EVM Address from Pubic Key" and not public key alias.


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.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the grammer seems off.


<Info>
A hollow account becomes complete when it is used as the transaction fee payer and the matching ECDSA private key signs the transaction. Until then, the account can only receive value or tokens.
</Info>

### **Clarifying Account ID vs. EVM Address**

Hedera accounts have a native **Account ID** (e.g., `0.0.xxxx`) and can also have an **EVM Address from Public Key** (a 20-byte address like Ethereum's, derived from the ECDSA public key). The EVM Address from Public Key makes the account compatible with `ECRECOVER` and other familiar EVM tools. For more details, see the [Smart Contract Addresses](/evm/development/addresses) page.
Expand Down
6 changes: 5 additions & 1 deletion evm/quickstart/get-test-hbar.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -27,10 +27,14 @@ To use the faucet, head to the [faucet](https://portal.hedera.com/faucet) landin

When you use an EVM wallet address for the first time, **Auto Account Creation** kicks in to establish a new Hedera account linked to your EVM address.

This process creates a **hollow account**, an account with an ID and alias but no key. Hollow accounts can receive HBAR and tokens, but it cannot transfer tokens from the account or modify any account properties until the account key has been added and the account is complete.
This process creates a **hollow account**, an account with an ID and alias but no key. Hollow accounts can receive HBAR and tokens, but they cannot transfer tokens or modify account properties until the account key has been added and the account is complete.

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.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lets use correct terminology - not just "alias"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do not use Long zero. Its either evm address from pubic key or evm address from accountid


For more detail, see [EVM account models and aliases](/evm/differences/accounts-and-keys).

</Warning>

<Frame>
Expand Down
Loading