Transaction Properties

Transaction properties on Hedera define the characteristics, behavior, and content of transactions on the network. These properties are set during transaction creation and determine how transactions are processed, validated, and applied to the network state.

Property	Description
Transaction ID	The unique identifier for a transaction on the Hedera network. The transaction ID is composed of the account ID of the account paying for the transaction and the transaction's valid start time. Format: accountID@validStartTime Example: 0.0.9401@1598924675.82525000 For child transactions in nested transactions, a nonce value is added: Format: accountID@validStartTime/nonce Example: 0.0.2252@1640119571.329880313/1
Node Account ID	The account of the node the transaction is being sent to. Format: <shardNum>.<realmNum>.<accountNum> Example: 0.0.3 For batch transactions, the node account ID of inner transactions must be set to 0.0.0 to indicate they are part of a batch.
Transaction Fee	The maximum fee the paying account is willing to pay for the transaction. This is an upper bound, and the actual fee charged may be less. The transaction fee consists of: - Node fee: Paid to the node processing the transaction - Network fee: Paid to the network for processing the transaction - Service fee: Paid for the specific service being used For batch transactions, the fee structure is: - The outer batch transaction has its own fee (node + network) - Each inner transaction pays its own fee (node + network + service) - Inner transactions are charged even if the batch fails
Valid Duration	The number of seconds that the client wishes the transaction to be deemed valid for, starting at the transaction's valid start time. Transactions have a valid duration of up to 180 seconds. If the transaction is not accepted within this timeframe, it will expire and must be recreated.
Memo	A string of text that can be included with a transaction. Limited to 100 bytes of UTF-8 encoded data. This field is optional and visible to all participants in the network.
Transaction Body	The specific operation to be performed. Only one operation type can be specified in a given transaction. The transaction body can contain one of the following operation types: - contractCall: Call a smart contract function - contractCreateInstance: Create a new smart contract instance - cryptoCreateAccount: Create a new cryptocurrency account - cryptoTransfer: Transfer cryptocurrency between accounts - fileCreate: Create a new file - consensusSubmitMessage: Submit a message to a topic - tokenCreation: Create a new token - atomicBatch: Execute multiple transactions atomically - And many others (over 40 different transaction types)
Batch Key	A property introduced in HIP-551 that must be set on inner transactions within a batch to ensure transaction integrity and prevent tampering. The batch key: - Signals the trusted signer who can finalize the batch - Ensures that batch transactions can only be submitted as a whole - Prevents malicious actors from tampering with a batch Required for all inner transactions in a batch. Must not be set on the outer batch transaction.
Signatures	Cryptographic proofs that authorize the transaction. Different transaction types may require different signatures: - The account paying for the transaction must always sign - For token operations, the token's admin key may need to sign - For account updates, the account's key must sign - For batch transactions, all batch keys must sign the outer transaction
Inner Transactions	For batch transactions, the list of transactions to be executed atomically. Inner transactions: - Are signed individually - Each pays for itself (node + network + service fees) - Have their own payer - Are deduplicated individually - Have scheduled = false and nonce = 0 - Cannot be batch transactions themselves - Must have nodeAccountID set to 0.0.0 - Must set batchKey
Transaction Valid Start	The timestamp at which the transaction begins to be valid. Format: Seconds.nanoseconds since the epoch Example: 1598924675.82525000 This timestamp is used as part of the transaction ID and can be set to a future date/time.
Generated Transaction ID	For child transactions in nested transactions, the transaction ID is generated with an additional nonce value. Parent Transaction ID: payerAccountId@transactionValidStart Child Transaction ID: payerAccountId@transactionValidStart/nonce Example: - Parent: 0.0.2252@1640119571.329880313 - Child 1: 0.0.2252@1640119571.329880313/1 - Child 2: 0.0.2252@1640119571.329880313/2
Consensus Timestamp	Generated by the network once consensus is reached; it reflects when the majority of nodes first received the transaction and is computed as the median of those times. This information is critical for record-keeping and audit trails.
Transaction Receipt	Produced after processing; it details the outcome (including status codes and new entity ids, if applicable) and confirms that consensus has been reached.
Transaction Hash	A unique digest (typically computed using sha-384) representing the finalized transaction content; useful for integrity verification.