# Get account by alias, id, or evm address Source: https://docs.hedera.com/api-reference/accounts/get-account-by-alias-id-or-evm-address /openapi.yaml get /api/v1/accounts/{idOrAliasOrEvmAddress} Return the account transactions and balance information given an account alias, an account id, or an evm address. The information will be limited to at most 1000 token balances for the account as outlined in HIP-367. When the timestamp parameter is supplied, we will return transactions and account state for the relevant timestamp query. Balance information will be accurate to within 15 minutes of the provided timestamp query. Historical ethereum nonce information is currently not available and may not be the exact value at a provided timestamp. # Get crypto allowances for an account info Source: https://docs.hedera.com/api-reference/accounts/get-crypto-allowances-for-an-account-info /openapi.yaml get /api/v1/accounts/{idOrAliasOrEvmAddress}/allowances/crypto Returns information for all crypto allowances for an account. # Get fungible token allowances for an account Source: https://docs.hedera.com/api-reference/accounts/get-fungible-token-allowances-for-an-account /openapi.yaml get /api/v1/accounts/{idOrAliasOrEvmAddress}/allowances/tokens Returns information for fungible token allowances for an account. ## Ordering The order is governed by a combination of the spender id and the token id values, with spender id being the parent column. The token id value governs its order within the given spender id. Note: The default order for this API is currently ASC ## Filtering When filtering there are some restrictions enforced to ensure correctness and scalability. **The table below defines the restrictions and support for the endpoint** | Query Param | Comparison Operator | Support | Description | Example | | ------------- | ------------------- | ------- | --------------------- | ------- | | spender.id | eq | Y | Single occurrence only. | ?spender.id=X | | | ne | N | | | | | lt(e) | Y | Single occurrence only. | ?spender.id=lte:X | | | gt(e) | Y | Single occurrence only. | ?spender.id=gte:X | | token.id | eq | Y | Single occurrence only. Requires the presence of a **spender.id** query | ?token.id=lt:Y | | | ne | N | | | | | lt(e) | Y | Single occurrence only. Requires the presence of an **lte** or **eq** **spender.id** query | ?spender.id=lte:X&token.id=lt:Y | | | gt(e) | Y | Single occurrence only. Requires the presence of an **gte** or **eq** **spender.id** query | ?spender.id=gte:X&token.id=gt:Y | Both filters must be a single occurrence of **gt(e)** or **lt(e)** which provide a lower and or upper boundary for search. # Get nfts for an account info Source: https://docs.hedera.com/api-reference/accounts/get-nfts-for-an-account-info /openapi.yaml get /api/v1/accounts/{idOrAliasOrEvmAddress}/nfts Returns information for all non-fungible tokens for an account. ## Ordering When considering NFTs, their order is governed by a combination of their numerical **token.Id** and **serialnumber** values, with **token.id** being the parent column. A serialnumbers value governs its order within the given token.id In that regard, if a user acquired a set of NFTs in the order (2-2, 2-4 1-5, 1-1, 1-3, 3-3, 3-4), the following layouts illustrate the ordering expectations for ownership listing 1. **All NFTs in ASC order**: 1-1, 1-3, 1-5, 2-2, 2-4, 3-3, 3-4 2. **All NFTs in DESC order**: 3-4, 3-3, 2-4, 2-2, 1-5, 1-3, 1-1 3. **NFTs above 1-1 in ASC order**: 1-3, 1-5, 2-2, 2-4, 3-3, 3-4 4. **NFTs below 3-3 in ASC order**: 1-1, 1-3, 1-5, 2-2, 2-4 5. **NFTs between 1-3 and 3-3 inclusive in DESC order**: 3-4, 3-3, 2-4, 2-2, 1-5, 1-3 Note: The default order for this API is currently DESC ## Filtering When filtering there are some restrictions enforced to ensure correctness and scalability. **The table below defines the restrictions and support for the NFT ownership endpoint** | Query Param | Comparison Operator | Support | Description | Example | | ------------- | ------------------- | ------- | --------------------- | ------- | | token.id | eq | Y | Single occurrence only. | ?token.id=X | | | ne | N | | | | | lt(e) | Y | Single occurrence only. | ?token.id=lte:X | | | gt(e) | Y | Single occurrence only. | ?token.id=gte:X | | serialnumber | eq | Y | Single occurrence only. Requires the presence of a **token.id** query | ?serialnumber=Y | | | ne | N | | | | | lt(e) | Y | Single occurrence only. Requires the presence of an **lte** or **eq** **token.id** query | ?token.id=lte:X&serialnumber=lt:Y | | | gt(e) | Y | Single occurrence only. Requires the presence of an **gte** or **eq** **token.id** query | ?token.id=gte:X&serialnumber=gt:Y | | spender.id | eq | Y | | ?spender.id=Z | | | ne | N | | | | | lt(e) | Y | | ?spender.id=lt:Z | | | gt(e) | Y | | ?spender.id=gt:Z | Note: When searching across a range for individual NFTs a **serialnumber** with an additional **token.id** query filter must be provided. Both filters must be a single occurrence of **gt(e)** or **lt(e)** which provide a lower and or upper boundary for search. # Get non fungible token allowances for an account Source: https://docs.hedera.com/api-reference/accounts/get-non-fungible-token-allowances-for-an-account /openapi.yaml get /api/v1/accounts/{idOrAliasOrEvmAddress}/allowances/nfts Returns an account's non-fungible token allowances. ## Ordering The order is governed by a combination of the account ID and the token ID values, with account ID being the parent column. The token ID value governs its order within the given account ID. Note: The default order for this API is currently ascending. The account ID can be the owner or the spender ID depending upon the owner flag. ## Filtering When filtering there are some restrictions enforced to ensure correctness and scalability. **The table below defines the restrictions and support for the endpoint** | Query Param | Comparison Operator | Support | Description | Example | | ------------- | ------------------- | ------- | --------------------- | ------- | | account.id | eq | Y | Single occurrence only. | ?account.id=X | | | ne | N | | | | | lt(e) | Y | Single occurrence only. | ?account.id=lte:X | | | gt(e) | Y | Single occurrence only. | ?account.id=gte:X | | token.id | eq | Y | Single occurrence only. Requires the presence of an **account.id** parameter | ?account.id=X&token.id=eq:Y | | | ne | N | | | | | lt(e) | Y | Single occurrence only. Requires the presence of an **lte** or **eq** **account.id** parameter | ?account.id=lte:X&token.id=lt:Y | | | gt(e) | Y | Single occurrence only. Requires the presence of an **gte** or **eq** **account.id** parameter | ?account.id=gte:X&token.id=gt:Y | Both filters must be a single occurrence of **gt(e)** or **lt(e)** which provide a lower and or upper boundary for search. # Get past staking reward payouts for an account Source: https://docs.hedera.com/api-reference/accounts/get-past-staking-reward-payouts-for-an-account /openapi.yaml get /api/v1/accounts/{idOrAliasOrEvmAddress}/rewards Returns information for all past staking reward payouts for an account. # Get token relationships info for an account Source: https://docs.hedera.com/api-reference/accounts/get-token-relationships-info-for-an-account /openapi.yaml get /api/v1/accounts/{idOrAliasOrEvmAddress}/tokens Returns information for all token relationships for an account. # List account entities on network Source: https://docs.hedera.com/api-reference/accounts/list-account-entities-on-network /openapi.yaml get /api/v1/accounts Returns a list of all account entity items on the network. # Get outstanding token airdrops sent by an account Source: https://docs.hedera.com/api-reference/airdrops/get-outstanding-token-airdrops-sent-by-an-account /openapi.yaml get /api/v1/accounts/{idOrAliasOrEvmAddress}/airdrops/outstanding Returns outstanding token airdrops that have been sent by an account. # Get pending token airdrops received by an account Source: https://docs.hedera.com/api-reference/airdrops/get-pending-token-airdrops-received-by-an-account /openapi.yaml get /api/v1/accounts/{idOrAliasOrEvmAddress}/airdrops/pending Returns pending token airdrops that have been received by an account. # List account balances Source: https://docs.hedera.com/api-reference/balances/list-account-balances /openapi.yaml get /api/v1/balances Returns a list of account and token balances on the network. The latest balance information is returned when there is no timestamp query parameter, otherwise, the information is retrieved from snapshots with 15-minute granularity. This information is limited to at most 50 token balances per account as outlined in HIP-367. As such, it's not recommended for general use and we instead recommend using either `/api/v1/accounts/{id}/tokens` or `/api/v1/tokens/{id}/balances` to obtain the current token balance information and `/api/v1/accounts/{id}` to return the current account balance. # Get block by hash or number Source: https://docs.hedera.com/api-reference/blocks/get-block-by-hash-or-number /openapi.yaml get /api/v1/blocks/{hashOrNumber} Returns the block information by given hash or number. # List blocks Source: https://docs.hedera.com/api-reference/blocks/list-blocks /openapi.yaml get /api/v1/blocks Returns a list of blocks on the network. # Get contract by id Source: https://docs.hedera.com/api-reference/contracts/get-contract-by-id /openapi.yaml get /api/v1/contracts/{contractIdOrAddress} Return the contract information given an id # Get the contract actions from a contract on the network for a given transactionId or ethereum transaction hash Source: https://docs.hedera.com/api-reference/contracts/get-the-contract-actions-from-a-contract-on-the-network-for-a-given-transactionid-or-ethereum-transaction-hash /openapi.yaml get /api/v1/contracts/results/{transactionIdOrHash}/actions Returns a list of ContractActions for a contract's function executions for a given transactionId or ethereum transaction hash. # Get the contract result from a contract on the network executed at a given timestamp Source: https://docs.hedera.com/api-reference/contracts/get-the-contract-result-from-a-contract-on-the-network-executed-at-a-given-timestamp /openapi.yaml get /api/v1/contracts/{contractIdOrAddress}/results/{timestamp} Returns a single ContractResult for a contract's function executions at a specific timestamp. # Get the contract result from a contract on the network for a given transactionId or ethereum transaction hash Source: https://docs.hedera.com/api-reference/contracts/get-the-contract-result-from-a-contract-on-the-network-for-a-given-transactionid-or-ethereum-transaction-hash /openapi.yaml get /api/v1/contracts/results/{transactionIdOrHash} Returns a single ContractResult for a contract's function executions for a given transactionId or ethereum transaction hash. # Get the opcode traces for a historical transaction on the network with the given transaction ID or hash Source: https://docs.hedera.com/api-reference/contracts/get-the-opcode-traces-for-a-historical-transaction-on-the-network-with-the-given-transaction-id-or-hash /openapi.yaml get /api/v1/contracts/results/{transactionIdOrHash}/opcodes Re-executes a transaction and returns a result containing detailed information for the execution, including all values from the {@code stack}, {@code memory} and {@code storage} and the entire trace of opcodes that were executed during the replay. Note that to provide the output, the transaction needs to be re-executed on the EVM, which may take a significant amount of time to complete if stack and memory information is requested. # Invoke a smart contract Source: https://docs.hedera.com/api-reference/contracts/invoke-a-smart-contract /openapi.yaml post /api/v1/contracts/call Returns a result from EVM execution such as cost-free execution of read-only smart contract queries, gas estimation, and transient simulation of read-write operations. If the `estimate` field is set to true gas estimation is executed. This API can process calls against the `latest` block or specific historical blocks when a hexadecimal or decimal block number is provided in the `block` field. # List contract entities on network Source: https://docs.hedera.com/api-reference/contracts/list-contract-entities-on-network /openapi.yaml get /api/v1/contracts Returns a list of all contract entity items on the network. # List contract logs from a contract on the network Source: https://docs.hedera.com/api-reference/contracts/list-contract-logs-from-a-contract-on-the-network /openapi.yaml get /api/v1/contracts/{contractIdOrAddress}/results/logs Search the logs of a specific contract across multiple contract calls. Chained logs are not included but can be found by calling `/api/v1/contracts/{contractId}/results/{timestamp}` or `/api/v1/contracts/results/{transactionId}`. When searching by topic a timestamp parameter must be supplied and span a time range of at most seven days. ## Ordering The order is governed by the combination of timestamp and index values. If the index param is omitted, the order is determined by the timestamp only. Note: The default order for this API is currently DESC ## Filtering When filtering there are some restrictions enforced to ensure correctness and scalability. **The table below defines the restrictions and support for the endpoint** | Query Param | Comparison Operator | Support | Description | Example | | ------------- | ------------------- | ------- | --------------------- | ------- | | index | eq | Y | Single occurrence only. Requires the presence of timestamp | ?index=X | | | ne | N | | | | | lt(e) | Y | Single occurrence only. Requires the presence of timestamp | ?index=lte:X | | | gt(e) | Y | Single occurrence only. Requires the presence of timestamp | ?index=gte:X | | timestamp | eq | Y | Single occurrence only. | ?timestamp=Y | | ne | N | | | | | lt(e) | Y | Single occurrence only. Optional second timestamp **gt(e)** | ?timestamp=lte:Y | | gt(e) | Y | Single occurrence only. Optional second timestamp **lt(e)** | ?timestamp=gte:Y Both filters must be a single occurrence of **gt(e)** or **lt(e)** which provide a lower and or upper boundary for search. # List contract results from a contract on the network Source: https://docs.hedera.com/api-reference/contracts/list-contract-results-from-a-contract-on-the-network /openapi.yaml get /api/v1/contracts/{contractIdOrAddress}/results Returns a list of all ContractResults for a contract's function executions. # List contract results from all contracts on the network Source: https://docs.hedera.com/api-reference/contracts/list-contract-results-from-all-contracts-on-the-network /openapi.yaml get /api/v1/contracts/results Returns a list of all ContractResults for all contract's function executions. # List contracts logs across many contracts on the network Source: https://docs.hedera.com/api-reference/contracts/list-contracts-logs-across-many-contracts-on-the-network /openapi.yaml get /api/v1/contracts/results/logs Search the logs across many contracts with multiple contract calls. Chained logs are not included but can be found by calling `/api/v1/contracts/{contractId}/results/{timestamp}` or `/api/v1/contracts/results/{transactionId}`. When searching by topic a timestamp parameter must be supplied and span a time range of at most seven days. ## Ordering The order is governed by the combination of timestamp and index values. If the index param is omitted, the order is determined by the timestamp only. Note: The default order for this API is currently DESC ## Filtering When filtering there are some restrictions enforced to ensure correctness and scalability. **The table below defines the restrictions and support for the endpoint** | Query Param | Comparison Operator | Support | Description | Example | | ------------- | ------------------- | ------- | --------------------- | ------- | | index | eq | Y | Single occurrence only. Requires the presence of timestamp | ?index=X | | | ne | N | | | | | lt(e) | Y | Single occurrence only. Requires the presence of timestamp | ?index=lte:X | | | gt(e) | Y | Single occurrence only. Requires the presence of timestamp | ?index=gte:X | | timestamp | eq | Y | Single occurrence only. | ?timestamp=Y | | ne | N | | | | | lt(e) | Y | Single occurrence only. Optional second timestamp **gt(e)** | ?timestamp=lte:Y | | gt(e) | Y | Single occurrence only. Optional second timestamp **lt(e)** | ?timestamp=gte:Y Both filters must be a single occurrence of **gt(e)** or **lt(e)** which provide a lower and or upper boundary for search. # The contract state from a contract on the network Source: https://docs.hedera.com/api-reference/contracts/the-contract-state-from-a-contract-on-the-network /openapi.yaml get /api/v1/contracts/{contractIdOrAddress}/state Returns a list of all contract's slots. If no timestamp is provided, returns the current state. # List all components Source: https://docs.hedera.com/api-reference/list-all-components /hedera-status-api.yaml get /components.json Provides detailed information about each component of the Hedera network. # Change the logging level of the application Source: https://docs.hedera.com/api-reference/logging/change-the-logging-level-of-the-application /smart-contract-verification-api.yaml post /change-log-level Allows changing the logging level dynamically at runtime for the application. Requires Basic Authentication. # Estimate network fees Source: https://docs.hedera.com/api-reference/network/estimate-network-fees /openapi.yaml post /api/v1/network/fees Given a protobuf-encoded HAPI transaction, returns an itemized fee estimate in tinycents. The response is broken down into `node`, `network`, and `service` components, each with a `base` price and a list of `extras` (e.g., signatures, memo bytes). The `total` field is the sum of all subtotals. When the request transaction sets the [HIP-1313](https://hips.hedera.com/hip/hip-1313) `high_volume` flag, the response includes a `high_volume_multiplier`. The totals in the response are **not** pre-multiplied — multiply `total` by `high_volume_multiplier / 1000` to obtain the high-volume price. # Get network stake information Source: https://docs.hedera.com/api-reference/network/get-network-stake-information /openapi.yaml get /api/v1/network/stake Returns the network's current stake information. # Get registered nodes Source: https://docs.hedera.com/api-reference/network/get-registered-nodes /openapi.yaml get /api/v1/network/registered-nodes Returns the list of registered nodes # Get the network address book nodes Source: https://docs.hedera.com/api-reference/network/get-the-network-address-book-nodes /openapi.yaml get /api/v1/network/nodes Returns the network's list of nodes used in consensus # Get the network exchange rate to estimate costs Source: https://docs.hedera.com/api-reference/network/get-the-network-exchange-rate-to-estimate-costs /openapi.yaml get /api/v1/network/exchangerate Returns the network's exchange rate, current and next. # Get the network fees Source: https://docs.hedera.com/api-reference/network/get-the-network-fees /openapi.yaml get /api/v1/network/fees Returns the estimated gas in tinybars per each transaction type. Default order is ASC. Currently only `ContractCall`, `ContractCreate` and `EthereumTransaction` transaction types are supported. # Get the network supply Source: https://docs.hedera.com/api-reference/network/get-the-network-supply /openapi.yaml get /api/v1/network/supply Returns the network's released supply of hbars # Check if contracts are verified (full match) by addresses and chain IDs Source: https://docs.hedera.com/api-reference/repository/check-if-contracts-are-verified-full-match-by-addresses-and-chain-ids /smart-contract-verification-api.yaml get /check-by-addresses Checks if contract with the desired chain and address is verified and in the repository. It will search only the perfect matches. # Check if contracts are verified (full or partial match) by addresses and chain IDs Source: https://docs.hedera.com/api-reference/repository/check-if-contracts-are-verified-full-or-partial-match-by-addresses-and-chain-ids /smart-contract-verification-api.yaml get /check-all-by-addresses Checks if contract with the desired chain and address is verified and in the repository. It will search for both perfect and partial matches. # Get a specific file from the repository with the file path (static serving) Source: https://docs.hedera.com/api-reference/repository/get-a-specific-file-from-the-repository-with-the-file-path-static-serving /smart-contract-verification-api.yaml get /repository/contracts/{matchType}/{chain}/{address}/{filePath} Retrieve statically served files over the server. # Get all contract addresses verified on a chain (full or partial match) Source: https://docs.hedera.com/api-reference/repository/get-all-contract-addresses-verified-on-a-chain-full-or-partial-match /smart-contract-verification-api.yaml get /files/contracts/{chain} Returns all verified contracts from the repository for the desired chain. Searches for full and partial matches. # Get all files of a contract (full and partial match) Source: https://docs.hedera.com/api-reference/repository/get-all-files-of-a-contract-full-and-partial-match /smart-contract-verification-api.yaml get /files/any/{chain}/{address} Returns all files for the desired contract with the address and chain. Searches both full and partial matches. # Get all files of a contract (full match) Source: https://docs.hedera.com/api-reference/repository/get-all-files-of-a-contract-full-match /smart-contract-verification-api.yaml get /files/{chain}/{address} Returns all files for the desired contract with the address and chain. Searches only for full matches. # Get file tree (full and partial match) Source: https://docs.hedera.com/api-reference/repository/get-file-tree-full-and-partial-match /smart-contract-verification-api.yaml get /files/tree/any/{chain}/{address} Returns repository URLs for every file in the source tree for the desired chain and address. Searches for full and partial matches. # Get file tree (full match) Source: https://docs.hedera.com/api-reference/repository/get-file-tree-full-match /smart-contract-verification-api.yaml get /files/tree/{chain}/{address} Returns repository URLs for every file in the source tree for the desired chain and address. Searches only for full matches. # Retrieve a summary of the status page. Source: https://docs.hedera.com/api-reference/retrieve-a-summary-of-the-status-page /hedera-status-api.yaml get /summary.json Get a summary of the status page, including a status indicator, component statuses, unresolved incidents, and any upcoming or in-progress scheduled maintenances. # Retrieve active scheduled maintenances Source: https://docs.hedera.com/api-reference/retrieve-active-scheduled-maintenances /hedera-status-api.yaml get /scheduled-maintenances/active.json Fetches details about all currently active scheduled maintenance events for the Hedera network. # Retrieve all incidents Source: https://docs.hedera.com/api-reference/retrieve-all-incidents /hedera-status-api.yaml get /incidents.json Fetches a list of all incidents, both resolved and unresolved, affecting the Hedera network. # Retrieve all scheduled maintenances Source: https://docs.hedera.com/api-reference/retrieve-all-scheduled-maintenances /hedera-status-api.yaml get /scheduled-maintenances.json Fetches details about all scheduled maintenance events for the Hedera network. # Retrieve the current status of the Hedera network Source: https://docs.hedera.com/api-reference/retrieve-the-current-status-of-the-hedera-network /hedera-status-api.yaml get /status.json Fetches the overall status and health indicators of the Hedera network. # Retrieve unresolved incidents Source: https://docs.hedera.com/api-reference/retrieve-unresolved-incidents /hedera-status-api.yaml get /incidents/unresolved.json Provides information about all currently unresolved incidents affecting the Hedera network. # Retrieve upcoming scheduled maintenances Source: https://docs.hedera.com/api-reference/retrieve-upcoming-scheduled-maintenances /hedera-status-api.yaml get /scheduled-maintenances/upcoming.json Provides information about all upcoming scheduled maintenance events for the Hedera network. # Get schedule by id Source: https://docs.hedera.com/api-reference/schedules/get-schedule-by-id /openapi.yaml get /api/v1/schedules/{scheduleId} Returns schedule information based on the given schedule id # List schedules entities Source: https://docs.hedera.com/api-reference/schedules/list-schedules-entities /openapi.yaml get /api/v1/schedules Lists schedules on the network that govern the execution logic of scheduled transactions. This includes executed and non executed schedules. # Add input files Source: https://docs.hedera.com/api-reference/session-verification/add-input-files /smart-contract-verification-api.yaml post /session/input-files # Clear session data Source: https://docs.hedera.com/api-reference/session-verification/clear-session-data /smart-contract-verification-api.yaml post /session/clear # Get session data Source: https://docs.hedera.com/api-reference/session-verification/get-session-data /smart-contract-verification-api.yaml get /session/data # Import deployed contract trying to fetch metadata and files form IPFS Source: https://docs.hedera.com/api-reference/session-verification/import-deployed-contract-trying-to-fetch-metadata-and-files-form-ipfs /smart-contract-verification-api.yaml post /session/input-contract # Verify checked contract in session Source: https://docs.hedera.com/api-reference/session-verification/verify-checked-contract-in-session /smart-contract-verification-api.yaml post /session/verify-checked # Verify from Etherscan Source: https://docs.hedera.com/api-reference/session-verification/verify-from-etherscan /smart-contract-verification-api.yaml post /session/verify/etherscan # Verify solc-json Source: https://docs.hedera.com/api-reference/session-verification/verify-solc-json /smart-contract-verification-api.yaml post /session/input-solc-json # Post verify Source: https://docs.hedera.com/api-reference/stateless-verification/post-verify /smart-contract-verification-api.yaml post /verify Sends provided files for verification # Verify an Etherscan verified contract Source: https://docs.hedera.com/api-reference/stateless-verification/verify-an-etherscan-verified-contract /smart-contract-verification-api.yaml post /verify/etherscan # Verify solc-json Source: https://docs.hedera.com/api-reference/stateless-verification/verify-solc-json /smart-contract-verification-api.yaml post /verify/solc-json # Get an nfts transction history Source: https://docs.hedera.com/api-reference/tokens/get-an-nfts-transction-history /openapi.yaml get /api/v1/tokens/{tokenId}/nfts/{serialNumber}/transactions Returns a list of transactions for a given non-fungible token # Get nft info Source: https://docs.hedera.com/api-reference/tokens/get-nft-info /openapi.yaml get /api/v1/tokens/{tokenId}/nfts/{serialNumber} Returns information for a non-fungible token # Get token by id Source: https://docs.hedera.com/api-reference/tokens/get-token-by-id /openapi.yaml get /api/v1/tokens/{tokenId} Returns token entity information given the id # List nfts Source: https://docs.hedera.com/api-reference/tokens/list-nfts /openapi.yaml get /api/v1/tokens/{tokenId}/nfts Returns a list of non-fungible tokens # List token balances Source: https://docs.hedera.com/api-reference/tokens/list-token-balances /openapi.yaml get /api/v1/tokens/{tokenId}/balances Returns a list of token balances given the id. This represents the Token supply distribution across the network # List tokens Source: https://docs.hedera.com/api-reference/tokens/list-tokens /openapi.yaml get /api/v1/tokens Returns a list of tokens on the network. # Get topic by ID Source: https://docs.hedera.com/api-reference/topics/get-topic-by-id /openapi.yaml get /api/v1/topics/{topicId} Returns the topic details for the given topic ID. # Get topic message by consensusTimestamp Source: https://docs.hedera.com/api-reference/topics/get-topic-message-by-consensustimestamp /openapi.yaml get /api/v1/topics/messages/{timestamp} Returns a topic message the given the consensusTimestamp. # Get topic message by id and sequence number Source: https://docs.hedera.com/api-reference/topics/get-topic-message-by-id-and-sequence-number /openapi.yaml get /api/v1/topics/{topicId}/messages/{sequenceNumber} Returns a single topic message for the given topic id and sequence number. # List topic messages by id Source: https://docs.hedera.com/api-reference/topics/list-topic-messages-by-id /openapi.yaml get /api/v1/topics/{topicId}/messages Returns the list of topic messages for the given topic id. # Get transaction by id Source: https://docs.hedera.com/api-reference/transactions/get-transaction-by-id /openapi.yaml get /api/v1/transactions/{transactionId} Returns transaction information based on the given transaction id # List transactions Source: https://docs.hedera.com/api-reference/transactions/list-transactions /openapi.yaml get /api/v1/transactions Lists transactions on the network. This includes successful and unsuccessful transactions. # Core Concepts Source: https://docs.hedera.com/hedera/core-concepts # Accounts Source: https://docs.hedera.com/hedera/core-concepts/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. 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](/hedera/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. ## FAQs A Hedera account is a unique entity in the Hedera Network that can hold tokens. These can be Hedera's native fungible token (HBAR), custom fungible, or [non-fungible tokens (NFTs)](/hedera/support-and-community/glossary#non-fungible-token-nft). New accounts are created by submitting a transaction to the network and paying the transaction fee. You'll need access to an existing account with sufficient HBAR to cover this fee. If you don't have access to an existing account, you can use a supported wallet, visit the [Hedera Developer Portal](https://portal.hedera.com/), or use the "Auto Account Creation" feature for applications. [Auto Account Creation](/hedera/core-concepts/accounts/auto-account-creation) allows applications to generate free user accounts instantly, even without an internet connection, by creating an account alias. If an account is created with an [EVM address](/hedera/core-concepts/accounts/auto-account-creation#evm-address) via [Auto Account Creation](/hedera/core-concepts/accounts/auto-account-creation), 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. # Account Creation Source: https://docs.hedera.com/hedera/core-concepts/accounts/account-creation New accounts are created on the Hedera ledger by submitting a transaction to the network and paying the transaction fee to create the account. The transaction fee to create the account includes the costs required to use network resources, reach consensus amongst the nodes, and share the data across the network. You will need access to an existing account with enough HBAR to cover the transaction fee to create the account. Suppose you don't have access to an existing account. In that case, you can use a supported wallet or visit the [Hedera Developer Portal](https://portal.hedera.com/register) to create an account. You can also ask a friend with an existing Hedera account to generously create one for you. Applications can check out the "[Auto Account Creation](/hedera/core-concepts/accounts/auto-account-creation)" feature to make free Hedera user accounts. When an account is created, it is stored in the state on the Hedera network. The current state can be queried from the ledger and viewed in a [Network Explorer](/hedera/networks/community-mirror-nodes). Each account has at least one public and private key pair. The private key(s) on the account is used to sign and authorize transactions that involve the account. To view the properties that can be set for an account, check out the "[Account Properties](/hedera/core-concepts/accounts/account-properties)" section. An account can be created through any of the following methods. To create accounts using the SDKs, you will need access to an existing account to pay for the transaction fee to create a new account. Supported wallets may or may not support creating testnet and previewnet accounts. ❌ mainnet
✅ testnet
✅ previewnet ✅ mainnet
🔶 testnet
🔶 previewnet ✅ mainnet
✅ testnet
✅ previewnet # Account Properties Source: https://docs.hedera.com/hedera/core-concepts/accounts/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** `..`. 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. #### Support for Arbitrary Shards & Realms The Hedera network now supports non-zero realm IDs (such as *`0.100.0`*). This is particularly important for private networks that will populate realm values. The default values for the Hedera network are `shard 0` and `realm 0`. For private networks or other implementations, shard and realm values will be different. Refer to the specific network's documentation for accurate values in your implementation. Format: **`shardNum`**`.realmNum.account` The shard number is the number of the shard the account exists in. A shard is a partition of the data received by the nodes participating in a given shard. Today, Hedera operates in only one shard. This value will remain zero until Hedera operates in more than one shard. This value is non-negative and is 4 bytes. Default Hedera Mainnet: `0` Format: `shardNum.`**`realNum`**`.account` The realm number is the number of the realm the account exists within a given shard. Today, Hedera operates in only one realm. This value will remain zero until Hedera operates in more than one shard. This value is non-negative and is `8` bytes. The account can only belong to precisely one realm. The realm ID can be reused in other shards. Default for Hedera Mainnet: `0` Format: `shardNum.realNum.`**`account`** The `account` can be one of the following: * [Account Number](#account-number) \\ * [Account Alias](#account-alias) #### Examples of Valid Account IDs * `0.0.123` - Account 123 in `realm 0` of `shard 0` (traditional format) * `0.100.456` - Account 456 in `realm 100` of `shard 0` (non-zero realm ID) * `1.0.789` - Account 789 in `realm 0` of `shard 1` (future support for non-zero shard ID) ### ID Requirements * A shard number must be unique across the network * A realm number must be unique within a shard (but may be reused in different shards) * An entity number must be unique within a realm (but may be reused in different realms) ### Entity Counter Each realm maintains a single counter for assigning entity numbers. This ensures that if there is a file with ID `0.1.2`, then there won't be an account or smart contract instance with ID `0.1.2` in the same realm. ### **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 `..`.
Account Number IDDescription
0.0.10The 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](/hedera/core-concepts/accounts/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 IDAccount Number Alias Example
0.0.10The hex encoding value for 10 is "0a."

000000000000000000000000000000000000000a
### 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](/hedera/core-concepts/accounts/..#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 `..`. 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 `..` 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](#keys) used to determine the cryptographic signature needed to sign transactions for the account. `0.0.302d300706052b8104000a03220002d588ec1000770949ab77516c77ee729774de1c8fe058cab6d64f1b12ffc8ff07` #### **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](https://ethereum.github.io/yellowpaper/paper.pdf). 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](/hedera/core-concepts/accounts/auto-account-creation) flow. The EVM address is also commonly known as the public address. The EVM address account ID format is `..` where `alias` is the EVM address. The EVM address account and the [account number alias](#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. #### Value Transfer Behavior with Account Identifiers * `CryptoTransfer` Transactions: When transferring value via the SDK, any of the four account identifiers can be used: * Standard Hedera account ID (`shard.realm.num`) * Public key alias * Account number alias (a hex-encoded form of the account number prefixed with 20 bytes of zeros) * EVM address alias (the rightmost 20 bytes of the 32-byte Keccak-256 hash of the ECDSA public key) * EVM Transactions: The address used for a value transfer recipient in EVM transactions (`ContractCreate`, `ContractCall`, and `EthereumTransaction`) must be the main one for the account. This will be the ECDSA-derived EVM address alias if set on the account. If not, the long zero address (account number alias) will be used. This ensures compatibility with the EVM's expected behavior for account addresses. The shard number and realm number are set to `0` followed by the EVM address. **Example** EVM Address: `b794f5ea0ba39494ce839613fffba74279579268` HEX Encoded EVM Address: `0xb794f5ea0ba39494ce839613fffba74279579268` EVM Address Account Alias Account ID: `0.0.b794f5ea0ba39494ce839613fffba74279579268` Reference Hedera Improvement Proposal: [HIP-583](https://hips.hedera.com/hip/hip-583) ## 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. The effective consensus timestamp at (and after) which the entity is set to expire. The auto-renewal account is the account that will be charged for the auto-renewal fee when the account expires. By default, the auto-renewal account is the account itself. The auto-renewal account can be updated to another account by the account owner. The auto-renewal account must sign the transaction to update the auto-renewal account. The interval at which this account will be charged the auto renewal fees. The maximum auto renew period for an account is be limited to 3 months (8000001 sec seconds). The minimum auto renew period is 30 days. The auto renew period is mutable and can be updated at any time. If there are insufficient funds, then it extends as long as possible. If it is empty when it expires, then it is deleted. Reference: [HIP-16](https://hips.hedera.com/hip/hip-16) ## 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](https://hips.hedera.com/hip/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` defines how many tokens an account can automatically associate with.
Property Value
0Automatic token associations or airdrops are not allowed; the account must manually associate each token.
-1Unlimited automatic token associations are allowed. this is the default for accounts created via auto account creation and for accounts that originated as hollow accounts (created from EVM aliases) and have since been completed. a value of -1 allows the account to receive new tokens without manually associating them
> 0the account can automatically associate up to that number of tokens. the sender covers the maxAutoAssociations fee and the first auto‑renewal rent for the association.
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. Reference Hedera Improvement Proposal: [HIP-23](https://hips.hedera.com/hip/hip-23), [HIP-904](https://hips.hedera.com/hip/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](/hedera/networks/community-mirror-nodes) 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 0.0.tokenNum

ex: 0.0.100

| | **Non-Fungible Token (NFTs)** | Custom non-fungible tokens (NFTs) created on Hedera. |

NFT ID is represented as 0.0.tokenNum-serialNum.

ex: 0.0.101-1

| ## 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. Warning: 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](/hedera/core-concepts/staking) 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. An account can optionally elect to stake its HBAR to a node in the Hedera network. The staked node ID is the node an account can stake to. The full balance of the account is staked to the node. Do not confuse the node ID with the node's account ID. If you stake to the node's account ID, your account will not earn staking rewards. The staked account balance is liquid at all times. This means you can transfer HBAR tokens in and out of the account, and your account will continue to be staked to the node without disruption. There is no lock-up period. This means the HBAR tokens in your account are not held for a period of time before you can use them. The node ID for a node can be found [here](/hedera/networks/mainnet/mainnet-nodes) or can be queried from the [nodes REST API](https://testnet.mirrornode.hedera.com/api/v1/docs/#/network/getNetworkNodes).\\ Example: Node ID: `1` An account can optionally elect to stake its HBAR to another account in the Hedera network. This is known as **indirect staking**. The staked account ID is the ID of the account to stake to. The full balance of the account is staked to the specified account. There is no lock-up period and the balance is always liquid just like staking to a node. Accounts that stake to another account do not earn the staking rewards. For example, If account A is staked to account B, account B will need to be staked to a node in order to contribute to network security and earn staking rewards. Account B will earn the rewards for staking when staked to a node for both the HBAR balances in both Account A + Account B. Account A will not earn rewards for staking. Example: Account ID: `0.0.10` Accounts can decline to earn staking rewards when they stake to a node or an account. The staked account still contributes to the staking weight of the node, but does not earn rewards or is calculated as part of the payment of the rewards to the other accounts that have elected to earn rewards. By default, all staked accounts will earn rewards unless this boolean flag is set to true. This election can be changed by updating the account properties. Hedera treasury accounts enable this flag to decline earning staking rewards. Default: `true` (all accounts accept earning staking rewards if the account is staked) #### Daily Rewards for Active Nodes Hedera now guarantees minimum daily rewards for active nodes on the network. Key features include: * **Active Node Definition**: Nodes that create a "judge" in a significant fraction of rounds during a staking period * **Minimum Guaranteed Rewards**: Active nodes receive a minimum daily reward amount, configurable by the network * **Opt-Out Option**: Node operators can decline rewards by setting the `declineReward` flag to true For node operators: To opt out of receiving rewards, use the `setDeclineReward(true)` method when creating or updating your node. ***Reference:*** [***HIP-1064***](https://hips.hedera.com/hip/hip-1064) ### Staking Information The network stores the staking metadata for an account and contract accounts. This information is returned in account information query requests (`AccountInfoQuery` or`ContractInfoQuery`). 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](https://hips.hedera.com/hip/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. The effective consensus timestamp at (and after) which the entity is set to expire. The auto renew account is the account that will be used to pay for the auto renewal fees. If there is no auto renew account specified, the auto renewal fees will be charged to the account. The interval at which this account will be charged the auto renewal fees. The maximum auto renew period for an account is be limited to 3 months (8000001 sec seconds). The minimum auto renew period is 30 days. The auto renew period is mutable and can be updated at any time. If there are insufficient funds, then it extends as long as possible. If it is empty when it expires, then it is deleted. Reference Hedera Improvement Proposal: [HIP-16](https://hips.hedera.com/hip/hip-16) # Auto Account Creation Source: https://docs.hedera.com/hedera/core-concepts/accounts/auto-account-creation 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 can make these by generating an **account alias.** The alias account ID format used to specify the account alias in Hedera transactions comprises the shard ID, realm ID, and account alias `..`. This is an alternative account identifier compared to the standard account number format `..`. The account alias can be either one of the supported types: The public key alias can be an ED25519 or ECDSA secp256k1 public key type. **Example** ECDSA secp256k1 Public Key: `02d588ec1000770949ab77516c77ee729774de1c8fe058cab6d64f1b12ffc8ff07` DER Encoded ECDSA secp256k1 Public Key Alias: `302d300706052b8104000a03220002d588ec1000770949ab77516c77ee729774de1c8fe058cab6d64f1b12ffc8ff07` ECDSA secp256k1 Public Key Alias Account ID: `0.0.302d300706052b8104000a03220002d588ec1000770949ab77516c77ee729774de1c8fe058cab6d64f1b12ffc8ff07` EDDSA ED25519 Public Key: `1a5a62bb9f35990d3fea1a5bb7ef6f1df0a297697adef1e04510c9d4ecc5db3f` DER Encoded EDDSA ED25519 Public Key Alias: `302a300506032b65700321001a5a62bb9f35990d3fea1a5bb7ef6f1df0a297697adef1e04510c9d4ecc5db3f` EDDSA ED25519 Public Key Alias Account ID: `0.0.302a300506032b65700321001a5a62bb9f35990d3fea1a5bb7ef6f1df0a297697adef1e04510c9d4ecc5db3f` The EVM address alias 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 EVM Address Alias Account ID. 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` EVM Address Alias Account ID: `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 * Sets the account key if the alias is a public key, or leaves the account **hollow** if the alias is an EVM address 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`](/hedera/sdks-and-apis/sdks/accounts-and-hbar/transfer-cryptocurrency)). * 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. ## Examples * [Java](https://github.com/hiero-ledger/hiero-sdk-java/blob/main/examples/src/main/java/com/hedera/hashgraph/sdk/examples/AccountAliasExample.java) * [JavaScript](https://github.com/hiero-ledger/hiero-sdk-js/blob/main/examples/account-alias.js) * [Go](https://github.com/hiero-ledger/hiero-sdk-go/blob/main/examples/alias_id_example/main.go) * [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/transfer-using-evm-address.js) * [Go](https://github.com/hiero-ledger/hiero-sdk-go/blob/main/examples/account_create_token_transfer/main.go) # Hiero Hooks Source: https://docs.hedera.com/hedera/core-concepts/accounts/hiero-hooks Hiero Hooks provide programmable extension points to inject Solidity-based logic directly into the network's transaction pipeline. Hooks attach to accounts to enforce custom rules on actions like token transfers, but they do not run automatically—a hook is triggered only when explicitly referenced in a `TransferTransaction` (e.g., `CryptoTransfer`). Unlike regular smart contracts, hooks execute in a special EVM context where `address(this)` is always the reserved system address `0x16d`, enabling them to act with the privileges of the account they're attached to. This model combines smart contract flexibility with native HAPI transaction efficiency, allowing custom validation without deploying full-scale contracts. ## Core Concepts Hooks are a mechanism for [**Account Abstraction**](/hedera/support-and-community/glossary#account-abstraction) on Hedera, enabling custom validation and logic without migrating entire applications to the EVM. A hook is a small piece of Solidity logic that is **triggered only when referenced/specified in a `TransferTransaction`**—not automatically. Think of it like a webhook for the ledger itself. Instead of waiting for an off-chain call, the hook runs inside the network when a transaction explicitly references it. Hooks can check conditions before execution, update state, log data, or stop a transfer if validation fails. ### Why Hooks? Before Hooks, developers faced two major limitations: 1. **Protocol dependency**: New functionality required network-wide upgrades through HIPs (slow and heavyweight) 2. **EVM migration**: Moving applications to smart contracts sacrificed the performance and cost-efficiency of native HAPI transactions Hooks solve this by allowing developers to inject custom logic directly into native flows, offering better performance and lower cost than general-purpose `ContractCall` operations. ### Key Characteristics | Concept | Description | | :------------------ | :----------------------------------------------------------------------------------------------------- | | **Trigger Model** | **Triggered only when referenced/specified** in a `TransferTransaction`—not automatic event listeners. | | **Implementation** | EVM Hooks: Solidity contracts executed by the network's EVM. | | **Extension Point** | Account Allowance Hooks validate transfers during a `CryptoTransfer`. | | **Key Advantage** | Custom logic on native assets (HBAR and HTS tokens) without `ContractCall` overhead. | | **Use Cases** | Compliance rules, transfer constraints, one-time passcodes, receiver signature waivers. | *** ## Extension Points Hooks attach to specific extension points in a transaction's lifecycle. An extension point defines the type of hook allowed for a transaction but doesn't specify when or why a hook is activated. Currently, the first supported extension point is the Account Allowance Hook (`ACCOUNT_ALLOWANCE_HOOK`). This hook runs when a `TransferTransaction` references the hook on a transfer entry, acting as a programmable replacement for traditional ERC-style allowances. Future extension points may include other native transaction types or entity lifecycle events, enabling hooks to validate or augment a wide range of on-chain operations. *** ## Propose a New Hook Hooks are designed to be extended by the community. If you have a use case that would benefit from a new extension point — such as hooks for topic submissions, token minting, or scheduled transactions — you can propose it through the [Hiero Improvement Proposal (HIP) process](https://hips.hedera.com/). To get started: 1. Review the [HIP-1195 specification](https://hips.hedera.com/hip/hip-1195) to understand the existing hooks architecture and extension point model 2. Draft a new HIP that defines your proposed extension point, its trigger conditions, and the Solidity interface hooks would implement 3. Submit your proposal to the [Hiero HIP repository](https://github.com/hiero-ledger/hiero-improvement-proposal) for community review and discussion The hooks framework is built to support new extension points without protocol-level changes to the core hook infrastructure. # Network Accounts Source: https://docs.hedera.com/hedera/core-concepts/accounts/network-accounts The Hedera network uses several special, network-controlled accounts for its operations. These accounts are fundamental to the network's fee structure, staking rewards, and overall economic model. ### Special Accounts Comparison | Account ID | Name | Purpose | Accepts Deposits? | Has Keys? | | :--------- | :------------------------ | :--------------------------------------------------------------------------------------------- | :---------------- | :-------- | | `0.0.98` | Network Admin Fee Account | Receives the majority of network transaction fees (typically 80%). | Yes | Yes | | `0.0.800` | Staking Rewards Account | Holds funds for staking reward distribution. Receives a portion of daily fees (typically 10%). | Yes (donations) | No | | `0.0.801` | Node Rewards Account | Holds funds for node reward distribution. Receives a portion of daily fees (typically 10%). | No | No | | `0.0.802` | Fee Collection Account | Consolidates all transaction fees before daily distribution. | No | No | ### Account Details #### Fee Collection Account (`0.0.802`) Introduced in [HIP-1259](https://hips.hedera.com/hip/hip-1259), this account serves as a temporary holding account for all transaction fees. It is fully code-controlled, has no keys, and cannot accept HBAR deposits from users. This design simplifies transaction records and improves network efficiency. #### Staking Rewards Account (`0.0.800`) This account holds the HBAR that will be distributed to users who are staking their tokens. It receives a portion of the daily accumulated fees from the Fee Collection Account. While it does not have keys, it can accept HBAR donations from the community. #### Node Rewards Account (`0.0.801`) This account holds the HBAR that will be distributed to node operators for their services. It receives a portion of the daily accumulated fees from the Fee Collection Account. It does not have keys and cannot accept HBAR deposits. #### Network Admin Fee Account (`0.0.98`) This account receives the largest portion of the daily accumulated fees from the Fee Collection Account (typically 80%). These funds are used to support the long-term growth and development of the Hedera network. Unlike the other special fee accounts, this account has keys and can accept HBAR deposits. # Fee Model Source: https://docs.hedera.com/hedera/core-concepts/fee-model Understand the simplified `base-fee-plus-extras` model for Hedera transaction and query fees introduced by [HIP-1261](https://hips.hedera.com/hip/hip-1261) ## Overview Hedera uses a simplified fee model where every transaction cost is calculated as a **base fee plus extras**. Introduced in [HIP-1261](https://hips.hedera.com/hip/hip-1261), this model replaces the previous resource-weighted fee schedule with transparent, predictable pricing. All fees are defined in **USD as tinycents** and converted to HBAR at the current network exchange rate before being charged. The fee schedule is stored as a JSON document in system file `0.0.113` on the network. **What is a tinycent?** One cent USD = 10⁸ tinycents. One dollar USD = 10¹⁰ tinycents. Tinycents provide high precision for fee calculations without floating-point math. | Term | Definition | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ | | **Base Fee** | The fixed minimum fee in tinycents for a transaction or query before any extras are applied. | | **Extras** | Additional cost factors on top of the base fee, such as signatures, bytes, keys, or gas. Each has a per-unit fee and an optional included count. | | **Included Count** | Units of an extra included for free in the base fee before additional charges apply. | | **Tinycent** | The smallest fee unit. 10⁸ tinycents = 1 cent USD. 10¹⁰ tinycents = 1 USD. | | **Node Fee** | Fee paid to the submitting node. Same calculation for all transaction types. | | **Network Fee** | A multiplier of the node fee covering consensus and storage. | | **Service Fee** | Covers execution costs. Varies by transaction type. | ## Fee Components Every transaction fee is split into three components: | Component | What It Covers | How It's Calculated | | ----------- | ------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | | **Node** | Compensates the submitting node for pre-checking and forwarding the transaction | `baseFee` + extras (processing bytes, signatures). Identical formula for **all** transaction types. | | **Network** | Covers gossip, consensus, signature verification, and blockchain storage | A configurable multiplier of the node fee (default: 9×). | | **Service** | Covers execution costs, state changes, and blockstream output | `baseFee` + transaction-specific extras (keys, token types, gas, etc.). Varies by transaction type. | ```text theme={null} totalFee = nodeFee + networkFee + serviceFee ``` The node and network fees are uniform across all transaction types — only the service fee varies per transaction. ## Extras Extras are additional cost factors applied on top of a base fee. Each extra has a **name**, a **per-unit fee** (in tinycents), and an optional **included count** — the number of units included for free before additional charges apply. Hedera transaction and query fees follow a `base fee + extras` [fee model](/hedera/core-concepts/fee-model) defined by [HIP-1261 (Simple Fees)](https://hips.hedera.com/hip/hip-1261). For current per-unit fees in USD, see the [mainnet fees page](/hedera/networks/mainnet/fees#extras). The following extras are defined in the fee schedule: | Extra | Description | | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `Signatures` | Signature verifications on the transaction. 1 included in base fee. | | `Keys` | Keys defined when creating or updating an entity. 1 included in base fee. | | `Accounts` | Accounts loaded during handling. 2 included on `CryptoTransfer`. | | `TokenTypes` | Distinct token types referenced in a transfer. 1 included in base fee. | | `Gas` | Gas consumed by hook program execution within transfers and by `ContractCallLocal` queries. | | `Allowances` | Allowances granted on `ApproveAllowance`, or NFT allowances deleted on `DeleteAllowance`. 1 included in base fee. | | `Airdrops` | Pending airdrops created — applies only when the recipient hasn't pre-associated the token. | | `TokenTransferBase` | Applies once per `CryptoTransfer` with one or more token transfers when no token has custom fees. | | `TokenTransferBaseCustomFees` | Applies once per `CryptoTransfer` with at least one custom-fee token. | | `TokenCreateWithCustomFee` | Added to `TokenCreate` when custom fees or a `fee_schedule_key` are defined. | | `TokenMintNft` | NFT serials minted on `TokenMint`. 1 included in base fee. | | `TokenMintNftBase` | Added once per `TokenMint` operation that mints NFTs (not fungible). | | `NftUpdate` | NFTs updated on `TokenUpdateNfts`. 1 included in base fee. | | `TokenAssociate` | Token associations on `TokenAssociate` or auto-associations during a transfer. 1 included in base fee. | | `ConsensusCreateTopicWithCustomFee` | Added to `ConsensusCreateTopic` when the new topic has custom fees defined. | | `ConsensusSubmitMessageWithCustomFee` | Per message submitted to a topic with custom fees. | | `ConsensusSubmitMessageWithCustomFeeBytes` | Per byte of message payload on a custom-fee topic. First 1,024 bytes included in base fee. | | `ConsensusSubmitMessageWithoutCustomFeeBytes` | Per byte of message payload on a regular topic. First 100 bytes included in base fee. | | `ScheduleCreateContractCallBase` | Added to `ScheduleCreate` when the scheduled inner operation is a contract call. | | `Records` | Records returned by `TransactionGetRecord`. 1 included in base fee. | | `StateBytes` | Bytes persisted to state on `FileCreate`, `FileUpdate`, or `FileAppend`. 1,000 bytes included per transaction. | | `ProcessingBytes` | Transaction body bytes processed by the node. 1,350 included in the base fee. | | `EvmDispatchSurcharge` | A 20% premium added to the HAPI fee of any operation invoked from a smart contract via Hedera's system contracts (HTS, HAS, HSS). Does not apply to pure-EVM operations. | Hedera transaction and query fees follow a `base fee + extras` [fee model](/hedera/core-concepts/fee-model) defined by [HIP-1261 (Simple Fees)](https://hips.hedera.com/hip/hip-1261). The **included count** means you don't pay extra for typical usage. For example, the node fee includes a default allotment of processing bytes and one signature — a small, single-signature transaction pays zero byte and signature extras on the node component. ## Fee Calculation Example Consider a basic `CryptoCreate` transaction with a single key and 150 bytes: The node fee applies the same formula to all transactions: ```text wrap theme={null} Node baseFee: 100,000 tinycents ProcessingBytes extra: 150 bytes used, 1,024 included → 0 charged → 0 Signatures extra: 1 signature, 1 included → 0 charged → 0 ───────────────────────────────────────────────────────────────────── Node fee total: 100,000 tinycents ``` The network fee is a multiplier of the node fee: ```text theme={null} Network fee = 9 × 100,000 = 900,000 tinycents ``` The service fee is specific to `CryptoCreate`: ```text wrap theme={null} Service baseFee: 499,000,000 tinycents Keys extra: 1 key used, 1 included → 0 charged → 0 ────────────────────────────────────────────────────────── Service fee total: 499,000,000 tinycents ``` ```text wrap theme={null} Total = 100,000 + 900,000 + 499,000,000 = 500,000,000 tinycents ≈ $0.05 USD ``` This amount is converted to HBAR at the current exchange rate and charged to the payer. If the same transaction used **two** keys instead of one, the service fee would increase by the per-key extra fee (e.g., 10,000,000 tinycents), because the included count of 1 key is exceeded by 1. ## Transaction Outcomes and Fees Not all transactions succeed. The fee charged depends on how far the transaction progresses: | Outcome | Description | Who Pays | Components Charged | | -------------- | ---------------------------------------------------------------------------------------------------------------- | --------------- | ------------------------------- | | **Successful** | Transaction executed normally | Payer | Node + Network + Service | | **Bad** | Passed due-diligence but failed during execution (e.g., out of gas, semantically wrong, inconsistent with state) | Payer | Node + Network + Service (full) | | **Unhandled** | Well-formed but not executed (e.g., throttled, duplicate, unexecuted portion of an atomic batch) | Payer | Node + Network | | **Invalid** | Failed due-diligence checks by the submitting node (e.g., payer can't afford the fee, incompatible fields) | Submitting node | Network only | | **Unreadable** | Bytes cannot be parsed as a valid protobuf `Transaction` | Submitting node | Punitive flat fee | Bad transactions are charged full freight (node + network + service) to protect the network from denial-of-service attacks. This applies even if the transaction fails due to a bug (`FAIL_INVALID`). ## Congestion Pricing [HIP-1313](https://hips.hedera.com/hip/hip-1313#hip-1313) introduces an optional high-volume lane for entity-creation transactions above the standard throttle. When a transaction opts in with `setHighVolume(true)`, the network may apply a fee multiplier if the high-volume throttle bucket is under load. The multiplier scales with congestion level and is reflected in the `high_volume_multiplier` field of the fee estimate response. The `high_volume_multiplier` field uses a 1-based scale `(1 = 1×, 4 = 4×)`. `TransactionRecord.highVolumePricingMultiplier` — available after execution — uses a `1000-based scale (1000 = 1×, 4000 = 4×)`. Both represent the same multiplier. To simulate the fee at a specific congestion level before committing, use `setHighVolumeThrottle()` on `FeeEstimateQuery`. See [Estimating Fees](/hedera/sdks-and-apis/sdks/fees/fee-estimation) with the SDK for code examples. ## Fee Schedule Configuration The fee schedule is a JSON document stored in system file **`0.0.113`**. It defines: | Section | Purpose | | ------------ | --------------------------------------------------------------- | | `extras` | All available extra fee definitions (name + per-unit fee) | | `node` | Node fee configuration (base fee + extras with included counts) | | `network` | Network fee configuration (multiplier) | | `services` | Per-service groupings of transaction and query fee definitions | | `unreadable` | Punitive fee for unparsable transaction bytes | ```json theme={null} { "version": 0, "extras": [ { "name": "Signatures", "fee": 100000 }, { "name": "ProcessingBytes", "fee": 10000 }, { "name": "Keys", "fee": 10000000 } ], "node": { "baseFee": 100000, "extras": [ { "name": "ProcessingBytes", "includedCount": 1024 }, { "name": "Signatures", "includedCount": 1 } ] }, "network": { "multiplier": 9 }, "services": [ { "name": "CryptoService", "transactions": [ { "name": "CryptoCreate", "baseFee": 499000000, "extras": [ { "name": "Keys", "includedCount": 1 } ] } ], "queries": [] } ], "unreadable": { "fee": 100000000000 } } ``` The legacy fee schedule in system file `0.0.111` remains available in its existing format for backward compatibility, but it will not receive further updates. ## Fee Estimation You can estimate transaction fees before submitting them using the Mirror Node REST API: ```bash theme={null} POST /api/v1/network/fees?mode=intrinsic Content-Type: application/protobuf ``` The endpoint supports two modes: | Mode | Behavior | | --------------------- | ------------------------------------------------------------------------------------- | | `intrinsic` (default) | Estimates based on the transaction's inherent properties (size, signatures, keys) | | `state` | Estimates using the mirror node's latest known state (e.g., checks if accounts exist) | See [Mirror Node REST API Network](/hedera/sdks-and-apis/rest-api/network) for the full endpoint specification and response format. ## Queries Queries follow the same base-fee-plus-extras structure as transactions. Some queries are marked as `free` in the fee schedule (e.g., `CryptoGetAccountBalance`, `TransactionGetReceipt`). For non-free queries, the SDK creates a `CryptoTransfer` payment transaction to pay the node, network, and service fees. ## Fee Schedule Schema (Protobuf) The fee schedule is defined as a set of protobuf messages. The wire format is JSON, stored in system file `0.0.113`. ### FeeSchedule Top-level message defining the complete fee configuration. | Field | Type | Description | | ------------ | -------------------------------- | -------------------------------------------------------- | | `node` | NodeFeeSchedule | How to compute the node fee component. **Required.** | | `network` | NetworkFeeSchedule | How to compute the network fee component. **Required.** | | `unreadable` | UnreadableTransactionFeeSchedule | Fee for unparsable transaction bytes. Optional. | | `extras` | repeated ExtraFeeDefinition | All available extra fee definitions. No duplicate names. | | `services` | repeated ServiceFeeSchedule | Fee configs per network service. No duplicate names. | ### ExtraFeeDefinition Defines a single extra fee — an additional charge for a specific cost factor. | Field | Type | Description | | ------ | ------ | --------------------------------------------------------------- | | `name` | string | Unique name. Must match `[A-Za-z].*[A-Za-z0-9]*`. **Required.** | | `fee` | uint64 | Fee per unit in tinycents. Must be > 0. **Required.** | ### NodeFeeSchedule Node fee configuration. Applied identically to **all** transaction types. | Field | Type | Description | | ---------- | -------------------------- | ----------------------------------------------------------- | | `base_fee` | uint64 | Base fee in tinycents. Defaults to 0. | | `extras` | repeated ExtraFeeReference | Extras for computing the node fee. No duplicate references. | ### NetworkFeeSchedule Network fee configuration. Calculated as a multiplier of the node fee. | Field | Type | Description | | ------------ | ------ | ------------------------------------------------------ | | `multiplier` | uint32 | Multiplied by the node fee. Must be ≥ 1. **Required.** | ### ServiceFeeSchedule Groups transaction and query fee configs for a single gRPC service. | Field | Type | Description | | ---------- | ----------------------------- | --------------------------------------------------- | | `name` | string | Service name (e.g., `CryptoService`). **Required.** | | `schedule` | repeated ServiceFeeDefinition | Transaction/query fee configs. Must not be empty. | ### ServiceFeeDefinition Fee definition for a single transaction or query. | Field | Type | Description | | ---------- | -------------------------- | ----------------------------------------------------------------------- | | `name` | string | Transaction/query name (e.g., `CryptoCreate`). **Required.** | | `base_fee` | uint64 | Base fee in tinycents. Defaults to 0. | | `extras` | repeated ExtraFeeReference | Extras for this transaction/query. No duplicate references. | | `free` | bool | If `true`, `base_fee` and `extras` are ignored — the operation is free. | ### ExtraFeeReference References an ExtraFeeDefinition with an optional included count. | Field | Type | Description | | ---------------- | ------ | ----------------------------------------------------------------------- | | `name` | string | Name of the referenced extra. Must match a defined extra. **Required.** | | `included_count` | uint32 | Units included for free in the base fee. Defaults to 0. | ### UnreadableTransactionFeeSchedule Punitive fee for nodes that submit unparsable bytes. | Field | Type | Description | | ----- | ------ | ----------------------------------------------- | | `fee` | uint64 | Punitive fee in tinycents. Optional (may be 0). | ### Validation Rules Before a new fee schedule takes effect, the network validates it. If any rule fails, the schedule is rejected. The JSON must parse and conform to the `FeeSchedule` protobuf message. All required fields must be present and types must match. No unrecognized fields. All `baseFee` and `fee` fields must be non-negative integers. For extras, `fee` must be strictly > 0. The `multiplier` in `network` must be a positive integer ≥ 1. All names must match `[A-Za-z].*[A-Za-z0-9]*`. Extra names, service names, and transaction/query names within each service must be unique. Every extra reference must point to a defined extra. No duplicate references within a single list. If `free` is `true`, `baseFee` and `extras` are ignored during calculation but must still comply with all validation rules if present. ## Related The full Hiero Improvement Proposal specification. Fee tables for all transaction and query types on mainnet. Gas schedule and fee calculation for smart contracts. The fee collection account model that Simple Fees depends on. # Hashgraph Consensus Algorithm Source: https://docs.hedera.com/hedera/core-concepts/hashgraph-consensus-algorithms Distributed consensus algorithm The hashgraph consensus algorithm enables distributed consensus in an innovative, efficient way. Hashgraph is a distributed consensus algorithm and data structure that is fast, fair, and secure. This indirectly creates a trusted community, even when members do not necessarily trust each other. The [hashgraph consensus algorithm](/hedera/core-concepts/hashgraph-consensus-algorithms) and platform code are open-source under an Apache 2.0 license.