package proto

Mouse Melon logoGet desktop application:
View/edit binary Protocol Buffers messages

service AddressBookService

address_book_service.proto:102

* The Address Book service provides the ability for Hedera network node administrators to add, update, and remove consensus nodes. This addition, update, or removal of a consensus node requires governing council approval, but each node operator may update their own operational attributes without additional approval, reducing overhead for routine operations. Most operations are `privileged operations` and require governing council approval. ### For a node creation transaction. - The node operator SHALL create a `createNode` transaction. - The node operator MUST sign this transaction with the `Key` set as the `admin_key` for the new `Node`. - The node operator SHALL deliver the signed transaction to the Hedera council representative. - The Hedera council representative SHALL arrange for council members to review and sign the transaction. - Once sufficient council members have signed the transaction, the Hedera council representative SHALL submit the transaction to the network. - Upon receipt of a valid and signed node creation transaction the network software SHALL - Validate the threshold signature for the Hedera governing council - Validate the signature of the `Key` provided as the new `admin_key` for the `Node`. - Create the new node in state, this new node SHALL NOT be active in the network at this time. - When executing the next `freeze` transaction with `freeze_type` set to `PREPARE_UPGRADE`, update network configuration and bring the new node to an active status within the network. The node to be added SHALL be active in the network following this upgrade. ### For a node deletion transaction. - The node operator or Hedera council representative SHALL create a `deleteNode` transaction. - If the node operator creates the transaction - The node operator MUST sign this transaction with the `Key` set as the `admin_key` for the existing `Node`. - The node operator SHALL deliver the signed transaction to the Hedera council representative. - The Hedera council representative SHALL arrange for council members to review and sign the transaction. - Once sufficient council members have signed the transaction, the Hedera council representative SHALL submit the transaction to the network. - Upon receipt of a valid and signed node deletion transaction the network software SHALL - Validate the signature for the Hedera governing council - Remove the existing node from network state. The node SHALL still be active in the network at this time. - When executing the next `freeze` transaction with `freeze_type` set to `PREPARE_UPGRADE`, update network configuration and remove the node to be deleted from the network. The node to be deleted SHALL NOT be active in the network following this upgrade. ### For a node update transaction. - The node operator SHALL create an `updateNode` transaction. - The node operator MUST sign this transaction with the active `key` assigned as the `admin_key`. - The node operator SHALL submit the transaction to the network. Hedera council approval SHALL NOT be sought for this transaction - Upon receipt of a valid and signed node update transaction the network software SHALL - If the transaction modifies the value of the "node account", - Validate the signature of the active `key` for the account assigned as the _current_ "node account". - Validate the signature of the active `key` for the account to be assigned as the _new_ "node account". - Modify the node information held in network state with the changes requested in the update transaction. The node changes SHALL NOT be applied to network configuration, and SHALL NOT affect network operation at this time. - When executing the next `freeze` transaction with `freeze_type` set to `PREPARE_UPGRADE`, update network configuration according to the modified information in network state. The requested changes SHALL affect network operation following this upgrade.

service ConsensusService

consensus_service.proto:31

* The Hedera Consensus Service (HCS) provides the ability for a Hashgraph to provide aBFT consensus as to the order and validity of messages submitted to a *topic*, as well as a *consensus timestamp* for those messages.

service CryptoService

crypto_service.proto:36

* Transactions and queries for the Hedera Crypto Service.

The following queries are permanently removed. getStakersByAccountID, getFastTransactionRecord

service FileService

file_service.proto:54

* Service gRPC definitions for the Hedera File Service (HFS). #### Signature Requirements The HFS manages file authorization differently, depending on type of file transaction, and this can be surprising.<br/> The core element of file authorization is the `keys` field, which is a `KeyList`; a list of individual `Key` messages, each of which may represent a simple or complex key.<br/> The file service transactions treat this list differently.<br/> A `fileCreate`, `fileAppend`, or `fileUpdate` MUST have a valid signature from _each_ key in the list.<br/> A `fileDelete` MUST have a valid signature from _at least one_ key in the list. This is different, and allows a file "owned" by many entities to be deleted by any one of those entities. A deleted file cannot be restored, so it is important to consider this when assigning keys for a file.<br/> If any of the keys in a `KeyList` are complex, the full requirements of each complex key must be met to count as a "valid signature" for that key. A complex key structure (i.e. a `ThresholdKey`, or `KeyList`, possibly including additional `ThresholdKey` or `KeyList` descendants) may be assigned as the sole entry in a file `keys` field to ensure all transactions have the same signature requirements.

service FreezeService

freeze_service.proto:29

* A service to manage network "freeze" events. This service provides a facility to prepare for network upgrades, halt network processing, perform network software upgrades, and automatically restart the network following an upgrade.

service NetworkService

network_service.proto:31

* Basic "network information" queries. This service supports queries for the active services and API versions, and a query for account details.

service ScheduleService

schedule_service.proto:74

* Transactions and queries for the Schedule Service.<br/> The Schedule Service enables transactions to be submitted without all required signatures and offers a `scheduleSign` transaction to provide additional signatures independently after the schedule is created. The scheduled transaction may be executed immediately when all required signatures are present, or at expiration if "long term" schedules are enabled in network configuration. ### Execution Scheduled transactions SHALL be executed under the following conditions. 1. If "long term" schedules are enabled and `wait_for_expiry` is set for that schedule then the transaction SHALL NOT be executed before the network consensus time matches or exceeds the `expiration_time` field for that schedule. 1. If "long term" schedules are enabled and `wait_for_expiry` is _not_ set for that schedule, then the transaction SHALL be executed when all signatures required by the scheduled transaction are active for that schedule. This MAY be immediately after the `scheduleCreate` or a subsequent `scheduleSign` transaction, or MAY be at expiration if the signature requirements are met at that time. 1. If "long term" schedules are _disabled_, then the scheduled transaction SHALL be executed immediately after all signature requirements for the scheduled transaction are met during the `scheduleCreate` or a subsequent `scheduleSign` transaction. The scheduled transaction SHALL NOT be on expiration when "long term" schedules are disabled. A schedule SHALL remain in state and MAY be queried with a `getScheduleInfo` transaction after execution, until the schedule expires.<br/> When network consensus time matches or exceeds the `expiration_time` for a schedule, that schedule SHALL be removed from state, whether it has executed or not.<br/> If "long term" schedules are _disabled_, the maximum expiration time SHALL be the consensus time of the `scheduleCreate` transaction extended by the network configuration value `ledger.scheduleTxExpiryTimeSecs`. ### Block Stream Effects When a scheduled transaction is executed, the timestamp in the transaction identifier for that transaction SHALL be 1 nanosecond after the consensus timestamp for the transaction that resulted in its execution. If execution occurred at expiration, that transaction may be almost any transaction, including another scheduled transaction that executed at expiration.<br/> The transaction identifier for a scheduled transaction that is executed SHALL have the `scheduled` flag set and SHALL inherit the `accountID` and `transactionValidStart` values from the `scheduleCreate` that created the schedule.<br/> The `scheduleRef` property of the record for a scheduled transaction SHALL be populated with the schedule identifier of the schedule that executed.

service SmartContractService

smart_contract_service.proto:32

* The Hedera Smart Contract Service (HSCS) provides an interface to an EVM compatible environment to create, store, manage, and execute smart contract calls. Smart Contracts implement useful and often highly complex interactions between individuals, systems, and the distributed ledger.

service TokenService

token_service.proto:28

* Transactions and queries for the Token Service

The following queries are permanently removed getAccountNftInfos, getTokenNftInfos

service UtilService

util_service.proto:35

* The Utility Service provides a pseudo-random number generator. The single gRPC call defined for this service simply reports a single pseudo-random number in the transaction record. That value may either be a 32-bit integer within a requested range, or a 384-bit byte array. ### Block Stream Effects The requested value is reported exclusively in a `UtilPrngOutput` message.

message Account

account.proto:112

