Transaction

Overview

A blockchain transaction contains fields defined by the target protocol. Common elements include sender or inputs, destination or outputs, asset value, fee parameters, nonce or sequence, network identifier, call data, and signatures. Some networks also support multiple signers, account lists, or batched instructions.

The transaction first reaches a node, sequencer, or private relay. The receiving service checks basic validity and may place it in a transaction pool. A producer selects it for a block according to fee, priority, ordering, and capacity rules.

Execution determines the actual result. A native transfer may update balances directly, while a smart-contract transaction can generate internal calls, token events, or a revert. Fees may still be charged when execution fails.

After inclusion, confirmation and finality reduce reversal risk. Applications should store the transaction identifier, block hash, execution status, asset movements, and confirmation state. A successful API submission response proves only that a provider accepted the request.

Transactions are protocol objects, while payments and orders are business objects. One transaction can contain multiple transfers, and one payment can require several transactions. Reliable systems keep the technical transaction linked to its intended business context without treating them as identical.

Transaction construction should be deterministic and reviewable. Applications should use integer base units, preserve chain identifiers, and avoid floating-point amounts. The signed bytes should be stored or reproducible from the approved transaction object. Recovery logic must also distinguish rebroadcasting the same signed transaction from creating a new replacement. These controls prevent silent changes in amount, fee, recipient, or nonce during retries and provider failover.