| |
| Field |
Type |
Description |
| getByKey |
GetByKeyQuery |
Get all entities associated with a given key |
| |
Get all accounts, claims, files, and smart contract instances whose associated keys include the given Key. The given Key must not be a contractID or a ThresholdKey. This is not yet implemented in the API, but will be in the future.
| Field |
Type |
Description |
| header |
QueryHeader |
Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). |
| |
Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for.
| Field |
Type |
Description |
| payment |
Transaction |
A signed CryptoTransferTransaction to pay the node a fee for handling this query |
| |
A single signed transaction, including all its signatures. The SignatureList will have a Signature for each Key in the transaction, either explicit or implicit, in the order that they appear in the transaction. For example, a CryptoTransfer will first have a Signature corresponding to the Key for the paying account, followed by a Signature corresponding to the Key for each account that is sending or receiving cryptocurrency in the transfer. Each Transaction should not have more than 50 levels.
| Field |
Type |
Description |
| bodyData |
oneof |
|
| |
| Field |
Type |
Description |
| body |
TransactionBody |
the body of the transaction, which needs to be signed |
| |
A single transaction. All transaction types are possible here.
| Field |
Type |
Description |
| transactionID |
TransactionID |
The ID for this transaction, which includes the payer's account (the account paying the transaction fee). If two transactions have the same transactionID, they won't both have an effect |
| |
The ID for a transaction. This is used for retrieving receipts and records for a transaction, for appending to a file right after creating it, for instantiating a smart contract with bytecode in a file just created, and internally by the network for detecting when duplicate transactions are submitted. A user might get a transaction processed faster by submitting it to N 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 will not take effect. So this could make the transaction take effect faster, if any given node might be slow. However, the full transaction fee is charged for each transaction, so the total fee is N times as much if the transaction is sent to N nodes.
| Field |
Type |
Description |
| transactionValidStart |
Timestamp |
The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| accountID |
AccountID |
The Account ID that paid for this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| nodeAccountID |
AccountID |
The account of the node that submits the client's transaction to the network |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transactionFee |
uint64 |
The maximum transaction fee the client is willing to pay, which is split between the network and the node |
| transactionValidDuration |
Duration |
The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| generateRecord |
bool |
Should a record of this transaction be generated? (A receipt is always generated, but the record is optional) |
| memo |
string |
Any notes or descriptions that should be put into the record (max length 100) |
| data |
oneof |
|
| |
| Field |
Type |
Description |
| contractCall |
ContractCallTransactionBody |
Contains the call a function of a contract instance |
| |
Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.
| Field |
Type |
Description |
| contractID |
ContractID |
the contract instance to call, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| gas |
int64 |
the maximum amount of gas to use for the call |
| amount |
int64 |
number of tinybars sent (the function must be payable if this is nonzero) |
| functionParameters |
bytes |
which function to call, and the parameters to pass to the function |
|
| contractCreateInstance |
ContractCreateTransactionBody |
Contains the create data a contract instance |
| |
Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.
| Field |
Type |
Description |
| fileID |
FileID |
the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| adminKey |
Key |
the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| gas |
int64 |
gas to run the constructor |
| initialBalance |
int64 |
initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
the instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| constructorParameters |
bytes |
parameters to pass to the constructor |
| shardID |
ShardID |
shard in which to create this |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
realm in which to create this (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
if realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| memo |
string |
the memo that was submitted as part of the contract (max 100 bytes) |
|
| contractUpdateInstance |
ContractUpdateTransactionBody |
Contains contract modify info such as expiration date for a contract instance |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to update (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| expirationTime |
Timestamp |
Extend the expiration of the instance and its account to this time (no effect if it already is this time or later) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| adminKey |
Key |
The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
The instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| fileID |
FileID |
The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| memo |
string |
The memo associated with the contract (max 100 bytes) |
|
| contractDeleteInstance |
ContractDeleteTransactionBody |
Delete contract and transfer remaining balance into specified account |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to delete (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| obtainers |
oneof |
|
| |
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transferContractID |
ContractID |
The contract ID which will receive all remaining hbars |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| cryptoAddClaim |
CryptoAddClaimTransactionBody |
Attach a new claim to an account |
| |
Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.
| Field |
Type |
Description |
| claim |
Claim |
A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it |
| |
A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet.
| Field |
Type |
Description |
| accountID |
AccountID |
the account to which the claim is attached |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hash |
bytes |
48 byte SHA-384 hash (presumably of some kind of credential or certificate) |
| keys |
KeyList |
list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys). |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| claimDuration |
Duration |
the duration for which the claim will remain valid |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
|
|
| cryptoCreateAccount |
CryptoCreateTransactionBody |
Create a new cryptocurrency account |
| |
Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency for each record generated, so the thresholds are useful for limiting Record generation to happen only for large transactions. The Key field is the key used to sign transactions for this account. If the account has receiverSigRequired set to true, then all cryptocurrency transfers must be signed by this account's key, both for transfers in and out. If it is false, then only transfers out have to be signed by it. When the account is created, the payer account is charged enough hbars so that the new account will not expire for the next autoRenewPeriod seconds. When it reaches the expiration time, the new account will then be automatically charged to renew for another autoRenewPeriod seconds. If it does not have enough hbars to renew for that long, then the remaining hbars are used to extend its expiration as long as possible. If it is has a zero balance when it expires, then it is deleted. This transaction must be signed by the payer account. If receiverSigRequired is false, then the transaction does not have to be signed by the keys in the keys field. If it is true, then it must be signed by them, in addition to the keys of the payer account.
| Field |
Type |
Description |
| key |
Key |
The key that must sign each transfer out of the account. If receiverSigRequired is true, then it must also sign any transfer into the account. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| initialBalance |
uint64 |
The initial number of tinybars to put into the account |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| sendRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| receiveRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction |
| receiverSigRequired |
bool |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
| autoRenewPeriod |
Duration |
The account is charged to extend its expiration date every this many seconds. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| shardID |
ShardID |
The shard in which this account is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The realm in which this account is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| cryptoDelete |
CryptoDeleteTransactionBody |
Delete a cryptocurrency account (mark as deleted, and transfer hbars out) |
| |
Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way.
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| deleteAccountID |
AccountID |
The account ID which should be deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| cryptoDeleteClaim |
CryptoDeleteClaimTransactionBody |
Remove a claim from an account |
| |
Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes.
| Field |
Type |
Description |
| accountIDToDeleteFrom |
AccountID |
The account ID that should have a claim deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hashToDelete |
bytes |
The hash in the claim to delete (a SHA-384 hash, 48 bytes) |
|
| cryptoTransfer |
CryptoTransferTransactionBody |
Transfer amount between accounts |
| |
Transfer cryptocurrency from some accounts to other accounts. The accounts list can contain up to 10 accounts. The amounts list must be the same length as the accounts list. Each negative amount is withdrawn from the corresponding account (a sender), and each positive one is added to the corresponding account (a receiver). The amounts list must sum to zero. Each amount is a number of tinyBars (there are 100,000,000 tinyBars in one Hbar). If any sender account fails to have sufficient hbars to do the withdrawal, then the entire transaction fails, and none of those transfers occur, though the transaction fee is still charged. This transaction must be signed by the keys for all the sending accounts, and for any receiving accounts that have receiverSigRequired == true. The signatures are in the same order as the accounts, skipping those accounts that don't need a signature.
| Field |
Type |
Description |
| transfers |
TransferList |
Accounts and amounts to transfer |
| |
A list of accounts and amounts to transfer out of each account (negative) or into it (positive).
| Field |
Type |
Description |
| accountAmounts |
AccountAmount (repeated) |
Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative) |
| |
An account, and the amount that it sends or receives during a cryptocurrency transfer.
| Field |
Type |
Description |
| accountID |
AccountID |
The Account ID that sends or receives cryptocurrency |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| amount |
sint64 |
The amount of tinybars that the account sends(negative) or receives(positive) |
|
|
|
| cryptoUpdateAccount |
CryptoUpdateTransactionBody |
Modify information such as the expiration date for an account |
| |
Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account.
| Field |
Type |
Description |
| accountIDToUpdate |
AccountID |
The account ID which is being updated in this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| key |
Key |
The new key |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| proxyFraction |
int32 |
[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account |
| sendRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| sendRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| sendRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
|
| receiveRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| receiveRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
| receiveRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
|
| autoRenewPeriod |
Duration |
The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| expirationTime |
Timestamp |
The new expiration time to extend to (ignored if equal to or before the current one) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| receiverSigRequiredField |
oneof |
|
| |
| Field |
Type |
Description |
| receiverSigRequired |
bool |
[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose. |
| receiverSigRequiredWrapper |
google.protobuf.BoolValue |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
|
|
| fileAppend |
FileAppendTransactionBody |
Add bytes to the end of the contents of a file |
| |
Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to which the bytes are appended to |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contents |
bytes |
The bytes to append to the contents of the file |
|
| fileCreate |
FileCreateTransactionBody |
Create a new file |
| |
Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.
| Field |
Type |
Description |
| expirationTime |
Timestamp |
The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
All these keys must sign to create or modify the file. Any one of them can sign to delete the file. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The bytes that are the contents of the file |
| shardID |
ShardID |
Shard in which this file is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The Realm in which to the file is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| fileDelete |
FileDeleteTransactionBody |
Delete a file (remove contents and mark as deleted until it expires) |
| |
Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys).
| Field |
Type |
Description |
| fileID |
FileID |
The file to delete. It will be marked as deleted until it expires. Then it will disappear. |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
|
| fileUpdate |
FileUpdateTransactionBody |
Modify information such as the expiration date for a file |
| |
Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to update |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| expirationTime |
Timestamp |
The new time at which it should expire (ignored if not later than the current value) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
The keys that can modify or delete the file |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The new file contents. All the bytes in the old contents are discarded. |
|
| systemDelete |
SystemDeleteTransactionBody |
Hedera multisig system deletes a file or smart contract |
| |
Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to delete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to delete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
| expirationTime |
TimestampSeconds |
The timestamp in seconds at which the "deleted" file should truly be permanently deleted |
| |
An exact date and time, with a resolution of one second (no nanoseconds).
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
|
|
| systemUndelete |
SystemUndeleteTransactionBody |
To undelete an entity deleted by SystemDelete |
| |
Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID to undelete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to undelete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| freeze |
FreezeTransactionBody |
Freeze the nodes |
| |
Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance.
| Field |
Type |
Description |
| startHour |
int32 |
The start hour (in UTC time), a value between 0 and 23 |
| startMin |
int32 |
The start minute (in UTC time), a value between 0 and 59 |
| endHour |
int32 |
The end hour (in UTC time), a value between 0 and 23 |
| endMin |
int32 |
The end minute (in UTC time), a value between 0 and 59 |
|
| consensusCreateTopic |
ConsensusCreateTopicTransactionBody |
|
| consensusUpdateTopic |
ConsensusUpdateTopicTransactionBody |
|
| consensusDeleteTopic |
ConsensusDeleteTopicTransactionBody |
|
| consensusSubmitMessage |
ConsensusSubmitMessageTransactionBody |
|
| |
| Field |
Type |
Description |
| topicID |
TopicID |
Topic to submit message to. |
| |
Unique identifier for a topic (used by the consensus service)
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| topicNum |
int64 |
Unique topic identifier within a realm (nonnegative). |
|
| message |
bytes |
Message to be submitted. Max size of the Transaction (including signatures) is 4kB. |
|
|
|
| bodyBytes |
bytes |
TransactionBody serialized into bytes , which needs to be signed |
|
| sigs |
SignatureList |
The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field |
| |
The signatures corresponding to a KeyList of the same length.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
Signature (repeated) |
each signature corresponds to a Key in the KeyList |
| |
A Signature corresponding to a Key. It is a sequence of bytes holding a public key signature from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be a list of signatures corresponding to a single threshold key. Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. If it has a smart contract ID associated with it, then that smart contract is allowed to transfer cryptocurrency out of it. The smart contract doesn't actually have a key, and doesn't actually sign a transaction. But it's as if a virtual transaction were created, and the smart contract signed it with a private key. A key can also be a "threshold key", which means a list of M keys, any N of which must sign in order for the threshold signature to be considered valid. The keys within a threshold signature may themselves be threshold signatures, to allow complex signature requirements (this nesting is not supported in the currently, but will be supported in a future version of API). If a Signature message is missing the "signature" field, then this is considered to be a null signature. That is useful in cases such as threshold signatures, where some of the signatures can be null.
| Field |
Type |
Description |
| deprecated |
option |
|
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature bytes |
| RSA_3072 |
bytes |
RSA-3072 signature bytes |
| ECDSA_384 |
bytes |
ECDSA p-384 signature bytes |
| thresholdSignature |
ThresholdSignature |
A list of signatures for a single N-of-M threshold Key. This must be a list of exactly M signatures, at least N of which are non-null. |
| |
A signature corresponding to a ThresholdKey. For an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
SignatureList |
for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null |
| |
Self Reference
|
|
| signatureList |
SignatureList |
A list of M signatures, each corresponding to a Key in a KeyList of the same length. |
| |
Self Reference
|
|
|
|
| sigMap |
SignatureMap |
The signatures on the body with the new format, to authorize the transaction |
| |
A set of signatures corresponding to every unique public key used to sign a given transaction.
| Field |
Type |
Description |
| sigPair |
SignaturePair (repeated) |
Each signature pair corresponds to a unique Key required to sign the transaction. |
| |
The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.
| Field |
Type |
Description |
| pubKeyPrefix |
bytes |
First few bytes of the public key |
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature |
| RSA_3072 |
bytes |
RSA-3072 signature |
| ECDSA_384 |
bytes |
ECDSA p-384 signature |
|
|
|
|
| responseType |
ResponseType |
The requested response, asking for cost, state proof, both, or neither |
| |
The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request.
| Enum Name |
Description |
| ANSWER_ONLY |
Response returns answer |
| ANSWER_STATE_PROOF |
Response returns both answer and state proof |
| COST_ANSWER |
Response returns the cost of answer |
| COST_ANSWER_STATE_PROOF |
Response returns the total cost of answer and state proof |
|
|
| key |
Key |
The key to search for. It must not contain a contractID nor a ThresholdSignature. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| getBySolidityID |
GetBySolidityIDQuery |
Get the IDs in the format used in transactions, given the format used in Solidity |
| |
Get the IDs in the format used by transactions, given the ID in the format used by Solidity. If the Solidity ID is for a smart contract instance, then both the ContractID and associated AccountID will be returned.
| Field |
Type |
Description |
| header |
QueryHeader |
Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). |
| |
Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for.
| Field |
Type |
Description |
| payment |
Transaction |
A signed CryptoTransferTransaction to pay the node a fee for handling this query |
| |
A single signed transaction, including all its signatures. The SignatureList will have a Signature for each Key in the transaction, either explicit or implicit, in the order that they appear in the transaction. For example, a CryptoTransfer will first have a Signature corresponding to the Key for the paying account, followed by a Signature corresponding to the Key for each account that is sending or receiving cryptocurrency in the transfer. Each Transaction should not have more than 50 levels.
| Field |
Type |
Description |
| bodyData |
oneof |
|
| |
| Field |
Type |
Description |
| body |
TransactionBody |
the body of the transaction, which needs to be signed |
| |
A single transaction. All transaction types are possible here.
| Field |
Type |
Description |
| transactionID |
TransactionID |
The ID for this transaction, which includes the payer's account (the account paying the transaction fee). If two transactions have the same transactionID, they won't both have an effect |
| |
The ID for a transaction. This is used for retrieving receipts and records for a transaction, for appending to a file right after creating it, for instantiating a smart contract with bytecode in a file just created, and internally by the network for detecting when duplicate transactions are submitted. A user might get a transaction processed faster by submitting it to N 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 will not take effect. So this could make the transaction take effect faster, if any given node might be slow. However, the full transaction fee is charged for each transaction, so the total fee is N times as much if the transaction is sent to N nodes.
| Field |
Type |
Description |
| transactionValidStart |
Timestamp |
The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| accountID |
AccountID |
The Account ID that paid for this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| nodeAccountID |
AccountID |
The account of the node that submits the client's transaction to the network |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transactionFee |
uint64 |
The maximum transaction fee the client is willing to pay, which is split between the network and the node |
| transactionValidDuration |
Duration |
The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| generateRecord |
bool |
Should a record of this transaction be generated? (A receipt is always generated, but the record is optional) |
| memo |
string |
Any notes or descriptions that should be put into the record (max length 100) |
| data |
oneof |
|
| |
| Field |
Type |
Description |
| contractCall |
ContractCallTransactionBody |
Contains the call a function of a contract instance |
| |
Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.
| Field |
Type |
Description |
| contractID |
ContractID |
the contract instance to call, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| gas |
int64 |
the maximum amount of gas to use for the call |
| amount |
int64 |
number of tinybars sent (the function must be payable if this is nonzero) |
| functionParameters |
bytes |
which function to call, and the parameters to pass to the function |
|
| contractCreateInstance |
ContractCreateTransactionBody |
Contains the create data a contract instance |
| |
Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.
| Field |
Type |
Description |
| fileID |
FileID |
the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| adminKey |
Key |
the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| gas |
int64 |
gas to run the constructor |
| initialBalance |
int64 |
initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
the instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| constructorParameters |
bytes |
parameters to pass to the constructor |
| shardID |
ShardID |
shard in which to create this |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
realm in which to create this (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
if realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| memo |
string |
the memo that was submitted as part of the contract (max 100 bytes) |
|
| contractUpdateInstance |
ContractUpdateTransactionBody |
Contains contract modify info such as expiration date for a contract instance |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to update (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| expirationTime |
Timestamp |
Extend the expiration of the instance and its account to this time (no effect if it already is this time or later) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| adminKey |
Key |
The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
The instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| fileID |
FileID |
The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| memo |
string |
The memo associated with the contract (max 100 bytes) |
|
| contractDeleteInstance |
ContractDeleteTransactionBody |
Delete contract and transfer remaining balance into specified account |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to delete (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| obtainers |
oneof |
|
| |
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transferContractID |
ContractID |
The contract ID which will receive all remaining hbars |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| cryptoAddClaim |
CryptoAddClaimTransactionBody |
Attach a new claim to an account |
| |
Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.
| Field |
Type |
Description |
| claim |
Claim |
A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it |
| |
A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet.
| Field |
Type |
Description |
| accountID |
AccountID |
the account to which the claim is attached |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hash |
bytes |
48 byte SHA-384 hash (presumably of some kind of credential or certificate) |
| keys |
KeyList |
list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys). |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| claimDuration |
Duration |
the duration for which the claim will remain valid |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
|
|
| cryptoCreateAccount |
CryptoCreateTransactionBody |
Create a new cryptocurrency account |
| |
Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency for each record generated, so the thresholds are useful for limiting Record generation to happen only for large transactions. The Key field is the key used to sign transactions for this account. If the account has receiverSigRequired set to true, then all cryptocurrency transfers must be signed by this account's key, both for transfers in and out. If it is false, then only transfers out have to be signed by it. When the account is created, the payer account is charged enough hbars so that the new account will not expire for the next autoRenewPeriod seconds. When it reaches the expiration time, the new account will then be automatically charged to renew for another autoRenewPeriod seconds. If it does not have enough hbars to renew for that long, then the remaining hbars are used to extend its expiration as long as possible. If it is has a zero balance when it expires, then it is deleted. This transaction must be signed by the payer account. If receiverSigRequired is false, then the transaction does not have to be signed by the keys in the keys field. If it is true, then it must be signed by them, in addition to the keys of the payer account.
| Field |
Type |
Description |
| key |
Key |
The key that must sign each transfer out of the account. If receiverSigRequired is true, then it must also sign any transfer into the account. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| initialBalance |
uint64 |
The initial number of tinybars to put into the account |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| sendRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| receiveRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction |
| receiverSigRequired |
bool |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
| autoRenewPeriod |
Duration |
The account is charged to extend its expiration date every this many seconds. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| shardID |
ShardID |
The shard in which this account is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The realm in which this account is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| cryptoDelete |
CryptoDeleteTransactionBody |
Delete a cryptocurrency account (mark as deleted, and transfer hbars out) |
| |
Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way.
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| deleteAccountID |
AccountID |
The account ID which should be deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| cryptoDeleteClaim |
CryptoDeleteClaimTransactionBody |
Remove a claim from an account |
| |
Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes.
| Field |
Type |
Description |
| accountIDToDeleteFrom |
AccountID |
The account ID that should have a claim deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hashToDelete |
bytes |
The hash in the claim to delete (a SHA-384 hash, 48 bytes) |
|
| cryptoTransfer |
CryptoTransferTransactionBody |
Transfer amount between accounts |
| |
Transfer cryptocurrency from some accounts to other accounts. The accounts list can contain up to 10 accounts. The amounts list must be the same length as the accounts list. Each negative amount is withdrawn from the corresponding account (a sender), and each positive one is added to the corresponding account (a receiver). The amounts list must sum to zero. Each amount is a number of tinyBars (there are 100,000,000 tinyBars in one Hbar). If any sender account fails to have sufficient hbars to do the withdrawal, then the entire transaction fails, and none of those transfers occur, though the transaction fee is still charged. This transaction must be signed by the keys for all the sending accounts, and for any receiving accounts that have receiverSigRequired == true. The signatures are in the same order as the accounts, skipping those accounts that don't need a signature.
| Field |
Type |
Description |
| transfers |
TransferList |
Accounts and amounts to transfer |
| |
A list of accounts and amounts to transfer out of each account (negative) or into it (positive).
| Field |
Type |
Description |
| accountAmounts |
AccountAmount (repeated) |
Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative) |
| |
An account, and the amount that it sends or receives during a cryptocurrency transfer.
| Field |
Type |
Description |
| accountID |
AccountID |
The Account ID that sends or receives cryptocurrency |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| amount |
sint64 |
The amount of tinybars that the account sends(negative) or receives(positive) |
|
|
|
| cryptoUpdateAccount |
CryptoUpdateTransactionBody |
Modify information such as the expiration date for an account |
| |
Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account.
| Field |
Type |
Description |
| accountIDToUpdate |
AccountID |
The account ID which is being updated in this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| key |
Key |
The new key |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| proxyFraction |
int32 |
[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account |
| sendRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| sendRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| sendRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
|
| receiveRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| receiveRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
| receiveRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
|
| autoRenewPeriod |
Duration |
The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| expirationTime |
Timestamp |
The new expiration time to extend to (ignored if equal to or before the current one) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| receiverSigRequiredField |
oneof |
|
| |
| Field |
Type |
Description |
| receiverSigRequired |
bool |
[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose. |
| receiverSigRequiredWrapper |
google.protobuf.BoolValue |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
|
|
| fileAppend |
FileAppendTransactionBody |
Add bytes to the end of the contents of a file |
| |
Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to which the bytes are appended to |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contents |
bytes |
The bytes to append to the contents of the file |
|
| fileCreate |
FileCreateTransactionBody |
Create a new file |
| |
Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.
| Field |
Type |
Description |
| expirationTime |
Timestamp |
The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
All these keys must sign to create or modify the file. Any one of them can sign to delete the file. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The bytes that are the contents of the file |
| shardID |
ShardID |
Shard in which this file is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The Realm in which to the file is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| fileDelete |
FileDeleteTransactionBody |
Delete a file (remove contents and mark as deleted until it expires) |
| |
Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys).
| Field |
Type |
Description |
| fileID |
FileID |
The file to delete. It will be marked as deleted until it expires. Then it will disappear. |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
|
| fileUpdate |
FileUpdateTransactionBody |
Modify information such as the expiration date for a file |
| |
Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to update |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| expirationTime |
Timestamp |
The new time at which it should expire (ignored if not later than the current value) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
The keys that can modify or delete the file |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The new file contents. All the bytes in the old contents are discarded. |
|
| systemDelete |
SystemDeleteTransactionBody |
Hedera multisig system deletes a file or smart contract |
| |
Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to delete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to delete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
| expirationTime |
TimestampSeconds |
The timestamp in seconds at which the "deleted" file should truly be permanently deleted |
| |
An exact date and time, with a resolution of one second (no nanoseconds).
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
|
|
| systemUndelete |
SystemUndeleteTransactionBody |
To undelete an entity deleted by SystemDelete |
| |
Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID to undelete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to undelete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| freeze |
FreezeTransactionBody |
Freeze the nodes |
| |
Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance.
| Field |
Type |
Description |
| startHour |
int32 |
The start hour (in UTC time), a value between 0 and 23 |
| startMin |
int32 |
The start minute (in UTC time), a value between 0 and 59 |
| endHour |
int32 |
The end hour (in UTC time), a value between 0 and 23 |
| endMin |
int32 |
The end minute (in UTC time), a value between 0 and 59 |
|
| consensusCreateTopic |
ConsensusCreateTopicTransactionBody |
|
| consensusUpdateTopic |
ConsensusUpdateTopicTransactionBody |
|
| consensusDeleteTopic |
ConsensusDeleteTopicTransactionBody |
|
| consensusSubmitMessage |
ConsensusSubmitMessageTransactionBody |
|
| |
| Field |
Type |
Description |
| topicID |
TopicID |
Topic to submit message to. |
| |
Unique identifier for a topic (used by the consensus service)
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| topicNum |
int64 |
Unique topic identifier within a realm (nonnegative). |
|
| message |
bytes |
Message to be submitted. Max size of the Transaction (including signatures) is 4kB. |
|
|
|
| bodyBytes |
bytes |
TransactionBody serialized into bytes , which needs to be signed |
|
| sigs |
SignatureList |
The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field |
| |
The signatures corresponding to a KeyList of the same length.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
Signature (repeated) |
each signature corresponds to a Key in the KeyList |
| |
A Signature corresponding to a Key. It is a sequence of bytes holding a public key signature from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be a list of signatures corresponding to a single threshold key. Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. If it has a smart contract ID associated with it, then that smart contract is allowed to transfer cryptocurrency out of it. The smart contract doesn't actually have a key, and doesn't actually sign a transaction. But it's as if a virtual transaction were created, and the smart contract signed it with a private key. A key can also be a "threshold key", which means a list of M keys, any N of which must sign in order for the threshold signature to be considered valid. The keys within a threshold signature may themselves be threshold signatures, to allow complex signature requirements (this nesting is not supported in the currently, but will be supported in a future version of API). If a Signature message is missing the "signature" field, then this is considered to be a null signature. That is useful in cases such as threshold signatures, where some of the signatures can be null.
| Field |
Type |
Description |
| deprecated |
option |
|
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature bytes |
| RSA_3072 |
bytes |
RSA-3072 signature bytes |
| ECDSA_384 |
bytes |
ECDSA p-384 signature bytes |
| thresholdSignature |
ThresholdSignature |
A list of signatures for a single N-of-M threshold Key. This must be a list of exactly M signatures, at least N of which are non-null. |
| |
A signature corresponding to a ThresholdKey. For an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
SignatureList |
for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null |
| |
Self Reference
|
|
| signatureList |
SignatureList |
A list of M signatures, each corresponding to a Key in a KeyList of the same length. |
| |
Self Reference
|
|
|
|
| sigMap |
SignatureMap |
The signatures on the body with the new format, to authorize the transaction |
| |
A set of signatures corresponding to every unique public key used to sign a given transaction.
| Field |
Type |
Description |
| sigPair |
SignaturePair (repeated) |
Each signature pair corresponds to a unique Key required to sign the transaction. |
| |
The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.
| Field |
Type |
Description |
| pubKeyPrefix |
bytes |
First few bytes of the public key |
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature |
| RSA_3072 |
bytes |
RSA-3072 signature |
| ECDSA_384 |
bytes |
ECDSA p-384 signature |
|
|
|
|
| responseType |
ResponseType |
The requested response, asking for cost, state proof, both, or neither |
| |
The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request.
| Enum Name |
Description |
| ANSWER_ONLY |
Response returns answer |
| ANSWER_STATE_PROOF |
Response returns both answer and state proof |
| COST_ANSWER |
Response returns the cost of answer |
| COST_ANSWER_STATE_PROOF |
Response returns the total cost of answer and state proof |
|
|
| solidityID |
string |
The ID in the format used by Solidity |
|
| contractCallLocal |
ContractCallLocalQuery |
Call a function of a smart contract instance |
| |
Call a function of the given smart contract instance, giving it functionParameters as its inputs. It will consume the entire given amount of gas.
| Field |
Type |
Description |
| header |
QueryHeader |
standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). The payment must cover the fees and all of the gas offered. |
| |
Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for.
| Field |
Type |
Description |
| payment |
Transaction |
A signed CryptoTransferTransaction to pay the node a fee for handling this query |
| |
A single signed transaction, including all its signatures. The SignatureList will have a Signature for each Key in the transaction, either explicit or implicit, in the order that they appear in the transaction. For example, a CryptoTransfer will first have a Signature corresponding to the Key for the paying account, followed by a Signature corresponding to the Key for each account that is sending or receiving cryptocurrency in the transfer. Each Transaction should not have more than 50 levels.
| Field |
Type |
Description |
| bodyData |
oneof |
|
| |
| Field |
Type |
Description |
| body |
TransactionBody |
the body of the transaction, which needs to be signed |
| |
A single transaction. All transaction types are possible here.
| Field |
Type |
Description |
| transactionID |
TransactionID |
The ID for this transaction, which includes the payer's account (the account paying the transaction fee). If two transactions have the same transactionID, they won't both have an effect |
| |
The ID for a transaction. This is used for retrieving receipts and records for a transaction, for appending to a file right after creating it, for instantiating a smart contract with bytecode in a file just created, and internally by the network for detecting when duplicate transactions are submitted. A user might get a transaction processed faster by submitting it to N 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 will not take effect. So this could make the transaction take effect faster, if any given node might be slow. However, the full transaction fee is charged for each transaction, so the total fee is N times as much if the transaction is sent to N nodes.
| Field |
Type |
Description |
| transactionValidStart |
Timestamp |
The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| accountID |
AccountID |
The Account ID that paid for this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| nodeAccountID |
AccountID |
The account of the node that submits the client's transaction to the network |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transactionFee |
uint64 |
The maximum transaction fee the client is willing to pay, which is split between the network and the node |
| transactionValidDuration |
Duration |
The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| generateRecord |
bool |
Should a record of this transaction be generated? (A receipt is always generated, but the record is optional) |
| memo |
string |
Any notes or descriptions that should be put into the record (max length 100) |
| data |
oneof |
|
| |
| Field |
Type |
Description |
| contractCall |
ContractCallTransactionBody |
Contains the call a function of a contract instance |
| |
Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.
| Field |
Type |
Description |
| contractID |
ContractID |
the contract instance to call, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| gas |
int64 |
the maximum amount of gas to use for the call |
| amount |
int64 |
number of tinybars sent (the function must be payable if this is nonzero) |
| functionParameters |
bytes |
which function to call, and the parameters to pass to the function |
|
| contractCreateInstance |
ContractCreateTransactionBody |
Contains the create data a contract instance |
| |
Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.
| Field |
Type |
Description |
| fileID |
FileID |
the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| adminKey |
Key |
the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| gas |
int64 |
gas to run the constructor |
| initialBalance |
int64 |
initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
the instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| constructorParameters |
bytes |
parameters to pass to the constructor |
| shardID |
ShardID |
shard in which to create this |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
realm in which to create this (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
if realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| memo |
string |
the memo that was submitted as part of the contract (max 100 bytes) |
|
| contractUpdateInstance |
ContractUpdateTransactionBody |
Contains contract modify info such as expiration date for a contract instance |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to update (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| expirationTime |
Timestamp |
Extend the expiration of the instance and its account to this time (no effect if it already is this time or later) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| adminKey |
Key |
The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
The instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| fileID |
FileID |
The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| memo |
string |
The memo associated with the contract (max 100 bytes) |
|
| contractDeleteInstance |
ContractDeleteTransactionBody |
Delete contract and transfer remaining balance into specified account |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to delete (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| obtainers |
oneof |
|
| |
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transferContractID |
ContractID |
The contract ID which will receive all remaining hbars |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| cryptoAddClaim |
CryptoAddClaimTransactionBody |
Attach a new claim to an account |
| |
Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.
| Field |
Type |
Description |
| claim |
Claim |
A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it |
| |
A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet.
| Field |
Type |
Description |
| accountID |
AccountID |
the account to which the claim is attached |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hash |
bytes |
48 byte SHA-384 hash (presumably of some kind of credential or certificate) |
| keys |
KeyList |
list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys). |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| claimDuration |
Duration |
the duration for which the claim will remain valid |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
|
|
| cryptoCreateAccount |
CryptoCreateTransactionBody |
Create a new cryptocurrency account |
| |
Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency for each record generated, so the thresholds are useful for limiting Record generation to happen only for large transactions. The Key field is the key used to sign transactions for this account. If the account has receiverSigRequired set to true, then all cryptocurrency transfers must be signed by this account's key, both for transfers in and out. If it is false, then only transfers out have to be signed by it. When the account is created, the payer account is charged enough hbars so that the new account will not expire for the next autoRenewPeriod seconds. When it reaches the expiration time, the new account will then be automatically charged to renew for another autoRenewPeriod seconds. If it does not have enough hbars to renew for that long, then the remaining hbars are used to extend its expiration as long as possible. If it is has a zero balance when it expires, then it is deleted. This transaction must be signed by the payer account. If receiverSigRequired is false, then the transaction does not have to be signed by the keys in the keys field. If it is true, then it must be signed by them, in addition to the keys of the payer account.
| Field |
Type |
Description |
| key |
Key |
The key that must sign each transfer out of the account. If receiverSigRequired is true, then it must also sign any transfer into the account. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| initialBalance |
uint64 |
The initial number of tinybars to put into the account |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| sendRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| receiveRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction |
| receiverSigRequired |
bool |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
| autoRenewPeriod |
Duration |
The account is charged to extend its expiration date every this many seconds. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| shardID |
ShardID |
The shard in which this account is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The realm in which this account is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| cryptoDelete |
CryptoDeleteTransactionBody |
Delete a cryptocurrency account (mark as deleted, and transfer hbars out) |
| |
Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way.
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| deleteAccountID |
AccountID |
The account ID which should be deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| cryptoDeleteClaim |
CryptoDeleteClaimTransactionBody |
Remove a claim from an account |
| |
Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes.
| Field |
Type |
Description |
| accountIDToDeleteFrom |
AccountID |
The account ID that should have a claim deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hashToDelete |
bytes |
The hash in the claim to delete (a SHA-384 hash, 48 bytes) |
|
| cryptoTransfer |
CryptoTransferTransactionBody |
Transfer amount between accounts |
| |
Transfer cryptocurrency from some accounts to other accounts. The accounts list can contain up to 10 accounts. The amounts list must be the same length as the accounts list. Each negative amount is withdrawn from the corresponding account (a sender), and each positive one is added to the corresponding account (a receiver). The amounts list must sum to zero. Each amount is a number of tinyBars (there are 100,000,000 tinyBars in one Hbar). If any sender account fails to have sufficient hbars to do the withdrawal, then the entire transaction fails, and none of those transfers occur, though the transaction fee is still charged. This transaction must be signed by the keys for all the sending accounts, and for any receiving accounts that have receiverSigRequired == true. The signatures are in the same order as the accounts, skipping those accounts that don't need a signature.
| Field |
Type |
Description |
| transfers |
TransferList |
Accounts and amounts to transfer |
| |
A list of accounts and amounts to transfer out of each account (negative) or into it (positive).
| Field |
Type |
Description |
| accountAmounts |
AccountAmount (repeated) |
Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative) |
| |
An account, and the amount that it sends or receives during a cryptocurrency transfer.
| Field |
Type |
Description |
| accountID |
AccountID |
The Account ID that sends or receives cryptocurrency |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| amount |
sint64 |
The amount of tinybars that the account sends(negative) or receives(positive) |
|
|
|
| cryptoUpdateAccount |
CryptoUpdateTransactionBody |
Modify information such as the expiration date for an account |
| |
Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account.
| Field |
Type |
Description |
| accountIDToUpdate |
AccountID |
The account ID which is being updated in this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| key |
Key |
The new key |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| proxyFraction |
int32 |
[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account |
| sendRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| sendRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| sendRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
|
| receiveRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| receiveRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
| receiveRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
|
| autoRenewPeriod |
Duration |
The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| expirationTime |
Timestamp |
The new expiration time to extend to (ignored if equal to or before the current one) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| receiverSigRequiredField |
oneof |
|
| |
| Field |
Type |
Description |
| receiverSigRequired |
bool |
[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose. |
| receiverSigRequiredWrapper |
google.protobuf.BoolValue |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
|
|
| fileAppend |
FileAppendTransactionBody |
Add bytes to the end of the contents of a file |
| |
Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to which the bytes are appended to |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contents |
bytes |
The bytes to append to the contents of the file |
|
| fileCreate |
FileCreateTransactionBody |
Create a new file |
| |
Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.
| Field |
Type |
Description |
| expirationTime |
Timestamp |
The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
All these keys must sign to create or modify the file. Any one of them can sign to delete the file. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The bytes that are the contents of the file |
| shardID |
ShardID |
Shard in which this file is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The Realm in which to the file is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| fileDelete |
FileDeleteTransactionBody |
Delete a file (remove contents and mark as deleted until it expires) |
| |
Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys).
| Field |
Type |
Description |
| fileID |
FileID |
The file to delete. It will be marked as deleted until it expires. Then it will disappear. |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
|
| fileUpdate |
FileUpdateTransactionBody |
Modify information such as the expiration date for a file |
| |
Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to update |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| expirationTime |
Timestamp |
The new time at which it should expire (ignored if not later than the current value) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
The keys that can modify or delete the file |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The new file contents. All the bytes in the old contents are discarded. |
|
| systemDelete |
SystemDeleteTransactionBody |
Hedera multisig system deletes a file or smart contract |
| |
Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to delete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to delete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
| expirationTime |
TimestampSeconds |
The timestamp in seconds at which the "deleted" file should truly be permanently deleted |
| |
An exact date and time, with a resolution of one second (no nanoseconds).
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
|
|
| systemUndelete |
SystemUndeleteTransactionBody |
To undelete an entity deleted by SystemDelete |
| |
Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID to undelete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to undelete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| freeze |
FreezeTransactionBody |
Freeze the nodes |
| |
Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance.
| Field |
Type |
Description |
| startHour |
int32 |
The start hour (in UTC time), a value between 0 and 23 |
| startMin |
int32 |
The start minute (in UTC time), a value between 0 and 59 |
| endHour |
int32 |
The end hour (in UTC time), a value between 0 and 23 |
| endMin |
int32 |
The end minute (in UTC time), a value between 0 and 59 |
|
| consensusCreateTopic |
ConsensusCreateTopicTransactionBody |
|
| consensusUpdateTopic |
ConsensusUpdateTopicTransactionBody |
|
| consensusDeleteTopic |
ConsensusDeleteTopicTransactionBody |
|
| consensusSubmitMessage |
ConsensusSubmitMessageTransactionBody |
|
| |
| Field |
Type |
Description |
| topicID |
TopicID |
Topic to submit message to. |
| |
Unique identifier for a topic (used by the consensus service)
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| topicNum |
int64 |
Unique topic identifier within a realm (nonnegative). |
|
| message |
bytes |
Message to be submitted. Max size of the Transaction (including signatures) is 4kB. |
|
|
|
| bodyBytes |
bytes |
TransactionBody serialized into bytes , which needs to be signed |
|
| sigs |
SignatureList |
The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field |
| |
The signatures corresponding to a KeyList of the same length.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
Signature (repeated) |
each signature corresponds to a Key in the KeyList |
| |
A Signature corresponding to a Key. It is a sequence of bytes holding a public key signature from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be a list of signatures corresponding to a single threshold key. Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. If it has a smart contract ID associated with it, then that smart contract is allowed to transfer cryptocurrency out of it. The smart contract doesn't actually have a key, and doesn't actually sign a transaction. But it's as if a virtual transaction were created, and the smart contract signed it with a private key. A key can also be a "threshold key", which means a list of M keys, any N of which must sign in order for the threshold signature to be considered valid. The keys within a threshold signature may themselves be threshold signatures, to allow complex signature requirements (this nesting is not supported in the currently, but will be supported in a future version of API). If a Signature message is missing the "signature" field, then this is considered to be a null signature. That is useful in cases such as threshold signatures, where some of the signatures can be null.
| Field |
Type |
Description |
| deprecated |
option |
|
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature bytes |
| RSA_3072 |
bytes |
RSA-3072 signature bytes |
| ECDSA_384 |
bytes |
ECDSA p-384 signature bytes |
| thresholdSignature |
ThresholdSignature |
A list of signatures for a single N-of-M threshold Key. This must be a list of exactly M signatures, at least N of which are non-null. |
| |
A signature corresponding to a ThresholdKey. For an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
SignatureList |
for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null |
| |
Self Reference
|
|
| signatureList |
SignatureList |
A list of M signatures, each corresponding to a Key in a KeyList of the same length. |
| |
Self Reference
|
|
|
|
| sigMap |
SignatureMap |
The signatures on the body with the new format, to authorize the transaction |
| |
A set of signatures corresponding to every unique public key used to sign a given transaction.
| Field |
Type |
Description |
| sigPair |
SignaturePair (repeated) |
Each signature pair corresponds to a unique Key required to sign the transaction. |
| |
The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.
| Field |
Type |
Description |
| pubKeyPrefix |
bytes |
First few bytes of the public key |
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature |
| RSA_3072 |
bytes |
RSA-3072 signature |
| ECDSA_384 |
bytes |
ECDSA p-384 signature |
|
|
|
|
| responseType |
ResponseType |
The requested response, asking for cost, state proof, both, or neither |
| |
The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request.
| Enum Name |
Description |
| ANSWER_ONLY |
Response returns answer |
| ANSWER_STATE_PROOF |
Response returns both answer and state proof |
| COST_ANSWER |
Response returns the cost of answer |
| COST_ANSWER_STATE_PROOF |
Response returns the total cost of answer and state proof |
|
|
| contractID |
ContractID |
the contract instance to call, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| gas |
int64 |
the amount of gas to use for the call. All of the gas offered will be charged for. |
| functionParameters |
bytes |
which function to call, and the parameters to pass to the function |
| maxResultSize |
int64 |
max number of bytes that the result might include. The run will fail if it would have returned more than this number of bytes. |
|
| contractGetInfo |
ContractGetInfoQuery |
Get information about a smart contract instance |
| |
Get information about a smart contract instance. This includes the account that it uses, the file containing its bytecode, and the time when it will expire.
| Field |
Type |
Description |
| header |
QueryHeader |
standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). |
| |
Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for.
| Field |
Type |
Description |
| payment |
Transaction |
A signed CryptoTransferTransaction to pay the node a fee for handling this query |
| |
A single signed transaction, including all its signatures. The SignatureList will have a Signature for each Key in the transaction, either explicit or implicit, in the order that they appear in the transaction. For example, a CryptoTransfer will first have a Signature corresponding to the Key for the paying account, followed by a Signature corresponding to the Key for each account that is sending or receiving cryptocurrency in the transfer. Each Transaction should not have more than 50 levels.
| Field |
Type |
Description |
| bodyData |
oneof |
|
| |
| Field |
Type |
Description |
| body |
TransactionBody |
the body of the transaction, which needs to be signed |
| |
A single transaction. All transaction types are possible here.
| Field |
Type |
Description |
| transactionID |
TransactionID |
The ID for this transaction, which includes the payer's account (the account paying the transaction fee). If two transactions have the same transactionID, they won't both have an effect |
| |
The ID for a transaction. This is used for retrieving receipts and records for a transaction, for appending to a file right after creating it, for instantiating a smart contract with bytecode in a file just created, and internally by the network for detecting when duplicate transactions are submitted. A user might get a transaction processed faster by submitting it to N 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 will not take effect. So this could make the transaction take effect faster, if any given node might be slow. However, the full transaction fee is charged for each transaction, so the total fee is N times as much if the transaction is sent to N nodes.
| Field |
Type |
Description |
| transactionValidStart |
Timestamp |
The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| accountID |
AccountID |
The Account ID that paid for this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| nodeAccountID |
AccountID |
The account of the node that submits the client's transaction to the network |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transactionFee |
uint64 |
The maximum transaction fee the client is willing to pay, which is split between the network and the node |
| transactionValidDuration |
Duration |
The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| generateRecord |
bool |
Should a record of this transaction be generated? (A receipt is always generated, but the record is optional) |
| memo |
string |
Any notes or descriptions that should be put into the record (max length 100) |
| data |
oneof |
|
| |
| Field |
Type |
Description |
| contractCall |
ContractCallTransactionBody |
Contains the call a function of a contract instance |
| |
Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.
| Field |
Type |
Description |
| contractID |
ContractID |
the contract instance to call, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| gas |
int64 |
the maximum amount of gas to use for the call |
| amount |
int64 |
number of tinybars sent (the function must be payable if this is nonzero) |
| functionParameters |
bytes |
which function to call, and the parameters to pass to the function |
|
| contractCreateInstance |
ContractCreateTransactionBody |
Contains the create data a contract instance |
| |
Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.
| Field |
Type |
Description |
| fileID |
FileID |
the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| adminKey |
Key |
the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| gas |
int64 |
gas to run the constructor |
| initialBalance |
int64 |
initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
the instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| constructorParameters |
bytes |
parameters to pass to the constructor |
| shardID |
ShardID |
shard in which to create this |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
realm in which to create this (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
if realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| memo |
string |
the memo that was submitted as part of the contract (max 100 bytes) |
|
| contractUpdateInstance |
ContractUpdateTransactionBody |
Contains contract modify info such as expiration date for a contract instance |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to update (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| expirationTime |
Timestamp |
Extend the expiration of the instance and its account to this time (no effect if it already is this time or later) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| adminKey |
Key |
The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
The instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| fileID |
FileID |
The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| memo |
string |
The memo associated with the contract (max 100 bytes) |
|
| contractDeleteInstance |
ContractDeleteTransactionBody |
Delete contract and transfer remaining balance into specified account |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to delete (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| obtainers |
oneof |
|
| |
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transferContractID |
ContractID |
The contract ID which will receive all remaining hbars |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| cryptoAddClaim |
CryptoAddClaimTransactionBody |
Attach a new claim to an account |
| |
Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.
| Field |
Type |
Description |
| claim |
Claim |
A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it |
| |
A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet.
| Field |
Type |
Description |
| accountID |
AccountID |
the account to which the claim is attached |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hash |
bytes |
48 byte SHA-384 hash (presumably of some kind of credential or certificate) |
| keys |
KeyList |
list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys). |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| claimDuration |
Duration |
the duration for which the claim will remain valid |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
|
|
| cryptoCreateAccount |
CryptoCreateTransactionBody |
Create a new cryptocurrency account |
| |
Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency for each record generated, so the thresholds are useful for limiting Record generation to happen only for large transactions. The Key field is the key used to sign transactions for this account. If the account has receiverSigRequired set to true, then all cryptocurrency transfers must be signed by this account's key, both for transfers in and out. If it is false, then only transfers out have to be signed by it. When the account is created, the payer account is charged enough hbars so that the new account will not expire for the next autoRenewPeriod seconds. When it reaches the expiration time, the new account will then be automatically charged to renew for another autoRenewPeriod seconds. If it does not have enough hbars to renew for that long, then the remaining hbars are used to extend its expiration as long as possible. If it is has a zero balance when it expires, then it is deleted. This transaction must be signed by the payer account. If receiverSigRequired is false, then the transaction does not have to be signed by the keys in the keys field. If it is true, then it must be signed by them, in addition to the keys of the payer account.
| Field |
Type |
Description |
| key |
Key |
The key that must sign each transfer out of the account. If receiverSigRequired is true, then it must also sign any transfer into the account. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| initialBalance |
uint64 |
The initial number of tinybars to put into the account |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| sendRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| receiveRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction |
| receiverSigRequired |
bool |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
| autoRenewPeriod |
Duration |
The account is charged to extend its expiration date every this many seconds. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| shardID |
ShardID |
The shard in which this account is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The realm in which this account is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| cryptoDelete |
CryptoDeleteTransactionBody |
Delete a cryptocurrency account (mark as deleted, and transfer hbars out) |
| |
Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way.
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| deleteAccountID |
AccountID |
The account ID which should be deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| cryptoDeleteClaim |
CryptoDeleteClaimTransactionBody |
Remove a claim from an account |
| |
Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes.
| Field |
Type |
Description |
| accountIDToDeleteFrom |
AccountID |
The account ID that should have a claim deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hashToDelete |
bytes |
The hash in the claim to delete (a SHA-384 hash, 48 bytes) |
|
| cryptoTransfer |
CryptoTransferTransactionBody |
Transfer amount between accounts |
| |
Transfer cryptocurrency from some accounts to other accounts. The accounts list can contain up to 10 accounts. The amounts list must be the same length as the accounts list. Each negative amount is withdrawn from the corresponding account (a sender), and each positive one is added to the corresponding account (a receiver). The amounts list must sum to zero. Each amount is a number of tinyBars (there are 100,000,000 tinyBars in one Hbar). If any sender account fails to have sufficient hbars to do the withdrawal, then the entire transaction fails, and none of those transfers occur, though the transaction fee is still charged. This transaction must be signed by the keys for all the sending accounts, and for any receiving accounts that have receiverSigRequired == true. The signatures are in the same order as the accounts, skipping those accounts that don't need a signature.
| Field |
Type |
Description |
| transfers |
TransferList |
Accounts and amounts to transfer |
| |
A list of accounts and amounts to transfer out of each account (negative) or into it (positive).
| Field |
Type |
Description |
| accountAmounts |
AccountAmount (repeated) |
Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative) |
| |
An account, and the amount that it sends or receives during a cryptocurrency transfer.
| Field |
Type |
Description |
| accountID |
AccountID |
The Account ID that sends or receives cryptocurrency |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| amount |
sint64 |
The amount of tinybars that the account sends(negative) or receives(positive) |
|
|
|
| cryptoUpdateAccount |
CryptoUpdateTransactionBody |
Modify information such as the expiration date for an account |
| |
Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account.
| Field |
Type |
Description |
| accountIDToUpdate |
AccountID |
The account ID which is being updated in this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| key |
Key |
The new key |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| proxyFraction |
int32 |
[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account |
| sendRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| sendRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| sendRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
|
| receiveRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| receiveRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
| receiveRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
|
| autoRenewPeriod |
Duration |
The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| expirationTime |
Timestamp |
The new expiration time to extend to (ignored if equal to or before the current one) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| receiverSigRequiredField |
oneof |
|
| |
| Field |
Type |
Description |
| receiverSigRequired |
bool |
[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose. |
| receiverSigRequiredWrapper |
google.protobuf.BoolValue |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
|
|
| fileAppend |
FileAppendTransactionBody |
Add bytes to the end of the contents of a file |
| |
Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to which the bytes are appended to |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contents |
bytes |
The bytes to append to the contents of the file |
|
| fileCreate |
FileCreateTransactionBody |
Create a new file |
| |
Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.
| Field |
Type |
Description |
| expirationTime |
Timestamp |
The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
All these keys must sign to create or modify the file. Any one of them can sign to delete the file. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The bytes that are the contents of the file |
| shardID |
ShardID |
Shard in which this file is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The Realm in which to the file is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| fileDelete |
FileDeleteTransactionBody |
Delete a file (remove contents and mark as deleted until it expires) |
| |
Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys).
| Field |
Type |
Description |
| fileID |
FileID |
The file to delete. It will be marked as deleted until it expires. Then it will disappear. |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
|
| fileUpdate |
FileUpdateTransactionBody |
Modify information such as the expiration date for a file |
| |
Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to update |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| expirationTime |
Timestamp |
The new time at which it should expire (ignored if not later than the current value) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
The keys that can modify or delete the file |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The new file contents. All the bytes in the old contents are discarded. |
|
| systemDelete |
SystemDeleteTransactionBody |
Hedera multisig system deletes a file or smart contract |
| |
Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to delete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to delete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
| expirationTime |
TimestampSeconds |
The timestamp in seconds at which the "deleted" file should truly be permanently deleted |
| |
An exact date and time, with a resolution of one second (no nanoseconds).
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
|
|
| systemUndelete |
SystemUndeleteTransactionBody |
To undelete an entity deleted by SystemDelete |
| |
Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID to undelete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to undelete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| freeze |
FreezeTransactionBody |
Freeze the nodes |
| |
Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance.
| Field |
Type |
Description |
| startHour |
int32 |
The start hour (in UTC time), a value between 0 and 23 |
| startMin |
int32 |
The start minute (in UTC time), a value between 0 and 59 |
| endHour |
int32 |
The end hour (in UTC time), a value between 0 and 23 |
| endMin |
int32 |
The end minute (in UTC time), a value between 0 and 59 |
|
| consensusCreateTopic |
ConsensusCreateTopicTransactionBody |
|
| consensusUpdateTopic |
ConsensusUpdateTopicTransactionBody |
|
| consensusDeleteTopic |
ConsensusDeleteTopicTransactionBody |
|
| consensusSubmitMessage |
ConsensusSubmitMessageTransactionBody |
|
| |
| Field |
Type |
Description |
| topicID |
TopicID |
Topic to submit message to. |
| |
Unique identifier for a topic (used by the consensus service)
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| topicNum |
int64 |
Unique topic identifier within a realm (nonnegative). |
|
| message |
bytes |
Message to be submitted. Max size of the Transaction (including signatures) is 4kB. |
|
|
|
| bodyBytes |
bytes |
TransactionBody serialized into bytes , which needs to be signed |
|
| sigs |
SignatureList |
The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field |
| |
The signatures corresponding to a KeyList of the same length.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
Signature (repeated) |
each signature corresponds to a Key in the KeyList |
| |
A Signature corresponding to a Key. It is a sequence of bytes holding a public key signature from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be a list of signatures corresponding to a single threshold key. Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. If it has a smart contract ID associated with it, then that smart contract is allowed to transfer cryptocurrency out of it. The smart contract doesn't actually have a key, and doesn't actually sign a transaction. But it's as if a virtual transaction were created, and the smart contract signed it with a private key. A key can also be a "threshold key", which means a list of M keys, any N of which must sign in order for the threshold signature to be considered valid. The keys within a threshold signature may themselves be threshold signatures, to allow complex signature requirements (this nesting is not supported in the currently, but will be supported in a future version of API). If a Signature message is missing the "signature" field, then this is considered to be a null signature. That is useful in cases such as threshold signatures, where some of the signatures can be null.
| Field |
Type |
Description |
| deprecated |
option |
|
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature bytes |
| RSA_3072 |
bytes |
RSA-3072 signature bytes |
| ECDSA_384 |
bytes |
ECDSA p-384 signature bytes |
| thresholdSignature |
ThresholdSignature |
A list of signatures for a single N-of-M threshold Key. This must be a list of exactly M signatures, at least N of which are non-null. |
| |
A signature corresponding to a ThresholdKey. For an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
SignatureList |
for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null |
| |
Self Reference
|
|
| signatureList |
SignatureList |
A list of M signatures, each corresponding to a Key in a KeyList of the same length. |
| |
Self Reference
|
|
|
|
| sigMap |
SignatureMap |
The signatures on the body with the new format, to authorize the transaction |
| |
A set of signatures corresponding to every unique public key used to sign a given transaction.
| Field |
Type |
Description |
| sigPair |
SignaturePair (repeated) |
Each signature pair corresponds to a unique Key required to sign the transaction. |
| |
The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.
| Field |
Type |
Description |
| pubKeyPrefix |
bytes |
First few bytes of the public key |
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature |
| RSA_3072 |
bytes |
RSA-3072 signature |
| ECDSA_384 |
bytes |
ECDSA p-384 signature |
|
|
|
|
| responseType |
ResponseType |
The requested response, asking for cost, state proof, both, or neither |
| |
The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request.
| Enum Name |
Description |
| ANSWER_ONLY |
Response returns answer |
| ANSWER_STATE_PROOF |
Response returns both answer and state proof |
| COST_ANSWER |
Response returns the cost of answer |
| COST_ANSWER_STATE_PROOF |
Response returns the total cost of answer and state proof |
|
|
| contractID |
ContractID |
the contract for which information is requested |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
| contractGetBytecode |
ContractGetBytecodeQuery |
Get bytecode used by a smart contract instance |
| |
Get the bytecode for a smart contract instance
| Field |
Type |
Description |
| header |
QueryHeader |
standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). |
| |
Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for.
| Field |
Type |
Description |
| payment |
Transaction |
A signed CryptoTransferTransaction to pay the node a fee for handling this query |
| |
A single signed transaction, including all its signatures. The SignatureList will have a Signature for each Key in the transaction, either explicit or implicit, in the order that they appear in the transaction. For example, a CryptoTransfer will first have a Signature corresponding to the Key for the paying account, followed by a Signature corresponding to the Key for each account that is sending or receiving cryptocurrency in the transfer. Each Transaction should not have more than 50 levels.
| Field |
Type |
Description |
| bodyData |
oneof |
|
| |
| Field |
Type |
Description |
| body |
TransactionBody |
the body of the transaction, which needs to be signed |
| |
A single transaction. All transaction types are possible here.
| Field |
Type |
Description |
| transactionID |
TransactionID |
The ID for this transaction, which includes the payer's account (the account paying the transaction fee). If two transactions have the same transactionID, they won't both have an effect |
| |
The ID for a transaction. This is used for retrieving receipts and records for a transaction, for appending to a file right after creating it, for instantiating a smart contract with bytecode in a file just created, and internally by the network for detecting when duplicate transactions are submitted. A user might get a transaction processed faster by submitting it to N 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 will not take effect. So this could make the transaction take effect faster, if any given node might be slow. However, the full transaction fee is charged for each transaction, so the total fee is N times as much if the transaction is sent to N nodes.
| Field |
Type |
Description |
| transactionValidStart |
Timestamp |
The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| accountID |
AccountID |
The Account ID that paid for this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| nodeAccountID |
AccountID |
The account of the node that submits the client's transaction to the network |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transactionFee |
uint64 |
The maximum transaction fee the client is willing to pay, which is split between the network and the node |
| transactionValidDuration |
Duration |
The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| generateRecord |
bool |
Should a record of this transaction be generated? (A receipt is always generated, but the record is optional) |
| memo |
string |
Any notes or descriptions that should be put into the record (max length 100) |
| data |
oneof |
|
| |
| Field |
Type |
Description |
| contractCall |
ContractCallTransactionBody |
Contains the call a function of a contract instance |
| |
Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.
| Field |
Type |
Description |
| contractID |
ContractID |
the contract instance to call, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| gas |
int64 |
the maximum amount of gas to use for the call |
| amount |
int64 |
number of tinybars sent (the function must be payable if this is nonzero) |
| functionParameters |
bytes |
which function to call, and the parameters to pass to the function |
|
| contractCreateInstance |
ContractCreateTransactionBody |
Contains the create data a contract instance |
| |
Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.
| Field |
Type |
Description |
| fileID |
FileID |
the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| adminKey |
Key |
the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| gas |
int64 |
gas to run the constructor |
| initialBalance |
int64 |
initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
the instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| constructorParameters |
bytes |
parameters to pass to the constructor |
| shardID |
ShardID |
shard in which to create this |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
realm in which to create this (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
if realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| memo |
string |
the memo that was submitted as part of the contract (max 100 bytes) |
|
| contractUpdateInstance |
ContractUpdateTransactionBody |
Contains contract modify info such as expiration date for a contract instance |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to update (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| expirationTime |
Timestamp |
Extend the expiration of the instance and its account to this time (no effect if it already is this time or later) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| adminKey |
Key |
The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
The instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| fileID |
FileID |
The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| memo |
string |
The memo associated with the contract (max 100 bytes) |
|
| contractDeleteInstance |
ContractDeleteTransactionBody |
Delete contract and transfer remaining balance into specified account |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to delete (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| obtainers |
oneof |
|
| |
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transferContractID |
ContractID |
The contract ID which will receive all remaining hbars |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| cryptoAddClaim |
CryptoAddClaimTransactionBody |
Attach a new claim to an account |
| |
Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.
| Field |
Type |
Description |
| claim |
Claim |
A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it |
| |
A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet.
| Field |
Type |
Description |
| accountID |
AccountID |
the account to which the claim is attached |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hash |
bytes |
48 byte SHA-384 hash (presumably of some kind of credential or certificate) |
| keys |
KeyList |
list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys). |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| claimDuration |
Duration |
the duration for which the claim will remain valid |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
|
|
| cryptoCreateAccount |
CryptoCreateTransactionBody |
Create a new cryptocurrency account |
| |
Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency for each record generated, so the thresholds are useful for limiting Record generation to happen only for large transactions. The Key field is the key used to sign transactions for this account. If the account has receiverSigRequired set to true, then all cryptocurrency transfers must be signed by this account's key, both for transfers in and out. If it is false, then only transfers out have to be signed by it. When the account is created, the payer account is charged enough hbars so that the new account will not expire for the next autoRenewPeriod seconds. When it reaches the expiration time, the new account will then be automatically charged to renew for another autoRenewPeriod seconds. If it does not have enough hbars to renew for that long, then the remaining hbars are used to extend its expiration as long as possible. If it is has a zero balance when it expires, then it is deleted. This transaction must be signed by the payer account. If receiverSigRequired is false, then the transaction does not have to be signed by the keys in the keys field. If it is true, then it must be signed by them, in addition to the keys of the payer account.
| Field |
Type |
Description |
| key |
Key |
The key that must sign each transfer out of the account. If receiverSigRequired is true, then it must also sign any transfer into the account. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| initialBalance |
uint64 |
The initial number of tinybars to put into the account |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| sendRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| receiveRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction |
| receiverSigRequired |
bool |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
| autoRenewPeriod |
Duration |
The account is charged to extend its expiration date every this many seconds. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| shardID |
ShardID |
The shard in which this account is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The realm in which this account is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| cryptoDelete |
CryptoDeleteTransactionBody |
Delete a cryptocurrency account (mark as deleted, and transfer hbars out) |
| |
Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way.
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| deleteAccountID |
AccountID |
The account ID which should be deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| cryptoDeleteClaim |
CryptoDeleteClaimTransactionBody |
Remove a claim from an account |
| |
Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes.
| Field |
Type |
Description |
| accountIDToDeleteFrom |
AccountID |
The account ID that should have a claim deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hashToDelete |
bytes |
The hash in the claim to delete (a SHA-384 hash, 48 bytes) |
|
| cryptoTransfer |
CryptoTransferTransactionBody |
Transfer amount between accounts |
| |
Transfer cryptocurrency from some accounts to other accounts. The accounts list can contain up to 10 accounts. The amounts list must be the same length as the accounts list. Each negative amount is withdrawn from the corresponding account (a sender), and each positive one is added to the corresponding account (a receiver). The amounts list must sum to zero. Each amount is a number of tinyBars (there are 100,000,000 tinyBars in one Hbar). If any sender account fails to have sufficient hbars to do the withdrawal, then the entire transaction fails, and none of those transfers occur, though the transaction fee is still charged. This transaction must be signed by the keys for all the sending accounts, and for any receiving accounts that have receiverSigRequired == true. The signatures are in the same order as the accounts, skipping those accounts that don't need a signature.
| Field |
Type |
Description |
| transfers |
TransferList |
Accounts and amounts to transfer |
| |
A list of accounts and amounts to transfer out of each account (negative) or into it (positive).
| Field |
Type |
Description |
| accountAmounts |
AccountAmount (repeated) |
Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative) |
| |
An account, and the amount that it sends or receives during a cryptocurrency transfer.
| Field |
Type |
Description |
| accountID |
AccountID |
The Account ID that sends or receives cryptocurrency |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| amount |
sint64 |
The amount of tinybars that the account sends(negative) or receives(positive) |
|
|
|
| cryptoUpdateAccount |
CryptoUpdateTransactionBody |
Modify information such as the expiration date for an account |
| |
Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account.
| Field |
Type |
Description |
| accountIDToUpdate |
AccountID |
The account ID which is being updated in this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| key |
Key |
The new key |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| proxyFraction |
int32 |
[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account |
| sendRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| sendRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| sendRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
|
| receiveRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| receiveRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
| receiveRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
|
| autoRenewPeriod |
Duration |
The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| expirationTime |
Timestamp |
The new expiration time to extend to (ignored if equal to or before the current one) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| receiverSigRequiredField |
oneof |
|
| |
| Field |
Type |
Description |
| receiverSigRequired |
bool |
[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose. |
| receiverSigRequiredWrapper |
google.protobuf.BoolValue |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
|
|
| fileAppend |
FileAppendTransactionBody |
Add bytes to the end of the contents of a file |
| |
Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to which the bytes are appended to |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contents |
bytes |
The bytes to append to the contents of the file |
|
| fileCreate |
FileCreateTransactionBody |
Create a new file |
| |
Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.
| Field |
Type |
Description |
| expirationTime |
Timestamp |
The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
All these keys must sign to create or modify the file. Any one of them can sign to delete the file. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The bytes that are the contents of the file |
| shardID |
ShardID |
Shard in which this file is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The Realm in which to the file is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| fileDelete |
FileDeleteTransactionBody |
Delete a file (remove contents and mark as deleted until it expires) |
| |
Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys).
| Field |
Type |
Description |
| fileID |
FileID |
The file to delete. It will be marked as deleted until it expires. Then it will disappear. |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
|
| fileUpdate |
FileUpdateTransactionBody |
Modify information such as the expiration date for a file |
| |
Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to update |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| expirationTime |
Timestamp |
The new time at which it should expire (ignored if not later than the current value) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
The keys that can modify or delete the file |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The new file contents. All the bytes in the old contents are discarded. |
|
| systemDelete |
SystemDeleteTransactionBody |
Hedera multisig system deletes a file or smart contract |
| |
Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to delete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to delete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
| expirationTime |
TimestampSeconds |
The timestamp in seconds at which the "deleted" file should truly be permanently deleted |
| |
An exact date and time, with a resolution of one second (no nanoseconds).
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
|
|
| systemUndelete |
SystemUndeleteTransactionBody |
To undelete an entity deleted by SystemDelete |
| |
Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID to undelete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to undelete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| freeze |
FreezeTransactionBody |
Freeze the nodes |
| |
Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance.
| Field |
Type |
Description |
| startHour |
int32 |
The start hour (in UTC time), a value between 0 and 23 |
| startMin |
int32 |
The start minute (in UTC time), a value between 0 and 59 |
| endHour |
int32 |
The end hour (in UTC time), a value between 0 and 23 |
| endMin |
int32 |
The end minute (in UTC time), a value between 0 and 59 |
|
| consensusCreateTopic |
ConsensusCreateTopicTransactionBody |
|
| consensusUpdateTopic |
ConsensusUpdateTopicTransactionBody |
|
| consensusDeleteTopic |
ConsensusDeleteTopicTransactionBody |
|
| consensusSubmitMessage |
ConsensusSubmitMessageTransactionBody |
|
| |
| Field |
Type |
Description |
| topicID |
TopicID |
Topic to submit message to. |
| |
Unique identifier for a topic (used by the consensus service)
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| topicNum |
int64 |
Unique topic identifier within a realm (nonnegative). |
|
| message |
bytes |
Message to be submitted. Max size of the Transaction (including signatures) is 4kB. |
|
|
|
| bodyBytes |
bytes |
TransactionBody serialized into bytes , which needs to be signed |
|
| sigs |
SignatureList |
The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field |
| |
The signatures corresponding to a KeyList of the same length.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
Signature (repeated) |
each signature corresponds to a Key in the KeyList |
| |
A Signature corresponding to a Key. It is a sequence of bytes holding a public key signature from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be a list of signatures corresponding to a single threshold key. Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. If it has a smart contract ID associated with it, then that smart contract is allowed to transfer cryptocurrency out of it. The smart contract doesn't actually have a key, and doesn't actually sign a transaction. But it's as if a virtual transaction were created, and the smart contract signed it with a private key. A key can also be a "threshold key", which means a list of M keys, any N of which must sign in order for the threshold signature to be considered valid. The keys within a threshold signature may themselves be threshold signatures, to allow complex signature requirements (this nesting is not supported in the currently, but will be supported in a future version of API). If a Signature message is missing the "signature" field, then this is considered to be a null signature. That is useful in cases such as threshold signatures, where some of the signatures can be null.
| Field |
Type |
Description |
| deprecated |
option |
|
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature bytes |
| RSA_3072 |
bytes |
RSA-3072 signature bytes |
| ECDSA_384 |
bytes |
ECDSA p-384 signature bytes |
| thresholdSignature |
ThresholdSignature |
A list of signatures for a single N-of-M threshold Key. This must be a list of exactly M signatures, at least N of which are non-null. |
| |
A signature corresponding to a ThresholdKey. For an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
SignatureList |
for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null |
| |
Self Reference
|
|
| signatureList |
SignatureList |
A list of M signatures, each corresponding to a Key in a KeyList of the same length. |
| |
Self Reference
|
|
|
|
| sigMap |
SignatureMap |
The signatures on the body with the new format, to authorize the transaction |
| |
A set of signatures corresponding to every unique public key used to sign a given transaction.
| Field |
Type |
Description |
| sigPair |
SignaturePair (repeated) |
Each signature pair corresponds to a unique Key required to sign the transaction. |
| |
The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.
| Field |
Type |
Description |
| pubKeyPrefix |
bytes |
First few bytes of the public key |
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature |
| RSA_3072 |
bytes |
RSA-3072 signature |
| ECDSA_384 |
bytes |
ECDSA p-384 signature |
|
|
|
|
| responseType |
ResponseType |
The requested response, asking for cost, state proof, both, or neither |
| |
The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request.
| Enum Name |
Description |
| ANSWER_ONLY |
Response returns answer |
| ANSWER_STATE_PROOF |
Response returns both answer and state proof |
| COST_ANSWER |
Response returns the cost of answer |
| COST_ANSWER_STATE_PROOF |
Response returns the total cost of answer and state proof |
|
|
| contractID |
ContractID |
the contract for which information is requested |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
| ContractGetRecords |
ContractGetRecordsQuery |
Get Records of the contract instance |
| |
Get all the records for a smart contract instance, for any function call (or the constructor call) during the last 25 hours, for which a Record was requested.
| Field |
Type |
Description |
| header |
QueryHeader |
Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). |
| |
Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for.
| Field |
Type |
Description |
| payment |
Transaction |
A signed CryptoTransferTransaction to pay the node a fee for handling this query |
| |
A single signed transaction, including all its signatures. The SignatureList will have a Signature for each Key in the transaction, either explicit or implicit, in the order that they appear in the transaction. For example, a CryptoTransfer will first have a Signature corresponding to the Key for the paying account, followed by a Signature corresponding to the Key for each account that is sending or receiving cryptocurrency in the transfer. Each Transaction should not have more than 50 levels.
| Field |
Type |
Description |
| bodyData |
oneof |
|
| |
| Field |
Type |
Description |
| body |
TransactionBody |
the body of the transaction, which needs to be signed |
| |
A single transaction. All transaction types are possible here.
| Field |
Type |
Description |
| transactionID |
TransactionID |
The ID for this transaction, which includes the payer's account (the account paying the transaction fee). If two transactions have the same transactionID, they won't both have an effect |
| |
The ID for a transaction. This is used for retrieving receipts and records for a transaction, for appending to a file right after creating it, for instantiating a smart contract with bytecode in a file just created, and internally by the network for detecting when duplicate transactions are submitted. A user might get a transaction processed faster by submitting it to N 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 will not take effect. So this could make the transaction take effect faster, if any given node might be slow. However, the full transaction fee is charged for each transaction, so the total fee is N times as much if the transaction is sent to N nodes.
| Field |
Type |
Description |
| transactionValidStart |
Timestamp |
The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| accountID |
AccountID |
The Account ID that paid for this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| nodeAccountID |
AccountID |
The account of the node that submits the client's transaction to the network |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transactionFee |
uint64 |
The maximum transaction fee the client is willing to pay, which is split between the network and the node |
| transactionValidDuration |
Duration |
The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| generateRecord |
bool |
Should a record of this transaction be generated? (A receipt is always generated, but the record is optional) |
| memo |
string |
Any notes or descriptions that should be put into the record (max length 100) |
| data |
oneof |
|
| |
| Field |
Type |
Description |
| contractCall |
ContractCallTransactionBody |
Contains the call a function of a contract instance |
| |
Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.
| Field |
Type |
Description |
| contractID |
ContractID |
the contract instance to call, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| gas |
int64 |
the maximum amount of gas to use for the call |
| amount |
int64 |
number of tinybars sent (the function must be payable if this is nonzero) |
| functionParameters |
bytes |
which function to call, and the parameters to pass to the function |
|
| contractCreateInstance |
ContractCreateTransactionBody |
Contains the create data a contract instance |
| |
Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.
| Field |
Type |
Description |
| fileID |
FileID |
the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| adminKey |
Key |
the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| gas |
int64 |
gas to run the constructor |
| initialBalance |
int64 |
initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
the instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| constructorParameters |
bytes |
parameters to pass to the constructor |
| shardID |
ShardID |
shard in which to create this |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
realm in which to create this (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
if realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| memo |
string |
the memo that was submitted as part of the contract (max 100 bytes) |
|
| contractUpdateInstance |
ContractUpdateTransactionBody |
Contains contract modify info such as expiration date for a contract instance |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to update (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| expirationTime |
Timestamp |
Extend the expiration of the instance and its account to this time (no effect if it already is this time or later) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| adminKey |
Key |
The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
The instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| fileID |
FileID |
The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| memo |
string |
The memo associated with the contract (max 100 bytes) |
|
| contractDeleteInstance |
ContractDeleteTransactionBody |
Delete contract and transfer remaining balance into specified account |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to delete (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| obtainers |
oneof |
|
| |
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transferContractID |
ContractID |
The contract ID which will receive all remaining hbars |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| cryptoAddClaim |
CryptoAddClaimTransactionBody |
Attach a new claim to an account |
| |
Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.
| Field |
Type |
Description |
| claim |
Claim |
A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it |
| |
A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet.
| Field |
Type |
Description |
| accountID |
AccountID |
the account to which the claim is attached |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hash |
bytes |
48 byte SHA-384 hash (presumably of some kind of credential or certificate) |
| keys |
KeyList |
list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys). |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| claimDuration |
Duration |
the duration for which the claim will remain valid |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
|
|
| cryptoCreateAccount |
CryptoCreateTransactionBody |
Create a new cryptocurrency account |
| |
Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency for each record generated, so the thresholds are useful for limiting Record generation to happen only for large transactions. The Key field is the key used to sign transactions for this account. If the account has receiverSigRequired set to true, then all cryptocurrency transfers must be signed by this account's key, both for transfers in and out. If it is false, then only transfers out have to be signed by it. When the account is created, the payer account is charged enough hbars so that the new account will not expire for the next autoRenewPeriod seconds. When it reaches the expiration time, the new account will then be automatically charged to renew for another autoRenewPeriod seconds. If it does not have enough hbars to renew for that long, then the remaining hbars are used to extend its expiration as long as possible. If it is has a zero balance when it expires, then it is deleted. This transaction must be signed by the payer account. If receiverSigRequired is false, then the transaction does not have to be signed by the keys in the keys field. If it is true, then it must be signed by them, in addition to the keys of the payer account.
| Field |
Type |
Description |
| key |
Key |
The key that must sign each transfer out of the account. If receiverSigRequired is true, then it must also sign any transfer into the account. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| initialBalance |
uint64 |
The initial number of tinybars to put into the account |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| sendRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| receiveRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction |
| receiverSigRequired |
bool |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
| autoRenewPeriod |
Duration |
The account is charged to extend its expiration date every this many seconds. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| shardID |
ShardID |
The shard in which this account is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The realm in which this account is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| cryptoDelete |
CryptoDeleteTransactionBody |
Delete a cryptocurrency account (mark as deleted, and transfer hbars out) |
| |
Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way.
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| deleteAccountID |
AccountID |
The account ID which should be deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| cryptoDeleteClaim |
CryptoDeleteClaimTransactionBody |
Remove a claim from an account |
| |
Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes.
| Field |
Type |
Description |
| accountIDToDeleteFrom |
AccountID |
The account ID that should have a claim deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hashToDelete |
bytes |
The hash in the claim to delete (a SHA-384 hash, 48 bytes) |
|
| cryptoTransfer |
CryptoTransferTransactionBody |
Transfer amount between accounts |
| |
Transfer cryptocurrency from some accounts to other accounts. The accounts list can contain up to 10 accounts. The amounts list must be the same length as the accounts list. Each negative amount is withdrawn from the corresponding account (a sender), and each positive one is added to the corresponding account (a receiver). The amounts list must sum to zero. Each amount is a number of tinyBars (there are 100,000,000 tinyBars in one Hbar). If any sender account fails to have sufficient hbars to do the withdrawal, then the entire transaction fails, and none of those transfers occur, though the transaction fee is still charged. This transaction must be signed by the keys for all the sending accounts, and for any receiving accounts that have receiverSigRequired == true. The signatures are in the same order as the accounts, skipping those accounts that don't need a signature.
| Field |
Type |
Description |
| transfers |
TransferList |
Accounts and amounts to transfer |
| |
A list of accounts and amounts to transfer out of each account (negative) or into it (positive).
| Field |
Type |
Description |
| accountAmounts |
AccountAmount (repeated) |
Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative) |
| |
An account, and the amount that it sends or receives during a cryptocurrency transfer.
| Field |
Type |
Description |
| accountID |
AccountID |
The Account ID that sends or receives cryptocurrency |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| amount |
sint64 |
The amount of tinybars that the account sends(negative) or receives(positive) |
|
|
|
| cryptoUpdateAccount |
CryptoUpdateTransactionBody |
Modify information such as the expiration date for an account |
| |
Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account.
| Field |
Type |
Description |
| accountIDToUpdate |
AccountID |
The account ID which is being updated in this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| key |
Key |
The new key |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| proxyFraction |
int32 |
[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account |
| sendRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| sendRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| sendRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
|
| receiveRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| receiveRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
| receiveRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
|
| autoRenewPeriod |
Duration |
The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| expirationTime |
Timestamp |
The new expiration time to extend to (ignored if equal to or before the current one) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| receiverSigRequiredField |
oneof |
|
| |
| Field |
Type |
Description |
| receiverSigRequired |
bool |
[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose. |
| receiverSigRequiredWrapper |
google.protobuf.BoolValue |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
|
|
| fileAppend |
FileAppendTransactionBody |
Add bytes to the end of the contents of a file |
| |
Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to which the bytes are appended to |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contents |
bytes |
The bytes to append to the contents of the file |
|
| fileCreate |
FileCreateTransactionBody |
Create a new file |
| |
Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.
| Field |
Type |
Description |
| expirationTime |
Timestamp |
The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
All these keys must sign to create or modify the file. Any one of them can sign to delete the file. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The bytes that are the contents of the file |
| shardID |
ShardID |
Shard in which this file is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The Realm in which to the file is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| fileDelete |
FileDeleteTransactionBody |
Delete a file (remove contents and mark as deleted until it expires) |
| |
Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys).
| Field |
Type |
Description |
| fileID |
FileID |
The file to delete. It will be marked as deleted until it expires. Then it will disappear. |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
|
| fileUpdate |
FileUpdateTransactionBody |
Modify information such as the expiration date for a file |
| |
Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to update |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| expirationTime |
Timestamp |
The new time at which it should expire (ignored if not later than the current value) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
The keys that can modify or delete the file |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The new file contents. All the bytes in the old contents are discarded. |
|
| systemDelete |
SystemDeleteTransactionBody |
Hedera multisig system deletes a file or smart contract |
| |
Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to delete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to delete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
| expirationTime |
TimestampSeconds |
The timestamp in seconds at which the "deleted" file should truly be permanently deleted |
| |
An exact date and time, with a resolution of one second (no nanoseconds).
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
|
|
| systemUndelete |
SystemUndeleteTransactionBody |
To undelete an entity deleted by SystemDelete |
| |
Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID to undelete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to undelete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| freeze |
FreezeTransactionBody |
Freeze the nodes |
| |
Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance.
| Field |
Type |
Description |
| startHour |
int32 |
The start hour (in UTC time), a value between 0 and 23 |
| startMin |
int32 |
The start minute (in UTC time), a value between 0 and 59 |
| endHour |
int32 |
The end hour (in UTC time), a value between 0 and 23 |
| endMin |
int32 |
The end minute (in UTC time), a value between 0 and 59 |
|
| consensusCreateTopic |
ConsensusCreateTopicTransactionBody |
|
| consensusUpdateTopic |
ConsensusUpdateTopicTransactionBody |
|
| consensusDeleteTopic |
ConsensusDeleteTopicTransactionBody |
|
| consensusSubmitMessage |
ConsensusSubmitMessageTransactionBody |
|
| |
| Field |
Type |
Description |
| topicID |
TopicID |
Topic to submit message to. |
| |
Unique identifier for a topic (used by the consensus service)
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| topicNum |
int64 |
Unique topic identifier within a realm (nonnegative). |
|
| message |
bytes |
Message to be submitted. Max size of the Transaction (including signatures) is 4kB. |
|
|
|
| bodyBytes |
bytes |
TransactionBody serialized into bytes , which needs to be signed |
|
| sigs |
SignatureList |
The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field |
| |
The signatures corresponding to a KeyList of the same length.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
Signature (repeated) |
each signature corresponds to a Key in the KeyList |
| |
A Signature corresponding to a Key. It is a sequence of bytes holding a public key signature from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be a list of signatures corresponding to a single threshold key. Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. If it has a smart contract ID associated with it, then that smart contract is allowed to transfer cryptocurrency out of it. The smart contract doesn't actually have a key, and doesn't actually sign a transaction. But it's as if a virtual transaction were created, and the smart contract signed it with a private key. A key can also be a "threshold key", which means a list of M keys, any N of which must sign in order for the threshold signature to be considered valid. The keys within a threshold signature may themselves be threshold signatures, to allow complex signature requirements (this nesting is not supported in the currently, but will be supported in a future version of API). If a Signature message is missing the "signature" field, then this is considered to be a null signature. That is useful in cases such as threshold signatures, where some of the signatures can be null.
| Field |
Type |
Description |
| deprecated |
option |
|
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature bytes |
| RSA_3072 |
bytes |
RSA-3072 signature bytes |
| ECDSA_384 |
bytes |
ECDSA p-384 signature bytes |
| thresholdSignature |
ThresholdSignature |
A list of signatures for a single N-of-M threshold Key. This must be a list of exactly M signatures, at least N of which are non-null. |
| |
A signature corresponding to a ThresholdKey. For an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
SignatureList |
for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null |
| |
Self Reference
|
|
| signatureList |
SignatureList |
A list of M signatures, each corresponding to a Key in a KeyList of the same length. |
| |
Self Reference
|
|
|
|
| sigMap |
SignatureMap |
The signatures on the body with the new format, to authorize the transaction |
| |
A set of signatures corresponding to every unique public key used to sign a given transaction.
| Field |
Type |
Description |
| sigPair |
SignaturePair (repeated) |
Each signature pair corresponds to a unique Key required to sign the transaction. |
| |
The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.
| Field |
Type |
Description |
| pubKeyPrefix |
bytes |
First few bytes of the public key |
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature |
| RSA_3072 |
bytes |
RSA-3072 signature |
| ECDSA_384 |
bytes |
ECDSA p-384 signature |
|
|
|
|
| responseType |
ResponseType |
The requested response, asking for cost, state proof, both, or neither |
| |
The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request.
| Enum Name |
Description |
| ANSWER_ONLY |
Response returns answer |
| ANSWER_STATE_PROOF |
Response returns both answer and state proof |
| COST_ANSWER |
Response returns the cost of answer |
| COST_ANSWER_STATE_PROOF |
Response returns the total cost of answer and state proof |
|
|
| contractID |
ContractID |
The smart contract instance for which the records should be retrieved |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
| cryptogetAccountBalance |
CryptoGetAccountBalanceQuery |
Get the current balance in a cryptocurrency account |
| |
Get the balance of a cryptocurrency account. This returns only the balance, so it is a smaller and faster reply than CryptoGetInfo, which returns the balance plus additional information.
| Field |
Type |
Description |
| header |
QueryHeader |
Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). |
| |
Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for.
| Field |
Type |
Description |
| payment |
Transaction |
A signed CryptoTransferTransaction to pay the node a fee for handling this query |
| |
A single signed transaction, including all its signatures. The SignatureList will have a Signature for each Key in the transaction, either explicit or implicit, in the order that they appear in the transaction. For example, a CryptoTransfer will first have a Signature corresponding to the Key for the paying account, followed by a Signature corresponding to the Key for each account that is sending or receiving cryptocurrency in the transfer. Each Transaction should not have more than 50 levels.
| Field |
Type |
Description |
| bodyData |
oneof |
|
| |
| Field |
Type |
Description |
| body |
TransactionBody |
the body of the transaction, which needs to be signed |
| |
A single transaction. All transaction types are possible here.
| Field |
Type |
Description |
| transactionID |
TransactionID |
The ID for this transaction, which includes the payer's account (the account paying the transaction fee). If two transactions have the same transactionID, they won't both have an effect |
| |
The ID for a transaction. This is used for retrieving receipts and records for a transaction, for appending to a file right after creating it, for instantiating a smart contract with bytecode in a file just created, and internally by the network for detecting when duplicate transactions are submitted. A user might get a transaction processed faster by submitting it to N 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 will not take effect. So this could make the transaction take effect faster, if any given node might be slow. However, the full transaction fee is charged for each transaction, so the total fee is N times as much if the transaction is sent to N nodes.
| Field |
Type |
Description |
| transactionValidStart |
Timestamp |
The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| accountID |
AccountID |
The Account ID that paid for this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| nodeAccountID |
AccountID |
The account of the node that submits the client's transaction to the network |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transactionFee |
uint64 |
The maximum transaction fee the client is willing to pay, which is split between the network and the node |
| transactionValidDuration |
Duration |
The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| generateRecord |
bool |
Should a record of this transaction be generated? (A receipt is always generated, but the record is optional) |
| memo |
string |
Any notes or descriptions that should be put into the record (max length 100) |
| data |
oneof |
|
| |
| Field |
Type |
Description |
| contractCall |
ContractCallTransactionBody |
Contains the call a function of a contract instance |
| |
Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.
| Field |
Type |
Description |
| contractID |
ContractID |
the contract instance to call, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| gas |
int64 |
the maximum amount of gas to use for the call |
| amount |
int64 |
number of tinybars sent (the function must be payable if this is nonzero) |
| functionParameters |
bytes |
which function to call, and the parameters to pass to the function |
|
| contractCreateInstance |
ContractCreateTransactionBody |
Contains the create data a contract instance |
| |
Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.
| Field |
Type |
Description |
| fileID |
FileID |
the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| adminKey |
Key |
the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| gas |
int64 |
gas to run the constructor |
| initialBalance |
int64 |
initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
the instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| constructorParameters |
bytes |
parameters to pass to the constructor |
| shardID |
ShardID |
shard in which to create this |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
realm in which to create this (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
if realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| memo |
string |
the memo that was submitted as part of the contract (max 100 bytes) |
|
| contractUpdateInstance |
ContractUpdateTransactionBody |
Contains contract modify info such as expiration date for a contract instance |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to update (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| expirationTime |
Timestamp |
Extend the expiration of the instance and its account to this time (no effect if it already is this time or later) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| adminKey |
Key |
The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
The instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| fileID |
FileID |
The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| memo |
string |
The memo associated with the contract (max 100 bytes) |
|
| contractDeleteInstance |
ContractDeleteTransactionBody |
Delete contract and transfer remaining balance into specified account |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to delete (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| obtainers |
oneof |
|
| |
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transferContractID |
ContractID |
The contract ID which will receive all remaining hbars |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| cryptoAddClaim |
CryptoAddClaimTransactionBody |
Attach a new claim to an account |
| |
Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.
| Field |
Type |
Description |
| claim |
Claim |
A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it |
| |
A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet.
| Field |
Type |
Description |
| accountID |
AccountID |
the account to which the claim is attached |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hash |
bytes |
48 byte SHA-384 hash (presumably of some kind of credential or certificate) |
| keys |
KeyList |
list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys). |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| claimDuration |
Duration |
the duration for which the claim will remain valid |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
|
|
| cryptoCreateAccount |
CryptoCreateTransactionBody |
Create a new cryptocurrency account |
| |
Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency for each record generated, so the thresholds are useful for limiting Record generation to happen only for large transactions. The Key field is the key used to sign transactions for this account. If the account has receiverSigRequired set to true, then all cryptocurrency transfers must be signed by this account's key, both for transfers in and out. If it is false, then only transfers out have to be signed by it. When the account is created, the payer account is charged enough hbars so that the new account will not expire for the next autoRenewPeriod seconds. When it reaches the expiration time, the new account will then be automatically charged to renew for another autoRenewPeriod seconds. If it does not have enough hbars to renew for that long, then the remaining hbars are used to extend its expiration as long as possible. If it is has a zero balance when it expires, then it is deleted. This transaction must be signed by the payer account. If receiverSigRequired is false, then the transaction does not have to be signed by the keys in the keys field. If it is true, then it must be signed by them, in addition to the keys of the payer account.
| Field |
Type |
Description |
| key |
Key |
The key that must sign each transfer out of the account. If receiverSigRequired is true, then it must also sign any transfer into the account. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| initialBalance |
uint64 |
The initial number of tinybars to put into the account |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| sendRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| receiveRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction |
| receiverSigRequired |
bool |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
| autoRenewPeriod |
Duration |
The account is charged to extend its expiration date every this many seconds. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| shardID |
ShardID |
The shard in which this account is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The realm in which this account is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| cryptoDelete |
CryptoDeleteTransactionBody |
Delete a cryptocurrency account (mark as deleted, and transfer hbars out) |
| |
Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way.
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| deleteAccountID |
AccountID |
The account ID which should be deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| cryptoDeleteClaim |
CryptoDeleteClaimTransactionBody |
Remove a claim from an account |
| |
Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes.
| Field |
Type |
Description |
| accountIDToDeleteFrom |
AccountID |
The account ID that should have a claim deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hashToDelete |
bytes |
The hash in the claim to delete (a SHA-384 hash, 48 bytes) |
|
| cryptoTransfer |
CryptoTransferTransactionBody |
Transfer amount between accounts |
| |
Transfer cryptocurrency from some accounts to other accounts. The accounts list can contain up to 10 accounts. The amounts list must be the same length as the accounts list. Each negative amount is withdrawn from the corresponding account (a sender), and each positive one is added to the corresponding account (a receiver). The amounts list must sum to zero. Each amount is a number of tinyBars (there are 100,000,000 tinyBars in one Hbar). If any sender account fails to have sufficient hbars to do the withdrawal, then the entire transaction fails, and none of those transfers occur, though the transaction fee is still charged. This transaction must be signed by the keys for all the sending accounts, and for any receiving accounts that have receiverSigRequired == true. The signatures are in the same order as the accounts, skipping those accounts that don't need a signature.
| Field |
Type |
Description |
| transfers |
TransferList |
Accounts and amounts to transfer |
| |
A list of accounts and amounts to transfer out of each account (negative) or into it (positive).
| Field |
Type |
Description |
| accountAmounts |
AccountAmount (repeated) |
Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative) |
| |
An account, and the amount that it sends or receives during a cryptocurrency transfer.
| Field |
Type |
Description |
| accountID |
AccountID |
The Account ID that sends or receives cryptocurrency |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| amount |
sint64 |
The amount of tinybars that the account sends(negative) or receives(positive) |
|
|
|
| cryptoUpdateAccount |
CryptoUpdateTransactionBody |
Modify information such as the expiration date for an account |
| |
Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account.
| Field |
Type |
Description |
| accountIDToUpdate |
AccountID |
The account ID which is being updated in this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| key |
Key |
The new key |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| proxyFraction |
int32 |
[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account |
| sendRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| sendRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| sendRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
|
| receiveRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| receiveRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
| receiveRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
|
| autoRenewPeriod |
Duration |
The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| expirationTime |
Timestamp |
The new expiration time to extend to (ignored if equal to or before the current one) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| receiverSigRequiredField |
oneof |
|
| |
| Field |
Type |
Description |
| receiverSigRequired |
bool |
[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose. |
| receiverSigRequiredWrapper |
google.protobuf.BoolValue |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
|
|
| fileAppend |
FileAppendTransactionBody |
Add bytes to the end of the contents of a file |
| |
Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to which the bytes are appended to |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contents |
bytes |
The bytes to append to the contents of the file |
|
| fileCreate |
FileCreateTransactionBody |
Create a new file |
| |
Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.
| Field |
Type |
Description |
| expirationTime |
Timestamp |
The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
All these keys must sign to create or modify the file. Any one of them can sign to delete the file. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The bytes that are the contents of the file |
| shardID |
ShardID |
Shard in which this file is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The Realm in which to the file is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| fileDelete |
FileDeleteTransactionBody |
Delete a file (remove contents and mark as deleted until it expires) |
| |
Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys).
| Field |
Type |
Description |
| fileID |
FileID |
The file to delete. It will be marked as deleted until it expires. Then it will disappear. |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
|
| fileUpdate |
FileUpdateTransactionBody |
Modify information such as the expiration date for a file |
| |
Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to update |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| expirationTime |
Timestamp |
The new time at which it should expire (ignored if not later than the current value) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
The keys that can modify or delete the file |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The new file contents. All the bytes in the old contents are discarded. |
|
| systemDelete |
SystemDeleteTransactionBody |
Hedera multisig system deletes a file or smart contract |
| |
Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to delete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to delete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
| expirationTime |
TimestampSeconds |
The timestamp in seconds at which the "deleted" file should truly be permanently deleted |
| |
An exact date and time, with a resolution of one second (no nanoseconds).
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
|
|
| systemUndelete |
SystemUndeleteTransactionBody |
To undelete an entity deleted by SystemDelete |
| |
Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID to undelete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to undelete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| freeze |
FreezeTransactionBody |
Freeze the nodes |
| |
Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance.
| Field |
Type |
Description |
| startHour |
int32 |
The start hour (in UTC time), a value between 0 and 23 |
| startMin |
int32 |
The start minute (in UTC time), a value between 0 and 59 |
| endHour |
int32 |
The end hour (in UTC time), a value between 0 and 23 |
| endMin |
int32 |
The end minute (in UTC time), a value between 0 and 59 |
|
| consensusCreateTopic |
ConsensusCreateTopicTransactionBody |
|
| consensusUpdateTopic |
ConsensusUpdateTopicTransactionBody |
|
| consensusDeleteTopic |
ConsensusDeleteTopicTransactionBody |
|
| consensusSubmitMessage |
ConsensusSubmitMessageTransactionBody |
|
| |
| Field |
Type |
Description |
| topicID |
TopicID |
Topic to submit message to. |
| |
Unique identifier for a topic (used by the consensus service)
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| topicNum |
int64 |
Unique topic identifier within a realm (nonnegative). |
|
| message |
bytes |
Message to be submitted. Max size of the Transaction (including signatures) is 4kB. |
|
|
|
| bodyBytes |
bytes |
TransactionBody serialized into bytes , which needs to be signed |
|
| sigs |
SignatureList |
The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field |
| |
The signatures corresponding to a KeyList of the same length.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
Signature (repeated) |
each signature corresponds to a Key in the KeyList |
| |
A Signature corresponding to a Key. It is a sequence of bytes holding a public key signature from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be a list of signatures corresponding to a single threshold key. Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. If it has a smart contract ID associated with it, then that smart contract is allowed to transfer cryptocurrency out of it. The smart contract doesn't actually have a key, and doesn't actually sign a transaction. But it's as if a virtual transaction were created, and the smart contract signed it with a private key. A key can also be a "threshold key", which means a list of M keys, any N of which must sign in order for the threshold signature to be considered valid. The keys within a threshold signature may themselves be threshold signatures, to allow complex signature requirements (this nesting is not supported in the currently, but will be supported in a future version of API). If a Signature message is missing the "signature" field, then this is considered to be a null signature. That is useful in cases such as threshold signatures, where some of the signatures can be null.
| Field |
Type |
Description |
| deprecated |
option |
|
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature bytes |
| RSA_3072 |
bytes |
RSA-3072 signature bytes |
| ECDSA_384 |
bytes |
ECDSA p-384 signature bytes |
| thresholdSignature |
ThresholdSignature |
A list of signatures for a single N-of-M threshold Key. This must be a list of exactly M signatures, at least N of which are non-null. |
| |
A signature corresponding to a ThresholdKey. For an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
SignatureList |
for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null |
| |
Self Reference
|
|
| signatureList |
SignatureList |
A list of M signatures, each corresponding to a Key in a KeyList of the same length. |
| |
Self Reference
|
|
|
|
| sigMap |
SignatureMap |
The signatures on the body with the new format, to authorize the transaction |
| |
A set of signatures corresponding to every unique public key used to sign a given transaction.
| Field |
Type |
Description |
| sigPair |
SignaturePair (repeated) |
Each signature pair corresponds to a unique Key required to sign the transaction. |
| |
The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.
| Field |
Type |
Description |
| pubKeyPrefix |
bytes |
First few bytes of the public key |
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature |
| RSA_3072 |
bytes |
RSA-3072 signature |
| ECDSA_384 |
bytes |
ECDSA p-384 signature |
|
|
|
|
| responseType |
ResponseType |
The requested response, asking for cost, state proof, both, or neither |
| |
The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request.
| Enum Name |
Description |
| ANSWER_ONLY |
Response returns answer |
| ANSWER_STATE_PROOF |
Response returns both answer and state proof |
| COST_ANSWER |
Response returns the cost of answer |
| COST_ANSWER_STATE_PROOF |
Response returns the total cost of answer and state proof |
|
|
| balanceSource |
oneof |
|
| |
| Field |
Type |
Description |
| accountID |
AccountID |
The account ID for which information is requested |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| contractID |
ContractID |
The account ID for which information is requested |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| cryptoGetAccountRecords |
CryptoGetAccountRecordsQuery |
Get all the records that currently exist for transactions involving an account |
| |
Get all the records for an account for any transfers into it and out of it, that were above the threshold, during the last 25 hours.
| Field |
Type |
Description |
| header |
QueryHeader |
Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). |
| |
Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for.
| Field |
Type |
Description |
| payment |
Transaction |
A signed CryptoTransferTransaction to pay the node a fee for handling this query |
| |
A single signed transaction, including all its signatures. The SignatureList will have a Signature for each Key in the transaction, either explicit or implicit, in the order that they appear in the transaction. For example, a CryptoTransfer will first have a Signature corresponding to the Key for the paying account, followed by a Signature corresponding to the Key for each account that is sending or receiving cryptocurrency in the transfer. Each Transaction should not have more than 50 levels.
| Field |
Type |
Description |
| bodyData |
oneof |
|
| |
| Field |
Type |
Description |
| body |
TransactionBody |
the body of the transaction, which needs to be signed |
| |
A single transaction. All transaction types are possible here.
| Field |
Type |
Description |
| transactionID |
TransactionID |
The ID for this transaction, which includes the payer's account (the account paying the transaction fee). If two transactions have the same transactionID, they won't both have an effect |
| |
The ID for a transaction. This is used for retrieving receipts and records for a transaction, for appending to a file right after creating it, for instantiating a smart contract with bytecode in a file just created, and internally by the network for detecting when duplicate transactions are submitted. A user might get a transaction processed faster by submitting it to N 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 will not take effect. So this could make the transaction take effect faster, if any given node might be slow. However, the full transaction fee is charged for each transaction, so the total fee is N times as much if the transaction is sent to N nodes.
| Field |
Type |
Description |
| transactionValidStart |
Timestamp |
The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| accountID |
AccountID |
The Account ID that paid for this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| nodeAccountID |
AccountID |
The account of the node that submits the client's transaction to the network |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transactionFee |
uint64 |
The maximum transaction fee the client is willing to pay, which is split between the network and the node |
| transactionValidDuration |
Duration |
The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| generateRecord |
bool |
Should a record of this transaction be generated? (A receipt is always generated, but the record is optional) |
| memo |
string |
Any notes or descriptions that should be put into the record (max length 100) |
| data |
oneof |
|
| |
| Field |
Type |
Description |
| contractCall |
ContractCallTransactionBody |
Contains the call a function of a contract instance |
| |
Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.
| Field |
Type |
Description |
| contractID |
ContractID |
the contract instance to call, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| gas |
int64 |
the maximum amount of gas to use for the call |
| amount |
int64 |
number of tinybars sent (the function must be payable if this is nonzero) |
| functionParameters |
bytes |
which function to call, and the parameters to pass to the function |
|
| contractCreateInstance |
ContractCreateTransactionBody |
Contains the create data a contract instance |
| |
Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.
| Field |
Type |
Description |
| fileID |
FileID |
the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| adminKey |
Key |
the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| gas |
int64 |
gas to run the constructor |
| initialBalance |
int64 |
initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
the instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| constructorParameters |
bytes |
parameters to pass to the constructor |
| shardID |
ShardID |
shard in which to create this |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
realm in which to create this (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
if realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| memo |
string |
the memo that was submitted as part of the contract (max 100 bytes) |
|
| contractUpdateInstance |
ContractUpdateTransactionBody |
Contains contract modify info such as expiration date for a contract instance |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to update (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| expirationTime |
Timestamp |
Extend the expiration of the instance and its account to this time (no effect if it already is this time or later) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| adminKey |
Key |
The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
The instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| fileID |
FileID |
The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| memo |
string |
The memo associated with the contract (max 100 bytes) |
|
| contractDeleteInstance |
ContractDeleteTransactionBody |
Delete contract and transfer remaining balance into specified account |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to delete (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| obtainers |
oneof |
|
| |
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transferContractID |
ContractID |
The contract ID which will receive all remaining hbars |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| cryptoAddClaim |
CryptoAddClaimTransactionBody |
Attach a new claim to an account |
| |
Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.
| Field |
Type |
Description |
| claim |
Claim |
A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it |
| |
A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet.
| Field |
Type |
Description |
| accountID |
AccountID |
the account to which the claim is attached |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hash |
bytes |
48 byte SHA-384 hash (presumably of some kind of credential or certificate) |
| keys |
KeyList |
list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys). |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| claimDuration |
Duration |
the duration for which the claim will remain valid |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
|
|
| cryptoCreateAccount |
CryptoCreateTransactionBody |
Create a new cryptocurrency account |
| |
Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency for each record generated, so the thresholds are useful for limiting Record generation to happen only for large transactions. The Key field is the key used to sign transactions for this account. If the account has receiverSigRequired set to true, then all cryptocurrency transfers must be signed by this account's key, both for transfers in and out. If it is false, then only transfers out have to be signed by it. When the account is created, the payer account is charged enough hbars so that the new account will not expire for the next autoRenewPeriod seconds. When it reaches the expiration time, the new account will then be automatically charged to renew for another autoRenewPeriod seconds. If it does not have enough hbars to renew for that long, then the remaining hbars are used to extend its expiration as long as possible. If it is has a zero balance when it expires, then it is deleted. This transaction must be signed by the payer account. If receiverSigRequired is false, then the transaction does not have to be signed by the keys in the keys field. If it is true, then it must be signed by them, in addition to the keys of the payer account.
| Field |
Type |
Description |
| key |
Key |
The key that must sign each transfer out of the account. If receiverSigRequired is true, then it must also sign any transfer into the account. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| initialBalance |
uint64 |
The initial number of tinybars to put into the account |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| sendRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| receiveRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction |
| receiverSigRequired |
bool |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
| autoRenewPeriod |
Duration |
The account is charged to extend its expiration date every this many seconds. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| shardID |
ShardID |
The shard in which this account is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The realm in which this account is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| cryptoDelete |
CryptoDeleteTransactionBody |
Delete a cryptocurrency account (mark as deleted, and transfer hbars out) |
| |
Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way.
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| deleteAccountID |
AccountID |
The account ID which should be deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| cryptoDeleteClaim |
CryptoDeleteClaimTransactionBody |
Remove a claim from an account |
| |
Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes.
| Field |
Type |
Description |
| accountIDToDeleteFrom |
AccountID |
The account ID that should have a claim deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hashToDelete |
bytes |
The hash in the claim to delete (a SHA-384 hash, 48 bytes) |
|
| cryptoTransfer |
CryptoTransferTransactionBody |
Transfer amount between accounts |
| |
Transfer cryptocurrency from some accounts to other accounts. The accounts list can contain up to 10 accounts. The amounts list must be the same length as the accounts list. Each negative amount is withdrawn from the corresponding account (a sender), and each positive one is added to the corresponding account (a receiver). The amounts list must sum to zero. Each amount is a number of tinyBars (there are 100,000,000 tinyBars in one Hbar). If any sender account fails to have sufficient hbars to do the withdrawal, then the entire transaction fails, and none of those transfers occur, though the transaction fee is still charged. This transaction must be signed by the keys for all the sending accounts, and for any receiving accounts that have receiverSigRequired == true. The signatures are in the same order as the accounts, skipping those accounts that don't need a signature.
| Field |
Type |
Description |
| transfers |
TransferList |
Accounts and amounts to transfer |
| |
A list of accounts and amounts to transfer out of each account (negative) or into it (positive).
| Field |
Type |
Description |
| accountAmounts |
AccountAmount (repeated) |
Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative) |
| |
An account, and the amount that it sends or receives during a cryptocurrency transfer.
| Field |
Type |
Description |
| accountID |
AccountID |
The Account ID that sends or receives cryptocurrency |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| amount |
sint64 |
The amount of tinybars that the account sends(negative) or receives(positive) |
|
|
|
| cryptoUpdateAccount |
CryptoUpdateTransactionBody |
Modify information such as the expiration date for an account |
| |
Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account.
| Field |
Type |
Description |
| accountIDToUpdate |
AccountID |
The account ID which is being updated in this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| key |
Key |
The new key |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| proxyFraction |
int32 |
[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account |
| sendRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| sendRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| sendRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
|
| receiveRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| receiveRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
| receiveRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
|
| autoRenewPeriod |
Duration |
The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| expirationTime |
Timestamp |
The new expiration time to extend to (ignored if equal to or before the current one) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| receiverSigRequiredField |
oneof |
|
| |
| Field |
Type |
Description |
| receiverSigRequired |
bool |
[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose. |
| receiverSigRequiredWrapper |
google.protobuf.BoolValue |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
|
|
| fileAppend |
FileAppendTransactionBody |
Add bytes to the end of the contents of a file |
| |
Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to which the bytes are appended to |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contents |
bytes |
The bytes to append to the contents of the file |
|
| fileCreate |
FileCreateTransactionBody |
Create a new file |
| |
Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.
| Field |
Type |
Description |
| expirationTime |
Timestamp |
The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
All these keys must sign to create or modify the file. Any one of them can sign to delete the file. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The bytes that are the contents of the file |
| shardID |
ShardID |
Shard in which this file is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The Realm in which to the file is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| fileDelete |
FileDeleteTransactionBody |
Delete a file (remove contents and mark as deleted until it expires) |
| |
Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys).
| Field |
Type |
Description |
| fileID |
FileID |
The file to delete. It will be marked as deleted until it expires. Then it will disappear. |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
|
| fileUpdate |
FileUpdateTransactionBody |
Modify information such as the expiration date for a file |
| |
Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to update |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| expirationTime |
Timestamp |
The new time at which it should expire (ignored if not later than the current value) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
The keys that can modify or delete the file |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The new file contents. All the bytes in the old contents are discarded. |
|
| systemDelete |
SystemDeleteTransactionBody |
Hedera multisig system deletes a file or smart contract |
| |
Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to delete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to delete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
| expirationTime |
TimestampSeconds |
The timestamp in seconds at which the "deleted" file should truly be permanently deleted |
| |
An exact date and time, with a resolution of one second (no nanoseconds).
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
|
|
| systemUndelete |
SystemUndeleteTransactionBody |
To undelete an entity deleted by SystemDelete |
| |
Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID to undelete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to undelete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| freeze |
FreezeTransactionBody |
Freeze the nodes |
| |
Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance.
| Field |
Type |
Description |
| startHour |
int32 |
The start hour (in UTC time), a value between 0 and 23 |
| startMin |
int32 |
The start minute (in UTC time), a value between 0 and 59 |
| endHour |
int32 |
The end hour (in UTC time), a value between 0 and 23 |
| endMin |
int32 |
The end minute (in UTC time), a value between 0 and 59 |
|
| consensusCreateTopic |
ConsensusCreateTopicTransactionBody |
|
| consensusUpdateTopic |
ConsensusUpdateTopicTransactionBody |
|
| consensusDeleteTopic |
ConsensusDeleteTopicTransactionBody |
|
| consensusSubmitMessage |
ConsensusSubmitMessageTransactionBody |
|
| |
| Field |
Type |
Description |
| topicID |
TopicID |
Topic to submit message to. |
| |
Unique identifier for a topic (used by the consensus service)
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| topicNum |
int64 |
Unique topic identifier within a realm (nonnegative). |
|
| message |
bytes |
Message to be submitted. Max size of the Transaction (including signatures) is 4kB. |
|
|
|
| bodyBytes |
bytes |
TransactionBody serialized into bytes , which needs to be signed |
|
| sigs |
SignatureList |
The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field |
| |
The signatures corresponding to a KeyList of the same length.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
Signature (repeated) |
each signature corresponds to a Key in the KeyList |
| |
A Signature corresponding to a Key. It is a sequence of bytes holding a public key signature from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be a list of signatures corresponding to a single threshold key. Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. If it has a smart contract ID associated with it, then that smart contract is allowed to transfer cryptocurrency out of it. The smart contract doesn't actually have a key, and doesn't actually sign a transaction. But it's as if a virtual transaction were created, and the smart contract signed it with a private key. A key can also be a "threshold key", which means a list of M keys, any N of which must sign in order for the threshold signature to be considered valid. The keys within a threshold signature may themselves be threshold signatures, to allow complex signature requirements (this nesting is not supported in the currently, but will be supported in a future version of API). If a Signature message is missing the "signature" field, then this is considered to be a null signature. That is useful in cases such as threshold signatures, where some of the signatures can be null.
| Field |
Type |
Description |
| deprecated |
option |
|
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature bytes |
| RSA_3072 |
bytes |
RSA-3072 signature bytes |
| ECDSA_384 |
bytes |
ECDSA p-384 signature bytes |
| thresholdSignature |
ThresholdSignature |
A list of signatures for a single N-of-M threshold Key. This must be a list of exactly M signatures, at least N of which are non-null. |
| |
A signature corresponding to a ThresholdKey. For an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
SignatureList |
for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null |
| |
Self Reference
|
|
| signatureList |
SignatureList |
A list of M signatures, each corresponding to a Key in a KeyList of the same length. |
| |
Self Reference
|
|
|
|
| sigMap |
SignatureMap |
The signatures on the body with the new format, to authorize the transaction |
| |
A set of signatures corresponding to every unique public key used to sign a given transaction.
| Field |
Type |
Description |
| sigPair |
SignaturePair (repeated) |
Each signature pair corresponds to a unique Key required to sign the transaction. |
| |
The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.
| Field |
Type |
Description |
| pubKeyPrefix |
bytes |
First few bytes of the public key |
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature |
| RSA_3072 |
bytes |
RSA-3072 signature |
| ECDSA_384 |
bytes |
ECDSA p-384 signature |
|
|
|
|
| responseType |
ResponseType |
The requested response, asking for cost, state proof, both, or neither |
| |
The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request.
| Enum Name |
Description |
| ANSWER_ONLY |
Response returns answer |
| ANSWER_STATE_PROOF |
Response returns both answer and state proof |
| COST_ANSWER |
Response returns the cost of answer |
| COST_ANSWER_STATE_PROOF |
Response returns the total cost of answer and state proof |
|
|
| accountID |
AccountID |
The account ID for which the records should be retrieved |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| cryptoGetInfo |
CryptoGetInfoQuery |
Get all information about an account |
| |
Get all the information about an account, including the balance. This does not get the list of account records.
| Field |
Type |
Description |
| header |
QueryHeader |
Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). |
| |
Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for.
| Field |
Type |
Description |
| payment |
Transaction |
A signed CryptoTransferTransaction to pay the node a fee for handling this query |
| |
A single signed transaction, including all its signatures. The SignatureList will have a Signature for each Key in the transaction, either explicit or implicit, in the order that they appear in the transaction. For example, a CryptoTransfer will first have a Signature corresponding to the Key for the paying account, followed by a Signature corresponding to the Key for each account that is sending or receiving cryptocurrency in the transfer. Each Transaction should not have more than 50 levels.
| Field |
Type |
Description |
| bodyData |
oneof |
|
| |
| Field |
Type |
Description |
| body |
TransactionBody |
the body of the transaction, which needs to be signed |
| |
A single transaction. All transaction types are possible here.
| Field |
Type |
Description |
| transactionID |
TransactionID |
The ID for this transaction, which includes the payer's account (the account paying the transaction fee). If two transactions have the same transactionID, they won't both have an effect |
| |
The ID for a transaction. This is used for retrieving receipts and records for a transaction, for appending to a file right after creating it, for instantiating a smart contract with bytecode in a file just created, and internally by the network for detecting when duplicate transactions are submitted. A user might get a transaction processed faster by submitting it to N 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 will not take effect. So this could make the transaction take effect faster, if any given node might be slow. However, the full transaction fee is charged for each transaction, so the total fee is N times as much if the transaction is sent to N nodes.
| Field |
Type |
Description |
| transactionValidStart |
Timestamp |
The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| accountID |
AccountID |
The Account ID that paid for this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| nodeAccountID |
AccountID |
The account of the node that submits the client's transaction to the network |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transactionFee |
uint64 |
The maximum transaction fee the client is willing to pay, which is split between the network and the node |
| transactionValidDuration |
Duration |
The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| generateRecord |
bool |
Should a record of this transaction be generated? (A receipt is always generated, but the record is optional) |
| memo |
string |
Any notes or descriptions that should be put into the record (max length 100) |
| data |
oneof |
|
| |
| Field |
Type |
Description |
| contractCall |
ContractCallTransactionBody |
Contains the call a function of a contract instance |
| |
Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.
| Field |
Type |
Description |
| contractID |
ContractID |
the contract instance to call, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| gas |
int64 |
the maximum amount of gas to use for the call |
| amount |
int64 |
number of tinybars sent (the function must be payable if this is nonzero) |
| functionParameters |
bytes |
which function to call, and the parameters to pass to the function |
|
| contractCreateInstance |
ContractCreateTransactionBody |
Contains the create data a contract instance |
| |
Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.
| Field |
Type |
Description |
| fileID |
FileID |
the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| adminKey |
Key |
the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| gas |
int64 |
gas to run the constructor |
| initialBalance |
int64 |
initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
the instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| constructorParameters |
bytes |
parameters to pass to the constructor |
| shardID |
ShardID |
shard in which to create this |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
realm in which to create this (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
if realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| memo |
string |
the memo that was submitted as part of the contract (max 100 bytes) |
|
| contractUpdateInstance |
ContractUpdateTransactionBody |
Contains contract modify info such as expiration date for a contract instance |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to update (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| expirationTime |
Timestamp |
Extend the expiration of the instance and its account to this time (no effect if it already is this time or later) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| adminKey |
Key |
The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
The instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| fileID |
FileID |
The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| memo |
string |
The memo associated with the contract (max 100 bytes) |
|
| contractDeleteInstance |
ContractDeleteTransactionBody |
Delete contract and transfer remaining balance into specified account |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to delete (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| obtainers |
oneof |
|
| |
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transferContractID |
ContractID |
The contract ID which will receive all remaining hbars |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| cryptoAddClaim |
CryptoAddClaimTransactionBody |
Attach a new claim to an account |
| |
Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.
| Field |
Type |
Description |
| claim |
Claim |
A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it |
| |
A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet.
| Field |
Type |
Description |
| accountID |
AccountID |
the account to which the claim is attached |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hash |
bytes |
48 byte SHA-384 hash (presumably of some kind of credential or certificate) |
| keys |
KeyList |
list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys). |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| claimDuration |
Duration |
the duration for which the claim will remain valid |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
|
|
| cryptoCreateAccount |
CryptoCreateTransactionBody |
Create a new cryptocurrency account |
| |
Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency for each record generated, so the thresholds are useful for limiting Record generation to happen only for large transactions. The Key field is the key used to sign transactions for this account. If the account has receiverSigRequired set to true, then all cryptocurrency transfers must be signed by this account's key, both for transfers in and out. If it is false, then only transfers out have to be signed by it. When the account is created, the payer account is charged enough hbars so that the new account will not expire for the next autoRenewPeriod seconds. When it reaches the expiration time, the new account will then be automatically charged to renew for another autoRenewPeriod seconds. If it does not have enough hbars to renew for that long, then the remaining hbars are used to extend its expiration as long as possible. If it is has a zero balance when it expires, then it is deleted. This transaction must be signed by the payer account. If receiverSigRequired is false, then the transaction does not have to be signed by the keys in the keys field. If it is true, then it must be signed by them, in addition to the keys of the payer account.
| Field |
Type |
Description |
| key |
Key |
The key that must sign each transfer out of the account. If receiverSigRequired is true, then it must also sign any transfer into the account. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| initialBalance |
uint64 |
The initial number of tinybars to put into the account |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| sendRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| receiveRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction |
| receiverSigRequired |
bool |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
| autoRenewPeriod |
Duration |
The account is charged to extend its expiration date every this many seconds. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| shardID |
ShardID |
The shard in which this account is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The realm in which this account is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| cryptoDelete |
CryptoDeleteTransactionBody |
Delete a cryptocurrency account (mark as deleted, and transfer hbars out) |
| |
Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way.
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| deleteAccountID |
AccountID |
The account ID which should be deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| cryptoDeleteClaim |
CryptoDeleteClaimTransactionBody |
Remove a claim from an account |
| |
Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes.
| Field |
Type |
Description |
| accountIDToDeleteFrom |
AccountID |
The account ID that should have a claim deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hashToDelete |
bytes |
The hash in the claim to delete (a SHA-384 hash, 48 bytes) |
|
| cryptoTransfer |
CryptoTransferTransactionBody |
Transfer amount between accounts |
| |
Transfer cryptocurrency from some accounts to other accounts. The accounts list can contain up to 10 accounts. The amounts list must be the same length as the accounts list. Each negative amount is withdrawn from the corresponding account (a sender), and each positive one is added to the corresponding account (a receiver). The amounts list must sum to zero. Each amount is a number of tinyBars (there are 100,000,000 tinyBars in one Hbar). If any sender account fails to have sufficient hbars to do the withdrawal, then the entire transaction fails, and none of those transfers occur, though the transaction fee is still charged. This transaction must be signed by the keys for all the sending accounts, and for any receiving accounts that have receiverSigRequired == true. The signatures are in the same order as the accounts, skipping those accounts that don't need a signature.
| Field |
Type |
Description |
| transfers |
TransferList |
Accounts and amounts to transfer |
| |
A list of accounts and amounts to transfer out of each account (negative) or into it (positive).
| Field |
Type |
Description |
| accountAmounts |
AccountAmount (repeated) |
Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative) |
| |
An account, and the amount that it sends or receives during a cryptocurrency transfer.
| Field |
Type |
Description |
| accountID |
AccountID |
The Account ID that sends or receives cryptocurrency |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| amount |
sint64 |
The amount of tinybars that the account sends(negative) or receives(positive) |
|
|
|
| cryptoUpdateAccount |
CryptoUpdateTransactionBody |
Modify information such as the expiration date for an account |
| |
Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account.
| Field |
Type |
Description |
| accountIDToUpdate |
AccountID |
The account ID which is being updated in this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| key |
Key |
The new key |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| proxyFraction |
int32 |
[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account |
| sendRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| sendRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| sendRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
|
| receiveRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| receiveRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
| receiveRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
|
| autoRenewPeriod |
Duration |
The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| expirationTime |
Timestamp |
The new expiration time to extend to (ignored if equal to or before the current one) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| receiverSigRequiredField |
oneof |
|
| |
| Field |
Type |
Description |
| receiverSigRequired |
bool |
[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose. |
| receiverSigRequiredWrapper |
google.protobuf.BoolValue |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
|
|
| fileAppend |
FileAppendTransactionBody |
Add bytes to the end of the contents of a file |
| |
Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to which the bytes are appended to |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contents |
bytes |
The bytes to append to the contents of the file |
|
| fileCreate |
FileCreateTransactionBody |
Create a new file |
| |
Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.
| Field |
Type |
Description |
| expirationTime |
Timestamp |
The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
All these keys must sign to create or modify the file. Any one of them can sign to delete the file. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The bytes that are the contents of the file |
| shardID |
ShardID |
Shard in which this file is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The Realm in which to the file is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| fileDelete |
FileDeleteTransactionBody |
Delete a file (remove contents and mark as deleted until it expires) |
| |
Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys).
| Field |
Type |
Description |
| fileID |
FileID |
The file to delete. It will be marked as deleted until it expires. Then it will disappear. |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
|
| fileUpdate |
FileUpdateTransactionBody |
Modify information such as the expiration date for a file |
| |
Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to update |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| expirationTime |
Timestamp |
The new time at which it should expire (ignored if not later than the current value) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
The keys that can modify or delete the file |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The new file contents. All the bytes in the old contents are discarded. |
|
| systemDelete |
SystemDeleteTransactionBody |
Hedera multisig system deletes a file or smart contract |
| |
Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to delete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to delete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
| expirationTime |
TimestampSeconds |
The timestamp in seconds at which the "deleted" file should truly be permanently deleted |
| |
An exact date and time, with a resolution of one second (no nanoseconds).
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
|
|
| systemUndelete |
SystemUndeleteTransactionBody |
To undelete an entity deleted by SystemDelete |
| |
Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID to undelete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to undelete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| freeze |
FreezeTransactionBody |
Freeze the nodes |
| |
Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance.
| Field |
Type |
Description |
| startHour |
int32 |
The start hour (in UTC time), a value between 0 and 23 |
| startMin |
int32 |
The start minute (in UTC time), a value between 0 and 59 |
| endHour |
int32 |
The end hour (in UTC time), a value between 0 and 23 |
| endMin |
int32 |
The end minute (in UTC time), a value between 0 and 59 |
|
| consensusCreateTopic |
ConsensusCreateTopicTransactionBody |
|
| consensusUpdateTopic |
ConsensusUpdateTopicTransactionBody |
|
| consensusDeleteTopic |
ConsensusDeleteTopicTransactionBody |
|
| consensusSubmitMessage |
ConsensusSubmitMessageTransactionBody |
|
| |
| Field |
Type |
Description |
| topicID |
TopicID |
Topic to submit message to. |
| |
Unique identifier for a topic (used by the consensus service)
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| topicNum |
int64 |
Unique topic identifier within a realm (nonnegative). |
|
| message |
bytes |
Message to be submitted. Max size of the Transaction (including signatures) is 4kB. |
|
|
|
| bodyBytes |
bytes |
TransactionBody serialized into bytes , which needs to be signed |
|
| sigs |
SignatureList |
The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field |
| |
The signatures corresponding to a KeyList of the same length.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
Signature (repeated) |
each signature corresponds to a Key in the KeyList |
| |
A Signature corresponding to a Key. It is a sequence of bytes holding a public key signature from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be a list of signatures corresponding to a single threshold key. Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. If it has a smart contract ID associated with it, then that smart contract is allowed to transfer cryptocurrency out of it. The smart contract doesn't actually have a key, and doesn't actually sign a transaction. But it's as if a virtual transaction were created, and the smart contract signed it with a private key. A key can also be a "threshold key", which means a list of M keys, any N of which must sign in order for the threshold signature to be considered valid. The keys within a threshold signature may themselves be threshold signatures, to allow complex signature requirements (this nesting is not supported in the currently, but will be supported in a future version of API). If a Signature message is missing the "signature" field, then this is considered to be a null signature. That is useful in cases such as threshold signatures, where some of the signatures can be null.
| Field |
Type |
Description |
| deprecated |
option |
|
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature bytes |
| RSA_3072 |
bytes |
RSA-3072 signature bytes |
| ECDSA_384 |
bytes |
ECDSA p-384 signature bytes |
| thresholdSignature |
ThresholdSignature |
A list of signatures for a single N-of-M threshold Key. This must be a list of exactly M signatures, at least N of which are non-null. |
| |
A signature corresponding to a ThresholdKey. For an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
SignatureList |
for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null |
| |
Self Reference
|
|
| signatureList |
SignatureList |
A list of M signatures, each corresponding to a Key in a KeyList of the same length. |
| |
Self Reference
|
|
|
|
| sigMap |
SignatureMap |
The signatures on the body with the new format, to authorize the transaction |
| |
A set of signatures corresponding to every unique public key used to sign a given transaction.
| Field |
Type |
Description |
| sigPair |
SignaturePair (repeated) |
Each signature pair corresponds to a unique Key required to sign the transaction. |
| |
The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.
| Field |
Type |
Description |
| pubKeyPrefix |
bytes |
First few bytes of the public key |
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature |
| RSA_3072 |
bytes |
RSA-3072 signature |
| ECDSA_384 |
bytes |
ECDSA p-384 signature |
|
|
|
|
| responseType |
ResponseType |
The requested response, asking for cost, state proof, both, or neither |
| |
The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request.
| Enum Name |
Description |
| ANSWER_ONLY |
Response returns answer |
| ANSWER_STATE_PROOF |
Response returns both answer and state proof |
| COST_ANSWER |
Response returns the cost of answer |
| COST_ANSWER_STATE_PROOF |
Response returns the total cost of answer and state proof |
|
|
| accountID |
AccountID |
The account ID for which information is requested |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| cryptoGetClaim |
CryptoGetClaimQuery |
Get a single claim from a single account (or null if it doesn't exist) |
| |
Get a single claim attached to an account, or return null if it does not exist.
| Field |
Type |
Description |
| header |
QueryHeader |
Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). |
| |
Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for.
| Field |
Type |
Description |
| payment |
Transaction |
A signed CryptoTransferTransaction to pay the node a fee for handling this query |
| |
A single signed transaction, including all its signatures. The SignatureList will have a Signature for each Key in the transaction, either explicit or implicit, in the order that they appear in the transaction. For example, a CryptoTransfer will first have a Signature corresponding to the Key for the paying account, followed by a Signature corresponding to the Key for each account that is sending or receiving cryptocurrency in the transfer. Each Transaction should not have more than 50 levels.
| Field |
Type |
Description |
| bodyData |
oneof |
|
| |
| Field |
Type |
Description |
| body |
TransactionBody |
the body of the transaction, which needs to be signed |
| |
A single transaction. All transaction types are possible here.
| Field |
Type |
Description |
| transactionID |
TransactionID |
The ID for this transaction, which includes the payer's account (the account paying the transaction fee). If two transactions have the same transactionID, they won't both have an effect |
| |
The ID for a transaction. This is used for retrieving receipts and records for a transaction, for appending to a file right after creating it, for instantiating a smart contract with bytecode in a file just created, and internally by the network for detecting when duplicate transactions are submitted. A user might get a transaction processed faster by submitting it to N 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 will not take effect. So this could make the transaction take effect faster, if any given node might be slow. However, the full transaction fee is charged for each transaction, so the total fee is N times as much if the transaction is sent to N nodes.
| Field |
Type |
Description |
| transactionValidStart |
Timestamp |
The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| accountID |
AccountID |
The Account ID that paid for this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| nodeAccountID |
AccountID |
The account of the node that submits the client's transaction to the network |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transactionFee |
uint64 |
The maximum transaction fee the client is willing to pay, which is split between the network and the node |
| transactionValidDuration |
Duration |
The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| generateRecord |
bool |
Should a record of this transaction be generated? (A receipt is always generated, but the record is optional) |
| memo |
string |
Any notes or descriptions that should be put into the record (max length 100) |
| data |
oneof |
|
| |
| Field |
Type |
Description |
| contractCall |
ContractCallTransactionBody |
Contains the call a function of a contract instance |
| |
Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.
| Field |
Type |
Description |
| contractID |
ContractID |
the contract instance to call, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| gas |
int64 |
the maximum amount of gas to use for the call |
| amount |
int64 |
number of tinybars sent (the function must be payable if this is nonzero) |
| functionParameters |
bytes |
which function to call, and the parameters to pass to the function |
|
| contractCreateInstance |
ContractCreateTransactionBody |
Contains the create data a contract instance |
| |
Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.
| Field |
Type |
Description |
| fileID |
FileID |
the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| adminKey |
Key |
the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| gas |
int64 |
gas to run the constructor |
| initialBalance |
int64 |
initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
the instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| constructorParameters |
bytes |
parameters to pass to the constructor |
| shardID |
ShardID |
shard in which to create this |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
realm in which to create this (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
if realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| memo |
string |
the memo that was submitted as part of the contract (max 100 bytes) |
|
| contractUpdateInstance |
ContractUpdateTransactionBody |
Contains contract modify info such as expiration date for a contract instance |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to update (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| expirationTime |
Timestamp |
Extend the expiration of the instance and its account to this time (no effect if it already is this time or later) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| adminKey |
Key |
The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
The instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| fileID |
FileID |
The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| memo |
string |
The memo associated with the contract (max 100 bytes) |
|
| contractDeleteInstance |
ContractDeleteTransactionBody |
Delete contract and transfer remaining balance into specified account |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to delete (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| obtainers |
oneof |
|
| |
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transferContractID |
ContractID |
The contract ID which will receive all remaining hbars |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| cryptoAddClaim |
CryptoAddClaimTransactionBody |
Attach a new claim to an account |
| |
Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.
| Field |
Type |
Description |
| claim |
Claim |
A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it |
| |
A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet.
| Field |
Type |
Description |
| accountID |
AccountID |
the account to which the claim is attached |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hash |
bytes |
48 byte SHA-384 hash (presumably of some kind of credential or certificate) |
| keys |
KeyList |
list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys). |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| claimDuration |
Duration |
the duration for which the claim will remain valid |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
|
|
| cryptoCreateAccount |
CryptoCreateTransactionBody |
Create a new cryptocurrency account |
| |
Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency for each record generated, so the thresholds are useful for limiting Record generation to happen only for large transactions. The Key field is the key used to sign transactions for this account. If the account has receiverSigRequired set to true, then all cryptocurrency transfers must be signed by this account's key, both for transfers in and out. If it is false, then only transfers out have to be signed by it. When the account is created, the payer account is charged enough hbars so that the new account will not expire for the next autoRenewPeriod seconds. When it reaches the expiration time, the new account will then be automatically charged to renew for another autoRenewPeriod seconds. If it does not have enough hbars to renew for that long, then the remaining hbars are used to extend its expiration as long as possible. If it is has a zero balance when it expires, then it is deleted. This transaction must be signed by the payer account. If receiverSigRequired is false, then the transaction does not have to be signed by the keys in the keys field. If it is true, then it must be signed by them, in addition to the keys of the payer account.
| Field |
Type |
Description |
| key |
Key |
The key that must sign each transfer out of the account. If receiverSigRequired is true, then it must also sign any transfer into the account. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| initialBalance |
uint64 |
The initial number of tinybars to put into the account |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| sendRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| receiveRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction |
| receiverSigRequired |
bool |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
| autoRenewPeriod |
Duration |
The account is charged to extend its expiration date every this many seconds. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| shardID |
ShardID |
The shard in which this account is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The realm in which this account is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| cryptoDelete |
CryptoDeleteTransactionBody |
Delete a cryptocurrency account (mark as deleted, and transfer hbars out) |
| |
Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way.
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| deleteAccountID |
AccountID |
The account ID which should be deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| cryptoDeleteClaim |
CryptoDeleteClaimTransactionBody |
Remove a claim from an account |
| |
Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes.
| Field |
Type |
Description |
| accountIDToDeleteFrom |
AccountID |
The account ID that should have a claim deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hashToDelete |
bytes |
The hash in the claim to delete (a SHA-384 hash, 48 bytes) |
|
| cryptoTransfer |
CryptoTransferTransactionBody |
Transfer amount between accounts |
| |
Transfer cryptocurrency from some accounts to other accounts. The accounts list can contain up to 10 accounts. The amounts list must be the same length as the accounts list. Each negative amount is withdrawn from the corresponding account (a sender), and each positive one is added to the corresponding account (a receiver). The amounts list must sum to zero. Each amount is a number of tinyBars (there are 100,000,000 tinyBars in one Hbar). If any sender account fails to have sufficient hbars to do the withdrawal, then the entire transaction fails, and none of those transfers occur, though the transaction fee is still charged. This transaction must be signed by the keys for all the sending accounts, and for any receiving accounts that have receiverSigRequired == true. The signatures are in the same order as the accounts, skipping those accounts that don't need a signature.
| Field |
Type |
Description |
| transfers |
TransferList |
Accounts and amounts to transfer |
| |
A list of accounts and amounts to transfer out of each account (negative) or into it (positive).
| Field |
Type |
Description |
| accountAmounts |
AccountAmount (repeated) |
Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative) |
| |
An account, and the amount that it sends or receives during a cryptocurrency transfer.
| Field |
Type |
Description |
| accountID |
AccountID |
The Account ID that sends or receives cryptocurrency |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| amount |
sint64 |
The amount of tinybars that the account sends(negative) or receives(positive) |
|
|
|
| cryptoUpdateAccount |
CryptoUpdateTransactionBody |
Modify information such as the expiration date for an account |
| |
Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account.
| Field |
Type |
Description |
| accountIDToUpdate |
AccountID |
The account ID which is being updated in this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| key |
Key |
The new key |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| proxyFraction |
int32 |
[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account |
| sendRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| sendRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| sendRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
|
| receiveRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| receiveRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
| receiveRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
|
| autoRenewPeriod |
Duration |
The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| expirationTime |
Timestamp |
The new expiration time to extend to (ignored if equal to or before the current one) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| receiverSigRequiredField |
oneof |
|
| |
| Field |
Type |
Description |
| receiverSigRequired |
bool |
[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose. |
| receiverSigRequiredWrapper |
google.protobuf.BoolValue |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
|
|
| fileAppend |
FileAppendTransactionBody |
Add bytes to the end of the contents of a file |
| |
Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to which the bytes are appended to |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contents |
bytes |
The bytes to append to the contents of the file |
|
| fileCreate |
FileCreateTransactionBody |
Create a new file |
| |
Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.
| Field |
Type |
Description |
| expirationTime |
Timestamp |
The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
All these keys must sign to create or modify the file. Any one of them can sign to delete the file. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The bytes that are the contents of the file |
| shardID |
ShardID |
Shard in which this file is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The Realm in which to the file is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| fileDelete |
FileDeleteTransactionBody |
Delete a file (remove contents and mark as deleted until it expires) |
| |
Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys).
| Field |
Type |
Description |
| fileID |
FileID |
The file to delete. It will be marked as deleted until it expires. Then it will disappear. |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
|
| fileUpdate |
FileUpdateTransactionBody |
Modify information such as the expiration date for a file |
| |
Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to update |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| expirationTime |
Timestamp |
The new time at which it should expire (ignored if not later than the current value) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
The keys that can modify or delete the file |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The new file contents. All the bytes in the old contents are discarded. |
|
| systemDelete |
SystemDeleteTransactionBody |
Hedera multisig system deletes a file or smart contract |
| |
Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to delete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to delete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
| expirationTime |
TimestampSeconds |
The timestamp in seconds at which the "deleted" file should truly be permanently deleted |
| |
An exact date and time, with a resolution of one second (no nanoseconds).
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
|
|
| systemUndelete |
SystemUndeleteTransactionBody |
To undelete an entity deleted by SystemDelete |
| |
Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID to undelete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to undelete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| freeze |
FreezeTransactionBody |
Freeze the nodes |
| |
Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance.
| Field |
Type |
Description |
| startHour |
int32 |
The start hour (in UTC time), a value between 0 and 23 |
| startMin |
int32 |
The start minute (in UTC time), a value between 0 and 59 |
| endHour |
int32 |
The end hour (in UTC time), a value between 0 and 23 |
| endMin |
int32 |
The end minute (in UTC time), a value between 0 and 59 |
|
| consensusCreateTopic |
ConsensusCreateTopicTransactionBody |
|
| consensusUpdateTopic |
ConsensusUpdateTopicTransactionBody |
|
| consensusDeleteTopic |
ConsensusDeleteTopicTransactionBody |
|
| consensusSubmitMessage |
ConsensusSubmitMessageTransactionBody |
|
| |
| Field |
Type |
Description |
| topicID |
TopicID |
Topic to submit message to. |
| |
Unique identifier for a topic (used by the consensus service)
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| topicNum |
int64 |
Unique topic identifier within a realm (nonnegative). |
|
| message |
bytes |
Message to be submitted. Max size of the Transaction (including signatures) is 4kB. |
|
|
|
| bodyBytes |
bytes |
TransactionBody serialized into bytes , which needs to be signed |
|
| sigs |
SignatureList |
The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field |
| |
The signatures corresponding to a KeyList of the same length.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
Signature (repeated) |
each signature corresponds to a Key in the KeyList |
| |
A Signature corresponding to a Key. It is a sequence of bytes holding a public key signature from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be a list of signatures corresponding to a single threshold key. Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. If it has a smart contract ID associated with it, then that smart contract is allowed to transfer cryptocurrency out of it. The smart contract doesn't actually have a key, and doesn't actually sign a transaction. But it's as if a virtual transaction were created, and the smart contract signed it with a private key. A key can also be a "threshold key", which means a list of M keys, any N of which must sign in order for the threshold signature to be considered valid. The keys within a threshold signature may themselves be threshold signatures, to allow complex signature requirements (this nesting is not supported in the currently, but will be supported in a future version of API). If a Signature message is missing the "signature" field, then this is considered to be a null signature. That is useful in cases such as threshold signatures, where some of the signatures can be null.
| Field |
Type |
Description |
| deprecated |
option |
|
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature bytes |
| RSA_3072 |
bytes |
RSA-3072 signature bytes |
| ECDSA_384 |
bytes |
ECDSA p-384 signature bytes |
| thresholdSignature |
ThresholdSignature |
A list of signatures for a single N-of-M threshold Key. This must be a list of exactly M signatures, at least N of which are non-null. |
| |
A signature corresponding to a ThresholdKey. For an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
SignatureList |
for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null |
| |
Self Reference
|
|
| signatureList |
SignatureList |
A list of M signatures, each corresponding to a Key in a KeyList of the same length. |
| |
Self Reference
|
|
|
|
| sigMap |
SignatureMap |
The signatures on the body with the new format, to authorize the transaction |
| |
A set of signatures corresponding to every unique public key used to sign a given transaction.
| Field |
Type |
Description |
| sigPair |
SignaturePair (repeated) |
Each signature pair corresponds to a unique Key required to sign the transaction. |
| |
The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.
| Field |
Type |
Description |
| pubKeyPrefix |
bytes |
First few bytes of the public key |
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature |
| RSA_3072 |
bytes |
RSA-3072 signature |
| ECDSA_384 |
bytes |
ECDSA p-384 signature |
|
|
|
|
| responseType |
ResponseType |
The requested response, asking for cost, state proof, both, or neither |
| |
The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request.
| Enum Name |
Description |
| ANSWER_ONLY |
Response returns answer |
| ANSWER_STATE_PROOF |
Response returns both answer and state proof |
| COST_ANSWER |
Response returns the cost of answer |
| COST_ANSWER_STATE_PROOF |
Response returns the total cost of answer and state proof |
|
|
| accountID |
AccountID |
The account ID to which the claim was attached |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hash |
bytes |
The hash of the claim |
|
| cryptoGetProxyStakers |
CryptoGetStakersQuery |
Get all the accounts that proxy stake to a given account, and how much they proxy stake (not yet implemented in the current API) |
| |
Get all the accounts that are proxy staking to this account. For each of them, give the amount currently staked. This is not yet implemented, but will be in a future version of the API.
| Field |
Type |
Description |
| header |
QueryHeader |
Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). |
| |
Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for.
| Field |
Type |
Description |
| payment |
Transaction |
A signed CryptoTransferTransaction to pay the node a fee for handling this query |
| |
A single signed transaction, including all its signatures. The SignatureList will have a Signature for each Key in the transaction, either explicit or implicit, in the order that they appear in the transaction. For example, a CryptoTransfer will first have a Signature corresponding to the Key for the paying account, followed by a Signature corresponding to the Key for each account that is sending or receiving cryptocurrency in the transfer. Each Transaction should not have more than 50 levels.
| Field |
Type |
Description |
| bodyData |
oneof |
|
| |
| Field |
Type |
Description |
| body |
TransactionBody |
the body of the transaction, which needs to be signed |
| |
A single transaction. All transaction types are possible here.
| Field |
Type |
Description |
| transactionID |
TransactionID |
The ID for this transaction, which includes the payer's account (the account paying the transaction fee). If two transactions have the same transactionID, they won't both have an effect |
| |
The ID for a transaction. This is used for retrieving receipts and records for a transaction, for appending to a file right after creating it, for instantiating a smart contract with bytecode in a file just created, and internally by the network for detecting when duplicate transactions are submitted. A user might get a transaction processed faster by submitting it to N 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 will not take effect. So this could make the transaction take effect faster, if any given node might be slow. However, the full transaction fee is charged for each transaction, so the total fee is N times as much if the transaction is sent to N nodes.
| Field |
Type |
Description |
| transactionValidStart |
Timestamp |
The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| accountID |
AccountID |
The Account ID that paid for this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| nodeAccountID |
AccountID |
The account of the node that submits the client's transaction to the network |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transactionFee |
uint64 |
The maximum transaction fee the client is willing to pay, which is split between the network and the node |
| transactionValidDuration |
Duration |
The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| generateRecord |
bool |
Should a record of this transaction be generated? (A receipt is always generated, but the record is optional) |
| memo |
string |
Any notes or descriptions that should be put into the record (max length 100) |
| data |
oneof |
|
| |
| Field |
Type |
Description |
| contractCall |
ContractCallTransactionBody |
Contains the call a function of a contract instance |
| |
Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.
| Field |
Type |
Description |
| contractID |
ContractID |
the contract instance to call, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| gas |
int64 |
the maximum amount of gas to use for the call |
| amount |
int64 |
number of tinybars sent (the function must be payable if this is nonzero) |
| functionParameters |
bytes |
which function to call, and the parameters to pass to the function |
|
| contractCreateInstance |
ContractCreateTransactionBody |
Contains the create data a contract instance |
| |
Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.
| Field |
Type |
Description |
| fileID |
FileID |
the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| adminKey |
Key |
the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| gas |
int64 |
gas to run the constructor |
| initialBalance |
int64 |
initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
the instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| constructorParameters |
bytes |
parameters to pass to the constructor |
| shardID |
ShardID |
shard in which to create this |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
realm in which to create this (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
if realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| memo |
string |
the memo that was submitted as part of the contract (max 100 bytes) |
|
| contractUpdateInstance |
ContractUpdateTransactionBody |
Contains contract modify info such as expiration date for a contract instance |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to update (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| expirationTime |
Timestamp |
Extend the expiration of the instance and its account to this time (no effect if it already is this time or later) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| adminKey |
Key |
The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
The instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| fileID |
FileID |
The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| memo |
string |
The memo associated with the contract (max 100 bytes) |
|
| contractDeleteInstance |
ContractDeleteTransactionBody |
Delete contract and transfer remaining balance into specified account |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to delete (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| obtainers |
oneof |
|
| |
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transferContractID |
ContractID |
The contract ID which will receive all remaining hbars |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| cryptoAddClaim |
CryptoAddClaimTransactionBody |
Attach a new claim to an account |
| |
Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.
| Field |
Type |
Description |
| claim |
Claim |
A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it |
| |
A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet.
| Field |
Type |
Description |
| accountID |
AccountID |
the account to which the claim is attached |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hash |
bytes |
48 byte SHA-384 hash (presumably of some kind of credential or certificate) |
| keys |
KeyList |
list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys). |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| claimDuration |
Duration |
the duration for which the claim will remain valid |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
|
|
| cryptoCreateAccount |
CryptoCreateTransactionBody |
Create a new cryptocurrency account |
| |
Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency for each record generated, so the thresholds are useful for limiting Record generation to happen only for large transactions. The Key field is the key used to sign transactions for this account. If the account has receiverSigRequired set to true, then all cryptocurrency transfers must be signed by this account's key, both for transfers in and out. If it is false, then only transfers out have to be signed by it. When the account is created, the payer account is charged enough hbars so that the new account will not expire for the next autoRenewPeriod seconds. When it reaches the expiration time, the new account will then be automatically charged to renew for another autoRenewPeriod seconds. If it does not have enough hbars to renew for that long, then the remaining hbars are used to extend its expiration as long as possible. If it is has a zero balance when it expires, then it is deleted. This transaction must be signed by the payer account. If receiverSigRequired is false, then the transaction does not have to be signed by the keys in the keys field. If it is true, then it must be signed by them, in addition to the keys of the payer account.
| Field |
Type |
Description |
| key |
Key |
The key that must sign each transfer out of the account. If receiverSigRequired is true, then it must also sign any transfer into the account. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| initialBalance |
uint64 |
The initial number of tinybars to put into the account |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| sendRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| receiveRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction |
| receiverSigRequired |
bool |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
| autoRenewPeriod |
Duration |
The account is charged to extend its expiration date every this many seconds. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| shardID |
ShardID |
The shard in which this account is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The realm in which this account is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| cryptoDelete |
CryptoDeleteTransactionBody |
Delete a cryptocurrency account (mark as deleted, and transfer hbars out) |
| |
Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way.
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| deleteAccountID |
AccountID |
The account ID which should be deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| cryptoDeleteClaim |
CryptoDeleteClaimTransactionBody |
Remove a claim from an account |
| |
Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes.
| Field |
Type |
Description |
| accountIDToDeleteFrom |
AccountID |
The account ID that should have a claim deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hashToDelete |
bytes |
The hash in the claim to delete (a SHA-384 hash, 48 bytes) |
|
| cryptoTransfer |
CryptoTransferTransactionBody |
Transfer amount between accounts |
| |
Transfer cryptocurrency from some accounts to other accounts. The accounts list can contain up to 10 accounts. The amounts list must be the same length as the accounts list. Each negative amount is withdrawn from the corresponding account (a sender), and each positive one is added to the corresponding account (a receiver). The amounts list must sum to zero. Each amount is a number of tinyBars (there are 100,000,000 tinyBars in one Hbar). If any sender account fails to have sufficient hbars to do the withdrawal, then the entire transaction fails, and none of those transfers occur, though the transaction fee is still charged. This transaction must be signed by the keys for all the sending accounts, and for any receiving accounts that have receiverSigRequired == true. The signatures are in the same order as the accounts, skipping those accounts that don't need a signature.
| Field |
Type |
Description |
| transfers |
TransferList |
Accounts and amounts to transfer |
| |
A list of accounts and amounts to transfer out of each account (negative) or into it (positive).
| Field |
Type |
Description |
| accountAmounts |
AccountAmount (repeated) |
Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative) |
| |
An account, and the amount that it sends or receives during a cryptocurrency transfer.
| Field |
Type |
Description |
| accountID |
AccountID |
The Account ID that sends or receives cryptocurrency |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| amount |
sint64 |
The amount of tinybars that the account sends(negative) or receives(positive) |
|
|
|
| cryptoUpdateAccount |
CryptoUpdateTransactionBody |
Modify information such as the expiration date for an account |
| |
Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account.
| Field |
Type |
Description |
| accountIDToUpdate |
AccountID |
The account ID which is being updated in this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| key |
Key |
The new key |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| proxyFraction |
int32 |
[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account |
| sendRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| sendRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| sendRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
|
| receiveRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| receiveRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
| receiveRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
|
| autoRenewPeriod |
Duration |
The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| expirationTime |
Timestamp |
The new expiration time to extend to (ignored if equal to or before the current one) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| receiverSigRequiredField |
oneof |
|
| |
| Field |
Type |
Description |
| receiverSigRequired |
bool |
[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose. |
| receiverSigRequiredWrapper |
google.protobuf.BoolValue |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
|
|
| fileAppend |
FileAppendTransactionBody |
Add bytes to the end of the contents of a file |
| |
Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to which the bytes are appended to |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contents |
bytes |
The bytes to append to the contents of the file |
|
| fileCreate |
FileCreateTransactionBody |
Create a new file |
| |
Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.
| Field |
Type |
Description |
| expirationTime |
Timestamp |
The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
All these keys must sign to create or modify the file. Any one of them can sign to delete the file. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The bytes that are the contents of the file |
| shardID |
ShardID |
Shard in which this file is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The Realm in which to the file is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| fileDelete |
FileDeleteTransactionBody |
Delete a file (remove contents and mark as deleted until it expires) |
| |
Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys).
| Field |
Type |
Description |
| fileID |
FileID |
The file to delete. It will be marked as deleted until it expires. Then it will disappear. |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
|
| fileUpdate |
FileUpdateTransactionBody |
Modify information such as the expiration date for a file |
| |
Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to update |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| expirationTime |
Timestamp |
The new time at which it should expire (ignored if not later than the current value) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
The keys that can modify or delete the file |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The new file contents. All the bytes in the old contents are discarded. |
|
| systemDelete |
SystemDeleteTransactionBody |
Hedera multisig system deletes a file or smart contract |
| |
Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to delete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to delete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
| expirationTime |
TimestampSeconds |
The timestamp in seconds at which the "deleted" file should truly be permanently deleted |
| |
An exact date and time, with a resolution of one second (no nanoseconds).
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
|
|
| systemUndelete |
SystemUndeleteTransactionBody |
To undelete an entity deleted by SystemDelete |
| |
Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID to undelete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to undelete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| freeze |
FreezeTransactionBody |
Freeze the nodes |
| |
Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance.
| Field |
Type |
Description |
| startHour |
int32 |
The start hour (in UTC time), a value between 0 and 23 |
| startMin |
int32 |
The start minute (in UTC time), a value between 0 and 59 |
| endHour |
int32 |
The end hour (in UTC time), a value between 0 and 23 |
| endMin |
int32 |
The end minute (in UTC time), a value between 0 and 59 |
|
| consensusCreateTopic |
ConsensusCreateTopicTransactionBody |
|
| consensusUpdateTopic |
ConsensusUpdateTopicTransactionBody |
|
| consensusDeleteTopic |
ConsensusDeleteTopicTransactionBody |
|
| consensusSubmitMessage |
ConsensusSubmitMessageTransactionBody |
|
| |
| Field |
Type |
Description |
| topicID |
TopicID |
Topic to submit message to. |
| |
Unique identifier for a topic (used by the consensus service)
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| topicNum |
int64 |
Unique topic identifier within a realm (nonnegative). |
|
| message |
bytes |
Message to be submitted. Max size of the Transaction (including signatures) is 4kB. |
|
|
|
| bodyBytes |
bytes |
TransactionBody serialized into bytes , which needs to be signed |
|
| sigs |
SignatureList |
The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field |
| |
The signatures corresponding to a KeyList of the same length.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
Signature (repeated) |
each signature corresponds to a Key in the KeyList |
| |
A Signature corresponding to a Key. It is a sequence of bytes holding a public key signature from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be a list of signatures corresponding to a single threshold key. Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. If it has a smart contract ID associated with it, then that smart contract is allowed to transfer cryptocurrency out of it. The smart contract doesn't actually have a key, and doesn't actually sign a transaction. But it's as if a virtual transaction were created, and the smart contract signed it with a private key. A key can also be a "threshold key", which means a list of M keys, any N of which must sign in order for the threshold signature to be considered valid. The keys within a threshold signature may themselves be threshold signatures, to allow complex signature requirements (this nesting is not supported in the currently, but will be supported in a future version of API). If a Signature message is missing the "signature" field, then this is considered to be a null signature. That is useful in cases such as threshold signatures, where some of the signatures can be null.
| Field |
Type |
Description |
| deprecated |
option |
|
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature bytes |
| RSA_3072 |
bytes |
RSA-3072 signature bytes |
| ECDSA_384 |
bytes |
ECDSA p-384 signature bytes |
| thresholdSignature |
ThresholdSignature |
A list of signatures for a single N-of-M threshold Key. This must be a list of exactly M signatures, at least N of which are non-null. |
| |
A signature corresponding to a ThresholdKey. For an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
SignatureList |
for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null |
| |
Self Reference
|
|
| signatureList |
SignatureList |
A list of M signatures, each corresponding to a Key in a KeyList of the same length. |
| |
Self Reference
|
|
|
|
| sigMap |
SignatureMap |
The signatures on the body with the new format, to authorize the transaction |
| |
A set of signatures corresponding to every unique public key used to sign a given transaction.
| Field |
Type |
Description |
| sigPair |
SignaturePair (repeated) |
Each signature pair corresponds to a unique Key required to sign the transaction. |
| |
The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.
| Field |
Type |
Description |
| pubKeyPrefix |
bytes |
First few bytes of the public key |
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature |
| RSA_3072 |
bytes |
RSA-3072 signature |
| ECDSA_384 |
bytes |
ECDSA p-384 signature |
|
|
|
|
| responseType |
ResponseType |
The requested response, asking for cost, state proof, both, or neither |
| |
The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request.
| Enum Name |
Description |
| ANSWER_ONLY |
Response returns answer |
| ANSWER_STATE_PROOF |
Response returns both answer and state proof |
| COST_ANSWER |
Response returns the cost of answer |
| COST_ANSWER_STATE_PROOF |
Response returns the total cost of answer and state proof |
|
|
| accountID |
AccountID |
The Account ID for which the records should be retrieved |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| fileGetContents |
FileGetContentsQuery |
Get the contents of a file (the bytes stored in it) |
| |
Get the contents of a file. The content field is empty (no bytes) if the file is empty.
| Field |
Type |
Description |
| header |
QueryHeader |
Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). |
| |
Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for.
| Field |
Type |
Description |
| payment |
Transaction |
A signed CryptoTransferTransaction to pay the node a fee for handling this query |
| |
A single signed transaction, including all its signatures. The SignatureList will have a Signature for each Key in the transaction, either explicit or implicit, in the order that they appear in the transaction. For example, a CryptoTransfer will first have a Signature corresponding to the Key for the paying account, followed by a Signature corresponding to the Key for each account that is sending or receiving cryptocurrency in the transfer. Each Transaction should not have more than 50 levels.
| Field |
Type |
Description |
| bodyData |
oneof |
|
| |
| Field |
Type |
Description |
| body |
TransactionBody |
the body of the transaction, which needs to be signed |
| |
A single transaction. All transaction types are possible here.
| Field |
Type |
Description |
| transactionID |
TransactionID |
The ID for this transaction, which includes the payer's account (the account paying the transaction fee). If two transactions have the same transactionID, they won't both have an effect |
| |
The ID for a transaction. This is used for retrieving receipts and records for a transaction, for appending to a file right after creating it, for instantiating a smart contract with bytecode in a file just created, and internally by the network for detecting when duplicate transactions are submitted. A user might get a transaction processed faster by submitting it to N 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 will not take effect. So this could make the transaction take effect faster, if any given node might be slow. However, the full transaction fee is charged for each transaction, so the total fee is N times as much if the transaction is sent to N nodes.
| Field |
Type |
Description |
| transactionValidStart |
Timestamp |
The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| accountID |
AccountID |
The Account ID that paid for this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| nodeAccountID |
AccountID |
The account of the node that submits the client's transaction to the network |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transactionFee |
uint64 |
The maximum transaction fee the client is willing to pay, which is split between the network and the node |
| transactionValidDuration |
Duration |
The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| generateRecord |
bool |
Should a record of this transaction be generated? (A receipt is always generated, but the record is optional) |
| memo |
string |
Any notes or descriptions that should be put into the record (max length 100) |
| data |
oneof |
|
| |
| Field |
Type |
Description |
| contractCall |
ContractCallTransactionBody |
Contains the call a function of a contract instance |
| |
Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.
| Field |
Type |
Description |
| contractID |
ContractID |
the contract instance to call, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| gas |
int64 |
the maximum amount of gas to use for the call |
| amount |
int64 |
number of tinybars sent (the function must be payable if this is nonzero) |
| functionParameters |
bytes |
which function to call, and the parameters to pass to the function |
|
| contractCreateInstance |
ContractCreateTransactionBody |
Contains the create data a contract instance |
| |
Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.
| Field |
Type |
Description |
| fileID |
FileID |
the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| adminKey |
Key |
the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| gas |
int64 |
gas to run the constructor |
| initialBalance |
int64 |
initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
the instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| constructorParameters |
bytes |
parameters to pass to the constructor |
| shardID |
ShardID |
shard in which to create this |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
realm in which to create this (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
if realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| memo |
string |
the memo that was submitted as part of the contract (max 100 bytes) |
|
| contractUpdateInstance |
ContractUpdateTransactionBody |
Contains contract modify info such as expiration date for a contract instance |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to update (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| expirationTime |
Timestamp |
Extend the expiration of the instance and its account to this time (no effect if it already is this time or later) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| adminKey |
Key |
The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
The instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| fileID |
FileID |
The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| memo |
string |
The memo associated with the contract (max 100 bytes) |
|
| contractDeleteInstance |
ContractDeleteTransactionBody |
Delete contract and transfer remaining balance into specified account |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to delete (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| obtainers |
oneof |
|
| |
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transferContractID |
ContractID |
The contract ID which will receive all remaining hbars |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| cryptoAddClaim |
CryptoAddClaimTransactionBody |
Attach a new claim to an account |
| |
Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.
| Field |
Type |
Description |
| claim |
Claim |
A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it |
| |
A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet.
| Field |
Type |
Description |
| accountID |
AccountID |
the account to which the claim is attached |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hash |
bytes |
48 byte SHA-384 hash (presumably of some kind of credential or certificate) |
| keys |
KeyList |
list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys). |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| claimDuration |
Duration |
the duration for which the claim will remain valid |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
|
|
| cryptoCreateAccount |
CryptoCreateTransactionBody |
Create a new cryptocurrency account |
| |
Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency for each record generated, so the thresholds are useful for limiting Record generation to happen only for large transactions. The Key field is the key used to sign transactions for this account. If the account has receiverSigRequired set to true, then all cryptocurrency transfers must be signed by this account's key, both for transfers in and out. If it is false, then only transfers out have to be signed by it. When the account is created, the payer account is charged enough hbars so that the new account will not expire for the next autoRenewPeriod seconds. When it reaches the expiration time, the new account will then be automatically charged to renew for another autoRenewPeriod seconds. If it does not have enough hbars to renew for that long, then the remaining hbars are used to extend its expiration as long as possible. If it is has a zero balance when it expires, then it is deleted. This transaction must be signed by the payer account. If receiverSigRequired is false, then the transaction does not have to be signed by the keys in the keys field. If it is true, then it must be signed by them, in addition to the keys of the payer account.
| Field |
Type |
Description |
| key |
Key |
The key that must sign each transfer out of the account. If receiverSigRequired is true, then it must also sign any transfer into the account. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| initialBalance |
uint64 |
The initial number of tinybars to put into the account |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| sendRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| receiveRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction |
| receiverSigRequired |
bool |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
| autoRenewPeriod |
Duration |
The account is charged to extend its expiration date every this many seconds. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| shardID |
ShardID |
The shard in which this account is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The realm in which this account is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| cryptoDelete |
CryptoDeleteTransactionBody |
Delete a cryptocurrency account (mark as deleted, and transfer hbars out) |
| |
Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way.
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| deleteAccountID |
AccountID |
The account ID which should be deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| cryptoDeleteClaim |
CryptoDeleteClaimTransactionBody |
Remove a claim from an account |
| |
Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes.
| Field |
Type |
Description |
| accountIDToDeleteFrom |
AccountID |
The account ID that should have a claim deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hashToDelete |
bytes |
The hash in the claim to delete (a SHA-384 hash, 48 bytes) |
|
| cryptoTransfer |
CryptoTransferTransactionBody |
Transfer amount between accounts |
| |
Transfer cryptocurrency from some accounts to other accounts. The accounts list can contain up to 10 accounts. The amounts list must be the same length as the accounts list. Each negative amount is withdrawn from the corresponding account (a sender), and each positive one is added to the corresponding account (a receiver). The amounts list must sum to zero. Each amount is a number of tinyBars (there are 100,000,000 tinyBars in one Hbar). If any sender account fails to have sufficient hbars to do the withdrawal, then the entire transaction fails, and none of those transfers occur, though the transaction fee is still charged. This transaction must be signed by the keys for all the sending accounts, and for any receiving accounts that have receiverSigRequired == true. The signatures are in the same order as the accounts, skipping those accounts that don't need a signature.
| Field |
Type |
Description |
| transfers |
TransferList |
Accounts and amounts to transfer |
| |
A list of accounts and amounts to transfer out of each account (negative) or into it (positive).
| Field |
Type |
Description |
| accountAmounts |
AccountAmount (repeated) |
Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative) |
| |
An account, and the amount that it sends or receives during a cryptocurrency transfer.
| Field |
Type |
Description |
| accountID |
AccountID |
The Account ID that sends or receives cryptocurrency |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| amount |
sint64 |
The amount of tinybars that the account sends(negative) or receives(positive) |
|
|
|
| cryptoUpdateAccount |
CryptoUpdateTransactionBody |
Modify information such as the expiration date for an account |
| |
Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account.
| Field |
Type |
Description |
| accountIDToUpdate |
AccountID |
The account ID which is being updated in this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| key |
Key |
The new key |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| proxyFraction |
int32 |
[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account |
| sendRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| sendRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| sendRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
|
| receiveRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| receiveRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
| receiveRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
|
| autoRenewPeriod |
Duration |
The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| expirationTime |
Timestamp |
The new expiration time to extend to (ignored if equal to or before the current one) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| receiverSigRequiredField |
oneof |
|
| |
| Field |
Type |
Description |
| receiverSigRequired |
bool |
[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose. |
| receiverSigRequiredWrapper |
google.protobuf.BoolValue |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
|
|
| fileAppend |
FileAppendTransactionBody |
Add bytes to the end of the contents of a file |
| |
Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to which the bytes are appended to |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contents |
bytes |
The bytes to append to the contents of the file |
|
| fileCreate |
FileCreateTransactionBody |
Create a new file |
| |
Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.
| Field |
Type |
Description |
| expirationTime |
Timestamp |
The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
All these keys must sign to create or modify the file. Any one of them can sign to delete the file. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The bytes that are the contents of the file |
| shardID |
ShardID |
Shard in which this file is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The Realm in which to the file is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| fileDelete |
FileDeleteTransactionBody |
Delete a file (remove contents and mark as deleted until it expires) |
| |
Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys).
| Field |
Type |
Description |
| fileID |
FileID |
The file to delete. It will be marked as deleted until it expires. Then it will disappear. |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
|
| fileUpdate |
FileUpdateTransactionBody |
Modify information such as the expiration date for a file |
| |
Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to update |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| expirationTime |
Timestamp |
The new time at which it should expire (ignored if not later than the current value) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
The keys that can modify or delete the file |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The new file contents. All the bytes in the old contents are discarded. |
|
| systemDelete |
SystemDeleteTransactionBody |
Hedera multisig system deletes a file or smart contract |
| |
Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to delete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to delete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
| expirationTime |
TimestampSeconds |
The timestamp in seconds at which the "deleted" file should truly be permanently deleted |
| |
An exact date and time, with a resolution of one second (no nanoseconds).
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
|
|
| systemUndelete |
SystemUndeleteTransactionBody |
To undelete an entity deleted by SystemDelete |
| |
Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID to undelete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to undelete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| freeze |
FreezeTransactionBody |
Freeze the nodes |
| |
Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance.
| Field |
Type |
Description |
| startHour |
int32 |
The start hour (in UTC time), a value between 0 and 23 |
| startMin |
int32 |
The start minute (in UTC time), a value between 0 and 59 |
| endHour |
int32 |
The end hour (in UTC time), a value between 0 and 23 |
| endMin |
int32 |
The end minute (in UTC time), a value between 0 and 59 |
|
| consensusCreateTopic |
ConsensusCreateTopicTransactionBody |
|
| consensusUpdateTopic |
ConsensusUpdateTopicTransactionBody |
|
| consensusDeleteTopic |
ConsensusDeleteTopicTransactionBody |
|
| consensusSubmitMessage |
ConsensusSubmitMessageTransactionBody |
|
| |
| Field |
Type |
Description |
| topicID |
TopicID |
Topic to submit message to. |
| |
Unique identifier for a topic (used by the consensus service)
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| topicNum |
int64 |
Unique topic identifier within a realm (nonnegative). |
|
| message |
bytes |
Message to be submitted. Max size of the Transaction (including signatures) is 4kB. |
|
|
|
| bodyBytes |
bytes |
TransactionBody serialized into bytes , which needs to be signed |
|
| sigs |
SignatureList |
The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field |
| |
The signatures corresponding to a KeyList of the same length.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
Signature (repeated) |
each signature corresponds to a Key in the KeyList |
| |
A Signature corresponding to a Key. It is a sequence of bytes holding a public key signature from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be a list of signatures corresponding to a single threshold key. Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. If it has a smart contract ID associated with it, then that smart contract is allowed to transfer cryptocurrency out of it. The smart contract doesn't actually have a key, and doesn't actually sign a transaction. But it's as if a virtual transaction were created, and the smart contract signed it with a private key. A key can also be a "threshold key", which means a list of M keys, any N of which must sign in order for the threshold signature to be considered valid. The keys within a threshold signature may themselves be threshold signatures, to allow complex signature requirements (this nesting is not supported in the currently, but will be supported in a future version of API). If a Signature message is missing the "signature" field, then this is considered to be a null signature. That is useful in cases such as threshold signatures, where some of the signatures can be null.
| Field |
Type |
Description |
| deprecated |
option |
|
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature bytes |
| RSA_3072 |
bytes |
RSA-3072 signature bytes |
| ECDSA_384 |
bytes |
ECDSA p-384 signature bytes |
| thresholdSignature |
ThresholdSignature |
A list of signatures for a single N-of-M threshold Key. This must be a list of exactly M signatures, at least N of which are non-null. |
| |
A signature corresponding to a ThresholdKey. For an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
SignatureList |
for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null |
| |
Self Reference
|
|
| signatureList |
SignatureList |
A list of M signatures, each corresponding to a Key in a KeyList of the same length. |
| |
Self Reference
|
|
|
|
| sigMap |
SignatureMap |
The signatures on the body with the new format, to authorize the transaction |
| |
A set of signatures corresponding to every unique public key used to sign a given transaction.
| Field |
Type |
Description |
| sigPair |
SignaturePair (repeated) |
Each signature pair corresponds to a unique Key required to sign the transaction. |
| |
The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.
| Field |
Type |
Description |
| pubKeyPrefix |
bytes |
First few bytes of the public key |
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature |
| RSA_3072 |
bytes |
RSA-3072 signature |
| ECDSA_384 |
bytes |
ECDSA p-384 signature |
|
|
|
|
| responseType |
ResponseType |
The requested response, asking for cost, state proof, both, or neither |
| |
The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request.
| Enum Name |
Description |
| ANSWER_ONLY |
Response returns answer |
| ANSWER_STATE_PROOF |
Response returns both answer and state proof |
| COST_ANSWER |
Response returns the cost of answer |
| COST_ANSWER_STATE_PROOF |
Response returns the total cost of answer and state proof |
|
|
| fileID |
FileID |
The file ID of the file whose contents are requested |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
|
| fileGetInfo |
FileGetInfoQuery |
Get information about a file, such as its expiration date |
| |
Get all of the information about a file, except for its contents. When a file expires, it no longer exists, and there will be no info about it, and the fileInfo field will be blank. If a transaction or smart contract deletes the file, but it has not yet expired, then the fileInfo field will be non-empty, the deleted field will be true, its size will be 0, and its contents will be empty. Note that each file has a FileID, but does not have a filename.
| Field |
Type |
Description |
| header |
QueryHeader |
Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). |
| |
Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for.
| Field |
Type |
Description |
| payment |
Transaction |
A signed CryptoTransferTransaction to pay the node a fee for handling this query |
| |
A single signed transaction, including all its signatures. The SignatureList will have a Signature for each Key in the transaction, either explicit or implicit, in the order that they appear in the transaction. For example, a CryptoTransfer will first have a Signature corresponding to the Key for the paying account, followed by a Signature corresponding to the Key for each account that is sending or receiving cryptocurrency in the transfer. Each Transaction should not have more than 50 levels.
| Field |
Type |
Description |
| bodyData |
oneof |
|
| |
| Field |
Type |
Description |
| body |
TransactionBody |
the body of the transaction, which needs to be signed |
| |
A single transaction. All transaction types are possible here.
| Field |
Type |
Description |
| transactionID |
TransactionID |
The ID for this transaction, which includes the payer's account (the account paying the transaction fee). If two transactions have the same transactionID, they won't both have an effect |
| |
The ID for a transaction. This is used for retrieving receipts and records for a transaction, for appending to a file right after creating it, for instantiating a smart contract with bytecode in a file just created, and internally by the network for detecting when duplicate transactions are submitted. A user might get a transaction processed faster by submitting it to N 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 will not take effect. So this could make the transaction take effect faster, if any given node might be slow. However, the full transaction fee is charged for each transaction, so the total fee is N times as much if the transaction is sent to N nodes.
| Field |
Type |
Description |
| transactionValidStart |
Timestamp |
The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| accountID |
AccountID |
The Account ID that paid for this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| nodeAccountID |
AccountID |
The account of the node that submits the client's transaction to the network |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transactionFee |
uint64 |
The maximum transaction fee the client is willing to pay, which is split between the network and the node |
| transactionValidDuration |
Duration |
The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| generateRecord |
bool |
Should a record of this transaction be generated? (A receipt is always generated, but the record is optional) |
| memo |
string |
Any notes or descriptions that should be put into the record (max length 100) |
| data |
oneof |
|
| |
| Field |
Type |
Description |
| contractCall |
ContractCallTransactionBody |
Contains the call a function of a contract instance |
| |
Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.
| Field |
Type |
Description |
| contractID |
ContractID |
the contract instance to call, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| gas |
int64 |
the maximum amount of gas to use for the call |
| amount |
int64 |
number of tinybars sent (the function must be payable if this is nonzero) |
| functionParameters |
bytes |
which function to call, and the parameters to pass to the function |
|
| contractCreateInstance |
ContractCreateTransactionBody |
Contains the create data a contract instance |
| |
Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.
| Field |
Type |
Description |
| fileID |
FileID |
the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| adminKey |
Key |
the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| gas |
int64 |
gas to run the constructor |
| initialBalance |
int64 |
initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
the instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| constructorParameters |
bytes |
parameters to pass to the constructor |
| shardID |
ShardID |
shard in which to create this |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
realm in which to create this (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
if realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| memo |
string |
the memo that was submitted as part of the contract (max 100 bytes) |
|
| contractUpdateInstance |
ContractUpdateTransactionBody |
Contains contract modify info such as expiration date for a contract instance |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to update (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| expirationTime |
Timestamp |
Extend the expiration of the instance and its account to this time (no effect if it already is this time or later) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| adminKey |
Key |
The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
The instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| fileID |
FileID |
The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| memo |
string |
The memo associated with the contract (max 100 bytes) |
|
| contractDeleteInstance |
ContractDeleteTransactionBody |
Delete contract and transfer remaining balance into specified account |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to delete (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| obtainers |
oneof |
|
| |
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transferContractID |
ContractID |
The contract ID which will receive all remaining hbars |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| cryptoAddClaim |
CryptoAddClaimTransactionBody |
Attach a new claim to an account |
| |
Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.
| Field |
Type |
Description |
| claim |
Claim |
A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it |
| |
A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet.
| Field |
Type |
Description |
| accountID |
AccountID |
the account to which the claim is attached |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hash |
bytes |
48 byte SHA-384 hash (presumably of some kind of credential or certificate) |
| keys |
KeyList |
list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys). |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| claimDuration |
Duration |
the duration for which the claim will remain valid |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
|
|
| cryptoCreateAccount |
CryptoCreateTransactionBody |
Create a new cryptocurrency account |
| |
Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency for each record generated, so the thresholds are useful for limiting Record generation to happen only for large transactions. The Key field is the key used to sign transactions for this account. If the account has receiverSigRequired set to true, then all cryptocurrency transfers must be signed by this account's key, both for transfers in and out. If it is false, then only transfers out have to be signed by it. When the account is created, the payer account is charged enough hbars so that the new account will not expire for the next autoRenewPeriod seconds. When it reaches the expiration time, the new account will then be automatically charged to renew for another autoRenewPeriod seconds. If it does not have enough hbars to renew for that long, then the remaining hbars are used to extend its expiration as long as possible. If it is has a zero balance when it expires, then it is deleted. This transaction must be signed by the payer account. If receiverSigRequired is false, then the transaction does not have to be signed by the keys in the keys field. If it is true, then it must be signed by them, in addition to the keys of the payer account.
| Field |
Type |
Description |
| key |
Key |
The key that must sign each transfer out of the account. If receiverSigRequired is true, then it must also sign any transfer into the account. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| initialBalance |
uint64 |
The initial number of tinybars to put into the account |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| sendRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| receiveRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction |
| receiverSigRequired |
bool |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
| autoRenewPeriod |
Duration |
The account is charged to extend its expiration date every this many seconds. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| shardID |
ShardID |
The shard in which this account is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The realm in which this account is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| cryptoDelete |
CryptoDeleteTransactionBody |
Delete a cryptocurrency account (mark as deleted, and transfer hbars out) |
| |
Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way.
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| deleteAccountID |
AccountID |
The account ID which should be deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| cryptoDeleteClaim |
CryptoDeleteClaimTransactionBody |
Remove a claim from an account |
| |
Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes.
| Field |
Type |
Description |
| accountIDToDeleteFrom |
AccountID |
The account ID that should have a claim deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hashToDelete |
bytes |
The hash in the claim to delete (a SHA-384 hash, 48 bytes) |
|
| cryptoTransfer |
CryptoTransferTransactionBody |
Transfer amount between accounts |
| |
Transfer cryptocurrency from some accounts to other accounts. The accounts list can contain up to 10 accounts. The amounts list must be the same length as the accounts list. Each negative amount is withdrawn from the corresponding account (a sender), and each positive one is added to the corresponding account (a receiver). The amounts list must sum to zero. Each amount is a number of tinyBars (there are 100,000,000 tinyBars in one Hbar). If any sender account fails to have sufficient hbars to do the withdrawal, then the entire transaction fails, and none of those transfers occur, though the transaction fee is still charged. This transaction must be signed by the keys for all the sending accounts, and for any receiving accounts that have receiverSigRequired == true. The signatures are in the same order as the accounts, skipping those accounts that don't need a signature.
| Field |
Type |
Description |
| transfers |
TransferList |
Accounts and amounts to transfer |
| |
A list of accounts and amounts to transfer out of each account (negative) or into it (positive).
| Field |
Type |
Description |
| accountAmounts |
AccountAmount (repeated) |
Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative) |
| |
An account, and the amount that it sends or receives during a cryptocurrency transfer.
| Field |
Type |
Description |
| accountID |
AccountID |
The Account ID that sends or receives cryptocurrency |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| amount |
sint64 |
The amount of tinybars that the account sends(negative) or receives(positive) |
|
|
|
| cryptoUpdateAccount |
CryptoUpdateTransactionBody |
Modify information such as the expiration date for an account |
| |
Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account.
| Field |
Type |
Description |
| accountIDToUpdate |
AccountID |
The account ID which is being updated in this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| key |
Key |
The new key |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| proxyFraction |
int32 |
[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account |
| sendRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| sendRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| sendRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
|
| receiveRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| receiveRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
| receiveRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
|
| autoRenewPeriod |
Duration |
The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| expirationTime |
Timestamp |
The new expiration time to extend to (ignored if equal to or before the current one) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| receiverSigRequiredField |
oneof |
|
| |
| Field |
Type |
Description |
| receiverSigRequired |
bool |
[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose. |
| receiverSigRequiredWrapper |
google.protobuf.BoolValue |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
|
|
| fileAppend |
FileAppendTransactionBody |
Add bytes to the end of the contents of a file |
| |
Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to which the bytes are appended to |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contents |
bytes |
The bytes to append to the contents of the file |
|
| fileCreate |
FileCreateTransactionBody |
Create a new file |
| |
Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.
| Field |
Type |
Description |
| expirationTime |
Timestamp |
The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
All these keys must sign to create or modify the file. Any one of them can sign to delete the file. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The bytes that are the contents of the file |
| shardID |
ShardID |
Shard in which this file is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The Realm in which to the file is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| fileDelete |
FileDeleteTransactionBody |
Delete a file (remove contents and mark as deleted until it expires) |
| |
Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys).
| Field |
Type |
Description |
| fileID |
FileID |
The file to delete. It will be marked as deleted until it expires. Then it will disappear. |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
|
| fileUpdate |
FileUpdateTransactionBody |
Modify information such as the expiration date for a file |
| |
Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to update |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| expirationTime |
Timestamp |
The new time at which it should expire (ignored if not later than the current value) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
The keys that can modify or delete the file |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The new file contents. All the bytes in the old contents are discarded. |
|
| systemDelete |
SystemDeleteTransactionBody |
Hedera multisig system deletes a file or smart contract |
| |
Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to delete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to delete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
| expirationTime |
TimestampSeconds |
The timestamp in seconds at which the "deleted" file should truly be permanently deleted |
| |
An exact date and time, with a resolution of one second (no nanoseconds).
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
|
|
| systemUndelete |
SystemUndeleteTransactionBody |
To undelete an entity deleted by SystemDelete |
| |
Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID to undelete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to undelete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| freeze |
FreezeTransactionBody |
Freeze the nodes |
| |
Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance.
| Field |
Type |
Description |
| startHour |
int32 |
The start hour (in UTC time), a value between 0 and 23 |
| startMin |
int32 |
The start minute (in UTC time), a value between 0 and 59 |
| endHour |
int32 |
The end hour (in UTC time), a value between 0 and 23 |
| endMin |
int32 |
The end minute (in UTC time), a value between 0 and 59 |
|
| consensusCreateTopic |
ConsensusCreateTopicTransactionBody |
|
| consensusUpdateTopic |
ConsensusUpdateTopicTransactionBody |
|
| consensusDeleteTopic |
ConsensusDeleteTopicTransactionBody |
|
| consensusSubmitMessage |
ConsensusSubmitMessageTransactionBody |
|
| |
| Field |
Type |
Description |
| topicID |
TopicID |
Topic to submit message to. |
| |
Unique identifier for a topic (used by the consensus service)
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| topicNum |
int64 |
Unique topic identifier within a realm (nonnegative). |
|
| message |
bytes |
Message to be submitted. Max size of the Transaction (including signatures) is 4kB. |
|
|
|
| bodyBytes |
bytes |
TransactionBody serialized into bytes , which needs to be signed |
|
| sigs |
SignatureList |
The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field |
| |
The signatures corresponding to a KeyList of the same length.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
Signature (repeated) |
each signature corresponds to a Key in the KeyList |
| |
A Signature corresponding to a Key. It is a sequence of bytes holding a public key signature from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be a list of signatures corresponding to a single threshold key. Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. If it has a smart contract ID associated with it, then that smart contract is allowed to transfer cryptocurrency out of it. The smart contract doesn't actually have a key, and doesn't actually sign a transaction. But it's as if a virtual transaction were created, and the smart contract signed it with a private key. A key can also be a "threshold key", which means a list of M keys, any N of which must sign in order for the threshold signature to be considered valid. The keys within a threshold signature may themselves be threshold signatures, to allow complex signature requirements (this nesting is not supported in the currently, but will be supported in a future version of API). If a Signature message is missing the "signature" field, then this is considered to be a null signature. That is useful in cases such as threshold signatures, where some of the signatures can be null.
| Field |
Type |
Description |
| deprecated |
option |
|
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature bytes |
| RSA_3072 |
bytes |
RSA-3072 signature bytes |
| ECDSA_384 |
bytes |
ECDSA p-384 signature bytes |
| thresholdSignature |
ThresholdSignature |
A list of signatures for a single N-of-M threshold Key. This must be a list of exactly M signatures, at least N of which are non-null. |
| |
A signature corresponding to a ThresholdKey. For an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
SignatureList |
for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null |
| |
Self Reference
|
|
| signatureList |
SignatureList |
A list of M signatures, each corresponding to a Key in a KeyList of the same length. |
| |
Self Reference
|
|
|
|
| sigMap |
SignatureMap |
The signatures on the body with the new format, to authorize the transaction |
| |
A set of signatures corresponding to every unique public key used to sign a given transaction.
| Field |
Type |
Description |
| sigPair |
SignaturePair (repeated) |
Each signature pair corresponds to a unique Key required to sign the transaction. |
| |
The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.
| Field |
Type |
Description |
| pubKeyPrefix |
bytes |
First few bytes of the public key |
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature |
| RSA_3072 |
bytes |
RSA-3072 signature |
| ECDSA_384 |
bytes |
ECDSA p-384 signature |
|
|
|
|
| responseType |
ResponseType |
The requested response, asking for cost, state proof, both, or neither |
| |
The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request.
| Enum Name |
Description |
| ANSWER_ONLY |
Response returns answer |
| ANSWER_STATE_PROOF |
Response returns both answer and state proof |
| COST_ANSWER |
Response returns the cost of answer |
| COST_ANSWER_STATE_PROOF |
Response returns the total cost of answer and state proof |
|
|
| fileID |
FileID |
The file ID of the file for which information is requested |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
|
| transactionGetReceipt |
TransactionGetReceiptQuery |
Get a receipt for a transaction (lasts 180 seconds) |
| |
Get the receipt 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. This query is free (the payment field is left empty). No State proof is available for this response
| Field |
Type |
Description |
| header |
QueryHeader |
Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). |
| |
Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for.
| Field |
Type |
Description |
| payment |
Transaction |
A signed CryptoTransferTransaction to pay the node a fee for handling this query |
| |
A single signed transaction, including all its signatures. The SignatureList will have a Signature for each Key in the transaction, either explicit or implicit, in the order that they appear in the transaction. For example, a CryptoTransfer will first have a Signature corresponding to the Key for the paying account, followed by a Signature corresponding to the Key for each account that is sending or receiving cryptocurrency in the transfer. Each Transaction should not have more than 50 levels.
| Field |
Type |
Description |
| bodyData |
oneof |
|
| |
| Field |
Type |
Description |
| body |
TransactionBody |
the body of the transaction, which needs to be signed |
| |
A single transaction. All transaction types are possible here.
| Field |
Type |
Description |
| transactionID |
TransactionID |
The ID for this transaction, which includes the payer's account (the account paying the transaction fee). If two transactions have the same transactionID, they won't both have an effect |
| |
The ID for a transaction. This is used for retrieving receipts and records for a transaction, for appending to a file right after creating it, for instantiating a smart contract with bytecode in a file just created, and internally by the network for detecting when duplicate transactions are submitted. A user might get a transaction processed faster by submitting it to N 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 will not take effect. So this could make the transaction take effect faster, if any given node might be slow. However, the full transaction fee is charged for each transaction, so the total fee is N times as much if the transaction is sent to N nodes.
| Field |
Type |
Description |
| transactionValidStart |
Timestamp |
The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| accountID |
AccountID |
The Account ID that paid for this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| nodeAccountID |
AccountID |
The account of the node that submits the client's transaction to the network |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transactionFee |
uint64 |
The maximum transaction fee the client is willing to pay, which is split between the network and the node |
| transactionValidDuration |
Duration |
The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| generateRecord |
bool |
Should a record of this transaction be generated? (A receipt is always generated, but the record is optional) |
| memo |
string |
Any notes or descriptions that should be put into the record (max length 100) |
| data |
oneof |
|
| |
| Field |
Type |
Description |
| contractCall |
ContractCallTransactionBody |
Contains the call a function of a contract instance |
| |
Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.
| Field |
Type |
Description |
| contractID |
ContractID |
the contract instance to call, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| gas |
int64 |
the maximum amount of gas to use for the call |
| amount |
int64 |
number of tinybars sent (the function must be payable if this is nonzero) |
| functionParameters |
bytes |
which function to call, and the parameters to pass to the function |
|
| contractCreateInstance |
ContractCreateTransactionBody |
Contains the create data a contract instance |
| |
Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.
| Field |
Type |
Description |
| fileID |
FileID |
the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| adminKey |
Key |
the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| gas |
int64 |
gas to run the constructor |
| initialBalance |
int64 |
initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
the instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| constructorParameters |
bytes |
parameters to pass to the constructor |
| shardID |
ShardID |
shard in which to create this |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
realm in which to create this (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
if realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| memo |
string |
the memo that was submitted as part of the contract (max 100 bytes) |
|
| contractUpdateInstance |
ContractUpdateTransactionBody |
Contains contract modify info such as expiration date for a contract instance |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to update (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| expirationTime |
Timestamp |
Extend the expiration of the instance and its account to this time (no effect if it already is this time or later) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| adminKey |
Key |
The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
The instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| fileID |
FileID |
The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| memo |
string |
The memo associated with the contract (max 100 bytes) |
|
| contractDeleteInstance |
ContractDeleteTransactionBody |
Delete contract and transfer remaining balance into specified account |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to delete (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| obtainers |
oneof |
|
| |
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transferContractID |
ContractID |
The contract ID which will receive all remaining hbars |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| cryptoAddClaim |
CryptoAddClaimTransactionBody |
Attach a new claim to an account |
| |
Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.
| Field |
Type |
Description |
| claim |
Claim |
A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it |
| |
A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet.
| Field |
Type |
Description |
| accountID |
AccountID |
the account to which the claim is attached |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hash |
bytes |
48 byte SHA-384 hash (presumably of some kind of credential or certificate) |
| keys |
KeyList |
list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys). |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| claimDuration |
Duration |
the duration for which the claim will remain valid |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
|
|
| cryptoCreateAccount |
CryptoCreateTransactionBody |
Create a new cryptocurrency account |
| |
Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency for each record generated, so the thresholds are useful for limiting Record generation to happen only for large transactions. The Key field is the key used to sign transactions for this account. If the account has receiverSigRequired set to true, then all cryptocurrency transfers must be signed by this account's key, both for transfers in and out. If it is false, then only transfers out have to be signed by it. When the account is created, the payer account is charged enough hbars so that the new account will not expire for the next autoRenewPeriod seconds. When it reaches the expiration time, the new account will then be automatically charged to renew for another autoRenewPeriod seconds. If it does not have enough hbars to renew for that long, then the remaining hbars are used to extend its expiration as long as possible. If it is has a zero balance when it expires, then it is deleted. This transaction must be signed by the payer account. If receiverSigRequired is false, then the transaction does not have to be signed by the keys in the keys field. If it is true, then it must be signed by them, in addition to the keys of the payer account.
| Field |
Type |
Description |
| key |
Key |
The key that must sign each transfer out of the account. If receiverSigRequired is true, then it must also sign any transfer into the account. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| initialBalance |
uint64 |
The initial number of tinybars to put into the account |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| sendRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| receiveRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction |
| receiverSigRequired |
bool |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
| autoRenewPeriod |
Duration |
The account is charged to extend its expiration date every this many seconds. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| shardID |
ShardID |
The shard in which this account is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The realm in which this account is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| cryptoDelete |
CryptoDeleteTransactionBody |
Delete a cryptocurrency account (mark as deleted, and transfer hbars out) |
| |
Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way.
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| deleteAccountID |
AccountID |
The account ID which should be deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| cryptoDeleteClaim |
CryptoDeleteClaimTransactionBody |
Remove a claim from an account |
| |
Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes.
| Field |
Type |
Description |
| accountIDToDeleteFrom |
AccountID |
The account ID that should have a claim deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hashToDelete |
bytes |
The hash in the claim to delete (a SHA-384 hash, 48 bytes) |
|
| cryptoTransfer |
CryptoTransferTransactionBody |
Transfer amount between accounts |
| |
Transfer cryptocurrency from some accounts to other accounts. The accounts list can contain up to 10 accounts. The amounts list must be the same length as the accounts list. Each negative amount is withdrawn from the corresponding account (a sender), and each positive one is added to the corresponding account (a receiver). The amounts list must sum to zero. Each amount is a number of tinyBars (there are 100,000,000 tinyBars in one Hbar). If any sender account fails to have sufficient hbars to do the withdrawal, then the entire transaction fails, and none of those transfers occur, though the transaction fee is still charged. This transaction must be signed by the keys for all the sending accounts, and for any receiving accounts that have receiverSigRequired == true. The signatures are in the same order as the accounts, skipping those accounts that don't need a signature.
| Field |
Type |
Description |
| transfers |
TransferList |
Accounts and amounts to transfer |
| |
A list of accounts and amounts to transfer out of each account (negative) or into it (positive).
| Field |
Type |
Description |
| accountAmounts |
AccountAmount (repeated) |
Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative) |
| |
An account, and the amount that it sends or receives during a cryptocurrency transfer.
| Field |
Type |
Description |
| accountID |
AccountID |
The Account ID that sends or receives cryptocurrency |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| amount |
sint64 |
The amount of tinybars that the account sends(negative) or receives(positive) |
|
|
|
| cryptoUpdateAccount |
CryptoUpdateTransactionBody |
Modify information such as the expiration date for an account |
| |
Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account.
| Field |
Type |
Description |
| accountIDToUpdate |
AccountID |
The account ID which is being updated in this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| key |
Key |
The new key |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| proxyFraction |
int32 |
[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account |
| sendRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| sendRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| sendRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
|
| receiveRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| receiveRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
| receiveRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
|
| autoRenewPeriod |
Duration |
The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| expirationTime |
Timestamp |
The new expiration time to extend to (ignored if equal to or before the current one) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| receiverSigRequiredField |
oneof |
|
| |
| Field |
Type |
Description |
| receiverSigRequired |
bool |
[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose. |
| receiverSigRequiredWrapper |
google.protobuf.BoolValue |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
|
|
| fileAppend |
FileAppendTransactionBody |
Add bytes to the end of the contents of a file |
| |
Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to which the bytes are appended to |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contents |
bytes |
The bytes to append to the contents of the file |
|
| fileCreate |
FileCreateTransactionBody |
Create a new file |
| |
Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.
| Field |
Type |
Description |
| expirationTime |
Timestamp |
The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
All these keys must sign to create or modify the file. Any one of them can sign to delete the file. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The bytes that are the contents of the file |
| shardID |
ShardID |
Shard in which this file is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The Realm in which to the file is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| fileDelete |
FileDeleteTransactionBody |
Delete a file (remove contents and mark as deleted until it expires) |
| |
Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys).
| Field |
Type |
Description |
| fileID |
FileID |
The file to delete. It will be marked as deleted until it expires. Then it will disappear. |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
|
| fileUpdate |
FileUpdateTransactionBody |
Modify information such as the expiration date for a file |
| |
Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to update |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| expirationTime |
Timestamp |
The new time at which it should expire (ignored if not later than the current value) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
The keys that can modify or delete the file |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The new file contents. All the bytes in the old contents are discarded. |
|
| systemDelete |
SystemDeleteTransactionBody |
Hedera multisig system deletes a file or smart contract |
| |
Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to delete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to delete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
| expirationTime |
TimestampSeconds |
The timestamp in seconds at which the "deleted" file should truly be permanently deleted |
| |
An exact date and time, with a resolution of one second (no nanoseconds).
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
|
|
| systemUndelete |
SystemUndeleteTransactionBody |
To undelete an entity deleted by SystemDelete |
| |
Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID to undelete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to undelete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| freeze |
FreezeTransactionBody |
Freeze the nodes |
| |
Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance.
| Field |
Type |
Description |
| startHour |
int32 |
The start hour (in UTC time), a value between 0 and 23 |
| startMin |
int32 |
The start minute (in UTC time), a value between 0 and 59 |
| endHour |
int32 |
The end hour (in UTC time), a value between 0 and 23 |
| endMin |
int32 |
The end minute (in UTC time), a value between 0 and 59 |
|
| consensusCreateTopic |
ConsensusCreateTopicTransactionBody |
|
| consensusUpdateTopic |
ConsensusUpdateTopicTransactionBody |
|
| consensusDeleteTopic |
ConsensusDeleteTopicTransactionBody |
|
| consensusSubmitMessage |
ConsensusSubmitMessageTransactionBody |
|
| |
| Field |
Type |
Description |
| topicID |
TopicID |
Topic to submit message to. |
| |
Unique identifier for a topic (used by the consensus service)
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| topicNum |
int64 |
Unique topic identifier within a realm (nonnegative). |
|
| message |
bytes |
Message to be submitted. Max size of the Transaction (including signatures) is 4kB. |
|
|
|
| bodyBytes |
bytes |
TransactionBody serialized into bytes , which needs to be signed |
|
| sigs |
SignatureList |
The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field |
| |
The signatures corresponding to a KeyList of the same length.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
Signature (repeated) |
each signature corresponds to a Key in the KeyList |
| |
A Signature corresponding to a Key. It is a sequence of bytes holding a public key signature from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be a list of signatures corresponding to a single threshold key. Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. If it has a smart contract ID associated with it, then that smart contract is allowed to transfer cryptocurrency out of it. The smart contract doesn't actually have a key, and doesn't actually sign a transaction. But it's as if a virtual transaction were created, and the smart contract signed it with a private key. A key can also be a "threshold key", which means a list of M keys, any N of which must sign in order for the threshold signature to be considered valid. The keys within a threshold signature may themselves be threshold signatures, to allow complex signature requirements (this nesting is not supported in the currently, but will be supported in a future version of API). If a Signature message is missing the "signature" field, then this is considered to be a null signature. That is useful in cases such as threshold signatures, where some of the signatures can be null.
| Field |
Type |
Description |
| deprecated |
option |
|
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature bytes |
| RSA_3072 |
bytes |
RSA-3072 signature bytes |
| ECDSA_384 |
bytes |
ECDSA p-384 signature bytes |
| thresholdSignature |
ThresholdSignature |
A list of signatures for a single N-of-M threshold Key. This must be a list of exactly M signatures, at least N of which are non-null. |
| |
A signature corresponding to a ThresholdKey. For an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
SignatureList |
for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null |
| |
Self Reference
|
|
| signatureList |
SignatureList |
A list of M signatures, each corresponding to a Key in a KeyList of the same length. |
| |
Self Reference
|
|
|
|
| sigMap |
SignatureMap |
The signatures on the body with the new format, to authorize the transaction |
| |
A set of signatures corresponding to every unique public key used to sign a given transaction.
| Field |
Type |
Description |
| sigPair |
SignaturePair (repeated) |
Each signature pair corresponds to a unique Key required to sign the transaction. |
| |
The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.
| Field |
Type |
Description |
| pubKeyPrefix |
bytes |
First few bytes of the public key |
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature |
| RSA_3072 |
bytes |
RSA-3072 signature |
| ECDSA_384 |
bytes |
ECDSA p-384 signature |
|
|
|
|
| responseType |
ResponseType |
The requested response, asking for cost, state proof, both, or neither |
| |
The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request.
| Enum Name |
Description |
| ANSWER_ONLY |
Response returns answer |
| ANSWER_STATE_PROOF |
Response returns both answer and state proof |
| COST_ANSWER |
Response returns the cost of answer |
| COST_ANSWER_STATE_PROOF |
Response returns the total cost of answer and state proof |
|
|
| transactionID |
TransactionID |
The ID of the transaction for which the receipt is requested. |
| |
The ID for a transaction. This is used for retrieving receipts and records for a transaction, for appending to a file right after creating it, for instantiating a smart contract with bytecode in a file just created, and internally by the network for detecting when duplicate transactions are submitted. A user might get a transaction processed faster by submitting it to N 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 will not take effect. So this could make the transaction take effect faster, if any given node might be slow. However, the full transaction fee is charged for each transaction, so the total fee is N times as much if the transaction is sent to N nodes.
| Field |
Type |
Description |
| transactionValidStart |
Timestamp |
The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| accountID |
AccountID |
The Account ID that paid for this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
|
| transactionGetRecord |
TransactionGetRecordQuery |
Get a record for a transaction (lasts 1 hour) |
| |
Get the record for a transaction. If the transaction requested a record, then the record lasts for one hour, and a state proof is available for it. If the transaction created an account, file, or smart contract instance, then the record will contain the ID for what it created. If the transaction called a smart contract function, then the record contains the result of that call. If the transaction was a cryptocurrency transfer, then the record includes the TransferList which gives the details of that transfer. If the transaction didn't return anything that should be in the record, then the results field will be set to nothing.
| Field |
Type |
Description |
| header |
QueryHeader |
Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). |
| |
Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for.
| Field |
Type |
Description |
| payment |
Transaction |
A signed CryptoTransferTransaction to pay the node a fee for handling this query |
| |
A single signed transaction, including all its signatures. The SignatureList will have a Signature for each Key in the transaction, either explicit or implicit, in the order that they appear in the transaction. For example, a CryptoTransfer will first have a Signature corresponding to the Key for the paying account, followed by a Signature corresponding to the Key for each account that is sending or receiving cryptocurrency in the transfer. Each Transaction should not have more than 50 levels.
| Field |
Type |
Description |
| bodyData |
oneof |
|
| |
| Field |
Type |
Description |
| body |
TransactionBody |
the body of the transaction, which needs to be signed |
| |
A single transaction. All transaction types are possible here.
| Field |
Type |
Description |
| transactionID |
TransactionID |
The ID for this transaction, which includes the payer's account (the account paying the transaction fee). If two transactions have the same transactionID, they won't both have an effect |
| |
The ID for a transaction. This is used for retrieving receipts and records for a transaction, for appending to a file right after creating it, for instantiating a smart contract with bytecode in a file just created, and internally by the network for detecting when duplicate transactions are submitted. A user might get a transaction processed faster by submitting it to N 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 will not take effect. So this could make the transaction take effect faster, if any given node might be slow. However, the full transaction fee is charged for each transaction, so the total fee is N times as much if the transaction is sent to N nodes.
| Field |
Type |
Description |
| transactionValidStart |
Timestamp |
The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| accountID |
AccountID |
The Account ID that paid for this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| nodeAccountID |
AccountID |
The account of the node that submits the client's transaction to the network |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transactionFee |
uint64 |
The maximum transaction fee the client is willing to pay, which is split between the network and the node |
| transactionValidDuration |
Duration |
The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| generateRecord |
bool |
Should a record of this transaction be generated? (A receipt is always generated, but the record is optional) |
| memo |
string |
Any notes or descriptions that should be put into the record (max length 100) |
| data |
oneof |
|
| |
| Field |
Type |
Description |
| contractCall |
ContractCallTransactionBody |
Contains the call a function of a contract instance |
| |
Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.
| Field |
Type |
Description |
| contractID |
ContractID |
the contract instance to call, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| gas |
int64 |
the maximum amount of gas to use for the call |
| amount |
int64 |
number of tinybars sent (the function must be payable if this is nonzero) |
| functionParameters |
bytes |
which function to call, and the parameters to pass to the function |
|
| contractCreateInstance |
ContractCreateTransactionBody |
Contains the create data a contract instance |
| |
Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.
| Field |
Type |
Description |
| fileID |
FileID |
the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| adminKey |
Key |
the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| gas |
int64 |
gas to run the constructor |
| initialBalance |
int64 |
initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
the instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| constructorParameters |
bytes |
parameters to pass to the constructor |
| shardID |
ShardID |
shard in which to create this |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
realm in which to create this (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
if realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| memo |
string |
the memo that was submitted as part of the contract (max 100 bytes) |
|
| contractUpdateInstance |
ContractUpdateTransactionBody |
Contains contract modify info such as expiration date for a contract instance |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to update (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| expirationTime |
Timestamp |
Extend the expiration of the instance and its account to this time (no effect if it already is this time or later) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| adminKey |
Key |
The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
The instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| fileID |
FileID |
The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| memo |
string |
The memo associated with the contract (max 100 bytes) |
|
| contractDeleteInstance |
ContractDeleteTransactionBody |
Delete contract and transfer remaining balance into specified account |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to delete (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| obtainers |
oneof |
|
| |
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transferContractID |
ContractID |
The contract ID which will receive all remaining hbars |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| cryptoAddClaim |
CryptoAddClaimTransactionBody |
Attach a new claim to an account |
| |
Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.
| Field |
Type |
Description |
| claim |
Claim |
A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it |
| |
A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet.
| Field |
Type |
Description |
| accountID |
AccountID |
the account to which the claim is attached |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hash |
bytes |
48 byte SHA-384 hash (presumably of some kind of credential or certificate) |
| keys |
KeyList |
list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys). |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| claimDuration |
Duration |
the duration for which the claim will remain valid |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
|
|
| cryptoCreateAccount |
CryptoCreateTransactionBody |
Create a new cryptocurrency account |
| |
Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency for each record generated, so the thresholds are useful for limiting Record generation to happen only for large transactions. The Key field is the key used to sign transactions for this account. If the account has receiverSigRequired set to true, then all cryptocurrency transfers must be signed by this account's key, both for transfers in and out. If it is false, then only transfers out have to be signed by it. When the account is created, the payer account is charged enough hbars so that the new account will not expire for the next autoRenewPeriod seconds. When it reaches the expiration time, the new account will then be automatically charged to renew for another autoRenewPeriod seconds. If it does not have enough hbars to renew for that long, then the remaining hbars are used to extend its expiration as long as possible. If it is has a zero balance when it expires, then it is deleted. This transaction must be signed by the payer account. If receiverSigRequired is false, then the transaction does not have to be signed by the keys in the keys field. If it is true, then it must be signed by them, in addition to the keys of the payer account.
| Field |
Type |
Description |
| key |
Key |
The key that must sign each transfer out of the account. If receiverSigRequired is true, then it must also sign any transfer into the account. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| initialBalance |
uint64 |
The initial number of tinybars to put into the account |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| sendRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| receiveRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction |
| receiverSigRequired |
bool |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
| autoRenewPeriod |
Duration |
The account is charged to extend its expiration date every this many seconds. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| shardID |
ShardID |
The shard in which this account is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The realm in which this account is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| cryptoDelete |
CryptoDeleteTransactionBody |
Delete a cryptocurrency account (mark as deleted, and transfer hbars out) |
| |
Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way.
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| deleteAccountID |
AccountID |
The account ID which should be deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| cryptoDeleteClaim |
CryptoDeleteClaimTransactionBody |
Remove a claim from an account |
| |
Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes.
| Field |
Type |
Description |
| accountIDToDeleteFrom |
AccountID |
The account ID that should have a claim deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hashToDelete |
bytes |
The hash in the claim to delete (a SHA-384 hash, 48 bytes) |
|
| cryptoTransfer |
CryptoTransferTransactionBody |
Transfer amount between accounts |
| |
Transfer cryptocurrency from some accounts to other accounts. The accounts list can contain up to 10 accounts. The amounts list must be the same length as the accounts list. Each negative amount is withdrawn from the corresponding account (a sender), and each positive one is added to the corresponding account (a receiver). The amounts list must sum to zero. Each amount is a number of tinyBars (there are 100,000,000 tinyBars in one Hbar). If any sender account fails to have sufficient hbars to do the withdrawal, then the entire transaction fails, and none of those transfers occur, though the transaction fee is still charged. This transaction must be signed by the keys for all the sending accounts, and for any receiving accounts that have receiverSigRequired == true. The signatures are in the same order as the accounts, skipping those accounts that don't need a signature.
| Field |
Type |
Description |
| transfers |
TransferList |
Accounts and amounts to transfer |
| |
A list of accounts and amounts to transfer out of each account (negative) or into it (positive).
| Field |
Type |
Description |
| accountAmounts |
AccountAmount (repeated) |
Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative) |
| |
An account, and the amount that it sends or receives during a cryptocurrency transfer.
| Field |
Type |
Description |
| accountID |
AccountID |
The Account ID that sends or receives cryptocurrency |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| amount |
sint64 |
The amount of tinybars that the account sends(negative) or receives(positive) |
|
|
|
| cryptoUpdateAccount |
CryptoUpdateTransactionBody |
Modify information such as the expiration date for an account |
| |
Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account.
| Field |
Type |
Description |
| accountIDToUpdate |
AccountID |
The account ID which is being updated in this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| key |
Key |
The new key |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| proxyFraction |
int32 |
[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account |
| sendRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| sendRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| sendRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
|
| receiveRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| receiveRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
| receiveRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
|
| autoRenewPeriod |
Duration |
The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| expirationTime |
Timestamp |
The new expiration time to extend to (ignored if equal to or before the current one) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| receiverSigRequiredField |
oneof |
|
| |
| Field |
Type |
Description |
| receiverSigRequired |
bool |
[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose. |
| receiverSigRequiredWrapper |
google.protobuf.BoolValue |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
|
|
| fileAppend |
FileAppendTransactionBody |
Add bytes to the end of the contents of a file |
| |
Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to which the bytes are appended to |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contents |
bytes |
The bytes to append to the contents of the file |
|
| fileCreate |
FileCreateTransactionBody |
Create a new file |
| |
Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.
| Field |
Type |
Description |
| expirationTime |
Timestamp |
The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
All these keys must sign to create or modify the file. Any one of them can sign to delete the file. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The bytes that are the contents of the file |
| shardID |
ShardID |
Shard in which this file is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The Realm in which to the file is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| fileDelete |
FileDeleteTransactionBody |
Delete a file (remove contents and mark as deleted until it expires) |
| |
Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys).
| Field |
Type |
Description |
| fileID |
FileID |
The file to delete. It will be marked as deleted until it expires. Then it will disappear. |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
|
| fileUpdate |
FileUpdateTransactionBody |
Modify information such as the expiration date for a file |
| |
Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to update |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| expirationTime |
Timestamp |
The new time at which it should expire (ignored if not later than the current value) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
The keys that can modify or delete the file |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The new file contents. All the bytes in the old contents are discarded. |
|
| systemDelete |
SystemDeleteTransactionBody |
Hedera multisig system deletes a file or smart contract |
| |
Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to delete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to delete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
| expirationTime |
TimestampSeconds |
The timestamp in seconds at which the "deleted" file should truly be permanently deleted |
| |
An exact date and time, with a resolution of one second (no nanoseconds).
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
|
|
| systemUndelete |
SystemUndeleteTransactionBody |
To undelete an entity deleted by SystemDelete |
| |
Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID to undelete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to undelete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| freeze |
FreezeTransactionBody |
Freeze the nodes |
| |
Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance.
| Field |
Type |
Description |
| startHour |
int32 |
The start hour (in UTC time), a value between 0 and 23 |
| startMin |
int32 |
The start minute (in UTC time), a value between 0 and 59 |
| endHour |
int32 |
The end hour (in UTC time), a value between 0 and 23 |
| endMin |
int32 |
The end minute (in UTC time), a value between 0 and 59 |
|
| consensusCreateTopic |
ConsensusCreateTopicTransactionBody |
|
| consensusUpdateTopic |
ConsensusUpdateTopicTransactionBody |
|
| consensusDeleteTopic |
ConsensusDeleteTopicTransactionBody |
|
| consensusSubmitMessage |
ConsensusSubmitMessageTransactionBody |
|
| |
| Field |
Type |
Description |
| topicID |
TopicID |
Topic to submit message to. |
| |
Unique identifier for a topic (used by the consensus service)
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| topicNum |
int64 |
Unique topic identifier within a realm (nonnegative). |
|
| message |
bytes |
Message to be submitted. Max size of the Transaction (including signatures) is 4kB. |
|
|
|
| bodyBytes |
bytes |
TransactionBody serialized into bytes , which needs to be signed |
|
| sigs |
SignatureList |
The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field |
| |
The signatures corresponding to a KeyList of the same length.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
Signature (repeated) |
each signature corresponds to a Key in the KeyList |
| |
A Signature corresponding to a Key. It is a sequence of bytes holding a public key signature from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be a list of signatures corresponding to a single threshold key. Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. If it has a smart contract ID associated with it, then that smart contract is allowed to transfer cryptocurrency out of it. The smart contract doesn't actually have a key, and doesn't actually sign a transaction. But it's as if a virtual transaction were created, and the smart contract signed it with a private key. A key can also be a "threshold key", which means a list of M keys, any N of which must sign in order for the threshold signature to be considered valid. The keys within a threshold signature may themselves be threshold signatures, to allow complex signature requirements (this nesting is not supported in the currently, but will be supported in a future version of API). If a Signature message is missing the "signature" field, then this is considered to be a null signature. That is useful in cases such as threshold signatures, where some of the signatures can be null.
| Field |
Type |
Description |
| deprecated |
option |
|
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature bytes |
| RSA_3072 |
bytes |
RSA-3072 signature bytes |
| ECDSA_384 |
bytes |
ECDSA p-384 signature bytes |
| thresholdSignature |
ThresholdSignature |
A list of signatures for a single N-of-M threshold Key. This must be a list of exactly M signatures, at least N of which are non-null. |
| |
A signature corresponding to a ThresholdKey. For an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
SignatureList |
for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null |
| |
Self Reference
|
|
| signatureList |
SignatureList |
A list of M signatures, each corresponding to a Key in a KeyList of the same length. |
| |
Self Reference
|
|
|
|
| sigMap |
SignatureMap |
The signatures on the body with the new format, to authorize the transaction |
| |
A set of signatures corresponding to every unique public key used to sign a given transaction.
| Field |
Type |
Description |
| sigPair |
SignaturePair (repeated) |
Each signature pair corresponds to a unique Key required to sign the transaction. |
| |
The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.
| Field |
Type |
Description |
| pubKeyPrefix |
bytes |
First few bytes of the public key |
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature |
| RSA_3072 |
bytes |
RSA-3072 signature |
| ECDSA_384 |
bytes |
ECDSA p-384 signature |
|
|
|
|
| responseType |
ResponseType |
The requested response, asking for cost, state proof, both, or neither |
| |
The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request.
| Enum Name |
Description |
| ANSWER_ONLY |
Response returns answer |
| ANSWER_STATE_PROOF |
Response returns both answer and state proof |
| COST_ANSWER |
Response returns the cost of answer |
| COST_ANSWER_STATE_PROOF |
Response returns the total cost of answer and state proof |
|
|
| transactionID |
TransactionID |
The ID of the transaction for which the record is requested. |
| |
The ID for a transaction. This is used for retrieving receipts and records for a transaction, for appending to a file right after creating it, for instantiating a smart contract with bytecode in a file just created, and internally by the network for detecting when duplicate transactions are submitted. A user might get a transaction processed faster by submitting it to N 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 will not take effect. So this could make the transaction take effect faster, if any given node might be slow. However, the full transaction fee is charged for each transaction, so the total fee is N times as much if the transaction is sent to N nodes.
| Field |
Type |
Description |
| transactionValidStart |
Timestamp |
The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| accountID |
AccountID |
The Account ID that paid for this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
|
| transactionGetFastRecord |
TransactionGetFastRecordQuery |
Get a record for a transaction (lasts 180 seconds) |
| |
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. This query is free (the payment field is left empty).
| Field |
Type |
Description |
| header |
QueryHeader |
Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). |
| |
Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for.
| Field |
Type |
Description |
| payment |
Transaction |
A signed CryptoTransferTransaction to pay the node a fee for handling this query |
| |
A single signed transaction, including all its signatures. The SignatureList will have a Signature for each Key in the transaction, either explicit or implicit, in the order that they appear in the transaction. For example, a CryptoTransfer will first have a Signature corresponding to the Key for the paying account, followed by a Signature corresponding to the Key for each account that is sending or receiving cryptocurrency in the transfer. Each Transaction should not have more than 50 levels.
| Field |
Type |
Description |
| bodyData |
oneof |
|
| |
| Field |
Type |
Description |
| body |
TransactionBody |
the body of the transaction, which needs to be signed |
| |
A single transaction. All transaction types are possible here.
| Field |
Type |
Description |
| transactionID |
TransactionID |
The ID for this transaction, which includes the payer's account (the account paying the transaction fee). If two transactions have the same transactionID, they won't both have an effect |
| |
The ID for a transaction. This is used for retrieving receipts and records for a transaction, for appending to a file right after creating it, for instantiating a smart contract with bytecode in a file just created, and internally by the network for detecting when duplicate transactions are submitted. A user might get a transaction processed faster by submitting it to N 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 will not take effect. So this could make the transaction take effect faster, if any given node might be slow. However, the full transaction fee is charged for each transaction, so the total fee is N times as much if the transaction is sent to N nodes.
| Field |
Type |
Description |
| transactionValidStart |
Timestamp |
The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| accountID |
AccountID |
The Account ID that paid for this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| nodeAccountID |
AccountID |
The account of the node that submits the client's transaction to the network |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transactionFee |
uint64 |
The maximum transaction fee the client is willing to pay, which is split between the network and the node |
| transactionValidDuration |
Duration |
The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| generateRecord |
bool |
Should a record of this transaction be generated? (A receipt is always generated, but the record is optional) |
| memo |
string |
Any notes or descriptions that should be put into the record (max length 100) |
| data |
oneof |
|
| |
| Field |
Type |
Description |
| contractCall |
ContractCallTransactionBody |
Contains the call a function of a contract instance |
| |
Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.
| Field |
Type |
Description |
| contractID |
ContractID |
the contract instance to call, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| gas |
int64 |
the maximum amount of gas to use for the call |
| amount |
int64 |
number of tinybars sent (the function must be payable if this is nonzero) |
| functionParameters |
bytes |
which function to call, and the parameters to pass to the function |
|
| contractCreateInstance |
ContractCreateTransactionBody |
Contains the create data a contract instance |
| |
Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.
| Field |
Type |
Description |
| fileID |
FileID |
the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| adminKey |
Key |
the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| gas |
int64 |
gas to run the constructor |
| initialBalance |
int64 |
initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
the instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| constructorParameters |
bytes |
parameters to pass to the constructor |
| shardID |
ShardID |
shard in which to create this |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
realm in which to create this (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
if realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| memo |
string |
the memo that was submitted as part of the contract (max 100 bytes) |
|
| contractUpdateInstance |
ContractUpdateTransactionBody |
Contains contract modify info such as expiration date for a contract instance |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to update (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| expirationTime |
Timestamp |
Extend the expiration of the instance and its account to this time (no effect if it already is this time or later) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| adminKey |
Key |
The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| autoRenewPeriod |
Duration |
The instance will charge its account every this many seconds to renew for this long |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| fileID |
FileID |
The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| memo |
string |
The memo associated with the contract (max 100 bytes) |
|
| contractDeleteInstance |
ContractDeleteTransactionBody |
Delete contract and transfer remaining balance into specified account |
| |
Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable.
| Field |
Type |
Description |
| contractID |
ContractID |
The Contract ID instance to delete (this can't be changed) |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| obtainers |
oneof |
|
| |
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| transferContractID |
ContractID |
The contract ID which will receive all remaining hbars |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| cryptoAddClaim |
CryptoAddClaimTransactionBody |
Attach a new claim to an account |
| |
Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.
| Field |
Type |
Description |
| claim |
Claim |
A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it |
| |
A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet.
| Field |
Type |
Description |
| accountID |
AccountID |
the account to which the claim is attached |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hash |
bytes |
48 byte SHA-384 hash (presumably of some kind of credential or certificate) |
| keys |
KeyList |
list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys). |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| claimDuration |
Duration |
the duration for which the claim will remain valid |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
|
|
| cryptoCreateAccount |
CryptoCreateTransactionBody |
Create a new cryptocurrency account |
| |
Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency for each record generated, so the thresholds are useful for limiting Record generation to happen only for large transactions. The Key field is the key used to sign transactions for this account. If the account has receiverSigRequired set to true, then all cryptocurrency transfers must be signed by this account's key, both for transfers in and out. If it is false, then only transfers out have to be signed by it. When the account is created, the payer account is charged enough hbars so that the new account will not expire for the next autoRenewPeriod seconds. When it reaches the expiration time, the new account will then be automatically charged to renew for another autoRenewPeriod seconds. If it does not have enough hbars to renew for that long, then the remaining hbars are used to extend its expiration as long as possible. If it is has a zero balance when it expires, then it is deleted. This transaction must be signed by the payer account. If receiverSigRequired is false, then the transaction does not have to be signed by the keys in the keys field. If it is true, then it must be signed by them, in addition to the keys of the payer account.
| Field |
Type |
Description |
| key |
Key |
The key that must sign each transfer out of the account. If receiverSigRequired is true, then it must also sign any transfer into the account. |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| initialBalance |
uint64 |
The initial number of tinybars to put into the account |
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| sendRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| receiveRecordThreshold |
uint64 |
The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction |
| receiverSigRequired |
bool |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
| autoRenewPeriod |
Duration |
The account is charged to extend its expiration date every this many seconds. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| shardID |
ShardID |
The shard in which this account is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The realm in which this account is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| cryptoDelete |
CryptoDeleteTransactionBody |
Delete a cryptocurrency account (mark as deleted, and transfer hbars out) |
| |
Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way.
| Field |
Type |
Description |
| transferAccountID |
AccountID |
The account ID which will receive all remaining hbars |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| deleteAccountID |
AccountID |
The account ID which should be deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
| cryptoDeleteClaim |
CryptoDeleteClaimTransactionBody |
Remove a claim from an account |
| |
Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes.
| Field |
Type |
Description |
| accountIDToDeleteFrom |
AccountID |
The account ID that should have a claim deleted |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| hashToDelete |
bytes |
The hash in the claim to delete (a SHA-384 hash, 48 bytes) |
|
| cryptoTransfer |
CryptoTransferTransactionBody |
Transfer amount between accounts |
| |
Transfer cryptocurrency from some accounts to other accounts. The accounts list can contain up to 10 accounts. The amounts list must be the same length as the accounts list. Each negative amount is withdrawn from the corresponding account (a sender), and each positive one is added to the corresponding account (a receiver). The amounts list must sum to zero. Each amount is a number of tinyBars (there are 100,000,000 tinyBars in one Hbar). If any sender account fails to have sufficient hbars to do the withdrawal, then the entire transaction fails, and none of those transfers occur, though the transaction fee is still charged. This transaction must be signed by the keys for all the sending accounts, and for any receiving accounts that have receiverSigRequired == true. The signatures are in the same order as the accounts, skipping those accounts that don't need a signature.
| Field |
Type |
Description |
| transfers |
TransferList |
Accounts and amounts to transfer |
| |
A list of accounts and amounts to transfer out of each account (negative) or into it (positive).
| Field |
Type |
Description |
| accountAmounts |
AccountAmount (repeated) |
Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative) |
| |
An account, and the amount that it sends or receives during a cryptocurrency transfer.
| Field |
Type |
Description |
| accountID |
AccountID |
The Account ID that sends or receives cryptocurrency |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| amount |
sint64 |
The amount of tinybars that the account sends(negative) or receives(positive) |
|
|
|
| cryptoUpdateAccount |
CryptoUpdateTransactionBody |
Modify information such as the expiration date for an account |
| |
Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account.
| Field |
Type |
Description |
| accountIDToUpdate |
AccountID |
The account ID which is being updated in this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| key |
Key |
The new key |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
| proxyAccountID |
AccountID |
ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null. |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
| proxyFraction |
int32 |
[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account |
| sendRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| sendRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
| sendRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction |
|
| receiveRecordThresholdField |
oneof |
|
| |
| Field |
Type |
Description |
| receiveRecordThreshold |
uint64 |
[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
| receiveRecordThresholdWrapper |
google.protobuf.UInt64Value |
The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. |
|
| autoRenewPeriod |
Duration |
The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. |
| |
The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto)
| Field |
Type |
Description |
| seconds |
int64 |
number of seconds |
|
| expirationTime |
Timestamp |
The new expiration time to extend to (ignored if equal to or before the current one) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| receiverSigRequiredField |
oneof |
|
| |
| Field |
Type |
Description |
| receiverSigRequired |
bool |
[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose. |
| receiverSigRequiredWrapper |
google.protobuf.BoolValue |
If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) |
|
|
| fileAppend |
FileAppendTransactionBody |
Add bytes to the end of the contents of a file |
| |
Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to which the bytes are appended to |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contents |
bytes |
The bytes to append to the contents of the file |
|
| fileCreate |
FileCreateTransactionBody |
Create a new file |
| |
Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.
| Field |
Type |
Description |
| expirationTime |
Timestamp |
The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
All these keys must sign to create or modify the file. Any one of them can sign to delete the file. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The bytes that are the contents of the file |
| shardID |
ShardID |
Shard in which this file is created |
| |
Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1 within shard 0. Each realm maintains a single counter for assigning numbers, so if there is a file with ID 0.1.2, then there won't be an account or smart contract instance with ID 0.1.2.
| Field |
Type |
Description |
| shardNum |
int64 |
the shard number (nonnegative) |
|
| realmID |
RealmID |
The Realm in which to the file is created (leave this null to create a new realm) |
| |
The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm.
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
|
| newRealmAdminKey |
Key |
If realmID is null, then this the admin key for the new realm that will be created |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
Self Reference
|
|
|
|
|
| fileDelete |
FileDeleteTransactionBody |
Delete a file (remove contents and mark as deleted until it expires) |
| |
Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys).
| Field |
Type |
Description |
| fileID |
FileID |
The file to delete. It will be marked as deleted until it expires. Then it will disappear. |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
|
| fileUpdate |
FileUpdateTransactionBody |
Modify information such as the expiration date for a file |
| |
Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to update |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| expirationTime |
Timestamp |
The new time at which it should expire (ignored if not later than the current value) |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| keys |
KeyList |
The keys that can modify or delete the file |
| |
A list of keys
| Field |
Type |
Description |
| keys |
Key (repeated) |
list of keys |
| |
A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
| Field |
Type |
Description |
| key |
oneof |
|
| |
| Field |
Type |
Description |
| contractID |
ContractID |
smart contract instance that is authorized as if it had signed with a key |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
| ed25519 |
bytes |
ed25519 public key bytes |
| RSA_3072 |
bytes |
RSA-3072 public key bytes |
| ECDSA_384 |
bytes |
ECDSA with the p-384 curve public key bytes |
| thresholdKey |
ThresholdKey |
a threshold N followed by a list of M keys, any N of which are required to form a valid signature |
| |
A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here.
| Field |
Type |
Description |
| threshold |
uint32 |
A valid signature set must have at least this many signatures |
| keys |
KeyList |
List of all the keys that can sign |
| |
Self Reference
|
|
| keyList |
KeyList |
A list of Keys of the Key type. |
| |
Self Reference
|
|
|
|
| contents |
bytes |
The new file contents. All the bytes in the old contents are discarded. |
|
| systemDelete |
SystemDeleteTransactionBody |
Hedera multisig system deletes a file or smart contract |
| |
Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID of the file to delete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to delete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
| expirationTime |
TimestampSeconds |
The timestamp in seconds at which the "deleted" file should truly be permanently deleted |
| |
An exact date and time, with a resolution of one second (no nanoseconds).
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
|
|
| systemUndelete |
SystemUndeleteTransactionBody |
To undelete an entity deleted by SystemDelete |
| |
Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here.
| Field |
Type |
Description |
| id |
oneof |
|
| |
| Field |
Type |
Description |
| fileID |
FileID |
The file ID to undelete, in the format used in transactions |
| |
The ID for a file
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| fileNum |
int64 |
A nonnegative File number unique within its realm |
|
| contractID |
ContractID |
The contract ID instance to undelete, in the format used in transactions |
| |
The ID for a smart contract instance
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| contractNum |
int64 |
A nonnegative number unique within its realm |
|
|
|
| freeze |
FreezeTransactionBody |
Freeze the nodes |
| |
Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance.
| Field |
Type |
Description |
| startHour |
int32 |
The start hour (in UTC time), a value between 0 and 23 |
| startMin |
int32 |
The start minute (in UTC time), a value between 0 and 59 |
| endHour |
int32 |
The end hour (in UTC time), a value between 0 and 23 |
| endMin |
int32 |
The end minute (in UTC time), a value between 0 and 59 |
|
| consensusCreateTopic |
ConsensusCreateTopicTransactionBody |
|
| consensusUpdateTopic |
ConsensusUpdateTopicTransactionBody |
|
| consensusDeleteTopic |
ConsensusDeleteTopicTransactionBody |
|
| consensusSubmitMessage |
ConsensusSubmitMessageTransactionBody |
|
| |
| Field |
Type |
Description |
| topicID |
TopicID |
Topic to submit message to. |
| |
Unique identifier for a topic (used by the consensus service)
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| topicNum |
int64 |
Unique topic identifier within a realm (nonnegative). |
|
| message |
bytes |
Message to be submitted. Max size of the Transaction (including signatures) is 4kB. |
|
|
|
| bodyBytes |
bytes |
TransactionBody serialized into bytes , which needs to be signed |
|
| sigs |
SignatureList |
The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field |
| |
The signatures corresponding to a KeyList of the same length.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
Signature (repeated) |
each signature corresponds to a Key in the KeyList |
| |
A Signature corresponding to a Key. It is a sequence of bytes holding a public key signature from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be a list of signatures corresponding to a single threshold key. Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. If it has a smart contract ID associated with it, then that smart contract is allowed to transfer cryptocurrency out of it. The smart contract doesn't actually have a key, and doesn't actually sign a transaction. But it's as if a virtual transaction were created, and the smart contract signed it with a private key. A key can also be a "threshold key", which means a list of M keys, any N of which must sign in order for the threshold signature to be considered valid. The keys within a threshold signature may themselves be threshold signatures, to allow complex signature requirements (this nesting is not supported in the currently, but will be supported in a future version of API). If a Signature message is missing the "signature" field, then this is considered to be a null signature. That is useful in cases such as threshold signatures, where some of the signatures can be null.
| Field |
Type |
Description |
| deprecated |
option |
|
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature bytes |
| RSA_3072 |
bytes |
RSA-3072 signature bytes |
| ECDSA_384 |
bytes |
ECDSA p-384 signature bytes |
| thresholdSignature |
ThresholdSignature |
A list of signatures for a single N-of-M threshold Key. This must be a list of exactly M signatures, at least N of which are non-null. |
| |
A signature corresponding to a ThresholdKey. For an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null.
| Field |
Type |
Description |
| deprecated |
option |
|
| sigs |
SignatureList |
for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null |
| |
Self Reference
|
|
| signatureList |
SignatureList |
A list of M signatures, each corresponding to a Key in a KeyList of the same length. |
| |
Self Reference
|
|
|
|
| sigMap |
SignatureMap |
The signatures on the body with the new format, to authorize the transaction |
| |
A set of signatures corresponding to every unique public key used to sign a given transaction.
| Field |
Type |
Description |
| sigPair |
SignaturePair (repeated) |
Each signature pair corresponds to a unique Key required to sign the transaction. |
| |
The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.
| Field |
Type |
Description |
| pubKeyPrefix |
bytes |
First few bytes of the public key |
| signature |
oneof |
|
| |
| Field |
Type |
Description |
| contract |
bytes |
smart contract virtual signature (always length zero) |
| ed25519 |
bytes |
ed25519 signature |
| RSA_3072 |
bytes |
RSA-3072 signature |
| ECDSA_384 |
bytes |
ECDSA p-384 signature |
|
|
|
|
| responseType |
ResponseType |
The requested response, asking for cost, state proof, both, or neither |
| |
The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request.
| Enum Name |
Description |
| ANSWER_ONLY |
Response returns answer |
| ANSWER_STATE_PROOF |
Response returns both answer and state proof |
| COST_ANSWER |
Response returns the cost of answer |
| COST_ANSWER_STATE_PROOF |
Response returns the total cost of answer and state proof |
|
|
| transactionID |
TransactionID |
The ID of the transaction for which the record is requested. |
| |
The ID for a transaction. This is used for retrieving receipts and records for a transaction, for appending to a file right after creating it, for instantiating a smart contract with bytecode in a file just created, and internally by the network for detecting when duplicate transactions are submitted. A user might get a transaction processed faster by submitting it to N 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 will not take effect. So this could make the transaction take effect faster, if any given node might be slow. However, the full transaction fee is charged for each transaction, so the total fee is N times as much if the transaction is sent to N nodes.
| Field |
Type |
Description |
| transactionValidStart |
Timestamp |
The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid |
| |
An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto)
| Field |
Type |
Description |
| seconds |
int64 |
Number of complete seconds since the start of the epoch |
| nanos |
int32 |
Number of nanoseconds since the start of the last second |
|
| accountID |
AccountID |
The Account ID that paid for this transaction |
| |
The ID for an a cryptocurrency account
| Field |
Type |
Description |
| shardNum |
int64 |
The shard number (nonnegative) |
| realmNum |
int64 |
The realm number (nonnegative) |
| accountNum |
int64 |
A nonnegative account number unique within its realm |
|
|
|
| consensusGetTopicInfo |
ConsensusGetTopicInfoQuery |
Get the parameters of and state of a consensus topic. |
|