updated accounts core concepts to resolve #172

Author: theekrystallee

core-concepts/accounts/README.md

@@ -1,12 +1,12 @@
 # Accounts
 
-Accounts are the central starting point when interacting with the Hedera network and using Consensus Node services. A Hedera account is an entity, a distinct object type, stored in the ledger, that holds tokens. Accounts can hold the native Hedera fungible token (HBAR), custom fungible, and custom non-fungible tokens (NFTs) created on the Hedera network. 
+Accounts are the central starting point when interacting with the Hedera network and using Consensus Node services. A Hedera account is an entity, a distinct object type, stored in the ledger, that holds tokens. Accounts can hold the native Hedera fungible token (HBAR), custom fungible, and custom non-fungible tokens (NFTs) created on the Hedera network.
 
-The Hedera native token HBAR (ℏ) is a utility token primarily used to pay for transactions and query fees when interacting with the network. The HBAR symbol is represented as "ℏ."  Applications may reference HBAR as the token denomination; however, the network returns information in tinybars (tℏ), a denomination of HBAR. 100,000,000 tℏ are equivalent to 1 ℏ. This includes things like transaction fees or accounts HBAR balances. 
+The Hedera native token HBAR (ℏ) is a utility token primarily used to pay for transactions and query fees when interacting with the network. The HBAR symbol is represented as "ℏ." Applications may reference HBAR as the token denomination; however, the network returns information in tinybars (tℏ), a denomination of HBAR. 100,000,000 tℏ are equivalent to 1 ℏ. This includes things like transaction fees or accounts HBAR balances.
 
-You interact with the network by submitting transactions that modify the ledger's state or submitting query requests that read data from the ledger. Most transactions and queries have a [transaction fee](../../networks/mainnet/fees/) that is charged in HBAR. Unlike custom tokens users create on the Hedera network, no token ID represents the native HBAR token. 
+You interact with the network by submitting transactions that modify the ledger's state or submitting query requests that read data from the ledger. Most transactions and queries have a [transaction fee](../../networks/mainnet/fees/) that is charged in HBAR. Unlike custom tokens users create on the Hedera network, no token ID represents the native HBAR token.
 
-<table data-view="cards"><thead><tr><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><a href="account-creation.md">         <strong>Account Creation</strong></a></td><td><a href="account-creation.md">account-creation.md</a></td></tr><tr><td>   <a href="auto-account-creation.md"><strong>Auto Account Creation</strong></a></td><td><a href="auto-account-creation.md">auto-account-creation.md</a></td></tr><tr><td><a href="account-properties.md">     <strong>Account Properties</strong></a></td><td><a href="account-properties.md">account-properties.md</a></td></tr></tbody></table>
+<table data-view="cards"><thead><tr><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><a href="account-creation.md"><strong>Account Creation</strong></a></td><td><a href="account-creation.md">account-creation.md</a></td></tr><tr><td><a href="auto-account-creation.md"><strong>Auto Account Creation</strong></a></td><td><a href="auto-account-creation.md">auto-account-creation.md</a></td></tr><tr><td><a href="account-properties.md"><strong>Account Properties</strong></a></td><td><a href="account-properties.md">account-properties.md</a></td></tr></tbody></table>
 
 ## FAQ
 
@@ -30,14 +30,14 @@ New accounts are created by submitting a transaction to the network and paying t
 
 <summary>What is the 'Auto Account Creation' feature?</summary>
 
-[Auto Account Creation](auto-account-creation.md) allows applications to generate free user accounts instantly, even without an internet connection, by creating an account alias.&#x20;
+[Auto Account Creation](auto-account-creation.md) allows applications to generate free user accounts instantly, even without an internet connection, by creating an account alias.
 
 </details>
 
 <details>
 
 <summary>What is a "hollow" account?</summary>
 
