Which tab?
EVM Developers
Page URL or path
evm/development/accounts.mdx (new page — does not exist yet)
What's the problem?
The EVM Developers section has no dedicated content explaining how Hedera accounts work for EVM developers. Two specific gaps:
1. Auto-created / hollow accounts
The quickstart flow (MetaMask → faucet → deploy) silently auto-creates a hollow account with only a brief warning callout in evm/quickstart/get-test-hbar.mdx. There is no page explaining what hollow accounts are, how they differ from completed accounts, or what that means for contract and token interactions.
Missing content:
- How Hedera accounts differ from Ethereum addresses (every EVM address is backed by a registered account entity with a native Account ID)
- What auto account creation is and when it triggers
- What hollow accounts can and cannot do (they work fine for EVM/JSON-RPC workflows but cannot initiate native Hedera transactions until completed)
- How completion happens (automatically on first outbound EVM wallet transaction; or explicitly via SDK)
- How to map an EVM address to an Account ID (HashScan, Mirror Node
GET /api/v1/accounts/{evmAddress})
- Token association: ERC-20/ERC-721 tokens (Solidity contracts) require no association and behave like Ethereum; HTS tokens require association, controlled by
maxAutoAssociations (completed hollow accounts default to -1, unlimited, per HIP-904)
2. Long-zero accounts
Many existing Hedera users hold accounts created without an ECDSA public key alias. These appear in the EVM as long-zero addresses (0x000000000000000000000000000000000000004d). There is no content in the EVM section explaining this account type or its implications.
These accounts cannot: sign EthereumTransactions, use MetaMask or any EVM wallet, interact with smart contracts via EVM tooling, or pass ECRECOVER-based signature verification.
EVM developers building dApps need to know this so they understand why some users cannot connect a wallet, why permit/off-chain signing flows are incompatible with these users, and why ECRECOVER-based access control will silently fail for them.
Suggested fix
Create evm/development/accounts.mdx covering both gaps. Detailed content outline in the proposal doc. Cross-link from evm/quickstart/get-test-hbar.mdx and learn/core-concepts/accounts/auto-account-creation.mdx.
Reference HIPs: HIP-32, HIP-542, HIP-583, HIP-904
Which tab?
EVM Developers
Page URL or path
evm/development/accounts.mdx (new page — does not exist yet)
What's the problem?
The EVM Developers section has no dedicated content explaining how Hedera accounts work for EVM developers. Two specific gaps:
1. Auto-created / hollow accounts
The quickstart flow (MetaMask → faucet → deploy) silently auto-creates a hollow account with only a brief warning callout in
evm/quickstart/get-test-hbar.mdx. There is no page explaining what hollow accounts are, how they differ from completed accounts, or what that means for contract and token interactions.Missing content:
GET /api/v1/accounts/{evmAddress})maxAutoAssociations(completed hollow accounts default to-1, unlimited, per HIP-904)2. Long-zero accounts
Many existing Hedera users hold accounts created without an ECDSA public key alias. These appear in the EVM as long-zero addresses (
0x000000000000000000000000000000000000004d). There is no content in the EVM section explaining this account type or its implications.These accounts cannot: sign
EthereumTransactions, use MetaMask or any EVM wallet, interact with smart contracts via EVM tooling, or passECRECOVER-based signature verification.EVM developers building dApps need to know this so they understand why some users cannot connect a wallet, why permit/off-chain signing flows are incompatible with these users, and why
ECRECOVER-based access control will silently fail for them.Suggested fix
Create
evm/development/accounts.mdxcovering both gaps. Detailed content outline in the proposal doc. Cross-link fromevm/quickstart/get-test-hbar.mdxandlearn/core-concepts/accounts/auto-account-creation.mdx.Reference HIPs: HIP-32, HIP-542, HIP-583, HIP-904