* A single Account in the Hedera distributed ledger. Each Account SHALL have a unique three-part identifier, a Key, and one or more token balances.<br/> Each Account SHALL have an alias, which has multiple forms, and MAY be set automatically.<br/> Several additional items SHALL be associated with the Account to enable full functionality.<br/> Assets SHALL be represented as linked-lists with only the "head" item referenced directly in the Account, and the remaining items SHALL be accessible via the token relation or unique tokens maps.<br/> Accounts, as most items in the network, SHALL have an expiration time, recorded as seconds since the epoch, and MUST be "renewed" for a small fee at expiration. This helps to reduce the amount of inactive accounts retained in state.<br/> Another account MAY be designated to pay any renewal fees and automatically renew an account for (by default) 30-90 days at a time as a means to optionally ensure important accounts remain active.<br/> Accounts MAY participate in securing the network by "staking" the account balances to a particular network node, and receive a portion of network fees as a reward. An account MAY optionally decline these rewards but still stake its balances.<br/> An account MAY optionally require that inbound transfer transactions be signed by that account as receiver (in addition to the sender's signature).<br/> As with all network entities, Account ID SHALL be represented as shard.realm.X.<br/> Alias and contractId SHALL be additional identifiers used to connect accounts to transactions before the account is fully enabled, or in EVM contracts.<br/> --- #### Alias There is considerable complexity with `alias` (aka `evm_address`) for Accounts. Much of this comes from the existence of a "hidden" alias for almost all accounts, and the reuse of the alias field for both EVM reference and "automatic" account creation. For the purposes of this specification, we will use the following terms for clarity. - `key_alias` is the account public key as a protobuf serialized message and used for auto-creation and subsequent lookup. This is only valid if the account key is a single `primitive` key, either ED25519 or ECDSA_SECP256K1. - `evm_address` exists for every account and is one of - `contract_address`, which is the 20 byte EVM contract address per EIP-1014 - `evm_key_address`, which is the keccak-256 hash of a ECDSA_SECP256K1 `primitive` key. - This is for accounts lazy-created from EVM public keys, when the corresponding ECDSA_SECP256K1 public key is presented in a transaction signed by the private key for that public key, the account is created that key assigned, and the protobuf-serialized form is set as the account alias. - `long_zero`, is a synthetic 20 byte address inferred for "normally" created accounts. It is constructed from the "standard" AccountID as follows. - 4 byte big-endian shard number - 8 byte big-endian realm number - 8 byte big-endian entity number The `alias` field in the `Account` message SHALL contain one of four values for any given account. - The `key_alias`, if the account was created by transferring HBAR to the account referenced by `key_alias`. - The `evm_key_address` if the account was created from an EVM public key - The `contract_address` if the account belongs to an EVM contract - Not-Set/null/Bytes.EMPTY (collectively `null`) if the account was created normally If the `alias` field of an `Account` is any form of `null`, then the account MAY be referenced by `alias` in an `AccountID` by using the `long_zero` address for the account. This "hidden default" alias SHALL NOT be stored, but is synthesized by the node software as needed, and may be synthesized by an EVM contract or client software as well. An AccountID in a transaction MAY reference an `Account` with `shard`.`realm`.`alias`.<br/> If the account `alias` field is set for an Account, that value SHALL be the account alias.<br/> If the account `alias` field is not set for an Account, the `long_zero` alias SHALL be the account alias.

message AccountAmount

basic_types.proto:444

* An account, and the amount that it sends or receives during a token transfer. This message is only relevant to fungible/common token transfers. Non-fungible/unique (NFT) token transfers MUST use the NftTransfer message.

Used in: TokenTransferList, TransactionRecord, TransferList

message AccountApprovalForAllAllowance

account.proto:487

* Permission granted by one account (the "funding" account) to another account (the "spender" account) that allows the spender to transfer all serial numbers of a specific non-fungible token (NFT) collection owned by the funding account.<br/> This is a broad permission, as it does not matter how many NFTs of the specified collection the funding account owns, the spender MAY dispose of any or all of them with this allowance.<br/> Each token type (typically a collection of NFTs) SHALL require a separate allowance.<br/> Allowances for a specific serial number MUST be directly associated with that specific non-fungible token, rather than the holding account. An allowance SHALL NOT transfer any tokens directly, it only permits transactions signed only by the spender account to transfer any non-fungible tokens of the specified type owned by the funding account.

Used in: Account

message AccountCryptoAllowance

account.proto:560

* Permission granted by one account (the "funding" account) to another account (the "spender" account) that allows the spender to spend a specified amount of HBAR owned by the funding account. An allowance SHALL NOT transfer any HBAR directly, it only permits transactions signed only by the spender account to transfer HBAR, up to the amount specified, from the funding account. Once the specified amount is spent, the allowance SHALL be consumed and a new allowance SHALL be required before that spending account may spend additional HBAR from the funding account.

Used in: Account

message AccountFungibleTokenAllowance

account.proto:518

* Permission granted by one account (the "funding" account) to another account (the "spender" account) that allows the spender to spend a specified amount of a specific non-HBAR fungible token from the balance owned by the funding account. An allowance SHALL NOT transfer any tokens directly, it only permits transactions signed only by the spender account to transfer tokens of the specified type, up to the amount specified, from the funding account. Once the specified amount is spent, the allowance SHALL be consumed and a new allowance SHALL be required before that spending account may spend additional tokens from the funding account.

Used in: Account

message AccountID

basic_types.proto:200

* A unique identifier for an Hedera account. An account identifier is of the form `shard.realm.[number|alias]`.<br/> The identifier MAY use the alias form when transferring HBAR to a public key before the account for that key is created, when only the alias value is known, or in some smart contracts that use the EVM address style alias to refer to Accounts.<br/> When the account entry is completed, the alias SHALL be stored separately in the Account record, and the identifier in the Account SHALL use the `accountNum` form. --- ### Additional Notes #### Alias There is considerable complexity with `alias` (aka `evm_address`) for Accounts. Much of this comes from the existence of a "hidden" alias for almost all accounts, and the reuse of the alias field for both EVM reference and "automatic" account creation.<br/> For the purposes of this specification, we will use the following terms for clarity. - `key_alias`<br/> The account public key as a protobuf serialized message and used for auto-creation and subsequent lookup. This is only valid if the account key is a single `primitive` key, either Ed25519 or ECDSA_SECP256K1. - `evm_address`<br/> Exists for every account and is one of - `contract_address`<br/> The 20 byte EVM address prescribed by `CREATE` or `CREATE2` - `evm_key_address`<br/> An arbitrary 20 byte EVM address that, for a usable externally owned account (EOA) SHALL be the rightmost 20 bytes of the Keccak-256 hash of a ECDSA_SECP256K1 key.<br/> Such accounts may be created in one of three ways: - Sending hbar or fungible tokens to an unused ECDSA_SECP256K1 key alias. - Sending hbar or fungible tokens to an unassigned 20-byte EVM address. - Submitting a `CryptoCreate` signed with the corresponding private key. - `long_zero`<br/> A synthetic 20 byte address inferred for "normally" created accounts. It is constructed from the "standard" AccountID as follows. 1. 4 byte big-endian shard number 1. 8 byte big-endian realm number 1. 8 byte big-endian entity number<br/> The `alias` field in the `Account` message SHALL contain one of four values for any given account. - The `key_alias`, if the account was created by transferring HBAR to the `key_alias` public key value. - The `evm_key_address` if the account was created from an EVM public key - The `contract_address` if the account belongs to an EVM contract - Not-Set/null/Bytes.EMPTY (collectively `null`) if the account was created normally If the `alias` field of an `Account` is any form of `null`, then the account MAY be referred to by `alias` in an `AccountID` by using the `long_zero` address for the account.<br/> This "hidden default" alias SHALL NOT be stored, but is synthesized by the node software as needed, and may be synthesized by an EVM contract or client software as well. --- #### Alias forms An `AccountID` in a transaction MAY reference an `Account` with `shard.realm.alias`.<br/> If the account `alias` field is set for an Account, that value SHALL be the account alias.<br/> If the account `alias` field is not set for an Account, the `long_zero` alias SHALL be the account alias.

Used in: com.hedera.hapi.node.addressbook.NodeCreateTransactionBody, com.hedera.hapi.node.addressbook.NodeUpdateTransactionBody, com.hedera.hapi.node.state.addressbook.Node, Account, AccountAmount, AccountApprovalForAllAllowance, AccountCryptoAllowance, AccountFungibleTokenAllowance, AllProxyStakers, AssessedCustomFee, ConsensusCreateTopicTransactionBody, ConsensusTopicInfo, ConsensusUpdateTopicTransactionBody, ContractCallLocalQuery, ContractCreateTransactionBody, ContractDeleteTransactionBody, ContractFunctionResult, ContractGetInfoResponse.ContractInfo, ContractUpdateTransactionBody, CryptoAllowance, CryptoCreateTransactionBody, CryptoDeleteLiveHashTransactionBody, CryptoDeleteTransactionBody, CryptoGetAccountBalanceQuery, CryptoGetAccountBalanceResponse, CryptoGetAccountRecordsQuery, CryptoGetAccountRecordsResponse, CryptoGetInfoQuery, CryptoGetInfoResponse.AccountInfo, CryptoGetLiveHashQuery, CryptoGetStakersQuery, CryptoUpdateTransactionBody, CustomFee, CustomFeeLimit, EntityID, EntityIDPair, FixedCustomFee, GetAccountDetailsQuery, GetAccountDetailsResponse.AccountDetails, GetBySolidityIDResponse, GrantedCryptoAllowance, GrantedNftAllowance, GrantedTokenAllowance, LiveHash, Nft, NftAllowance, NftRemoveAllowance, NftTransfer, NodeAddress, PendingAirdropId, ProxyStaker, Schedule, ScheduleCreateTransactionBody, ScheduleInfo, StakingInfo, Token, TokenAllowance, TokenAssociateTransactionBody, TokenAssociation, TokenCreateTransactionBody, TokenDissociateTransactionBody, TokenFreezeAccountTransactionBody, TokenGetAccountNftInfosQuery, TokenGrantKycTransactionBody, TokenInfo, TokenNftInfo, TokenRejectTransactionBody, TokenRelation, TokenRevokeKycTransactionBody, TokenUnfreezeAccountTransactionBody, TokenUpdateTransactionBody, TokenWipeAccountTransactionBody, Topic, TransactionBody, TransactionID, TransactionReceipt, TransactionRecordEntry

message AccountPendingAirdrop

account_pending_airdrop.proto:36

* A node within a doubly linked list of pending airdrop references.<br/> This internal state message forms the entries in a doubly-linked list of references to pending airdrop entries that are "owed" by a particular account as "sender". Each entry in this list MUST refer to an existing pending airdrop.<br/> The pending airdrop MUST NOT be claimed.<br/> The pending airdrop MUST NOT be canceled.<br/> The pending airdrop `sender` account's `head_pending_airdrop_id` field MUST match the `pending_airdrop_id` field in this message.

message AllProxyStakers

crypto_get_stakers.proto:69

* All of the accounts proxy staking to a given account, and the amounts proxy staked

Used in: CryptoGetStakersResponse

message AssessedCustomFee

custom_fees.proto:289

* Description of a transfer added to a `cryptoTransfer` transaction that satisfies custom fee requirements. It is important to note that this is not the actual transfer. The transfer of value SHALL be merged into the original transaction to minimize the number of actual transfers. This descriptor presents the fee assessed separately in the record stream so that the details of the fee assessed are not hidden in this process.

Used in: TransactionRecord

message AtomicBatchTransactionBody

transaction.proto:666

* A transaction body for handling a set of transactions atomically.

<<<pbj.java_package = "com.hedera.hapi.node.util">>> This comment is special code for setting PBJ Compiler java package

Used in: TransactionBody

enum BlockHashAlgorithm

basic_types.proto:115

* A specific hash algorithm. We did not reuse Record Stream `HashAlgorithm` here because in all cases, currently, this will be `SHA2_384` and if that is the default value then we can save space by not serializing it, whereas `HASH_ALGORITHM_UNKNOWN` is the default for Record Stream `HashAlgorithm`. Note that enum values here MUST NOT match the name of any other enum value in the same `package`, as protobuf follows `C++` scope rules and all enum _names_ are treated as global constants within the `package`.

message BlockInfo

block_info.proto:35

* Information for a transaction block. This includes: - last block number. - consensus times for: - previous block start. - current block start. - last handled transaction. - hash data for a rolling window of 256 blocks. - whether migration records were produced.

message Bytecode

bytecode.proto:26

* The bytecode for a contract account. This is not referred to by any other protocol buffer, but is used internally within the Hedera Node software.

message CongestionLevelStarts

congestion_level_starts.proto:29

* Two lists of congestion pricing level "start" times. Each list details the start of each time period when the congestion pricing level changed (increasing, or decreasing, the congestion fee multiplier).

message ConsensusCreateTopicTransactionBody

consensus_create_topic.proto:60

* Create a topic to accept and group consensus messages. If `autoRenewAccount` is specified, that account Key MUST also sign this transaction.<br/> If `adminKey` is set, that Key MUST sign the transaction.<br/> On success, the resulting `TransactionReceipt` SHALL contain the newly created `TopicId`. The `autoRenewPeriod` on a topic MUST be set to a value between `autoRenewPeriod.minDuration` and `autoRenewPeriod.maxDuration`. These values are configurable, typically 30 and 92 days.<br/> This also sets the initial expirationTime of the topic. If no `adminKey` is set on a topic -`autoRenewAccount` SHALL NOT be set on the topic. - A `deleteTopic` transaction SHALL fail. - An `updateTopic` transaction that only extends the expirationTime MAY succeed. - Any other `updateTopic` transaction SHALL fail. If the topic expires and is not automatically renewed, the topic SHALL enter the `EXPIRED` state. - All transactions on the topic SHALL fail with TOPIC_EXPIRED - Except an updateTopic() call that only extends the expirationTime. - getTopicInfo() SHALL succeed, and show the topic is expired. The topic SHALL remain in the `EXPIRED` state for a time determined by the `autorenew.gracePeriod` (configurable, originally 7 days).<br/> After the grace period, if the topic's expirationTime is not extended, the topic SHALL be automatically deleted from state entirely, and cannot be recovered or recreated. ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

message ConsensusDeleteTopicTransactionBody

consensus_delete_topic.proto:37

* Delete a topic. Once deleted, subsequent transactions or queries for that topic SHALL NOT succeed.<br/> If adminKey is set on the topic, this transaction MUST be signed by that key.<br/> If adminKey is not set on the topic, this transaction SHALL fail with a response code of `UNAUTHORIZED`. A topic without an adminKey cannot be deleted (but MAY expire). ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

message ConsensusGetTopicInfoQuery

consensus_get_topic_info.proto:35

* Retrieve the latest state of a topic. This method is unrestricted and allowed on any topic by any payer account.<br/> A query for a deleted topic MAY succeed if the topic is within the "autorenew grace period".<br/> A query for a topic removed from state SHALL NOT succeed.

Used in: Query

message ConsensusGetTopicInfoResponse

consensus_get_topic_info.proto:55

* Query response to describe the current state of a topic in the Hedera Consensus Service(HCS).

Used in: Response

message ConsensusMessageChunkInfo

consensus_submit_message.proto:35

* Consensus message "chunk" detail.<br/> This message carries information describing the way in which a message submitted for consensus is broken into multiple fragments to fit within network transaction size limits. The use of multiple message fragments is RECOMMENDED for any message greater than 4KiB in total size. ### Block Stream Effects None

Used in: com.hedera.mirror.api.proto.ConsensusTopicResponse, ConsensusSubmitMessageTransactionBody

message ConsensusSubmitMessageTransactionBody

consensus_submit_message.proto:71

* Submit a message for consensus.<br/> This transaction adds a new entry to the "end" of a topic, and provides the core function of the consensus service. Valid and authorized messages on valid topics SHALL be ordered by the consensus service, published in the block stream, and available to all subscribers on this topic via the mirror nodes.<br/> If this transaction succeeds the resulting `TransactionReceipt` SHALL contain the latest `topicSequenceNumber` and `topicRunningHash` for the topic.<br/> If the topic `submitKey` is set, and not an empty `KeyList`, then that key MUST sign this transaction. ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

message ConsensusTopicInfo

consensus_topic_info.proto:30

* A query response describing the current state of a topic for the Hedera Consensus Service (HCS).

Used in: ConsensusGetTopicInfoResponse

message ConsensusUpdateTopicTransactionBody

consensus_update_topic.proto:37

* Update the fields of an existing HCS topic. The topicID field is REQUIRED. All other fields are OPTIONAL.<br/> Fields set on this transaction SHALL be updated.<br/> Fields _not_ set on this transaction SHALL NOT be updated. ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

message ContractCallLocalQuery

contract_call_local.proto:49

* Call a view function of a given smart contract<br/> The call must provide function parameter inputs as needed.<br/> This is potentially useful for calling view functions that will not revert when executed in a static EVM context. Many such use cases will be better served by using a Mirror Node API, however. This is performed locally on the particular node that the client is communicating with. Executing the call locally is faster and less costly, but imposes certain restrictions.<br/> The call MUST NOT change the state of the contract instance. This also precludes any expenditure or transfer of HBAR or other tokens.<br/> The call SHALL NOT have a separate consensus timestamp.<br/> The call SHALL NOT generate a record nor a receipt.<br/> The response SHALL contain the output returned by the function call.<br/> Any contract call that would use the `STATICCALL` opcode MAY be called via contract call local with performance and cost benefits. Unlike a ContractCall transaction, the node SHALL always consume the _entire_ amount of offered "gas" in determining the fee for this query, so accurate gas estimation is important.

Used in: Query

message ContractCallLocalResponse

contract_call_local.proto:105

* The response returned by a `ContractCallLocalQuery` transaction.

Used in: Response

message ContractCallTransactionBody

contract_call.proto:37

* Call a function of a given smart contract, providing function parameter inputs as needed. Resource ("gas") charges SHALL include all relevant fees incurred by the contract execution, including any storage required.<br/> The total transaction fee SHALL incorporate all of the "gas" actually consumed as well as the standard fees for transaction handling, data transfers, signature verification, etc...<br/> The response SHALL contain the output returned by the function call. ### Block Stream Effects A `CallContractOutput` message SHALL be emitted for each transaction.

Used in: SchedulableTransactionBody, TransactionBody

message ContractCreateTransactionBody

contract_create.proto:71

* Create a new smart contract. If this transaction succeeds, the `ContractID` for the new smart contract SHALL be set in the transaction receipt.<br/> The contract is defined by the initial bytecode (or `initcode`). The `initcode` SHALL be stored either in a previously created file, or in the transaction body itself for very small contracts. As part of contract creation, the constructor defined for the new smart contract SHALL run with the parameters provided in the `constructorParameters` field.<br/> The gas to "power" that constructor MUST be provided via the `gas` field, and SHALL be charged to the payer for this transaction.<br/> If the contract _constructor_ stores information, it is charged gas for that storage. There is a separate fee in HBAR to maintain that storage until the expiration, and that fee SHALL be added to this transaction as part of the _transaction fee_, rather than gas. ### Block Stream Effects A `CreateContractOutput` message SHALL be emitted for each transaction.

Used in: SchedulableTransactionBody, TransactionBody

message ContractDeleteTransactionBody

contract_delete.proto:51

* Delete a smart contract, and transfer any remaining HBAR balance to a designated account. If this call succeeds then all subsequent calls to that smart contract SHALL execute the `0x0` opcode, as required for EVM equivalence. ### Requirements - An account or smart contract MUST be designated to receive all remaining account balances. - The smart contract MUST have an admin key set. If the contract does not have `admin_key` set, then this transaction SHALL fail and response code `MODIFYING_IMMUTABLE_CONTRACT` SHALL be set. - If `admin_key` is, or contains, an empty `KeyList` key, it SHALL be treated the same as an admin key that is not set. - The `Key` set for `admin_key` on the smart contract MUST have a valid signature set on this transaction. - The designated receiving account MAY have `receiver_sig_required` set. If that field is set, the receiver account MUST also sign this transaction. - The field `permanent_removal` MUST NOT be set. That field is reserved for internal system use when purging the smart contract from state. Any user transaction with that field set SHALL be rejected and a response code `PERMANENT_REMOVAL_REQUIRES_SYSTEM_INITIATION` SHALL be set. ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

message ContractFunctionResult

contract_types.proto:94

* A contract function result.<br/> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall. The ContractCreateInstance transaction record also carries a function result, which is the results of the call to the constructor.

Used in: ContractCallLocalResponse, TransactionRecord

message ContractGetBytecodeQuery

contract_get_bytecode.proto:28

* A transaction body to request the current bytecode for a smart contract.

Used in: Query

message ContractGetBytecodeResponse

contract_get_bytecode.proto:48

* Information returned in response to a "get bytecode" query for a smart contract.

Used in: Response

message ContractGetInfoQuery

contract_get_info.proto:30

* Request detailed information about a smart contract.

Used in: Query

message ContractGetInfoResponse

contract_get_info.proto:50

* Information returned in response to a "get info" query for a smart contract.

Used in: Response

message ContractGetInfoResponse.ContractInfo

contract_get_info.proto:64

Used in: ContractGetInfoResponse

message ContractGetRecordsQuery

contract_get_records.proto:34

* Deprecated and not supported after release `0.9.0`. Request records of all transactions against the given contract in the last 25 hours.

Used in: Query

message ContractGetRecordsResponse

contract_get_records.proto:55

* Deprecated and not supported after release `0.9.0`. Response with records of all transactions against the given contract in the last 25 hours.

Used in: Response

message ContractID

basic_types.proto:271

* An identifier for a smart contract within the network.

Used in: ContractCallLocalQuery, ContractCallTransactionBody, ContractDeleteTransactionBody, ContractFunctionResult, ContractGetBytecodeQuery, ContractGetInfoQuery, ContractGetInfoResponse.ContractInfo, ContractGetRecordsQuery, ContractGetRecordsResponse, ContractLoginfo, ContractNonceInfo, ContractUpdateTransactionBody, CryptoGetAccountBalanceQuery, EntityID, GetBySolidityIDResponse, Key, SlotKey, SystemDeleteTransactionBody, SystemUndeleteTransactionBody, TransactionReceipt

message ContractLoginfo

contract_types.proto:53

* EVM log data for a contract call.<br/> The EVM log information produced by a smart contract function call. Each contract function call MAY return zero or more log events.

Used in: ContractFunctionResult

message ContractNonceInfo

contract_types.proto:33

* A contract "nonce" reference.<br/> This connects a contract and its "nonce" value, and is primarily for use in query responses. A "nonce" is short for "nonsense" and is usually a value with no particular meaning. The nonce of a contract SHALL be incremented when that contract creates another contract.

Used in: ContractFunctionResult

message ContractUpdateTransactionBody

contract_update.proto:44

* Modify the current state of a smart contract. ### Requirements - The `adminKey` MUST sign all contract update transactions except one that only updates the `expirationTime`. - A transaction that modifies any field other than `expirationTime` for a contract without a valid `adminKey` set SHALL fail with response code `MODIFYING_IMMUTABLE_CONTRACT`. - Fields set to non-default values in this transaction SHALL be updated on success. Fields not set to non-default values SHALL NOT be updated on success. ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

message CryptoAddLiveHashTransactionBody

crypto_add_live_hash.proto:80

* Add a hash value to the ledger and associate it with an account. Create an entry in the ledger for a SHA-384 hash of some content, and associate that with a specific account. This is sometimes used to associate a credential or certificate with an account as a public record.<br/> The entry created is also associated with a list of keys, all of which MUST sign this transaction.<br/> The account key for the associated account MUST sign this transaction.<br/> The live hash, once created, MAY be removed from the ledger with one or more signatures. - The account key of the account associated to the live hash. - Any one key from the key list in the live hash entry. - Any combination of keys from the key list in the live hash entry.

Used in: TransactionBody

message CryptoAllowance

crypto_approve_allowance.proto:94

* An approved allowance of hbar transfers. This message specifies one allowance for a single, unique, combination of owner, spender, and amount. If `owner` is not set, the effective `owner` SHALL be the `payer` for the enclosing transaction.<br/> The `spender` MUST be specified and MUST be a valid account.<br/> The `amount` MUST be a whole number, and SHOULD be greater than `0` unless this allowance is intended to _remove_ a previously approved allowance.

Used in: CryptoApproveAllowanceTransactionBody

message CryptoApproveAllowanceTransactionBody

crypto_approve_allowance.proto:57

* Create ("Approve") allowances for one account to transfer tokens owned by a different account.<br/> An allowance permits a "spender" account to independently transfer tokens owned by a separate "owner" account. Each such allowance permits spending any amount, up to a specified limit, for fungible/common tokens; a single specified non-fungible/unique token, or all non-fungible/unique tokens of a particular token type held by the "owner" account. If the "owner" account is not specified for any allowance in this transaction (the `owner` field is not set), the `payer` account for this transaction SHALL be owner for that allowance.<br/> Each `owner` account specified in any allowance approved in this transaction MUST sign this transaction.<br/> If the `amount` field for any fungible/common allowance in this transaction is `0`, then that allowance SHOULD match an existing, previously approved, allowance which SHALL be removed.<br/> There are three lists in this message. Each list MAY be empty, but _at least one_ list MUST contain _at least one_ entry. Example for the `payer` rule.<br/> - Given an account `0.0.X` that pays for this transaction, and owner is not specified in an allowance of `200` HBAR to spender account `0.0.Y`. At consensus the spender account `0.0.Y` will have a new allowance to spend `200` HBAR from the balance of account `0.0.X`. ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

message CryptoCreateTransactionBody

crypto_create.proto:35

Create a new account. If the auto_renew_account field is set, the key of the referenced account MUST sign this transaction.<br/> Current limitations REQUIRE that `shardID` and `realmID` both MUST be `0`. This is expected to change in the future. ### Block Stream Effects The newly created account SHALL be included in State Changes.

Used in: SchedulableTransactionBody, TransactionBody

message CryptoDeleteAllowanceTransactionBody

crypto_delete_allowance.proto:41

* Delete one or more allowances.<br/> Given one or more, previously approved, allowances for non-fungible/unique tokens to be transferred by a spending account from an owning account; this transaction removes a specified set of those allowances. The owner account for each listed allowance MUST sign this transaction.<br/> Allowances for HBAR cannot be removed with this transaction. The owner account MUST submit a new `cryptoApproveAllowance` transaction with the amount set to `0` to "remove" that allowance.<br/> Allowances for fungible/common tokens cannot be removed with this transaction. The owner account MUST submit a new `cryptoApproveAllowance` transaction with the amount set to `0` to "remove" that allowance.<br/> ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

message CryptoDeleteLiveHashTransactionBody

crypto_delete_live_hash.proto:37

* Delete a specific live hash associated to a given account. This transaction MUST be signed by either the key of the associated account, or at least one of the keys listed in the live hash. ### Block Stream Effects None

Used in: TransactionBody

message CryptoDeleteTransactionBody

crypto_delete.proto:40

* Delete an account.<br/> This will mark an account deleted, and transfer all tokens to a "sweep" account. A deleted account SHALL NOT hold a balance in any token type.<br/> A deleted account SHALL remain in state until it expires.<br/> Transfers that would increase the balance of a deleted account SHALL fail.<br/> A deleted account MAY be subject of a `cryptoUpdate` transaction to extend its expiration.<br/> When a deleted account expires it SHALL be removed entirely, and SHALL NOT be archived. ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

message CryptoGetAccountBalanceQuery

crypto_get_account_balance.proto:37

* Query to read the HBAR balance of an account or contract. This query SHALL return _only_ the HBAR balance for an account or smart contract. Early releases of the network would return all fungible/common token balances, but HIP-367 made it infeasible to return all such balances. This query SHALL NOT return any information beyond the current HBAR balance.

Used in: Query

message CryptoGetAccountBalanceResponse

crypto_get_account_balance.proto:71

* Response to a CryptoGetAccountBalanceQuery.<br/> This response SHALL contain only the information needed to identify the query request and the actual HBAR balance of the identified account or contract.

Used in: Response

message CryptoGetAccountRecordsQuery

crypto_get_account_records.proto:35

* Request records of all "recent" transactions for which the specified account is the effective payer.

Used in: Query

message CryptoGetAccountRecordsResponse

crypto_get_account_records.proto:57

* Return records of all "recent" transactions for which the specified account is the effective payer.

Used in: Response

message CryptoGetInfoQuery

crypto_get_info.proto:36

* A query to read information for an account. The returned information SHALL include balance.<br/> The returned information SHALL NOT include allowances.<br/> The returned information SHALL NOT include token relationships.<br/> The returned information SHALL NOT include account records.

Used in: Query

message CryptoGetInfoResponse

crypto_get_info.proto:53

* Response when the client sends the node CryptoGetInfoQuery

Used in: Response

message CryptoGetInfoResponse.AccountInfo

crypto_get_info.proto:90

* Information describing A single Account in the Hedera distributed ledger. #### Attributes Each Account may have a unique three-part identifier, a Key, and one or more token balances. Accounts also have an alias, which has multiple forms, and may be set automatically. Several additional items are associated with the Account to enable full functionality. #### Expiration Accounts, as most items in the network, have an expiration time, recorded as a `Timestamp`, and must be "renewed" for a small fee at expiration. This helps to reduce the amount of inactive accounts retained in state. Another account may be designated to pay any renewal fees and automatically renew the account for (by default) 30-90 days at a time as a means to optionally ensure important accounts remain active. ### Staking Accounts may participate in securing the network by "staking" the account balances to a particular network node, and receive a portion of network fees as a reward. An account may optionally decline these rewards but still stake its balances. #### Transfer Restrictions An account may optionally require that inbound transfer transactions be signed by that account as receiver (in addition to any other signatures required, including sender).

Used in: CryptoGetInfoResponse

message CryptoGetLiveHashQuery

crypto_get_live_hash.proto:35

* Request detail for a specific live hash associated to a specific account.

Used in: Query

message CryptoGetLiveHashResponse

crypto_get_live_hash.proto:63

* Return the full live hash associated to an account, if it is present. > Note that to generate a state proof of the _absence_ of a live hash from > an account a transaction MUST retrieve a state proof of the `Account` > with its list of live hashes.

Used in: Response

message CryptoGetStakersQuery

crypto_get_stakers.proto:34

* Get all the accounts that are proxy staking to this account. For each of them, give the amount currently staked. This was never implemented.

Used in: Query

message CryptoGetStakersResponse

crypto_get_stakers.proto:85

* Response when the client sends the node CryptoGetStakersQuery

Used in: Response

message CryptoTransferTransactionBody

crypto_transfer.proto:62

* Transfer HBAR and/or other tokens among two or more accounts and/or smart contracts. Transfers of HBAR or fungible/common tokens in this transaction are structured as a "double-entry" transfer list which debits one or more accounts, and separately credits one or more accounts. Each such transfer list may specify up to 10 individual credits or debits.<br/> Transfers of non-fungible/unique tokens in this transaction are structured as a "single-entry" transfer list, which both debits one account and credits another account in a single entry. At least one transfer MUST be present, this MAY be an HBAR transfer in `transfers`, or MAY be a token transfer in `tokenTransfers`.<br/> Either `transfers` or `tokenTransfers` MAY be unset, provided the other is set and not empty.<br/> If any one account with a debit in any transfer list holds insufficient balance to complete the transfer, the entire transaction SHALL fail, and all transfers SHALL NOT be completed.<br/> If any one account that is _sending_ an individual non-fungible/unique (NFT) token does not currently hold that unique NFT, the entire transaction SHALL FAIL, and all transfers SHALL NOT be completed. The transaction fee SHALL be charged for a transaction that fails due to insufficient balance or not holding the NFT to be transferred.<br/> Each account with any debit amounts in any transfer list MUST sign this transaction.<br/> Each account with any credit amounts in any transfer list that also has the `receiverSigRequired` flag set MUST sign this transaction. ### Block Stream Effects All debits and credits completed by this transaction SHALL be included in the transaction result transfer list.<br/> Multiple fungible/common debits from one account, or credits to one account, MAY be consolidated to a single debit or credit entry in the transaction result.<br/> Multiple non-fungible/unique transfers SHALL NOT be consolidated in the transaction result.

Used in: SchedulableTransactionBody, TransactionBody

message CryptoUpdateTransactionBody

crypto_update.proto:45

* Modify the current state of an account. ### Requirements - The `key` for this account MUST sign all account update transactions. - If the `key` field is set for this transaction, then _both_ the current `key` and the new `key` MUST sign this transaction, for security and to prevent setting the `key` field to an invalid value. - If the `auto_renew_account` field is set for this transaction, the account identified in that field MUST sign this transaction. - Fields set to non-default values in this transaction SHALL be updated on success. Fields not set to non-default values SHALL NOT be updated on success. - All fields that may be modified in this transaction SHALL have a default value of unset (a.k.a. `null`). ### Block Stream Effects None

NOTE: Seven deprecated fields should probably be removed and the field names reserved. reserved 4,5,6,7,10,11,12 Also, the `receiverSigRequiredField` oneOf should be removed around `receiverSigRequiredWrapper` and the field renamed (both actions are "safe" in protobuf) to `receiver_signature_required`.

Used in: SchedulableTransactionBody, TransactionBody

message CurrentAndNextFeeSchedule

basic_types.proto:1883

* The "current" fee schedule and the "next" fee schedule. The current fee schedule is the schedule that SHALL apply to the current transaction.<br/> The next fee schedule is the schedule that SHALL apply after the current schedule expires.<br/> We store both to avoid a condition where transactions are processed very near the time when a fee schedule expires and it might be indeterminate which fees to apply. With both current and next fee schedule the network can deterministically apply the correct fee schedule based on consensus timestamp for each transaction.

message CustomFee

custom_fees.proto:228

* A transfer fee to assess during a CryptoTransfer.<br/> This fee applies to transactions that transfer units of the token to which the fee is attached. A custom fee may be either fixed or fractional, and must specify a fee collector account to receive the assessed fees. Custom fees MUST be greater than zero (0).

Used in: Token, TokenCreateTransactionBody, TokenFeeScheduleUpdateTransactionBody, TokenInfo

message CustomFeeLimit

custom_fees.proto:397

* A maximum custom fee that the user is willing to pay. <p> This message is used to specify the maximum custom fee that given user is willing to pay.

Used in: TransactionBody

message Duration

duration.proto:27

* A length of time in seconds. It is RECOMMENDED that this message be used whenever an amount of time, rather than a specific point in time, is needed.

Used in: ConsensusCreateTopicTransactionBody, ConsensusTopicInfo, ConsensusUpdateTopicTransactionBody, ContractCreateTransactionBody, ContractGetInfoResponse.ContractInfo, ContractUpdateTransactionBody, CryptoCreateTransactionBody, CryptoGetInfoResponse.AccountInfo, CryptoUpdateTransactionBody, GetAccountDetailsResponse.AccountDetails, LiveHash, TokenCreateTransactionBody, TokenInfo, TokenUpdateTransactionBody, TransactionBody

message EntityID

get_by_key.proto:66

* The ID for a single entity (account, livehash, file, or smart contract) > The query that defines this message is no longer supported.

Used in: GetByKeyResponse

message EntityIDPair

common.proto:51

* A Pair of AccountID and TokenID.<br/> This is used as a key in certain cases. Deprecated.<br/> The TokenAssociation message should be used instead of this message.

message EntityNumber

common.proto:35

* A single 64-bit number identifying a Hedera native entity. Deprecated.<br/> A primitive `int64` or `google.protobuf.Int64Value` wrapper is preferred.

message EthereumTransactionBody

ethereum_transaction.proto:41

* A transaction in Ethereum format.<br/> Make an Ethereum transaction "call" with all data in Ethereum formats, including the contract alias. Call data may be in the transaction, or stored within an Hedera File. The caller MAY offer additional gas above what is offered in the call data, but MAY be charged up to 80% of that value if the amount required is less than this "floor" amount. ### Block Stream Effects An `EthereumOutput` message SHALL be emitted for each transaction.

Used in: TransactionBody

message ExchangeRate

exchange_rate.proto:44

* An exchange rate as a ratio of USD cents per HBAR. This ratio SHALL be used to convert tinycent (`10<sup>-8</sup>` USD cent) to tinybar for fees and other purposes.<br/> When applying an `ExchangeRate`, implementations SHOULD ensure input values are `tinycent` and/or `tinybar` before applying the exchange ratio.<br/> Exchange results MAY be converted to USD or HBAR via division if whole unit values are required. The ratio described here SHALL be assigned such that a value in `tinybar` may be obtained with the following equation. ``` amountInTinybar = (amountInTinycent * hbarEquiv) / centEquiv ```

Used in: ExchangeRateSet

message ExchangeRateSet

exchange_rate.proto:73

* A set of two exchange rates.<br/> The exchange rate for the network is stored and reported as a set of two rates; current and next. This structure supports the network cleanly switching between exchange rates when necessary. This also provides clear notice to clients when the exchange rate will change and the exchange rate that will be applied for the next time period. The difference in rate between `currentRate` and `nextRate` MUST NOT exceed the configured maximum percentage change. This limit SHALL be a network configuration value.

Used in: TransactionReceipt

message FeeComponents

basic_types.proto:1704

* A set of values the nodes use in determining transaction and query fees, and constants involved in fee calculations. Nodes SHALL multiply the amount of "resources" allocated to a transaction or query by the corresponding price to calculate the appropriate fee. Units are one-thousandth of a `tinyCent`. The "resource" allocations SHALL be estimated based on transaction characteristics and current network state, and MAY be further adjusted based on network load and congestion. This SHALL be used, in different contexts, for the cost _factors_ used to calculate charged amounts, for the resource accumulation, and for actual amounts to be charged.<br/> Amounts recorded here MUST be converted to tinybar according to the current active `ExchangeRate` for the network.

Used in: FeeData

message FeeData

basic_types.proto:1819

* A total fee, in component amounts charged for a transaction. Total fees are composed of three sets of components. - Node data, components that compensate the specific node that submitted the transaction. - Network data, components that compensate the Hedera network for gossiping the transaction and determining the consensus timestamp. - Service data, components that compensate the Hedera network for the ongoing maintenance and operation of the network, as well as ongoing development of network services. Fee components are recorded in thousandths of a tiny cent, and the network exchange rate converts these to tinybar amounts, which are what the network charges for transactions and what the network reports in the record stream.

Used in: TransactionFeeSchedule

message FeeExemptKeyList

custom_fees.proto:379

* A wrapper for fee exempt key list.<br/> This wrapper exists to enable an update transaction to differentiate between a field that is not set and an empty list of keys. <p> An _unset_ field of this type SHALL NOT modify existing values.<br/> A _set_ field of this type with an empty `keys` list SHALL remove any existing values.

Used in: ConsensusUpdateTopicTransactionBody

message FeeSchedule

basic_types.proto:1854

* A set of fee schedules covering all transaction types and query types, along with a specific time at which this fee schedule will expire. Nodes SHALL use the most recent unexpired fee schedule to determine the fees for all transactions based on various resource components imputed to each transaction.

Used in: CurrentAndNextFeeSchedule

message File

file.proto:34

* Representation of an Hedera File Service `file`. Files offer a place to store additional data, much more than is available in other entities, for use with smart contracts, non-fungible tokens, etc... As with all network entities, a file has a unique entity number, which is given along with the network's shard and realm in the form of a shard.realm.number id.

message FileAppendTransactionBody

file_append.proto:48

* A transaction body for an `appendContent` transaction.<br/> This transaction body provides a mechanism to append content to a "file" in network state. Hedera transactions are limited in size, but there are many uses for in-state byte arrays (e.g. smart contract bytecode) which require more than may fit within a single transaction. The `appendFile` transaction exists to support these requirements. The typical pattern is to create a file, append more data until the full content is stored, verify the file is correct, then update the file entry with any final metadata changes (e.g. adding threshold keys and removing the initial upload key). Each append transaction MUST remain within the total transaction size limit for the network (typically 6144 bytes).<br/> The total size of a file MUST remain within the maximum file size limit for the network (typically 1048576 bytes). #### Signature Requirements Append transactions MUST have signatures from _all_ keys in the `KeyList` assigned to the `keys` field of the file.<br/> See the [File Service](#FileService) specification for a detailed explanation of the signature requirements for all file transactions. ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

message FileCreateTransactionBody

file_create.proto:65

* Create a new file. If successful, the new file SHALL contain the (possibly empty) content provided in the `contents` field.<br/> When the current consensus time exceeds the `expirationTime` value, the network SHALL expire the file, and MAY archive the state entry. #### Signature Requirements The HFS manages file authorization in a manner that can be confusing. The core element of file authorization is the `keys` field, which is a `KeyList`; a list of individual `Key` messages, each of which may represent a simple or complex key.<br/> The file service transactions treat this list differently.<br/> A `fileCreate`, `fileAppend`, or `fileUpdate` MUST have a valid signature from _each_ key in the list.<br/> A `fileDelete` MUST have a valid signature from _at least one_ key in the list. This is different, and allows a file "owned" by many entities to be deleted by any one of those entities. A deleted file cannot be restored, so it is important to consider this when assigning keys for a file.<br/> If any of the keys in a `KeyList` are complex, the full requirements of each complex key must be met to count as a "valid signature" for that key. A complex key structure (i.e. a `ThresholdKey`, or `KeyList`, possibly including additional `ThresholdKey` or `KeyList` descendants) may be assigned as the sole entry in a file `keys` field to ensure all transactions have the same signature requirements. If the `keys` field is an empty `KeyList`, then the file SHALL be immutable and the only transaction permitted to modify that file SHALL be a `fileUpdate` transaction with _only_ the `expirationTime` set. #### Shard and Realm The current API ignores shardID and realmID. All files are created in shard 0 and realm 0. Future versions of the API may support multiple realms and multiple shards. ### Block Stream Effects After the file is created, the FileID for it SHALL be returned in the transaction receipt, and SHALL be recorded in the transaction record.

Used in: SchedulableTransactionBody, TransactionBody

message FileDeleteTransactionBody

file_delete.proto:49

* Mark a file as deleted and remove its content from network state. The metadata for a deleted file SHALL be retained at least until the expiration time for the file is exceeded.<br/> On completion, the identified file SHALL be marked `deleted`.<br/> On completion, the identified file SHALL have an empty `contents` array.<br/> This transaction SHALL be final and irreversible.<br/> #### Signature Requirements At least _one_ key from the `KeyList` in the `keys` field of the identified file MUST sign this transaction.<br/> If the keys field for the identified file is an empty `KeyList` (because that file was previously created or updated to have an empty `KeyList`), then the file is considered immutable and this message SHALL fail as UNAUTHORIZED. See the [File Service](#FileService) specification for a detailed explanation of the signature requirements for all file transactions. ### What is a "system" file A "system" file is any file with a file number less than or equal to the current configuration value for `ledger.numReservedSystemEntities`, typically `750`. ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

message FileGetContentsQuery

file_get_contents.proto:34

* A query request to the Hedera File Service (HFS) for file content.<br/> This query requests the content of a file, but none of the information _about_ a file. A client should submit a `fileGetInfo` query to view information about a file.<br/> File content may also be available from a block node or mirror node, generally at lower cost.

Used in: Query

message FileGetContentsResponse

file_get_contents.proto:58

* A response to a query for the content of a file in the Hedera File Service (HFS). This message SHALL contain the full content of the requested file, but SHALL NOT contain any metadata.

Used in: Response

message FileGetContentsResponse.FileContents

file_get_contents.proto:66

Used in: FileGetContentsResponse

message FileGetInfoQuery

file_get_info.proto:39

* Query to request file metadata from the Hedera File Service (HFS).<br/> This query requests all of the information _about_ a file, but none of the _content_ of a file. A client should submit a `fileGetContents` query to view the content of a file. File content _may_ also be available from a block node or mirror node, generally at lower cost. File metadata SHALL be available for active files and deleted files.<br/> The size of a deleted file SHALL be `0` and the content SHALL be empty.

Used in: Query

message FileGetInfoResponse

file_get_info.proto:59

* A response to a query for the metadata of a file in the HFS.

Used in: Response

message FileGetInfoResponse.FileInfo

file_get_info.proto:67

Used in: FileGetInfoResponse

message FileID

basic_types.proto:251

* An identifier for a File within the network.

Used in: com.hedera.mirror.api.proto.AddressBookQuery, ContractCreateTransactionBody, ContractUpdateTransactionBody, EntityID, EthereumTransactionBody, File, FileAppendTransactionBody, FileDeleteTransactionBody, FileGetContentsQuery, FileGetContentsResponse.FileContents, FileGetInfoQuery, FileGetInfoResponse.FileInfo, FileUpdateTransactionBody, FreezeTransactionBody, GetBySolidityIDResponse, SystemDeleteTransactionBody, SystemUndeleteTransactionBody, TransactionReceipt

message FileUpdateTransactionBody

file_update.proto:47

* Update the metadata, and/or replace the content, of a file in the Hedera File Service (HFS). Any field which is not set (i.e. is null) in this message, other than `fileID`, SHALL be ignored.<br/> If the `keys` list for the identified file is an empty `KeyList`, then this message MUST NOT set any field except `expirationTime`. #### Signature Requirements Every `Key` in the `keys` list for the identified file MUST sign this transaction, if any field other than `expirationTime` is to be updated.<br/> If the `keys` list for the identified file is an empty `KeyList` (because this file was previously created or updated to have an empty `KeyList`), then the file is considered immutable and this message MUST NOT set any field except `expirationTime`.<br/> See the [File Service](#FileService) specification for a detailed explanation of the signature requirements for all file transactions. ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

message FixedCustomFee

custom_fees.proto:334

* A custom fee definition for a consensus topic. <p> This fee definition is specific to an Hedera Consensus Service (HCS) topic and SHOULD NOT be used in any other context.<br/> All fields for this message are REQUIRED.<br/> Only "fixed" fee definitions are supported because there is no basis for a fractional fee on a consensus submit transaction.

Used in: ConsensusCreateTopicTransactionBody, ConsensusTopicInfo, FixedCustomFeeList, Topic

message FixedCustomFeeList

custom_fees.proto:362

* A wrapper around a consensus custom fee list.<br/> This wrapper exists to enable an update transaction to differentiate between a field that is not set and an empty list of custom fees. <p> An _unset_ field of this type SHALL NOT modify existing values.<br/> A _set_ field of this type with an empty `fees` list SHALL remove any existing values.

Used in: ConsensusUpdateTopicTransactionBody

message FixedFee

custom_fees.proto:114

* A fixed fee to assess for each token transfer, regardless of the amount transferred.<br/> This fee type describes a fixed fee for each transfer of a token type. The fee SHALL be charged to the `sender` for the token transfer transaction.<br/> This fee MAY be assessed in HBAR, the token type transferred, or any other token type, as determined by the `denominating_token_id` field.

Used in: CustomFee, CustomFeeLimit, FixedCustomFee, RoyaltyFee

message Fraction

basic_types.proto:598

* A rational number.<br/> A common use is to set the amount of a value transfer to collect as a custom fee. It is RECOMMENDED that both numerator and denominator be no larger than necessary to express the required fraction. A very large numerator, in particular, may not be reliable. Both fields are REQUIRED and SHOULD be positive integers.

Used in: FractionalFee, NodeStakeUpdateTransactionBody, RoyaltyFee

message FractionalFee

custom_fees.proto:50

* A descriptor for a fee based on a portion of the tokens transferred. This fee option describes fees as a fraction of the amount of fungible/common token(s) transferred. The fee also describes a minimum and maximum amount, both of which are OPTIONAL. This type of fee SHALL be assessed only for fungible/common tokens.<br/> This type of fee MUST NOT be defined for a non-fungible/unique token type.<br/> This fee SHALL be paid with the same type of tokens as those transferred.<br/> The fee MAY be subtracted from the transferred tokens, or MAY be assessed to the sender in addition to the tokens actually transferred, based on the `net_of_transfers` field. When a single transaction sends tokens from one sender to multiple recipients, and the `net_of_transfers` flag is false, the network SHALL attempt to evenly assess the total fee across all recipients proportionally. This may be inexact and, particularly when there are large differences between recipients, MAY result in small deviations from an ideal "fair" distribution.<br/> If the sender lacks sufficient tokens to pay fees, or the assessment of custom fees reduces the net amount transferred to or below zero, the transaction MAY fail due to insufficient funds to pay all fees.

Used in: CustomFee

message FreezeTransactionBody

freeze.proto:55

* A transaction body for all five freeze transactions. Combining five different transactions into a single message, this transaction body MUST support options to schedule a freeze, abort a scheduled freeze, prepare a software upgrade, prepare a telemetry upgrade, or initiate a software upgrade. For a scheduled freeze, at the scheduled time, according to network consensus time - A freeze (`FREEZE_ONLY`) causes the network nodes to stop creating events or accepting transactions, and enter a persistent maintenance state. - A freeze upgrade (`FREEZE_UPGRADE`) causes the network nodes to stop creating events or accepting transactions, and upgrade the node software from a previously prepared upgrade package. The network nodes then restart and rejoin the network after upgrading. For other freeze types, immediately upon processing the freeze transaction - A Freeze Abort (`FREEZE_ABORT`) cancels any pending scheduled freeze. - A prepare upgrade (`PREPARE_UPGRADE`) begins to extract the contents of the specified upgrade file to the local filesystem. - A telemetry upgrade (`TELEMETRY_UPGRADE`) causes the network nodes to extract a telemetry upgrade package to the local filesystem and signal other software on the machine to upgrade, without impacting the node or network processing. ### Block Stream Effects Unknown

Used in: SchedulableTransactionBody, TransactionBody

enum FreezeType

freeze_type.proto:28

* An enumeration of possible network freeze types. Each enumerated value SHALL be associated to a single network freeze scenario. Each freeze scenario defines the specific parameters REQUIRED for that freeze.

Used in: FreezeTransactionBody

message GetAccountDetailsQuery

get_account_details.proto:37

* Request detail information about an account. The returned information SHALL include balance and allowances.<br/> The returned information SHALL NOT include a list of account records. #### Important This query is a _privileged_ query. Only "system" accounts SHALL be permitted to submit this query.

Used in: Query

message GetAccountDetailsResponse

get_account_details.proto:60

* A response to a `GetAccountDetailsQuery`. This SHALL contain the account details if requested and successful.

Used in: Response

message GetAccountDetailsResponse.AccountDetails

get_account_details.proto:97

* Information describing a single Account in the Hedera distributed ledger. #### Attributes Each Account may have a unique three-part identifier, a Key, and one or more token balances. Accounts also have an alias, which has multiple forms, and may be set automatically. Several additional items are associated with the Account to enable full functionality. #### Expiration Accounts, as most items in the network, have an expiration time, recorded as a `Timestamp`, and must be "renewed" for a small fee at expiration. This helps to reduce the amount of inactive accounts retained in state. Another account may be designated to pay any renewal fees and automatically renew the account for (by default) 30-90 days at a time as a means to optionally ensure important accounts remain active. ### Staking Accounts may participate in securing the network by "staking" the account balances to a particular network node, and receive a portion of network fees as a reward. An account may optionally decline these rewards but still stake its balances. #### Transfer Restrictions An account may optionally require that inbound transfer transactions be signed by that account as receiver (in addition to any other signatures required, including sender).

Used in: GetAccountDetailsResponse

message GetByKeyQuery

get_by_key.proto:44

* Query all accounts, claims, files, and smart contract instances whose associated keys include the given Key. > This query is no longer supported.

Used in: Query

message GetByKeyResponse

get_by_key.proto:98

* Response when the client sends the node GetByKeyQuery > This query is no longer supported.

Used in: Response

message GetBySolidityIDQuery

get_by_solidity_id.proto:35

* Query to read Contract, Account, and File identifiers for a smart contract given a Solidity identifier.

Used in: Query

message GetBySolidityIDResponse

get_by_solidity_id.proto:58

* Response to a getBySolidityId query. This message returns the account, contract, and file identifiers for a smart contract.

Used in: Response

message GrantedCryptoAllowance

get_account_details.proto:312

* Permission granted by one account (the "funding" account) to another account (the "spender" account) that allows the spender to spend a specified amount of HBAR owned by the funding account. An allowance SHALL NOT transfer any HBAR directly, it only permits transactions signed only by the spender account to transfer HBAR, up to the amount specified, from the funding account. Once the specified amount is spent, the allowance SHALL be consumed and a new allowance SHALL be required before that spending account may spend additional HBAR from the funding account.

Used in: GetAccountDetailsResponse.AccountDetails

message GrantedNftAllowance

get_account_details.proto:352

* Permission granted by one account (the "funding" account) to another account (the "spender" account) that allows the spender to transfer all serial numbers of a specific non-fungible/unique token (NFT) collection owned by the funding account.<br/> This is a broad permission, as it does not matter how many NFTs of the specified collection the funding account owns, the spender MAY dispose of any or all of them with this allowance.<br/> Each token type (typically a collection of NFTs) SHALL require a separate allowance.<br/> Allowances for a specific serial number MUST be directly associated with that specific non-fungible/unique token, rather than the holding account. An allowance SHALL NOT transfer any tokens directly, it only permits transactions signed only by the spender account to transfer any non-fungible/unique tokens of the specified type owned by the funding account.

Used in: GetAccountDetailsResponse.AccountDetails

message GrantedTokenAllowance

get_account_details.proto:383

* Permission granted by one account (the "funding" account) to another account (the "spender" account) that allows the spender to spend a specified amount of a specific non-HBAR fungible token from the balance owned by the funding account. An allowance SHALL NOT transfer any tokens directly, it only permits transactions signed only by the spender account to transfer tokens of the specified type, up to the amount specified, from the funding account. Once the specified amount is spent, the allowance SHALL be consumed and a new allowance SHALL be required before that spending account may spend additional tokens from the funding account.

Used in: GetAccountDetailsResponse.AccountDetails

enum HederaFunctionality

basic_types.proto:1186

* The transactions and queries supported by Hedera Hashgraph.

FUTURE - Uncomment when https://github.com/hashgraph/pbj/issues/339 is fixed; currently the PBJ-generated unit tests fail when using reserved ordinals reserved 96, 97, 98, 99;

Used in: ThrottleGroup, TransactionFeeSchedule

message Key

basic_types.proto:895

* A Key is an entity representing one or more cryptographic public/private key pairs and, optionally, the structure for how multiple signatures may be composed to meet complex multiple-signature authorization requirements. A Key can be a public key from either the Ed25519 or ECDSA(secp256k1) signature schemes. In the ECDSA(secp256k1) case we require the 33-byte compressed form of the public key. For simplicity, we call these cryptographic public keys `primitive` keys.<br/> If an entity has a primitive key associated to it, then the corresponding private key must sign any transaction to send tokens or perform other actions requiring authorization. A Key can also be the ID of a smart contract, which SHALL authorize that contract to execute any system contract with signing requirements that are met by the key.<br/> > Example >> If account `0.0.A` has a threshold key whose threshold is satisfied >> by a contract ID key for contract `0.0.C`, then when `0.0.C` is called, >> it is authorized to use system contracts to manage any asset owned by >> `0.0.A`. If the contract ID key is "delegatable", then `0.0.C` can even >> perform these actions when running code accessed via `DELEGATECALL`. A Key can be a "threshold key", which is a list of N keys, any M of which may sign in order for the signature to be considered valid. The value of M for a given threshold key MUST be less than or equal to N. A threshold key is sometimes called a "M-of-N" key. A Key can be a "key list" where all keys in the list must sign unless specified otherwise in the documentation for a specific transaction type (e.g. FileDeleteTransactionBody).<br/> This implies that the use of a key list is dependent on context. For example, an Hedera file that is created with a list of keys, SHALL require that all of those keys must sign a transaction to create or modify the file, but only one key from that list MUST sign a transaction to delete the file. So it is a single list that sometimes acts as a N-of-N threshold key, and sometimes acts as a 1-of-N threshold key.<br/> To reduce confusion this may cause, a key list SHALL always be considered N-of-N, unless specified otherwise in official documentation.<br/> A key list MAY have repeated primitive public keys, but the signature requirement for all keys in a repeated set SHALL be satisfied by a single valid signature. There is no mechanism to require a single key to sign a single transaction more than once. Any list or threshold key MAY have nested key lists or threshold keys. This allows, for example, the keys within a threshold signature to themselves be threshold, list, contract, or primitive keys. This nesting structure enables complex asymmetric multi-party signature requirements to be met. To ensure adequate performance and transaction security, key nesting is limited to at most fifteen(15) levels.

Used in: com.hedera.hapi.node.addressbook.NodeCreateTransactionBody, com.hedera.hapi.node.addressbook.NodeUpdateTransactionBody, com.hedera.hapi.node.state.addressbook.Node, Account, ConsensusCreateTopicTransactionBody, ConsensusTopicInfo, ConsensusUpdateTopicTransactionBody, ContractCreateTransactionBody, ContractGetInfoResponse.ContractInfo, ContractUpdateTransactionBody, CryptoCreateTransactionBody, CryptoGetInfoResponse.AccountInfo, CryptoUpdateTransactionBody, FeeExemptKeyList, FileCreateTransactionBody, GetAccountDetailsResponse.AccountDetails, GetByKeyQuery, KeyList, Schedule, ScheduleCreateTransactionBody, ScheduleInfo, Token, TokenCreateTransactionBody, TokenInfo, TokenUpdateTransactionBody, Topic, TransactionBody

message KeyList

basic_types.proto:999

* A list of keys.<br/> A `KeyList` requires all keys (N-of-N) to sign, unless otherwise specified in official documentation. A KeyList may contain repeated keys, but all such repeated keys are considered a single key when determining signature authorization. ### Additional Notes 1. An empty key list is the "standard" mechanism to represent an unassigned key. For example, if the `admin_key` of a token is set to the empty key list, then that token has no admin key, and functionality that requires an admin key to sign the transaction is disabled.

Used in: File, FileCreateTransactionBody, FileGetInfoResponse.FileInfo, FileUpdateTransactionBody, Key, LiveHash, ScheduleInfo, ThresholdKey

message LiveHash

crypto_add_live_hash.proto:37

* A Live Hash value associating some item of content to an account. This message represents a desired entry in the ledger for a SHA-384 hash of some content, an associated specific account, a list of authorized keys, and a duration the live hash is "valid".

Used in: CryptoAddLiveHashTransactionBody, CryptoGetInfoResponse.AccountInfo, CryptoGetLiveHashResponse, EntityID

message NetworkGetExecutionTimeQuery

network_get_execution_time.proto:48

* Retrieve the time, in nanoseconds, spent in direct processing for one or more recent transactions. For each transaction identifier provided, if that transaction is sufficiently recent (that is, it is within the range of the configuration value `stats.executionTimesToTrack`), the node SHALL return the time, in nanoseconds, spent to directly process that transaction.<br/> This time will generally correspond to the time spent in a `handle` call within the workflow. Note that because each node processes every transaction for the Hedera network, this query MAY be sent to any node, and results MAY be different between different nodes.

Used in: Query

message NetworkGetExecutionTimeResponse

network_get_execution_time.proto:70

* A response to a `networkGetExecutionTime` query.

Used in: Response

message NetworkGetVersionInfoQuery

network_get_version_info.proto:29

* Query the deployed versions of Hedera Services and the API definitions in semantic version format

Used in: Query

message NetworkGetVersionInfoResponse

network_get_version_info.proto:44

* A response to a `NetworkGetVersionInfoQuery`. This SHALL return `SemanticVersion` information for both Hedera API (HAPI) and Hedera Services.

Used in: Response

message NetworkStakingRewards

network_staking_rewards.proto:28

* An Hedera Token Service staking reward entity. This stores values related to the aggregate staking rewards for all nodes in the network. It is calculated at the beginning of each staking period.

message Nft

nft.proto:35

* An Hedera Token Service non-fungible token (NFT).<br/> Every NFT is a unique instance of a token with non-fungible type. The NFT SHALL be identified by token ID and serial number.<br/> The token treasury account SHALL own all minted NFTs of that token type initially.<br/> NFTs owned by the token treasury SHALL NOT be linked into that account's virtual linked list of NFTs.<br/> NFTs not owned by the token treasury SHALL be linked into the owner account's virtual linked list of NFTs.

message NftAllowance

crypto_approve_allowance.proto:134

* An approved allowance of non-fungible tokens.<br/> This type of allowance may permit transfers for one or more individual unique tokens, or may permit transfers for all unique tokens of the specified type. If `owner` is not set, the effective `owner` SHALL be the `payer` for the enclosing transaction.<br/> The `spender` MUST be specified and MUST be a valid account.<br/> If `approve_for_all` is set, then `serial_numbers` SHOULD be empty and SHALL be ignored. If `approve_for_all` is unset, then `serial_numbers` MUST NOT be empty.

Used in: CryptoApproveAllowanceTransactionBody

message NftID

basic_types.proto:234

* An identifier for a unique token (or "NFT"), used by both contract and token services.

Used in: Account, Nft, PendingAirdropId, TokenGetNftInfoQuery, TokenNftInfo, TokenReference

message NftRemoveAllowance

crypto_delete_allowance.proto:71

* A single allowance for one non-fungible/unique token. This is specific to removal, and the allowance is identified for that specific purpose. All fields in this message are REQUIRED. The `serial_numbers` list MUST NOT be empty. The combination of field values in this message MUST match existing allowances for one or more individual non-fungible/unique tokens. ### Removing an allowance that is `approve_for_all` To remove an allowance that has set the `approve_for_all` flag, the `owner` account must first _approve_ a **new** allowance for a specific serial number using a `cryptoApproveAllowance`, and then, if desired, that newly approved allowance to a specific serial number may be deleted in a separate `cryptoDeleteAllowance` transaction.

Used in: CryptoDeleteAllowanceTransactionBody

message NftTransfer

basic_types.proto:501

* A NFT transfer.<br/> This refers to a sender account, a receiver account, and the serial number of an NFT to transfer from sender to receiver. Each `NftTransfer` SHALL be contained in another message (typically `TokenTransferList`) that details which `Token` type applies to this NFT transfer.

Used in: TokenTransferList

message NodeActivity

node_rewards.proto:72

* A record of judge rounds missed by a single node.<br/> This records, for a single node, the number of rounds so far, during this staking period that missed creating judges. This is used to determine if the node is "active" or not. This message SHALL NOT record the total number of rounds in a staking period.<br/> This message SHALL record a count of rounds for a single node that missed creating judges.

Used in: NodeRewards

message NodeAddress

basic_types.proto:1951

* The data about a node, including its service endpoints and the Hedera account to be paid for services provided by the node (that is, queries answered and transactions submitted). All active fields are populated in the `0.0.102` address book file.<br/> Only fields documented with "`0.0.101` field" are populated in the 0.0.101 address book file. This message MAY be superseded by messages in state/addressbook/node.proto and node_get_info.proto.

Used as response type in: com.hedera.mirror.api.proto.NetworkService.getNodes

Used as field type in: NodeAddressBook

message NodeAddressBook

basic_types.proto:2051

* A list of nodes and their metadata that contains details of the nodes running the network. Used to parse the contents of system files `0.0.101` and `0.0.102`.

message NodeRewards

node_rewards.proto:40

* A record of node rewards status.<br/> This is used to record the number of "active" nodes in a staking period based on number of judges each node created in that period. It also records the number of rounds so far in the staking period. A Node SHALL be considered "active" if it produced "judges" according to the consensus algorithm in a percentage of rounds, during the staking period, greater than the network configuration value for `nodes.activeRoundsPercent`.

message NodeStake

node_stake_update.proto:203

* Staking information for one node at the end of a staking period. This SHALL be one entry in a list reported at the end of each full staking period.

Used in: NodeStakeUpdateTransactionBody

message NodeStakeUpdateTransactionBody

node_stake_update.proto:50

* A system initiated transaction to update staking information. This transaction SHALL be issued at the end of each staking period to update node stakes and reward limits.<br/> This transaction SHALL be a child of the first transaction to reach consensus following the end of the previous staking period.<br/> This transaction MUST NOT be sent by a client and SHALL be rejected if received by any node.<br/> This transaction SHALL be present in the record stream or block stream. ### Block Stream Effects None

Used in: TransactionBody

message PendingAirdropId

basic_types.proto:2369

* A unique, composite, identifier for a pending airdrop. Each pending airdrop SHALL be uniquely identified by a `PendingAirdropId`.<br/> A `PendingAirdropId` SHALL be recorded when created and MUST be provided in any transaction that would modify that pending airdrop (such as a `claimAirdrop` or `cancelAirdrop`).

Used in: Account, AccountPendingAirdrop, PendingAirdropRecord, TokenCancelAirdropTransactionBody, TokenClaimAirdropTransactionBody

message PendingAirdropRecord

transaction_record.proto:216

* A record of a new pending airdrop.

Used in: TransactionRecord

message PendingAirdropValue

basic_types.proto:2422

* A single pending airdrop value. This message SHALL record the airdrop amount for a fungible/common token.<br/> This message SHOULD be null for a non-fungible/unique token.<br/> If a non-null `PendingAirdropValue` is set for a non-fungible/unique token, the amount field MUST be `0`. It is RECOMMENDED that implementations store pending airdrop information as a key-value map from `PendingAirdropId` to `PendingAirdropValue`, with a `null` value used for non-fungible pending airdrops.

Used in: AccountPendingAirdrop, PendingAirdropRecord

message ProtoBoolean

primitives.proto:41

* A single boolean with no particular meaning.

message ProtoBytes

primitives.proto:55

* A single byte array with no particular meaning.

message ProtoInteger

primitives.proto:34

* A single 32-bit number with no particular meaning.

message ProtoLong

primitives.proto:27

* A single 64-bit number with no particular meaning.

message ProtoString

primitives.proto:48

* A single string with no particular meaning.

message ProxyStaker

crypto_get_stakers.proto:52

* information about a single account that is proxy staking

Used in: AllProxyStakers

message Query

query.proto:66

* A query transaction.<br/> This message is serialized to bytes and those bytes are signed by the submitter, with the signature included in the QueryHeader for the query request.

Used as request type in: ConsensusService.getTopicInfo, CryptoService.cryptoGetBalance, CryptoService.getAccountInfo, CryptoService.getAccountRecords, CryptoService.getLiveHash, CryptoService.getTransactionReceipts, CryptoService.getTxRecordByTxID, FileService.getFileContent, FileService.getFileInfo, NetworkService.getAccountDetails, NetworkService.getExecutionTime, NetworkService.getVersionInfo, ScheduleService.getScheduleInfo, SmartContractService.ContractGetBytecode, SmartContractService.contractCallLocalMethod, SmartContractService.getBySolidityID, SmartContractService.getContractInfo, SmartContractService.getTxRecordByContractID, TokenService.getTokenInfo, TokenService.getTokenNftInfo

message QueryHeader

query_header.proto:68

* A standard query header.<br/> Each query from the client to the node must contain a QueryHeader, which specifies the desired response type, and includes a payment transaction that will compensate the network for responding to the query. The payment may be blank if the query is free. The payment transaction MUST be a `cryptoTransfer` from the payer account to the account of the node where the query is submitted.<br/> If the payment is sufficient, the network SHALL respond with the response type requested.<br/> If the response type is `COST_ANSWER` the payment MUST be unset. A state proof SHALL be available for some types of information.<br/> A state proof SHALL be available for a Record, but not a receipt, and the response entry for each supported "get info" query.

Used in: ConsensusGetTopicInfoQuery, ContractCallLocalQuery, ContractGetBytecodeQuery, ContractGetInfoQuery, ContractGetRecordsQuery, CryptoGetAccountBalanceQuery, CryptoGetAccountRecordsQuery, CryptoGetInfoQuery, CryptoGetLiveHashQuery, CryptoGetStakersQuery, FileGetContentsQuery, FileGetInfoQuery, GetAccountDetailsQuery, GetByKeyQuery, GetBySolidityIDQuery, NetworkGetExecutionTimeQuery, NetworkGetVersionInfoQuery, ScheduleGetInfoQuery, TokenGetAccountNftInfosQuery, TokenGetInfoQuery, TokenGetNftInfoQuery, TokenGetNftInfosQuery, TransactionGetFastRecordQuery, TransactionGetReceiptQuery, TransactionGetRecordQuery

message RealmID

basic_types.proto:68

* A realm identifier.<br/> Within a given shard, every realm has a unique numeric identifier. Each account, file, and contract instance belongs to exactly one realm.

Used in: ContractCreateTransactionBody, CryptoCreateTransactionBody, FileCreateTransactionBody

message Response

response.proto:64

* A single query response. Each query MUST define its specific response type.<br/> Each query response MUST include both the information request and a `ResponseHeader`.<br/> All possible query response types MUST be listed here in a `oneof`.

Used as response type in: ConsensusService.getTopicInfo, CryptoService.cryptoGetBalance, CryptoService.getAccountInfo, CryptoService.getAccountRecords, CryptoService.getLiveHash, CryptoService.getTransactionReceipts, CryptoService.getTxRecordByTxID, FileService.getFileContent, FileService.getFileInfo, NetworkService.getAccountDetails, NetworkService.getExecutionTime, NetworkService.getVersionInfo, ScheduleService.getScheduleInfo, SmartContractService.ContractGetBytecode, SmartContractService.contractCallLocalMethod, SmartContractService.getBySolidityID, SmartContractService.getContractInfo, SmartContractService.getTxRecordByContractID, TokenService.getTokenInfo, TokenService.getTokenNftInfo

enum ResponseCodeEnum

response_code.proto:24

* An enumeration of possible response codes.

Used in: ResponseHeader, TransactionReceipt, TransactionReceiptEntry, TransactionResponse

message ResponseHeader

response_header.proto:33

* A standard header returned with every query response. The fields for `cost` or `stateProof` MAY be unset if the requested `ResponseType` does not request those values.<br/> The `responseType` SHALL match the request response type.<br/> The `nodeTransactionPrecheckCode` field SHALL contain the result code for the query.

Used in: ConsensusGetTopicInfoResponse, ContractCallLocalResponse, ContractGetBytecodeResponse, ContractGetInfoResponse, ContractGetRecordsResponse, CryptoGetAccountBalanceResponse, CryptoGetAccountRecordsResponse, CryptoGetInfoResponse, CryptoGetLiveHashResponse, CryptoGetStakersResponse, FileGetContentsResponse, FileGetInfoResponse, GetAccountDetailsResponse, GetByKeyResponse, GetBySolidityIDResponse, NetworkGetExecutionTimeResponse, NetworkGetVersionInfoResponse, ScheduleGetInfoResponse, TokenGetAccountNftInfosResponse, TokenGetInfoResponse, TokenGetNftInfoResponse, TokenGetNftInfosResponse, TransactionGetFastRecordResponse, TransactionGetReceiptResponse, TransactionGetRecordResponse

enum ResponseType

query_header.proto:30

* The type of query response.<br/> This SHALL be answer-only as a default.<br/> This value SHALL support an "estimated cost" type.<br/> This value SHOULD support a "state proof" type, when available.

Used in: QueryHeader, ResponseHeader

message RoyaltyFee

custom_fees.proto:192

* A fee to assess during a CryptoTransfer that changes ownership of a non-fungible/unique (NFT) token.<br/> This message defines the fraction of the fungible value exchanged for an NFT that the ledger should collect as a royalty. "Fungible value" includes both HBAR (ℏ) and units of fungible HTS tokens. When the NFT sender does not receive any fungible value, the ledger will assess the fallback fee, if present, to the new NFT owner. Royalty fees can only be added to non-fungible/unique tokens. #### Important Note > Users should be aware that native royalty fees are _strictly_ a > convenience feature, SHALL NOT be guaranteed, and the network SHALL NOT > enforce _inescapable_ royalties on the exchange of a unique NFT.<br/> > For _one_ example, if the counterparties agree to split their value > transfer and NFT exchange into separate transactions, the network cannot > possibly determine the value exchanged. Even trustless transactions, > using a smart contract or other form of escrow, can arrange such split > transactions as a single _logical_ transfer. Counterparties that wish to _respect_ creator royalties MUST follow the pattern the network recognizes. <div style="margin-left: 2em; margin-top: -0.8em"> A single transaction MUST contain all three elements, transfer of the NFT, debit of fungible value from the receiver, and credit of fungible value to the sender, in order for the network to accurately assess royalty fees. </div> <div style="margin-left: 1em; margin-top: -0.8em"> Two examples are presented here. <div style="margin-left: 1em"> The NFT sender and receiver MUST both sign a single `cryptoTransfer` that transfers the NFT from sender to receiver, debits the fungible value from the receiver, and credits the sender with the fungible value the receiver is exchanging for the NFT.<br/> A marketplace using an approved spender account for an escrow transaction MUST credit the account selling the NFT in the same `cryptoTransfer` transaction that transfers the NFT to, and deducts fungible value from, the buying account. </div></div> This type of fee MAY NOT produce accurate results if multiple transfers are executed in a single transaction. It is RECOMMENDED that each NFT subject to royalty fees be transferred separately and without unrelated fungible token transfers. The network SHALL NOT consider third-party transfers, including "approved spender" accounts, in collecting royalty fees. An honest broker MUST ensure that transfer of an NFT and payment delivered to the sender are present in the same transaction. There is an [open suggestion](https://github.com/hashgraph/hedera-improvement-proposal/discussions/578) that proposes to broaden the scope of transfers from which the network automatically collects royalties to cover related third parties. If this interests or concerns you, please add your voice to that discussion.

Used in: CustomFee

message RunningHashes

running_hashes.proto:28

* The running hash of transaction records and the previous `3` running hashes. All hashes are 48 byte SHA384 hash values. If the running hashes do not exist yet (for example, at genesis) then each not-yet-available value SHALL be empty (zero-length) bytes.

message SchedulableTransactionBody

schedulable_transaction_body.proto:87

* A schedulable transaction. The network configuration `scheduling.whitelist` limits which of these transaction types may actually be scheduled. As of version `0.50.0` of the consensus node software this list contains only `CryptoTransfer`, `ConsensusSubmitMessage`, `TokenBurn`, `TokenMint`, and `CryptoApproveAllowance`.

Used in: Schedule, ScheduleCreateTransactionBody, ScheduleInfo

message Schedule

schedule.proto:33

* Representation of a Hedera Schedule entry in the network Merkle tree.<br/> A Schedule represents a request to run a transaction _at some future time_ either when the `Schedule` expires (if long term schedules are enabled and `wait_for_expiry` is true) or as soon as the `Schedule` has gathered enough signatures via any combination of the `scheduleCreate` and 0 or more subsequent `scheduleSign` transactions.

Used in: ScheduleList

message ScheduleCreateTransactionBody

schedule_create.proto:102

* Create a new Schedule. #### Requirements This transaction SHALL create a new _schedule_ entity in network state.<br/> The schedule created SHALL contain the `scheduledTransactionBody` to be executed.<br/> If successful the receipt SHALL contain a `scheduleID` with the full identifier of the schedule created.<br/> When a schedule _executes_ successfully, the receipt SHALL include a `scheduledTransactionID` with the `TransactionID` of the transaction that executed.<br/> When a scheduled transaction is executed the network SHALL charge the regular _service_ fee for the transaction to the `payerAccountID` for that schedule, but SHALL NOT charge node or network fees.<br/> If the `payerAccountID` field is not set, the effective `payerAccountID` SHALL be the `payer` for this create transaction.<br/> If an `adminKey` is not specified, or is an empty `KeyList`, the schedule created SHALL be immutable.<br/> An immutable schedule MAY be signed, and MAY execute, but SHALL NOT be deleted.<br/> If two schedules have the same values for all fields except `payerAccountID` then those two schedules SHALL be deemed "identical".<br/> If a `scheduleCreate` requests a new schedule that is identical to an existing schedule, the transaction SHALL fail and SHALL return a status code of `IDENTICAL_SCHEDULE_ALREADY_CREATED` in the receipt.<br/> The receipt for a duplicate schedule SHALL include the `ScheduleID` of the existing schedule and the `TransactionID` of the earlier `scheduleCreate` so that the earlier schedule may be queried and/or referred to in a subsequent `scheduleSign`. #### Signature Requirements A `scheduleSign` transaction SHALL be used to add additional signatures to an existing schedule.<br/> Each signature SHALL "activate" the corresponding cryptographic("primitive") key for that schedule.<br/> Signature requirements SHALL be met when the set of active keys includes all keys required by the scheduled transaction.<br/> A scheduled transaction for a "long term" schedule SHALL NOT execute if the signature requirements for that transaction are not met when the network consensus time reaches the schedule `expiration_time`.<br/> A "short term" schedule SHALL execute immediately once signature requirements are met. This MAY be immediately when created. #### Long Term Schedules A "short term" schedule SHALL have the flag `wait_for_expiry` _unset_.<br/> A "long term" schedule SHALL have the flag `wait_for_expiry` _set_.<br/> A "long term" schedule SHALL NOT be accepted if the network configuration `scheduling.longTermEnabled` is not enabled.<br/> A "long term" schedule SHALL execute when the current consensus time matches or exceeds the `expiration_time` for that schedule, if the signature requirements for the scheduled transaction are met at that instant.<br/> A "long term" schedule SHALL NOT execute before the current consensus time matches or exceeds the `expiration_time` for that schedule.<br/> A "long term" schedule SHALL expire, and be removed from state, after the network consensus time exceeds the schedule `expiration_time`.<br/> A short term schedule SHALL expire, and be removed from state, after the network consensus time exceeds the current network configuration for `ledger.scheduleTxExpiryTimeSecs`. > Note >> Long term schedules are not (as of release 0.56.0) enabled. Any schedule >> created currently MUST NOT set the `wait_for_expiry` flag.<br/> >> When long term schedules are not enabled, schedules SHALL NOT be >> executed at expiration, and MUST meet signature requirements strictly >> before expiration to be executed. ### Block Stream Effects If the scheduled transaction is executed immediately, the transaction record SHALL include a `scheduleRef` with the schedule identifier of the schedule created.

Used in: TransactionBody

message ScheduleDeleteTransactionBody

schedule_delete.proto:37

* Mark a schedule in the network state as deleted. This transaction MUST be signed by the `adminKey` for the identified schedule.<br/> If a schedule does not have `adminKey` set or if `adminKey` is an empty `KeyList`, that schedule SHALL be immutable and MUST NOT be deleted.<br/> A deleted schedule SHALL not be executed.<br/> A deleted schedule MUST NOT be the subject of a subsequent `scheduleSign` transaction. ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

message ScheduleGetInfoQuery

schedule_get_info.proto:34

* Request for information about a scheduled transaction. If the requested schedule does not exist, the network SHALL respond with `INVALID_SCHEDULE_ID`.

Used in: Query

message ScheduleGetInfoResponse

schedule_get_info.proto:210

* A response message for a `getScheduleInfo` query.

Used in: Response

message ScheduleID

basic_types.proto:334

* An unique identifier for a Schedule

Used in: Schedule, ScheduleDeleteTransactionBody, ScheduleGetInfoQuery, ScheduleIdList, ScheduleInfo, ScheduleSignTransactionBody, TransactionReceipt, TransactionRecord

message ScheduleIdList

schedule.proto:204

* A message for storing a list of schedule identifiers in state.<br/> This is used to store lists of `ScheduleID` values. One example is all schedules that expire at a particular time.

message ScheduleInfo

schedule_get_info.proto:54

* Information summarizing schedule state

Used in: ScheduleGetInfoResponse

message ScheduleList

schedule.proto:190

* A message for storing a list of schedules in state.<br/> This is used to store lists of `Schedule` values. One example is all schedules that expire at a particular time.

message ScheduleSignTransactionBody

schedule_sign.proto:50

* Add signatures to an existing scheduled transaction. When a schedule _executes_ successfully, the receipt SHALL include a `scheduledTransactionID` with the `TransactionID` of the transaction that executed.<br/> When a scheduled transaction is executed the network SHALL charge the regular _service_ fee for the transaction to the `payerAccountID` for that schedule, but SHALL NOT charge node or network fees.<br/> If the `payerAccountID` field is not set, the effective `payerAccountID` SHALL be the `payer` for this create transaction.<br/> Each signature on this transaction SHALL "activate" the corresponding cryptographic("primitive") key for the schedule identified.<br/> Signature requirements SHALL be met when the set of active keys includes all keys required by the scheduled transaction.<br/> A scheduled transaction for a "long term" schedule SHALL NOT execute if the signature requirements for that transaction are not met when the network consensus time reaches the schedule `expiration_time`.<br/> A "short term" schedule SHALL execute immediately once signature requirements are met. This MAY be immediately when created.<br/> ### Block Stream Effects If the scheduled transaction is executed immediately following this `scheduleSign` transaction, the transaction record SHALL include a `scheduleRef` with the schedule identifier `scheduleID`.

Used in: TransactionBody

message ScheduledCounts

schedule.proto:218

* A count of schedules scheduled and processed. This value summarizes the counts of scheduled and processed transactions within a particular consensus second.

message ScheduledOrder

schedule.proto:239

* An ordering for a scheduled transaction.<br/> This establishes the order in which scheduled transactions intended to execute at a particular consensus second will be executed. Scheduled transactions that have the same `expiry_second` SHALL execute in ascending order of `order_number`.

message SemanticVersion

basic_types.proto:2067

* A software version according to "[semantic versioning](https://semver.org/)" or "date versioning". Hedera currently modifies the "typical" semantic versioning somewhat, the `major` version is always `0`, and each release increments the `minor` version. The `patch` and `pre` components are used in the typical manner. The `build` component is not generally used.

Used in: com.hedera.hapi.node.state.blockstream.BlockStreamInfo, com.hedera.hapi.platform.event.EventCore, NetworkGetVersionInfoResponse

message ServiceEndpoint

basic_types.proto:1910

* A network node endpoint.<br/> Each network node in the global address book publishes one or more endpoints which enable the nodes to communicate both with other nodes, for gossip, and with clients to receive transaction requests. This message supports IPv4 with address and TCP port, and MAY include a FQDN instead of an IP address.<br/> IPv6 is not currently supported. When the `domain_name` field is set, the `ipAddressV4` field MUST NOT be set.<br/> When the `ipAddressV4` field is set, the `domain_name` field MUST NOT be set.

Used in: com.hedera.hapi.node.addressbook.NodeCreateTransactionBody, com.hedera.hapi.node.addressbook.NodeUpdateTransactionBody, com.hedera.hapi.node.state.addressbook.Node, com.hedera.hapi.node.state.roster.RosterEntry, NodeAddress

message ServicesConfigurationList

basic_types.proto:2145

* Setting values representing a source of runtime configuration information.

message Setting

basic_types.proto:2122

* A single runtime configuration setting. Typically a name-value pair, this may also contain a small amount of associated data.

Used in: ServicesConfigurationList

message ShardID

basic_types.proto:56

* A shard identifier.<br/> A shard is a partition of nodes running the network that processes transactions separately from other shards. Each shard is effectively an independent instance of the overall network that shares the same virtual distributed ledger, and may gossip cross-shard transactions with other shards to maintain overall correct processing of the ledger.

Used in: ContractCreateTransactionBody, CryptoCreateTransactionBody, FileCreateTransactionBody

message Signature

basic_types.proto:1017

* This message is deprecated and MUST NOT be used to communicate with network nodes. It is retained here only for historical reasons. Client software MUST NOT include this message in any request. <br/> Compliant nodes SHALL NOT accept any request containing this message. Please use the `SignaturePair` and `SignatureMap` messages instead of this message.

Used in: SignatureList

message SignatureList

basic_types.proto:1085

* This message is deprecated and MUST NOT be used to communicate with network nodes. It is retained here only for historical reasons. Client software MUST NOT include this message in any request. <br/> Compliant nodes SHALL NOT accept any request containing this message. Please use the `SignaturePair` and `SignatureMap` messages instead of this message.

Used in: Signature, ThresholdSignature, Transaction

message SignatureMap

basic_types.proto:1173

* A set of signatures corresponding to every unique public key that signed a given transaction. If any public key matches more than one prefix in the signature map, the transaction containing that map SHALL fail immediately with the response code `KEY_PREFIX_MISMATCH`.

Used in: SignedTransaction, Transaction

message SignaturePair

basic_types.proto:1099

* A public key and signature pair.<br/> Only Ed25519 and ECDSA(secp256k1) keys and signatures are currently supported as cryptographic (non-implied) signatures.

Used in: SignatureMap

message SignedTransaction

transaction_contents.proto:34

* A combination transaction bytes and a map of signatures.<br/> This message contains a serialized `TransactionBody` in a byte array and a `SignatureMap` that contains all of the signatures offered to authenticate the transaction. ### Block Stream Effects This content is recorded in the record stream exactly as received.

message SlotKey

storage_slot.proto:29

* The key of a storage slot. A slot is scoped to a specific contract ID. For each contract, its EVM storage is a mapping of 256-bit keys (or "words") to 256-bit values.

message SlotValue

storage_slot.proto:48

* The value of a contract storage slot. For the EVM, this is a single "word". Because we iterate through all the storage slots for an expired contract when purging it from state, our slot values also include the words of the previous and next keys in this contract's storage "virtual linked list".

message StakingInfo

basic_types.proto:2309

* Staking information for an account or a contract. This is used for responses returned from `CryptoGetInfo` or `ContractGetInfo` queries.

Used in: ContractGetInfoResponse.ContractInfo, CryptoGetInfoResponse.AccountInfo

message StakingNodeInfo

staking_node_info.proto:27

* An Hedera Token Service staking info entity. Staking info is per node. Shard and Realm are implied based on the network address book entry for this node.

enum SubType

basic_types.proto:679

* A transaction sub type.<br/> This enumeration enables a set of transaction base fees to be broadly defined for a type of operation and also be modified, when necessary, based on specifics of the operation. ### Explanation The resource cost for a TokenMint operation is different between minting fungible/common and non-fungible/unique tokens. This `enum` is used to "mark" a cost as applying to one or the other.<br/> Similarly, the resource cost for a basic `tokenCreate` without a custom fee schedule may yield a _base_ fee of $1. The resource cost for a `tokenCreate` _with_ a custom fee schedule is different and may yield a _base_ fee of $2 or more.

Used in: FeeData

message SystemDeleteTransactionBody

system_delete.proto:58

* Delete a file or contract bytecode as an administrative transaction. > Note >> A system delete/undelete for a `contractID` is not supported and >> SHALL return `INVALID_FILE_ID` or `MISSING_ENTITY_ID`. This transaction MAY be reversed by the `systemUndelete` transaction. A file deleted via `fileDelete`, however SHALL be irrecoverable.<br/> This transaction MUST specify an expiration timestamp (with seconds precision). The file SHALL be permanently removed from state when network consensus time exceeds the specified expiration time.<br/> This transaction MUST be signed by an Hedera administrative ("system") account. ### What is a "system" file A "system" file is any file with a file number less than or equal to the current configuration value for `ledger.numReservedSystemEntities`, typically `750`. ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

message SystemUndeleteTransactionBody

system_undelete.proto:54

* Recover a file or contract bytecode deleted from the Hedera File System (HFS) by a `systemDelete` transaction. > Note >> A system delete/undelete for a `contractID` is not supported and >> SHALL return `INVALID_FILE_ID` or `MISSING_ENTITY_ID`. This transaction can _only_ recover a file removed with the `systemDelete` transaction. A file deleted via `fileDelete` SHALL be irrecoverable.<br/> This transaction MUST be signed by an Hedera administrative ("system") account. ### What is a "system" file A "system" file is any file with a file number less than or equal to the current configuration value for `ledger.numReservedSystemEntities`, typically `750`. ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

message ThresholdKey

basic_types.proto:972

* A threshold value and a list of public keys that, together, form a threshold signature requirement. Any subset of the keys in the list may satisfy the signature requirements of this type of key, provided the number of keys meets or exceeds the threshold. For example, if a particular key has a threshold of three(3) and eight(8) keys in the list, then any three(3) signatures, from the list of eight(8), is sufficient to authorize that key. For threshold purposes, all signatures from a single `primitive` key are considered a single signature, so that signature(s) from a single key SHALL NOT _directly_ meet a threshold greater than one(1). #### Note > It is possible to construct a complex key structure that _would_ enable a > single primitive key to successfully meet a threshold requirement. All > threshold keys SHOULD be carefully audited to ensure no one `primitive` > key, or smart contract, has disproportionate capability.

Used in: Key

message ThresholdSignature

basic_types.proto:1065

* This message is deprecated and MUST NOT be used to communicate with network nodes. It is retained here only for historical reasons. Client software MUST NOT include this message in any request. <br/> Compliant nodes SHALL NOT accept any request containing this message. Please use the `SignaturePair` and `SignatureMap` messages, in combination with `ThresholdKey` keys, instead of this message.

Used in: Signature

message ThrottleBucket

throttle_definitions.proto:82

* A "bucket" of performance allocated across one or more throttle groups.<br/> This entry combines one or more throttle groups into a single unit to calculate limitations and congestion. Each "bucket" "fills" as operations are completed, then "drains" over a period of time defined for each bucket. This fill-and-drain characteristic enables the network to process sudden bursts of heavy traffic while still observing throttle limits over longer timeframes. The value of `burstPeriodMs` is combined with the `milliOpsPerSec` values for the individual throttle groups to determine the total bucket "capacity". This combination MUST be less than the maximum value of a signed long integer (`9223372036854775807`), when scaled to a nanosecond measurement resolution. > Note >> There is some question regarding the mechanism of calculating the >> combination of `burstPeriodMs` and `milliOpsPerSec`. The calculation >> Is implemented in difficult-to-find code, and very likely does not >> match the approach described here.

Used in: ThrottleDefinitions

message ThrottleDefinitions

throttle_definitions.proto:124

* A list of throttle buckets.<br/> This list, simultaneously enforced, defines a complete throttling policy. 1. When an operation appears in more than one throttling bucket, that operation SHALL be throttled unless all of the buckets where the operation appears have "capacity" available. 1. An operation assigned to no buckets is SHALL be throttled in every instance. The _effective_ throttle for this case is `0`.

message ThrottleGroup

throttle_definitions.proto:39

* A single throttle limit applied to one or more operations. The list of operations MUST contain at least one entry.<br/> The throttle limit SHALL be specified in thousandths of an operation per second; one operation per second for the network would be `1000`.<br/> The throttle limit MUST be greater than zero (`0`).

Used in: ThrottleBucket

message ThrottleUsageSnapshot

throttle_usage_snapshots.proto:51

* A single snapshot of the used throttle capacity for a throttle and point in time. > Question: >> What throttle does this apply to? How is that determined?

Used in: ThrottleUsageSnapshots

message ThrottleUsageSnapshots

throttle_usage_snapshots.proto:29

* All point-in-time snapshots of throttle usage for TPS and "gas" throttle values for a given point in time. > Question: >> What point in time? Should this store consensus timestamp here?

message Timestamp

timestamp.proto:30

* An exact date and time.<br/> This is the same data structure as the Google protobuf Timestamp.proto. #### Additional Notes Useful information is present in comments on the [Google version](https://github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto).

Used in: com.hedera.hapi.node.state.blockstream.BlockStreamInfo, com.hedera.hapi.node.state.hints.CRSState, com.hedera.hapi.node.state.hints.HintsConstruction, com.hedera.hapi.node.state.hints.HintsKeySet, com.hedera.hapi.node.state.history.HistoryProofConstruction, com.hedera.hapi.node.state.history.ProofKeySet, com.hedera.hapi.node.state.history.RecordedHistorySignature, com.hedera.hapi.platform.event.EventConsensusData, com.hedera.hapi.platform.event.EventCore, com.hedera.mirror.api.proto.ConsensusTopicQuery, com.hedera.mirror.api.proto.ConsensusTopicResponse, BlockInfo, CongestionLevelStarts, ConsensusTopicInfo, ConsensusUpdateTopicTransactionBody, ContractGetInfoResponse.ContractInfo, ContractUpdateTransactionBody, CryptoGetInfoResponse.AccountInfo, CryptoUpdateTransactionBody, FileCreateTransactionBody, FileGetInfoResponse.FileInfo, FileUpdateTransactionBody, FreezeTransactionBody, GetAccountDetailsResponse.AccountDetails, NetworkStakingRewards, Nft, NodeStakeUpdateTransactionBody, Schedule, ScheduleCreateTransactionBody, ScheduleInfo, StakingInfo, ThrottleUsageSnapshot, TokenCreateTransactionBody, TokenInfo, TokenNftInfo, TokenUpdateTransactionBody, TransactionID, TransactionRecord

message TimestampSeconds

timestamp.proto:54

* An exact date and time, with a resolution of one second.

Used in: ExchangeRate, FeeSchedule, SystemDeleteTransactionBody

message Token

token.proto:32

* An Hedera Token Service(HTS) token. A token SHALL represent a fungible or non-fungible unit of exchange.<br/> The specified Treasury Account SHALL receive the initial supply of tokens and SHALL determine distribution of all tokens once minted.

message TokenAirdropTransactionBody

token_airdrop.proto:87

* Airdrop one or more tokens to one or more accounts. ### Effects This distributes tokens from the balance of one or more sending account(s) to the balance of one or more recipient accounts. Accounts MAY receive the tokens in one of four ways. - An account already associated to the token to be distributed SHALL receive the airdropped tokens immediately to the recipient account balance.<br/> The fee for this transfer SHALL include the transfer, the airdrop fee, and any custom fees. - An account with available automatic association slots SHALL be automatically associated to the token, and SHALL immediately receive the airdropped tokens to the recipient account balance.<br/> The fee for this transfer SHALL include the transfer, the association, the cost to renew that association once, the airdrop fee, and any custom fees. - An account with "receiver signature required" set SHALL have a "Pending Airdrop" created and must claim that airdrop with a `claimAirdrop` transaction.<br/> The fee for this transfer SHALL include the transfer, the association, the cost to renew that association once, the airdrop fee, and any custom fees.<br/> If the pending airdrop is not claimed immediately, the `sender` SHALL pay the cost to renew the token association, and the cost to maintain the pending airdrop, until the pending airdrop is claimed or cancelled. - An account with no available automatic association slots SHALL have a "Pending Airdrop" created and must claim that airdrop with a `claimAirdrop` transaction.<br/> The fee for this transfer SHALL include the transfer, the association, the cost to renew that association once, the airdrop fee, and any custom fees.<br/> If the pending airdrop is not claimed immediately, the `sender` SHALL pay the cost to renew the token association, and the cost to maintain the pending airdrop, until the pending airdrop is claimed or cancelled. If an airdrop would create a pending airdrop for a fungible/common token, and a pending airdrop for the same sender, receiver, and token already exists, the existing pending airdrop SHALL be updated to add the new amount to the existing airdrop, rather than creating a new pending airdrop.<br/> Any airdrop that completes immediately SHALL be irreversible. Any airdrop that results in a "Pending Airdrop" MAY be canceled via a `cancelAirdrop` transaction.<br/> All transfer fees (including custom fees and royalties), as well as the rent cost for the first auto-renewal period for any automatic-association slot occupied by the airdropped tokens, SHALL be charged to the account paying for this transaction.<br/> ### Block Stream Effects - Each successful transfer SHALL be recorded in `token_transfer_list` for the transaction record. - Each successful transfer that consumes an automatic association slot SHALL populate the `automatic_association` field for the record. - Each pending transfer _created_ SHALL be added to the `pending_airdrops` field for the record. - Each pending transfer _updated_ SHALL be added to the `pending_airdrops` field for the record.

Used in: SchedulableTransactionBody, TransactionBody

message TokenAllowance

crypto_approve_allowance.proto:209

* An approved allowance of fungible/common token transfers. This message specifies one allowance for a single, unique, combination of token, owner, spender, and amount. If `owner` is not set, the effective `owner` SHALL be the `payer` for the enclosing transaction.<br/> The `tokenId` MUST be specified and MUST be a valid fungible/common token type.<br/> The `spender` MUST be specified and MUST be a valid account.<br/> The `amount` MUST be a whole number, and SHOULD be greater than `0` unless this allowance is intended to _remove_ a previously approved allowance.

Used in: CryptoApproveAllowanceTransactionBody

message TokenAssociateTransactionBody

token_associate.proto:53

* Associate an Hedera Token Service (HTS) token and an account. An association MUST exist between an account and a token before that account may transfer or receive that token.<br/> If the identified account is not found, the transaction SHALL return `INVALID_ACCOUNT_ID`.<br/> If the identified account has been deleted, the transaction SHALL return `ACCOUNT_DELETED`.<br/> If any of the identified tokens is not found, the transaction SHALL return `INVALID_TOKEN_REF`.<br/> If any of the identified tokens has been deleted, the transaction SHALL return `TOKEN_WAS_DELETED`.<br/> If an association already exists for any of the identified tokens, the transaction SHALL return `TOKEN_ALREADY_ASSOCIATED_TO_ACCOUNT`.<br/> The identified account MUST sign this transaction. ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

message TokenAssociation

basic_types.proto:2291

* An association between a token and an account. An account must be associated with a token before that account can transact in (send or receive) that token.

Used in: TransactionRecord

message TokenBalance

basic_types.proto:2245

* A number of _transferable units_ of a specified token. The transferable unit of a token is its smallest denomination, as given by the token's `decimals` property. Each minted token contains 10<sup>`decimals`</sup> transferable units. For example, we could think of the cent as the transferable unit of the US dollar (`decimals=2`); and the tinybar as the transferable unit of HBAR (`decimals=8`). Transferable units are not directly comparable across different tokens.

Used in: CryptoGetAccountBalanceResponse, TokenBalances

message TokenBalances

basic_types.proto:2277

* A set of token balance values. Each entry describes the balance the enclosing account holds for a specific token. The balance is an amount for a fungible/common token or a count for a non-fungible/unique token.

message TokenBurnTransactionBody

token_burn.proto:45

* Burns tokens from the Token's treasury Account. The token MUST have a `supply_key` set and that key MUST NOT be an empty `KeyList`.<br/> The token `supply_key` MUST sign this transaction.<br/> This operation SHALL decrease the total supply for the token type by the number of tokens "burned".<br/> The total supply for the token type MUST NOT be reduced below zero (`0`) by this transaction.<br/> The tokens to burn SHALL be deducted from the token treasury account.<br/> If the token is a fungible/common type, the amount MUST be specified.<br/> If the token is a non-fungible/unique type, the specific serial numbers MUST be specified.<br/> The global batch size limit (`tokens.nfts.maxBatchSizeBurn`) SHALL set the maximum number of individual NFT serial numbers permitted in a single `tokenBurn` transaction. ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

message TokenCancelAirdropTransactionBody

token_cancel_airdrop.proto:37

* Token cancel airdrop<br/> Remove one or more pending airdrops from state on behalf of the sender(s) for each airdrop. Each pending airdrop canceled SHALL be removed from state and SHALL NOT be available to claim.<br/> Each cancellation SHALL be represented in the transaction body and SHALL NOT be restated in the record file.<br/> All cancellations MUST succeed for this transaction to succeed. ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

message TokenClaimAirdropTransactionBody

token_claim_airdrop.proto:40

* Token claim airdrop<br/> Complete one or more pending transfers on behalf of the recipient(s) for an airdrop. The sender MUST have sufficient balance to fulfill the airdrop at the time of claim. If the sender does not have sufficient balance, the claim SHALL fail.<br/> Each pending airdrop successfully claimed SHALL be removed from state and SHALL NOT be available to claim again.<br/> Each claim SHALL be represented in the transaction body and SHALL NOT be restated in the record file.<br/> All claims MUST succeed for this transaction to succeed. ### Block Stream Effects The completed transfers SHALL be present in the transfer list.

Used in: SchedulableTransactionBody, TransactionBody

message TokenCreateTransactionBody

token_create.proto:72

* Create an HTS token. #### Keys Each token has several keys that, separately, control different functions for that token. It is *_strongly_* recommended that each key assigned to a token be unique, or disabled by assigning an empty `KeyList`. Keys and purpose - `adminKey` is a general access and may authorize a token update transaction as well as _update the other keys_. Even the admin key cannot authorize _adding_ a key that is not present, however.<br/> The admin key may also delete the token entirely. - `fee_schedule` may authorize updating the token custom fees. If this key is not present, the custom fees for the token are fixed and immutable. - `freeze` may authorize a token freeze or unfreeze transaction. If this key is not present, accounts holding this token cannot have their tokens frozen or unfrozen. - `kyc` may authorize a token grant KYC or revoke KYC transaction. If this key is not present, accounts holding this token cannot have KYC status granted or revoked. - `metadata` may authorize token update nfts transactions. If this key is not present, the token metadata values for that non-fungible/unique token _type_ will be immutable. - `pause` may authorize a token pause or token unpause transaction. If this key is not present, the token cannot be paused (preventing any account from transacting in that token) or resumed. - `supply` may authorize a token mint or burn transaction. If this key is not present, the token cannot mint additional supply and existing tokens cannot be "burned" from the treasury (but _might_ still be "burned" from individual accounts, c.f. `wipeKey` and `tokenWipe`). - `wipe` may authorize a token wipe account transaction. If this key is not present, accounts holding this token cannot have their balance or NFTs wiped (effectively burned). #### Requirements If `tokenType` is fungible/common, the `initialSupply` MUST be strictly greater than zero(`0`).<br/> If `tokenType` is non-fungible/unique, the `initialSupply` MUST be zero(`0`).<br/> If `tokenSupplyType` is "infinite", the `maxSupply` MUST be zero(`0`).<br/> If `tokenSupplyType` is "finite", the `maxSupply` MUST be strictly greater than zero(`0`).<br/> ### Block Stream Effects If the token is created, the Token Identifier SHALL be in the receipt.<br/>

Used in: SchedulableTransactionBody, TransactionBody

message TokenDeleteTransactionBody

token_delete.proto:50

* Mark a token as deleted.<br/> A deleted token remains present in the network state, but is no longer active, cannot be held in a balance, and all operations on that token fail. A deleted token is removed from network state when it expires. #### Operations on a deleted token All operations on a deleted token SHALL fail with a status code `TOKEN_WAS_DELETED`.<br/> Any attempt to transfer a deleted token between accounts SHALL fail with a status code `TOKEN_WAS_DELETED`. > QUESTIONS >> What happens to existing balances/NFTs? >> Are these removed; are they stuck on the accounts? > >> If balances/NFTs remain, can a `tokenReject` remove them? #### Requirements The `admin_key` for the token MUST be set, and MUST sign this transaction.<br/> If the `admin_key` for the token is not set, this transaction SHALL fail with a status code `TOKEN_IS_IMMUTABlE`. ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

message TokenDissociateTransactionBody

token_dissociate.proto:52

* Dissociate an account from one or more HTS tokens. If the identified account is not found, the transaction SHALL return `INVALID_ACCOUNT_ID`.<br/> If the identified account has been deleted, the transaction SHALL return `ACCOUNT_DELETED`.<br/> If any of the identified tokens is not found, the transaction SHALL return `INVALID_TOKEN_REF`.<br/> If any of the identified tokens has been deleted, the transaction SHALL return `TOKEN_WAS_DELETED`.<br/> If an association does not exist for any of the identified tokens, the transaction SHALL return `TOKEN_NOT_ASSOCIATED_TO_ACCOUNT`.<br/> If the identified account has a nonzero balance for any of the identified tokens, and that token is neither deleted nor expired, the transaction SHALL return `TRANSACTION_REQUIRES_ZERO_TOKEN_BALANCES`.<br/> If one of the identified tokens is a fungible/common token that is expired, the account MAY disassociate from that token, even if that token balance is not zero for that account.<br/> If one of the identified tokens is a non-fungible/unique token that is expired, the account MUST NOT disassociate if that account holds any individual NFT of that token. In this situation the transaction SHALL return `TRANSACTION_REQUIRED_ZERO_TOKEN_BALANCES`.<br/> The identified account MUST sign this transaction. ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

message TokenFeeScheduleUpdateTransactionBody

token_fee_schedule_update.proto:41

* Update the custom fee schedule for a token type. The token MUST have a `fee_schedule_key` set and that key MUST NOT be an empty `KeyList`.<br/> The token `fee_schedule_key` MUST sign this transaction.<br/> The token MUST exist, MUST NOT be deleted, and MUST NOT be expired.<br/> If the custom_fees list is empty, clears the fee schedule or resolves to CUSTOM_SCHEDULE_ALREADY_HAS_NO_FEES if the fee schedule was already empty. ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

message TokenFreezeAccountTransactionBody

token_freeze_account.proto:44

* Block transfers of a token type for an account.<br/> This, effectively, freezes assets of one account with respect to one token type. While frozen, that account cannot send or receive tokens of the identified type. The token MUST have a `freeze_key` set and that key MUST NOT be an empty `KeyList`.<br/> The token `freeze_key` MUST sign this transaction.<br/> The identified token MUST exist, MUST NOT be deleted, MUST NOT be paused, and MUST NOT be expired.<br/> The identified account MUST exist, MUST NOT be deleted, and MUST NOT be expired.<br/> If the identified account is already frozen with respect to the identified token, the transaction SHALL succeed, but no change SHALL be made.<br/> An association between the identified account and the identified token MUST exist. ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

enum TokenFreezeStatus

basic_types.proto:773

* Possible token freeze status values. This is returned by `TokenGetInfoQuery` or `CryptoGetInfoResponse` in `TokenRelationship`.

Used in: TokenInfo, TokenRelationship

message TokenGetAccountNftInfosQuery

token_get_account_nft_infos.proto:32

* Deleted and unsupported. This query is not implemented and any query of this type submitted SHALL return a `NOT_SUPPORTED` response code.

Used in: Query

message TokenGetAccountNftInfosResponse

token_get_account_nft_infos.proto:61

* Deleted and unsupported.

Used in: Response

message TokenGetInfoQuery

token_get_info.proto:31

* Request information for a token.

Used in: Query

message TokenGetInfoResponse

token_get_info.proto:380

* A response message for the `getTokenInfo` query.

Used in: Response

message TokenGetNftInfoQuery

token_get_nft_info.proto:29

* Applicable only to tokens of type NON_FUNGIBLE_UNIQUE. Gets info on a NFT for a given TokenID (of type NON_FUNGIBLE_UNIQUE) and serial number

Used in: Query

message TokenGetNftInfoResponse

token_get_nft_info.proto:90

* UNDOCUMENTED

Used in: Response

message TokenGetNftInfosQuery

token_get_nft_infos.proto:32

* Deleted and unsupported. This query is not implemented and any query of this type submitted SHALL return a `NOT_SUPPORTED` response code.

Used in: Query

message TokenGetNftInfosResponse

token_get_nft_infos.proto:65

* Deleted and unsupported.

Used in: Response

message TokenGrantKycTransactionBody

token_grant_kyc.proto:47

* Grant "Know Your Customer"(KYC) for one account for a single token. This transaction MUST be signed by the `kyc_key` for the token.<br/> The identified token MUST have a `kyc_key` set to a valid `Key` value.<br/> The token `kyc_key` MUST NOT be an empty `KeyList`.<br/> The identified token MUST exist and MUST NOT be deleted.<br/> The identified account MUST exist and MUST NOT be deleted.<br/> The identified account MUST have an association to the identified token.<br/> On success the association between the identified account and the identified token SHALL be marked as "KYC granted". ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

message TokenID

basic_types.proto:86

* Unique identifier for a token.<br/> As with all entity identifiers within the network, a token identifier consists of a combination of shard number, realm number, and entity number. Each of these numbers is unique within its scope (shard > realm > entity).

Used in: Account, AccountApprovalForAllAllowance, AccountFungibleTokenAllowance, AssessedCustomFee, EntityIDPair, FixedFee, GrantedNftAllowance, GrantedTokenAllowance, NftAllowance, NftID, NftRemoveAllowance, PendingAirdropId, Token, TokenAllowance, TokenAssociateTransactionBody, TokenAssociation, TokenBalance, TokenBurnTransactionBody, TokenDeleteTransactionBody, TokenDissociateTransactionBody, TokenFeeScheduleUpdateTransactionBody, TokenFreezeAccountTransactionBody, TokenGetInfoQuery, TokenGetNftInfosQuery, TokenGetNftInfosResponse, TokenGrantKycTransactionBody, TokenInfo, TokenMintTransactionBody, TokenPauseTransactionBody, TokenReference, TokenRelation, TokenRelationship, TokenRevokeKycTransactionBody, TokenTransferList, TokenUnfreezeAccountTransactionBody, TokenUnpauseTransactionBody, TokenUpdateNftsTransactionBody, TokenUpdateTransactionBody, TokenWipeAccountTransactionBody, TransactionReceipt

message TokenInfo

token_get_info.proto:55

* An Hedera Token Service(HTS) token. A token SHALL represent a fungible or non-fungible unit of exchange.<br/> The specified Treasury Account SHALL receive the initial supply of tokens and SHALL determine distribution of all tokens once minted.

Used in: TokenGetInfoResponse

enum TokenKeyValidation

basic_types.proto:754

* Types of validation strategies for token keys.

Used in: TokenUpdateTransactionBody

enum TokenKycStatus

basic_types.proto:798

* Possible token "KYC" status values. This is returned by `TokenGetInfoQuery` or `CryptoGetInfoResponse` in `TokenRelationship`.

Used in: TokenInfo, TokenRelationship

message TokenMintTransactionBody

token_mint.proto:47

* Mint tokens and deliver the new tokens to the token treasury account. The token MUST have a `supply_key` set and that key MUST NOT be an empty `KeyList`.<br/> The token `supply_key` MUST sign this transaction.<br/> This operation SHALL increase the total supply for the token type by the number of tokens "minted".<br/> The total supply for the token type MUST NOT be increased above the maximum supply limit (2^63-1) by this transaction.<br/> The tokens minted SHALL be credited to the token treasury account.<br/> If the token is a fungible/common type, the amount MUST be specified.<br/> If the token is a non-fungible/unique type, the metadata bytes for each unique token MUST be specified in the `metadata` list.<br/> Each unique metadata MUST not exceed the global metadata size limit defined by the network configuration value `tokens.maxMetadataBytes`.<br/> The global batch size limit (`tokens.nfts.maxBatchSizeMint`) SHALL set the maximum number of individual NFT metadata permitted in a single `tokenMint` transaction. ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

message TokenNftInfo

token_get_nft_info.proto:50

* Information for one non-fungible/unique token (NFT).

Used in: TokenGetAccountNftInfosResponse, TokenGetNftInfoResponse, TokenGetNftInfosResponse

enum TokenPauseStatus

basic_types.proto:824

* Possible Pause status values. This is returned by `TokenGetInfoQuery` in `TokenRelationship`.

Used in: TokenInfo

message TokenPauseTransactionBody

token_pause.proto:40

* Pause transaction activity for a token. This transaction MUST be signed by the Token `pause_key`.<br/> The `token` identified MUST exist, and MUST NOT be deleted.<br/> The `token` identified MAY be paused; if the token is already paused, this transaction SHALL have no effect. The `token` identified MUST have a `pause_key` set, the `pause_key` MUST be a valid `Key`, and the `pause_key` MUST NOT be an empty `KeyList`.<br/> A `paused` token SHALL NOT be transferred or otherwise modified except to "up-pause" the token with `unpauseToken` or in a `rejectToken` transaction. ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

message TokenReference

token_reject.proto:78

* A union token identifier. Identify a fungible/common token type, or a single non-fungible/unique token serial.

Used in: TokenRejectTransactionBody

message TokenRejectTransactionBody

token_reject.proto:44

* Reject undesired token(s).<br/> Transfer one or more token balances held by the requesting account to the treasury for each token type. Each transfer SHALL be one of the following - A single non-fungible/unique token. - The full balance held for a fungible/common token. A single `tokenReject` transaction SHALL support a maximum of 10 transfers.<br/> A token that is `pause`d MUST NOT be rejected.<br/> If the `owner` account is `frozen` with respect to the identified token(s) the token(s) MUST NOT be rejected.<br/> The `payer` for this transaction, and `owner` if set, SHALL NOT be charged any custom fees or other fees beyond the `tokenReject` transaction fee. ### Block Stream Effects - Each successful transfer from `payer` to `treasury` SHALL be recorded in the `token_transfer_list` for the transaction record.

Used in: SchedulableTransactionBody, TransactionBody

message TokenRelation

token_relation.proto:41

* An Hedera Token Service token relationship. A token relationship connects an Account with a Token and is necessary for that Account to transact in that Token. TokenRelationship defines a connection between one account and one token type. A TokenRelation SHALL be identified by the combination of token_id and account_id.<br/> A TokenRelation SHALL contain, for the referenced token,<br/> The account's current balance, whether the account has KYC granted, and whether the assets are frozen. TokenRelation entries SHALL be connected via a "virtual linked list" with the next TokenID and previous TokenID stored in the TokenRelation. These TokenIDs MUST be combined with the AccountID to find the next or previous relationship in the list.

message TokenRelationship

basic_types.proto:2166

* An Hedera Token Service token relationship. A token relationship describes the connection between an Account and a Token type, including the current account balance in that token. A `TokenRelationship` SHALL contain, for the designated token and enclosing account, The account's current balance, whether the account has KYC granted, whether the assets are frozen and whether the association was automatic.<br/> A `TokenRelationship` MAY also contain the `symbol` and `decimals` values copied from the token.<br/> `TokenRelationship` entries SHALL be valid only within the context of a `GetAccountDetails` query response, or other enclosing message, which specifies the account side of the relationship.

Used in: ContractGetInfoResponse.ContractInfo, CryptoGetInfoResponse.AccountInfo, GetAccountDetailsResponse.AccountDetails

message TokenRevokeKycTransactionBody

token_revoke_kyc.proto:47

* Revoke "Know Your Customer"(KYC) from one account for a single token. This transaction MUST be signed by the `kyc_key` for the token.<br/> The identified token MUST have a `kyc_key` set to a valid `Key` value.<br/> The token `kyc_key` MUST NOT be an empty `KeyList`.<br/> The identified token MUST exist and MUST NOT be deleted.<br/> The identified account MUST exist and MUST NOT be deleted.<br/> The identified account MUST have an association to the identified token.<br/> On success the association between the identified account and the identified token SHALL NOT be marked as "KYC granted". ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

enum TokenSupplyType

basic_types.proto:731

* Possible Token Supply Types (IWA Compatibility). This `enum` indicates the limit of tokens that can exist during the lifetime of a token definition. The "infinite" supply is only theoretically infinite, as it is still limited to the magnitude of a 64-bit signed integer. A "finite" supply is further limited to a value specified when the token is created (or updated, if not immutable).

Used in: Token, TokenCreateTransactionBody, TokenInfo

message TokenTransferList

basic_types.proto:546

* A list of transfers for a particular (non-HBAR) token type. A `TokenTransferList` applies to a single token type, but may contain many individual transfers.<br/> Each transfer of a fungible/common token MUST specify an `accountID` and `amount`. Amount SHALL be positive when the account receives tokens, and SHALL be negative when the account sends tokens. The amount SHOULD NOT be `0`.<br/> In a transfer list containing fungible/common tokens in the `transfers` list, the sum of all such transfers MUST be zero (`0`). Each transfer of a unique token SHALL specify both sender and receiver, as well as the serial number transferred.<br/> A single `TokenTransferList` MUST contain `transfers` or `nftTransfers`, but MUST NOT contain both.

Used in: CryptoTransferTransactionBody, TokenAirdropTransactionBody, TransactionRecord

enum TokenType

basic_types.proto:636

* Possible Token Types (IWA Compatibility). Apart from fungible and non-fungible, Tokens can have either a common or unique representation. Furthermore, tokens can have intrinsic or referential value, and can be whole and indivisible or fractional.<br/> These distinction might seem subtle, but it is important when considering how tokens can be traced, used, transferred, and if they can have isolated unique properties. A few examples (these may not match enumerations below) using IWA taxonomy. <dl> <dt>fungible, whole, intrinsic, unique</dt> <dd>Physical fiat currency</dd> <dt>fungible, fractional, intrinsic, common</dt> <dd>bank balance fiat currency</dd> <dt>non-fungible, fractional, reference, unique</dt> <dd>"mutual" collectible/art/property ownership</dd> <dt>non-fungible, whole, intrinsic, unique</dt> <dd>Physical work of fine art</dd> <dt>non-fungible, whole, reference, unique</dt> <dd>Registered property title</dd> </dl>

Used in: Token, TokenCreateTransactionBody, TokenInfo

message TokenUnfreezeAccountTransactionBody

token_unfreeze_account.proto:44

* Resume transfers of a token type for an account.<br/> This releases previously frozen assets of one account with respect to one token type. Once unfrozen, that account can once again send or receive tokens of the identified type. The token MUST have a `freeze_key` set and that key MUST NOT be an empty `KeyList`.<br/> The token `freeze_key` MUST sign this transaction.<br/> The identified token MUST exist, MUST NOT be deleted, MUST NOT be paused, and MUST NOT be expired.<br/> The identified account MUST exist, MUST NOT be deleted, and MUST NOT be expired.<br/> If the identified account is not frozen with respect to the identified token, the transaction SHALL succeed, but no change SHALL be made.<br/> An association between the identified account and the identified token MUST exist. ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

message TokenUnpauseTransactionBody

token_unpause.proto:40

* Resume transaction activity for a token. This transaction MUST be signed by the Token `pause_key`.<br/> The `token` identified MUST exist, and MUST NOT be deleted.<br/> The `token` identified MAY not be paused; if the token is not paused, this transaction SHALL have no effect. The `token` identified MUST have a `pause_key` set, the `pause_key` MUST be a valid `Key`, and the `pause_key` MUST NOT be an empty `KeyList`.<br/> An `unpaused` token MAY be transferred or otherwise modified. ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

message TokenUpdateNftsTransactionBody

token_update_nfts.proto:40

* Modify the metadata field for an individual non-fungible/unique token (NFT). Updating the metadata of an NFT SHALL NOT affect ownership or the ability to transfer that NFT.<br/> This transaction SHALL affect only the specific serial numbered tokens identified. This transaction SHALL modify individual token metadata.<br/> This transaction MUST be signed by the token `metadata_key`.<br/> The token `metadata_key` MUST be a valid `Key`.<br/> The token `metadata_key` MUST NOT be an empty `KeyList`. ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

message TokenUpdateTransactionBody

token_update.proto:52

* Update an existing token. This transaction SHALL NOT update any field that is not set.<br/> Most changes MUST be signed by the current `admin_key` of the token. If the token does not currently have a valid `admin_key`, then this transaction MUST NOT set any value other than `expiry` or a non-admin key.<br/> If the `treasury` is set to a new account, the new account MUST sign this transaction.<br/> If the `treasury` is set to a new account for a _non-fungible/unique_ token, The current treasury MUST NOT hold any tokens, or the network configuration property `tokens.nfts.useTreasuryWildcards` MUST be set. #### Requirements for Keys Any of the key values may be changed, even without an admin key, but the key to be changed MUST have an existing valid key assigned, and both the current key and the new key MUST sign the transaction.<br/> A key value MAY be set to an empty `KeyList`. In this case the existing key MUST sign this transaction, but the new value is not a valid key, and the update SHALL effectively remove the existing key. ### Block Stream Effects None

Used in: SchedulableTransactionBody, TransactionBody

message TokenWipeAccountTransactionBody

token_wipe_account.proto:43

* Wipe (administratively burn) tokens held by a non-treasury account.<br/> On success, the requested tokens will be removed from the identified account and the token supply will be reduced by the amount "wiped". This transaction MUST be signed by the token `wipe_key`.<br/> The identified token MUST exist, MUST NOT be deleted, and MUST NOT be paused.<br/> The identified token MUST have a valid `Key` set for the `wipe_key` field, and that key MUST NOT be an empty `KeyList`.<br/> The identified account MUST exist, MUST NOT be deleted, MUST be associated to the identified token, MUST NOT be frozen for the identified token, MUST NOT be the token `treasury`, and MUST hold a balance for the token or the specific serial numbers provided.<br/> This transaction SHOULD provide a value for `amount` or `serialNumbers`, but MUST NOT set both fields. ### Block Stream Effects The new total supply for the wiped token type SHALL be recorded.

Used in: SchedulableTransactionBody, TransactionBody

message Topic

topic.proto:38

* Representation of an Hedera Consensus Service(HCS) topic. As with all network entities, a topic has a unique entity number, which is usually given along with the network's shard and realm in the form of a shard.realm.number id.<br/> An HCS topic is an ordered logical stream of messages united and secured by a running hash of those messages. The integrity of any message on a topic, and the topic stream as a whole, can always be ascertained from block stream data by recomputing the running hash across any subset of messages on the topic.<br/> The messages on a topic SHALL NOT be stored in network state, but are available in the network block stream, and may be queried via the Mirror Node system.

message TopicID

basic_types.proto:314

* An unique identifier for a topic.<br/> Topics are part of the consensus service, messages are published to a topic.

Used in: com.hedera.mirror.api.proto.ConsensusTopicQuery, ConsensusDeleteTopicTransactionBody, ConsensusGetTopicInfoQuery, ConsensusGetTopicInfoResponse, ConsensusSubmitMessageTransactionBody, ConsensusUpdateTopicTransactionBody, Topic, TransactionReceipt

message Transaction

transaction.proto:114

* A wrapper around signed transaction bytes.<br/> This was originally a transaction with body, signatures, and/or bytes, but is not only a wrapper around a byte array containing signed transction bytes. The `signedTransactionBytes` field is REQUIRED and MUST contain a valid, serialized, `SignedTransaction` message.<br/> All other fields are deprecated and MUST NOT be set. #### Additional Notes The four deprecated fields will be removed and reserved in a future release.

<<<pbj.java_package = "com.hedera.hapi.node.base">>> This comment is special code for setting PBJ Compiler java package

Used as request type in: AddressBookService.createNode, AddressBookService.deleteNode, AddressBookService.updateNode, ConsensusService.createTopic, ConsensusService.deleteTopic, ConsensusService.submitMessage, ConsensusService.updateTopic, CryptoService.addLiveHash, CryptoService.approveAllowances, CryptoService.createAccount, CryptoService.cryptoDelete, CryptoService.cryptoTransfer, CryptoService.deleteAllowances, CryptoService.deleteLiveHash, CryptoService.updateAccount, FileService.appendContent, FileService.createFile, FileService.deleteFile, FileService.systemDelete, FileService.systemUndelete, FileService.updateFile, FreezeService.freeze, NetworkService.uncheckedSubmit, ScheduleService.createSchedule, ScheduleService.deleteSchedule, ScheduleService.signSchedule, SmartContractService.callEthereum, SmartContractService.contractCallMethod, SmartContractService.createContract, SmartContractService.deleteContract, SmartContractService.systemDelete, SmartContractService.systemUndelete, SmartContractService.updateContract, TokenService.airdropTokens, TokenService.associateTokens, TokenService.burnToken, TokenService.cancelAirdrop, TokenService.claimAirdrop, TokenService.createToken, TokenService.deleteToken, TokenService.dissociateTokens, TokenService.freezeTokenAccount, TokenService.grantKycToTokenAccount, TokenService.mintToken, TokenService.pauseToken, TokenService.rejectToken, TokenService.revokeKycFromTokenAccount, TokenService.unfreezeTokenAccount, TokenService.unpauseToken, TokenService.updateNfts, TokenService.updateToken, TokenService.updateTokenFeeSchedule, TokenService.wipeTokenAccount, UtilService.atomicBatch, UtilService.prng

Used as field type in: QueryHeader, TransactionList

message TransactionBody

transaction.proto:163

* A transaction body. Every transaction is structured as a signed byte array. That byte array is a serialized `TransactionBody`. The transaction body contains the full content of the transaction, while the `SignedTransaction` includes a signature map for signatures authenticating that byte array, and that is serialized and transmitted wrapped in a `Transaction` message.<br/> The bulk of this message is a `oneof` block which offers the option for any one of the transaction messages for the network. This message also includes several additional fields to specify various parameters required to process a transaction.

Used in: Schedule, Transaction

message TransactionFeeSchedule

basic_types.proto:1782

* The fee schedule for a specific transaction or query based on the fee data.

Used in: FeeSchedule

message TransactionGetFastRecordQuery

transaction_get_fast_record.proto:44

* Get the tx record of a transaction, given its transaction ID. Once a transaction reaches consensus, then information about whether it succeeded or failed will be available until the end of the receipt period. Before and after the receipt period, and for a transaction that was never submitted, the receipt is unknown.<br/> This query is free (the payment field is left empty).

Used in: Query

message TransactionGetFastRecordResponse

transaction_get_fast_record.proto:67

* Response when the client sends the node TransactionGetFastRecordQuery. If it created a new entity (account, file, or smart contract instance) then one of the three ID fields will be filled in with the ID of the new entity. Sometimes a single transaction will create more than one new entity, such as when a new contract instance is created, and this also creates the new account that it owned by that instance.

Used in: Response

message TransactionGetReceiptQuery

transaction_get_receipt.proto:70

* A query to retrieve a transaction receipt. This query retrieves the post-consensus (final) result of a transaction. A transaction receipt may not be available if queried too early (less than 5-10 seconds), or too late (more than 3 minutes). If a receipt is available, it contains basic transaction results. A query to a mirror node (or other archival system) is required to obtain full detail for a transaction, or any result after the basic receipt time period. This query is "free". The payment field in the header MUST be empty.<br/> If a receipt is not available, the response SHALL be `UNKNOWN`.<br/> A transaction receipt SHALL be available after the network reaches consensus for a transaction.<br/> A transaction receipt SHALL NOT be available after the end of the network configured "receipt period", typically three(3) minutes. <dl> <dt>What is the "first" transaction?</dt> <dd>The "first" transaction SHALL be the the transaction with the earliest consensus time and a status that is neither `INVALID_NODE_ACCOUNT` nor `INVALID_PAYER_SIGNATURE`.<br/> If no transaction is found meeting this status criteria, the "first" transaction SHALL be the transaction with the earliest consensus time.</dd> <dt>What is a "child" transaction?</dt> <dd>A "child" transaction is any transaction created in the process of completing another transaction. These are most common with a smart contract call, where a call to a contract may initiate one or more additional transactions to complete a complex process.</dd> </dl>

Used in: Query

message TransactionGetReceiptResponse

transaction_get_receipt.proto:135

* Response message for a `getTransactionReceipts` query. The `receipt` field SHALL return the receipt for the "first" transaction that matches the transaction identifier requested.<br/> If receipts for duplicate transactions are requested, those duplicate receipts SHALL be present in the `duplicateTransactionReceipts` list.<br/> If receipts for child transactions are requested, those child receipts SHALL be present in the `child_transaction_receipts` list.<br/> A state proof SHALL NOT be provided for this response; transaction receipts are not retained in network state. <dl> <dt>What is the "first" transaction?</dt> <dd>The "first" transaction receipt SHALL be the receipt for the first transaction with status that is neither `INVALID_NODE_ACCOUNT` nor `INVALID_PAYER_SIGNATURE`.<br/> If no transaction is found meeting the status criteria, the "first" transaction SHALL be the first transaction by consensus time.</dd> <dt>What is a "child" transaction?</dt> <dd>A "child" transaction is any transaction created in the process of completing another transaction. These are most common with a smart contract call, where a call to a contract may initiate one or more additional transactions to complete a complex process.</dd> </dl>

Used in: Response

message TransactionGetRecordQuery

transaction_get_record.proto:61

* Request for a `TransactionGetRecord` (a.k.a. `getTxRecordByTxID`) query. <p> A transaction record SHALL be available after the network reaches consensus and completes execution for a transaction.<br/> A transaction record SHALL NOT be available after the end of the network configured "record cache duration". <dl> <dt>What is the "first" transaction?</dt> <dd>The "first" transaction SHALL be the the transaction with the earliest consensus time and a status that is neither `INVALID_NODE_ACCOUNT` nor `INVALID_PAYER_SIGNATURE`.<br/> If no transaction is found meeting this status criteria, the "first" transaction SHALL be the transaction with the earliest consensus time.</dd> <dt>What is a "child" transaction?</dt> <dd>A "child" transaction is any transaction created in the process of completing another transaction. These are most common with a smart contract call, where a call to a contract may initiate one or more additional transactions to complete a complex process.</dd> </dl>

Used in: Query

message TransactionGetRecordResponse

transaction_get_record.proto:127

* Response message for a `getTxRecordByTxID` query. The `transactionRecord` field SHALL return the record for the "first" transaction that matches the transaction identifier requested.<br/> If records for duplicate transactions are requested, those duplicate records SHALL be present in the `duplicateTransactionReceipts` list.<br/> If records for child transactions are requested, those child records SHALL be present in the `child_transaction_records` list.<br/> A state proof MAY be provided for this response; provided the record is still available from the consensus nodes. <dl> <dt>What is the "first" transaction?</dt> <dd>The "first" transaction receipt SHALL be the receipt for the first transaction with status that is neither `INVALID_NODE_ACCOUNT` nor `INVALID_PAYER_SIGNATURE`.<br/> If no transaction is found meeting the status criteria, the "first" transaction SHALL be the first transaction by consensus time.</dd> <dt>What is a "child" transaction?</dt> <dd>A "child" transaction is any transaction created in the process of completing another transaction. These are most common with a smart contract call, where a call to a contract may initiate one or more additional transactions to complete a complex process.</dd> </dl>

Used in: Response

message TransactionID

basic_types.proto:395

* A transaction identifier.<br/> This is used for retrieving receipts and records for a transaction and internally by the network for detecting when duplicate transactions are submitted. A transaction may be processed more reliably by submitting it to several nodes, each with a different node account, but all with the same TransactionID. Then, the transaction will take effect when the first of all those nodes submits the transaction and it reaches consensus. The other transactions SHALL NOT be executed (and SHALL result in a `DUPLICATE_TRANSACTION` response).<br/> Multiple submission increase reliability on the assumption that an error in, for example, network connectivity will not affect all nodes equally. Latency might be slightly lower, if one node is handling intake significantly slower than others, for example. The base transaction fee is required for each submission, however, so the total fees charged are significantly higher when using this approach. ### Requirements Each transaction identifier MUST be unique.<br/> Multiple transactions MAY be submitted with the same transaction identifier, but all except the first SHALL be rejected as duplicate transactions.<br/> An identifier MUST specify a `payer` account to be charged all fees associated with the transaction.<br/> The `payer` account MUST exist and MUST have sufficient HBAR to pay all transaction fees.<br/> An identifier MUST specify a "valid start time".<br/> The "valid start time" MUST be strictly _earlier_ than the current network consensus time when submitted.<br/> The "valid start time" MUST NOT be more than `transaction.maxValidDuration` seconds before the current network consensus time when submitted.<br/> A client-submitted transaction MUST NOT set the `scheduled` flag. ### Additional Notes Additional items applicable to Scheduled Transactions: - The ID of a Scheduled Transaction, once executed, SHALL inherit both `transactionValidStart` and `accountID` from the `ScheduleCreate` transaction that created the schedule. - The `scheduled` property SHALL be set for Scheduled Transactions.

Used in: ConsensusMessageChunkInfo, NetworkGetExecutionTimeQuery, ScheduleInfo, TransactionBody, TransactionGetFastRecordQuery, TransactionGetReceiptQuery, TransactionGetRecordQuery, TransactionReceipt, TransactionReceiptEntry, TransactionRecord

message TransactionList

transaction_list.proto:17

* A simple protobuf wrapper to store a list of transactions. This is used by `Transaction.[from|to]Bytes()` in the SDKs. The reason the SDK needs a list of transactions is because it holds onto a transaction per node. So if a transaction is to be submitted to nodes 3 and 4 the SDK Transaction type would contain a list of 2 protobuf transactions, one for node 3 and one for node 4.

message TransactionReceipt

transaction_receipt.proto:34

* The summary of a transaction's result so far.<br/> If the transaction has not reached consensus, this result will be necessarily incomplete. Most items in this object are only set for specific transactions. Those values SHALL be unset for all other transactions.

Used in: TransactionGetReceiptResponse, TransactionRecord

message TransactionReceiptEntries

recordcache.proto:104

* A cache of transaction receipts.<br/> As transactions are handled and receipts are created, they are stored in state for a configured time limit (perhaps, for example, 3 minutes). During this time window, any client can query the node and get the receipt for the transaction. The `TransactionReceiptEntries` is the object stored in state with this information. This message SHALL contain a list of `TransactionReceiptEntry` objects.

message TransactionReceiptEntry

recordcache.proto:70

* An entry in the record cache with the receipt for a transaction. This is the entry stored in state that enables returning the receipt information when queried by clients. When a transaction is handled a receipt SHALL be created.<br/> This receipt MUST be stored in state for a configured time limit (e.g. 3 minutes).<br/> While a receipt is stored, a client MAY query the node and retrieve the receipt.

Used in: TransactionReceiptEntries

message TransactionRecord

transaction_record.proto:35

* Response when the client sends the node TransactionGetRecordResponse

Used in: ContractGetRecordsResponse, CryptoGetAccountRecordsResponse, TransactionGetFastRecordResponse, TransactionGetRecordResponse, TransactionRecordEntry

message TransactionRecordEntry

recordcache.proto:33

* As transactions are handled and records and receipts are created, they are stored in state for a configured time period (for example, 3 minutes). During this time, any client can query the node and get the record or receipt for the transaction. The `TransactionRecordEntry` is the object stored in state with this information.

message TransactionResponse

transaction_response.proto:40

* A message sent by a node in response to a transaction submission.<br/> This message only acknowledges that the individual node has checked the transaction, completed pre-check, and checked the fee offered. If the transaction fee is not sufficient, the `nodeTransactionPrecheckCode` value SHALL be `INSUFFICIENT_TX_FEE` and the `cost` field SHALL be the actual transaction fee, in tinybar, required.<br/> If the client requires acknowledgement of the network consensus result for a transaction, the client SHOULD request a transaction receipt or detailed transaction record. A client MAY also obtain network consensus results from a mirror node.

Used as response type in: AddressBookService.createNode, AddressBookService.deleteNode, AddressBookService.updateNode, ConsensusService.createTopic, ConsensusService.deleteTopic, ConsensusService.submitMessage, ConsensusService.updateTopic, CryptoService.addLiveHash, CryptoService.approveAllowances, CryptoService.createAccount, CryptoService.cryptoDelete, CryptoService.cryptoTransfer, CryptoService.deleteAllowances, CryptoService.deleteLiveHash, CryptoService.updateAccount, FileService.appendContent, FileService.createFile, FileService.deleteFile, FileService.systemDelete, FileService.systemUndelete, FileService.updateFile, FreezeService.freeze, NetworkService.uncheckedSubmit, ScheduleService.createSchedule, ScheduleService.deleteSchedule, ScheduleService.signSchedule, SmartContractService.callEthereum, SmartContractService.contractCallMethod, SmartContractService.createContract, SmartContractService.deleteContract, SmartContractService.systemDelete, SmartContractService.systemUndelete, SmartContractService.updateContract, TokenService.airdropTokens, TokenService.associateTokens, TokenService.burnToken, TokenService.cancelAirdrop, TokenService.claimAirdrop, TokenService.createToken, TokenService.deleteToken, TokenService.dissociateTokens, TokenService.freezeTokenAccount, TokenService.grantKycToTokenAccount, TokenService.mintToken, TokenService.pauseToken, TokenService.rejectToken, TokenService.revokeKycFromTokenAccount, TokenService.unfreezeTokenAccount, TokenService.unpauseToken, TokenService.updateNfts, TokenService.updateToken, TokenService.updateTokenFeeSchedule, TokenService.wipeTokenAccount, UtilService.atomicBatch, UtilService.prng

message TransferList

basic_types.proto:483

* A list of accounts and amounts to transfer. Each `AccountAmount` SHALL specify the account and the amount to send(negative) or receive(positive).<br/> Each `TransferList` SHALL be contained in another message that contains other details required to complete a transfer. This is typically a `CryptoTransferTransactionBody` or `TransactionRecord`.<br/> The `TransferList` SHALL only be used for HBAR transfers. Other token types MUST use the `TokenTransferList` message.

Used in: CryptoTransferTransactionBody, TransactionRecord

message UncheckedSubmitBody

unchecked_submit.proto:34

* Submit an arbitrary (serialized) Transaction to the network without pre-check. This transaction SHALL require `superuser` privileges (e.g. the `treasury` or `systemAdmin` accounts).

Used in: TransactionBody

message UtilPrngTransactionBody

util_prng.proto:30

* Request a deterministic pseudo-random number. The value returned SHALL be deterministic, but not easily predicted. The value returned SHALL NOT be suitable for cryptographic use. ### Block Stream Effects The result of this transaction is reported in a `UtilPrngOutput` message.

Used in: SchedulableTransactionBody, TransactionBody