Account Properties
Account ID
The account ID is the ID of the account entity on the Hedera network. The account ID includes the shard number, realm number, and an account <shardNum>.<realmNum>.<account>. The account ID is used to specify the account in all Hedera transactions and queries. There can be more than one account ID that can represent an account.
Account Number
Each Hedera account has a system-provided account number when the account is created. An account number is a non-negative number of 8 bytes. You can use the account number to specify the account in all Hedera transactions and query requests. Account numbers are unique and immutable. The account number for a newly created account is returned in the transaction receipt or transaction record for the transaction ID that created the account. The account number ID has the following format <shardNum>.<realmNum>.<accountNum>.
| Account Number ID | Description |
|---|---|
| The account number 10 in account number ID format. |
Account Number Alias
All accounts can have an account number alias. An account number alias is a hex-encoded form of the account number prefixed with 20 bytes of zeros. It is an EVM-compatible address that references the Hedera account. The account number alias does not contain the shard ID and realm ID.
This account property is not stored in consensus node state. You will not see this value returned when querying the consensus nodes for the account object and inspecting the account alias field. The mirror node will calculate the account number alias from the account number. The account number alias is calculated and returned in account REST APIs only when the account does not have an existing account alias. For example, if the account was created through the auto account creation flow using an account alias the account number alias will not be populated. If the account was normally created then the account alias field will store the account number alias.
| Account ID | Account Number Alias Example |
|---|---|
| The hex encoding value for 10 is "0a."
|
Account Alias
Some Hedera accounts will have an account alias. Account aliases are a pointer to the account object in addition to being identified by the account number. Account aliases are assigned to the account when the account is created via the auto account creation flow. The network does not generate the account alias; instead, the user specifies the account alias upon account creation. This property will be null if an account is created through the normal account creation flow. The account aliases are unique and immutable. The account alias ID has the following format <shardNum>.<realmNum>.<alias>.
This format is only acceptable when specified in the TransferTransaction, AccountInfoQuery and AccountBalanceQuery. If this format is used to reference an account in any other transaction type the transaction will not succeed.
The alias can be one of the following alias types:
Public Key Account Alias
The account alias public key is the public key of an ECDSA secp256k1 or ED25519 key type. The public key account ID format is <shardNum>.<realmNum>.<alias> where alias is the public key. This format is created using the bytes of a simple cryptographic public key supported by Hedera. The public key account alias is not required to match the account's public key used to determine the cryptographic signature needed to sign transactions for the account.
EVM Address Account Alias
An EVM address account alias is the rightmost 20 bytes of the 32-byte Keccak-256 hash of the ECDSA public key of the account. This calculation is in the manner described by the Ethereum Yellow Paper. Note that the recovery id is not formally part of the public key and is not included in the hash. This is calculated on the consensus nodes using the ECDSA key provided in the auto account creation flow. The EVM address is also commonly known as the public address. The EVM address account ID format is <shardNum>.<realmNum>.<alias> where alias is the EVM address.
The EVM address account and the account number alias are 20-byte values. They can be differentiated because the account number alias is always prefixed with 12 bytes. The EVM address account alias is commonly used in wallets and tools to represent account addresses.
Reference Hedera Improvement Proposal: HIP-583
Account Memo
A memo is like a short note that lives with the account object in the ledger state and can be viewed on a network explorer when looking up the account. This account memo is limited to 100 characters. The account memo is mutable and can be updated or removed from the account at any time. The account key is required to sign the transaction to facilitate any changes to this property.
Do not post any private information in the account memo field. This field is visible to all participants in the network.
Account Nonce
Accounts on Hedera can submit EthereumTransaction types processed by the Ethereum Virtual Machine (EVM) on a consensus node. The nonce on the account represents a sequentially incrementing count of the transactions submitted by an account through the EthereumTransaction type. The default account nonce value is set to zero.
Reference Hedera Improvement Proposal: HIP-410
Automatic Token Associations
Hedera accounts must generally approve custom tokens before transferring them into the receiving account. The receiving account must sign the transaction that will associate the tokens, allowing the specified tokens to be deposited into their account. The automatic token association feature allows the account to bypass manually associating the custom token before transferring it into the account.
Accounts can automatically approve up to 5,000 tokens without manually preauthorizing each custom token. Suppose an account needs to hold a balance for custom tokens greater than 5,000. In that case, the account must manually approve each additional token using the transaction to associate the tokens. There is no limit on the total number of tokens an account can hold. This property is mutable and can be changed after it is set.
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.
Reference Hedera Improvement Proposal: HIP-23, HIP-904
Balances
When a new account is created, you can specify an initial HBAR balance for the account. The initial HBAR balance for the token is deducted from the account that is paying to create the new account. Creating an account with an initial balance is optional.
A Hedera account can hold a balance of HBAR and custom fungible and non-fungible tokens (NFTs). Account balances can be viewed on a Network Explorer and queried from mirror node REST APIs or consensus nodes.
| Token Type | Description | Token ID Example |
|---|---|---|
HBAR | The native Hedera fungible token used to pay for transaction fees and secure the network. | None |
Fungible Token | Custom fungible tokens created on Hedera. | The fungible token ID is represented as |
Non-Fungible Token (NFTs) | Custom non-fungible tokens (NFTs) created on Hedera. | NFT ID is represented as ex: |
Keys
Each account is required to have at least one key upon creation. If a key is not supplied at the time of account creation, the network will reject the transaction. The individual(s) that have access to the account's private key(s) have access to authorize the transfer of tokens into or out of the account and are required to sign transactions that modify the account. Modifying the account includes changing any property, like the balance, keys, memo, etc.
Accounts can optionally have more than one key associated with them. These kinds of accounts are multi-signature accounts meaning you will require more than one key to sign the transaction to change a property on an account or debit HBARs. The signing requirements for a multi-signature account depend on the account's key chosen key structure. For support of key structures and key types, follow the link below.
Keys and SignaturesWarning: The private key(s) associated with the account is not to be shared with anyone as it will allow others to authorize transactions from your account on your behalf. Sharing your private key is like sharing your bank account password. Please make sure your private keys are stored in a secure wallet.
Receiver Signature Required
Accounts can optionally require the account to sign any transactions depositing tokens into the account. This feature is set to false by default. If this feature is set to true, the account will be required to sign all transactions that deposit tokens into the account. This property is mutable and can be updated after the account is created.
Staking
Staking in Hedera is taking an account and associating the HBAR balance to a node in the network. Custom fungible or non-fungible token balances an account holds do not contribute to staking on the network. The purpose of staking accounts to a node on the network is to strengthen the security of the network. To contribute to the security of the network, staked accounts can earn rewards in HBAR. Please see this guide for additional information about the staking rewards program. Contracts can also stake their accounts to earn rewards.
An account can only stake to one node or one account at any given time.
Staking Information
The network stores the staking metadata for an account and contract accounts. This information is returned in account information query requests (AccountInfoQuery orContractInfoQuery). The staking metadata for an account includes the following information:
decline_reward: whether or not the account declined to earn staking rewards
stake_period_start: The staking period during which either the staking settings for this account or contract changed (such as starting staking or changing staked_node_id) or the most recent reward was earned, whichever is later. If this account or contract is not currently staked to a node, then this field is not set. The stake period is 24 hours, starting UTC midnight.
pending_reward: The amount in tinybars that will be received in the next staking reward payment
staked_to_me: The total tinybar balance of all accounts staked to this account
staked_id: ID of the account or node to which this account or contract is staking
staked_account_id: The account to which this account or contract is staking to
staked_node_id: The ID of the node this account or contract is staked to
Reference Hedera Improvement Proposal: HIP-406
Auto Renewals & Expiration
Auto-renewals and expiration (rent) are currently not enabled.
Like the other Hedera entities, accounts take up network storage. To cover the cost of storing an account, a renewal fee will be charged for the storage utilized on the network. This feature is not enabled on the network today; however, in the future, when it is enabled, the account must have sufficient funds to pay for the renewal fees.
The amount charged for renewal will be charged every pre-determined period in seconds. The interval of time the account will be charged is the auto-renew period. The system will automatically charge the account renewal fees. If the account does not have an HBAR balance, it will be suspended for one week before it is deleted from the ledger. You can renew an account during the suspension period.
Reference Hedera Improvement Proposal: HIP-16
Last updated
