Accounts are the central starting point for Hedera. Accounts are stored on the public ledger and hold hbars which are used to pay for the transaction and query fees.
Accounts can be created, updated, or deleted. There are two ways you can create an account either by using an existing account or by using an alias. If you have an existing account, you can use that account to create a new account and to pay for the associated transaction fees in hbar. If you do not have access to an existing account, you can create a testnet account via the Hedera Developer Portal or a mainnet account through one of the options listed here. To create an account using an alias, you have to transfer an hbar to that alias. When the transfer transaction is successful it deducts the cost of creating the account and transfers the remaining balance into that new account.
Accounts are comprised of:
To create a mainnet or testnet account, please visit one of the following:
Each Hedera account is represented by an account ID. The account ID is used to reference a specific account in transactions and queries. Hedera account IDs have the format x.y.z (eg 0.0.3) where:
x represents the shard number (shardId). It will default to 0 today, as Hedera only performs in one shard.
y represents the realm number (realmId). It will default to 0 today, as realms are not yet supported.
z represents the account number, the equivalent of a human-friendly public key.
The account ID of the new account is found in the receipt or record of the account create transaction. A receipt or record can be requested immediatly after an account create transaction is successfully processed.
Each account is required to have a key associated with it. The key type can be a single key, a list of keys, or a threshold of keys.
If the account has a key list, all keys in that key list are required to sign transactions that modify the account like debiting tokens, updating account properties, etc.
If an account has a threshold key, all keys that meet the threshold are required to sign transactions that modify the account. For example, if there were 10 keys on the account and the threshold was to a value of five then five out of the ten keys would need to sign the transaction for it to succeed.
The private key(s) associated with the account are not to be shared with other members on the network as it will allow others to authorize transactions from your account on your behalf. The corresponding public key is visible to others on the Hedera network and stored on ledger.
The private key should be kept secret to the owner. Private keys without an associated recovery phrase cannot be recovered once they are lost. Private keys generated with a recovery phrase can be recovered.
Public and private keys are generated by an algorithm and are unique to one another. Hedera currently supports the following key generation systems:
The amount of HBAR (ℏ) and any other tokens created using the Hedera Token Service held by the account. An account can be created with a zero balance, however, it will eventually need hbars transferred to it from another account to interact with the Hedera APIs. You can purchase hbars here.
Auto Token Associations
When you create an account, you can select the number of token associations that can be automatically allowed. If this account property is set it means that any user can send you tokens without associating that token to your account first.
If you did not set this property when your account was created you will need to associate the tokens to your account prior to initiating the transfer of that token to your account.
Accounts can have an account alias if the account was created by transferring hbar to an account alias. The account alias is a simple key that is immutable once set. Follow the link here for more details.
Staked Node ID
An account can elect to stake its hbars to a node in the Hedera network. The staked node ID is the ID of the node the account anticipates staking to. The full balance of the account is staked to the node. The account balance is liquid at all times. There is no lock-up period. The node ID can be found here or can be queried from the nodes API. Staking to node is an optional account feature. An account can only stake to one node or one account at any given time. Reference HIP-406. This feature is available on:
Staked Account ID
An account can elect to stake its hbars to another account in the Hedera network. This is referenced as indirect staking. The staked account ID is the ID of the account this account would like to stake to. The full balance of the account is staked to the specified account. Staking to an account is an optional account feature. An account can only stake to one node or one account at any given time. Reference HIP-406. This feature is available on:
Decline to Earn Staking Rewards
Accounts have the option to decline earning staking rewards when they stake to a node or an account that then stakes to a node. The staked account still contributes to the stake of the node, but does not earn rewards or calculated as part of the rewards payment to the other accounts that have elected to earn rewards. By default, all staked accounts will earn rewards unless this flag is set. Declining to earn rewards is an optional account feature. Reference HIP-406. This feature is available on:
Accounts, like files and smart contracts, take up storage on the network. Accounts must have a sufficient amount of hbar to fund a renewal of its storage on the network. The amount for renewal will be charged every pre-determined number of seconds. This amount of time is known as the autoRenewPeriod.
The system will automatically pay account renewal fees if the account has a balance. If the account does not have a balance the account will be suspended for one week before it is deleted. You can renew an account during the suspension period.
The maximum autoRenewPeriod for an account, file, or smart contract will be limited to 3 months (7890000 seconds).
Currently not implemented on the network i.e. accounts do not expire.
A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this livehash to this account. At least one of them must reach its threshold to delete this livehash from this account.