> ## Documentation Index > Fetch the complete documentation index at: https://docs.hedera.com/llms.txt > Use this file to discover all available pages before exploring further. # Auto Account Creation > Auto-create free Hedera accounts by sending HBAR or HTS tokens to an EVM Address from Public Key, as defined in HIP-32 and HIP-542. Auto account creation is a unique flow in which applications like wallets and exchanges can create free user accounts instantly, even without an internet connection. Applications do this by generating an **EVM address** derived from an ECDSA public key and using it as the alias. The alias account ID format is `0.0.` on mainnet (the full format is `..`, shard and realm are `0` on mainnet today), an alternative to the standard account number format `0.0.`. **For EVM-compatible accounts, the alias is an EVM address derived from the account's ECDSA public key**. The EVM Address from Public Key is created by using the rightmost 20 bytes of the 32 byte `Keccak-256` hash of an `ECDSA secp256k1` public key. This calculation is in the manner described by the [Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf). The EVM address is not equivalent to the ECDSA public key. The acceptable format for Hedera transactions is the account ID with the EVM address (`0.0.`). The acceptable format for Ethereum public addresses to denote an account address is the hex encoded public address. **Example** EVM Address: `b794f5ea0ba39494ce839613fffba74279579268` HEX Encoded EVM Address: `0xb794f5ea0ba39494ce839613fffba74279579268` Account ID with EVM Address: `0.0.b794f5ea0ba39494ce839613fffba74279579268` The `..` format is only acceptable when specified in the `TransferTransaction`, `AccountInfoQuery`, and `AccountBalanceQuery` transaction types. If this format is used to specify an account in any other transaction type, the transaction will not succeed. Reference Hedera Improvement Proposal: [HIP-583](https://hips.hedera.com/hip/hip-583) ## **Auto Account Creation Flow** ### **1. Create an account alias** Create an account alias and convert it to the alias account ID format. The alias account ID format requires appending the shard number and realm numbers to the account alias. This form of account is purely a local account, i.e., not registered with the Hedera network. ### **2. Deposit tokens to the account alias account ID** Once the alias Account ID exists, create a **TransferTransaction** that sends HBAR or HTS tokens to that alias. Sending tokens triggers auto account creation on the network, and the first token transferred is automatically associated with the new account. When the transfer executes, the network: * Creates a **child** account-creation transaction just before the transfer * Assigns a new account number and stores the alias on the account * Sets the memo to indicate an auto-created account * Leaves the account **hollow** until the matching ECDSA key signs a transaction (see [Complete a Hollow Account](#complete-a-hollow-account)) The **parent** transaction is the token transfer. The **child** is the account creation. They share a transaction ID; the child uses the same ID with a nonce increment. To fetch the new account ID, query the child record or request the parent record with child records included. The **payer** of the transfer covers both the token transfer fee and the account creation fee. #### **Note** The account-creation child transaction is timestamped just before the transfer (a minimal offset).\ Parent and child share the same Transaction ID; the child uses the same ID with a nonce increment.\ Fees for both the account creation and the transfer are charged **in tinybars** to the payer of the parent transfer.\ To retrieve the new Account ID, either request the parent record with child records included or query the child record directly by incrementing the nonce. ### **3. Get the new account number** You can obtain the new account number in any of the following ways: * Request the parent transaction record or receipt and set the child transaction record boolean flag equal to true. * Request the transaction receipt or record of the account create transaction by using the transaction ID of the parent transfer transaction and incrementing the nonce value from 0 to 1. * Specify the account alias account ID in an `AccountInfoQuery` transaction request. The response will return the account's account number account ID. * Inspect the parent transfer transaction record transfer list for the account with a transfer equal to the token transfer value. ## Auto Account Creation with an EVM Address When the alias is an EVM address, the network creates a **hollow account**. A hollow account has an account number and alias but no key. It can receive tokens, but it cannot send tokens or modify account properties until it is a complete account. ### Complete a Hollow Account To complete a hollow account, submit a Hedera transaction that: 1. Make the hollow account the **fee payer** for a Hedera transaction, and 2. Sign that transaction with the **ECDSA private key** that matches the EVM address. If either condition is missing, the transaction is rejected. After completion, the account behaves like a regular Hedera account. #### **Using HAPI (SDKs)** * Build a transaction (for example, a small [`TransferTransaction`](/native/accounts/transfer)). * Set the transaction’s payer to the hollow account in your SDK. * Sign with the corresponding ECDSA key and execute. #### **Using EVM Wallets via JSON-RPC** * Send the first transaction from the new account in the wallet. * EVM wallets will set the new account as the transaction fee payer when users sign transactions to complete the account. No further action is required as the RPC will set the users account ID as the fee payer. ## **Automatic Token Associations for Completed Accounts** Once a hollow account has been converted into a complete account by acting as the payer for a transaction and signing with its ECDSA private key, it inherits the default automatic association settings. Specifically, the account’s `maxAutoAssociations` property defaults to `–1`, enabling unlimited automatic token associations. This means that any subsequent HTS tokens transferred to the completed account will be automatically associated, and the recipient does not need to manually associate with each token. This behavior is part of frictionless airdrops ([HIP‑904](https://hips.hedera.com/hip/hip-904)) and differs from earlier network versions where auto‑association for new tokens was not available. ## EVM Developer Reference Building a dApp? See [Account Model for EVM Developers](/evm/development/accounts) for how hollow accounts and long-zero accounts affect EVM tooling, wallet compatibility, and token association. ## Examples * [Java](https://github.com/hiero-ledger/hiero-sdk-java/blob/main/examples/src/main/java/com/hedera/hashgraph/sdk/examples/AutoCreateAccountTransferTransactionExample.java) * [JavaScript](https://github.com/hiero-ledger/hiero-sdk-js/blob/main/examples/account/transfer-using-evm-address.js) * [Go](https://github.com/hiero-ledger/hiero-sdk-go/blob/main/examples/account_create_token_transfer/main.go) * [C++](https://github.com/hiero-ledger/hiero-sdk-cpp/blob/main/src/sdk/examples/AutoCreateAccountTransferTransactionExample.cpp)