-If an account is created with an [EVM address](auto-account-creation.md#evm-address) alias via [Auto Account Creation](auto-account-creation.md), it results in a "hollow" account. This account has an account number and alias but no account key. It can accept token transfers but cannot transfer tokens or modify account properties until the account key has been added, completing the account.
+If an account is created with an [EVM address](auto-account-creation.md#evm-address) via [Auto Account Creation](auto-account-creation.md), it results in a "hollow" account. This account has an account number and alias but no account key. It can accept token transfers but cannot transfer tokens or modify account properties until the account key has been added, completing the account.
 
 </details>

core-concepts/accounts/account-properties.md

@@ -195,7 +195,11 @@ Accounts can automatically approve up to 5,000 tokens without manually preauthor
 
 ## Maximum Auto-Associations
 
-The property `maxAutoAssociations` of Hedera accounts defines the maximum number of automatic associations allowed. If this is `0`, then automatic token associations or airdrops are not allowed, and it requires manual association with the token. This is also if the value is lesser or equal to `usedAutoAssociations`. The default value of the property is `-1` for the new automatically created accounts in a way that basically allows unlimited number of auto-associations \[NOT ENABLED]. If the value is a positive number, this puts a limit on the number of auto token associations to that value.
+The property `maxAutoAssociations` defines how many tokens an account can automatically associate with.
+
+<table><thead><tr><th width="107.8438720703125" align="center">Property Value</th><th></th></tr></thead><tbody><tr><td align="center"><code>0</code></td><td>Automatic token associations or airdrops are not allowed; the account must manually associate each token.</td></tr><tr><td align="center"><code>-1</code></td><td>Unlimited automatic token associations are allowed. this is the default for accounts created via <strong>auto account creation</strong> and for accounts that originated as hollow accounts (created from EVM aliases) and have since been completed. a value of <code>-1</code> allows the account to receive new tokens without manually associating them</td></tr><tr><td align="center"><code>> 0</code></td><td>the account can automatically associate up to that number of tokens. the sender covers the <code>maxAutoAssociations</code> fee and the first auto‑renewal rent for the association.</td></tr></tbody></table>
+
+This feature is enabled on Hedera mainnet as part of frictionless airdrops (hip‑904). When tokens are sent to an account with available auto‑association slots, one slot is consumed and the account becomes associated automatically.&#x20;
 
 Reference Hedera Improvement Proposal: [HIP-23](https://hips.hedera.com/hip/hip-23), [HIP-904](https://hips.hedera.com/hip/hip-904)
 

core-concepts/accounts/auto-account-creation.md

@@ -64,23 +64,26 @@ Create an account alias and convert it to the alias account ID format. The alias
 
 ### **2. Deposit tokens to the account alias account ID**
 
-Once the alias account ID is created, applications can create a transaction to transfer tokens to the alias account ID for users. Users can transfer HBAR, custom fungible or non-fungible tokens to the alias account ID. This will trigger the creation of the official Hedera account. When using the auto account creation flow, the first token transferred to the alias account ID is automatically associated to the account.
+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.
 
-The initial transfer of tokens to the alias account ID will do a few things:
+When the transfer executes, the network:
 
-1. The system will first create a system-initiated transaction to create a new account on Hedera. This is to create a new account on Hedera officially. This transaction occurs one nanosecond before the subsequent token transfer transaction.
-2. After the new account is created, the system will assign a new account number, and the account alias will be stored with the account in the alias field in the state. The new account will have an "auto-created account" set in the account memo field.
-   * For accounts created using the public key alias, the account will be assigned the account public key that matches the alias public key.
-   * For an account created via an EVM address alias, the account will not have an account public key, creating a [hollow account](auto-account-creation.md#auto-account-creation-evm-address-alias).
-3. Once the new account is officially created, the token transfer transaction instantiated by the user will transfer the tokens to the new account.
-4. The account specified to pay for the token transfer transaction fees will also be charged the account creation transaction fees in tinybar.
+* 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
+* Sets the account key if the alias is a public key, or leaves the account **hollow** if the alias is an EVM address
 
-The above interactions introduce the concept of [parent and child transactions](../transactions-and-queries/#nested-transactions). The parent transaction is the transaction that represents the transfer of tokens from the sender account to the destination account. The child transaction is the transaction the system initiated to create the account. This concept is important since the parent transaction record or receipt will not return the new account number ID. You must get the transaction record or receipt of the child transaction. The parent and child transactions will share the same transaction ID, except the child transaction has an added nonce value.
+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.
 
 {% hint style="info" %}
-**parent transaction**: the transaction responsible for transferring the tokens to the alias account ID destination account.
+#### **Note**
 
-**child transaction**: the transaction that created the new account
+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.
 {% endhint %}
 
 ### **3. Get the new account number**
@@ -92,11 +95,38 @@ You can obtain the new account number in any of the following ways:
 * 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: EVM Address Alias
+## 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. Sets the hollow account as the **fee payer** (`TransactionID.accountID`), and
+2. Is **signed** 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`](../../sdks-and-apis/sdks/accounts-and-hbar/transfer-cryptocurrency.md)).
+* Set the payer by generating a `TransactionId` with the hollow account ID.
+* 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.
+* JSON-RPC relay providers set the payer to the new account and include the user’s ECDSA signature automatically. 
+
+#### **Set a Different Fee Payer (After Completion)**
+
+* **HAPI (SDKs):** Generate a `TransactionId` with the desired payer before freeze/sign. If not set, the SDK uses the client operator by default.
+* **JSON-RPC:** Configure your relay or custom endpoint to set `TransactionID.accountID` to the payer account. Submit the signed EVM transaction to that endpoint and the relay will wrap it, set the payer, forward it to Hedera, and you can verify the payer in the transaction record or on HashScan.
 
-Accounts created with the auto account creation flow using an [EVM address alias](account-properties.md#account-alias-evm-address) result in creating a **hollow account**. Hollow accounts are incomplete accounts with an account number and alias but not an account key. The hollow account can accept token transfers into the account in this state. It cannot transfer tokens from the account or modify any account properties until the account key has been added and the account is complete.
+## **Automatic Token Associations for Completed Accounts**
 
-To update the hollow account into a complete account, the hollow account needs to be specified as a transaction fee payer account for a Hedera transaction. It must also sign the transaction with the ECDSA private key corresponding to the EVM address alias. When the hollow account becomes a complete account, you can use the account to pay for transaction fees or update account properties as you would with regular Hedera 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.
 
 ## Examples
 

sdks-and-apis/sdks/accounts-and-hbar/create-an-account.md

@@ -28,7 +28,7 @@ When creating a **new account** using the<mark style="color:purple;">`AccountCre
 
 Accounts have a property, `maxAutoAssociations`, and the property's value determines the maximum number of automatic token associations allowed.
 
-<table><thead><tr><th width="162" align="center">Property Value</th><th>Description</th></tr></thead><tbody><tr><td align="center"><code>0</code></td><td>Automatic <strong>token</strong> associations or <a data-footnote-ref href="#user-content-fn-1"><strong>token airdrops</strong></a> are not allowed, and the account must be manually associated with a token. This also applies if the value is less than or equal to <code>usedAutoAssociations</code>.</td></tr><tr><td align="center"><code>-1</code></td><td>The number of automatic <strong>token</strong> associations an account can have is unlimited. <code>-1</code> is the default value for new automatically-created accounts.</td></tr><tr><td align="center"><code>> 0</code></td><td>If the value is a positive number (number greater than 0), the number of automatic token associations an account can have is limited to that number. </td></tr></tbody></table>
+<table><thead><tr><th width="162" align="center">Property Value</th><th>Description</th></tr></thead><tbody><tr><td align="center"><code>0</code></td><td>Automatic <strong>token</strong> associations or <strong>token airdrops</strong> are not allowed, and the account must be manually associated with a token. This also applies if the value is less than or equal to <code>usedAutoAssociations</code>.</td></tr><tr><td align="center"><code>-1</code></td><td>Unlimited automatic token associations are allowed, and this is the default for accounts created via <a href="../../../core-concepts/accounts/auto-account-creation.md">auto account creation</a> and for accounts that began as hollow accounts and are now complete. Accounts with <code>-1</code> can receive new tokens without manually associating them. The sender still pays the <code>maxAutoAssociations</code> fee and initial rent for each association.</td></tr><tr><td align="center"><code>> 0</code></td><td>If the value is a positive number (number greater than 0), the number of automatic token associations an account can have is limited to that number.</td></tr></tbody></table>
 
 {% hint style="info" %}
 The sender pays the `maxAutoAssociations` fee and the rent for the first auto-renewal period for the association. This is in addition to the typical transfer fees. This ensures the receiver can receive tokens without association and makes it a smoother transfer process.
@@ -41,9 +41,9 @@ The sender pays the `maxAutoAssociations` fee and the rent for the first auto-re
 <table><thead><tr><th width="508">Method</th><th width="125.33333333333331">Type</th><th>Requirement</th></tr></thead><tbody><tr><td><code>setKey(&#x3C;key>)</code></td><td>Key</td><td>Required</td></tr><tr><td><code>setAlias(&#x3C;alias>)</code></td><td>EvmAddress</td><td>Optional</td></tr><tr><td><code>setInitialBalance(&#x3C;initialBalance>)</code></td><td>HBar</td><td>Optional</td></tr><tr><td><code>setReceiverSignatureRequired(&#x3C;booleanValue>)</code></td><td>boolean</td><td>Optional</td></tr><tr><td><code>setMaxAutomaticTokenAssociations(&#x3C;amount>)</code></td><td>int</td><td>Optional</td></tr><tr><td><code>setStakedAccountId(&#x3C;stakedAccountId>)</code></td><td>AccountId</td><td>Optional</td></tr><tr><td><code>setStakedNodeId(&#x3C;stakedNodeId>)</code></td><td>long</td><td>Optional</td></tr><tr><td><code>setDeclineStakingReward(&#x3C;declineStakingReward>)</code></td><td>boolean</td><td>Optional</td></tr><tr><td><code>setAccountMemo(&#x3C;memo>)</code></td><td>String</td><td>Optional</td></tr><tr><td><code>setAutoRenewPeriod(&#x3C;autoRenewPeriod>)</code></td><td>Duration</td><td>Disabled</td></tr></tbody></table>
 
 {% hint style="warning" %}
-#### Account Alias
+**Account Alias**
 
-If an alias is set during account creation, it becomes [immutable](../../../support-and-community/glossary.md#immutability), meaning it cannot be changed. If you plan to update or rotate keys in the future, do not set the alias at the time of initial account creation. The alias can be set after finalizing all key updates.&#x20;
+If an alias is set during account creation, it becomes [immutable](../../../support-and-community/glossary.md#immutability), meaning it cannot be changed. If you plan to update or rotate keys in the future, do not set the alias at the time of initial account creation. The alias can be set after finalizing all key updates.
 {% endhint %}
 
 {% tabs %}
@@ -215,5 +215,3 @@ accountKey, err := AccountCreateTransaction.GetKey()
 ```
 {% endtab %}
 {% endtabs %}
-
-[^1]: