On-Chain Transaction

Overview

An on-chain transaction is a protocol-recognized object that enters the network’s transaction pipeline. A sender creates and usually signs the transaction, broadcasts its Serialized Transaction bytes, and waits for a block producer to include it. Nodes verify its format, authorization, nonce or input references, fee conditions, and other consensus rules before accepting it into a block or local transaction pool.

After inclusion, the chain executes or applies the transaction according to its state-transition rules. Account-based networks may update balances, storage, and contract state, while UTXO-based networks consume previous outputs and create new ones. A transaction can be included yet fail at execution, revert a contract call, or produce a status that differs from the user’s intended business outcome. The Transaction Result must therefore be checked separately from block inclusion.

On-chain processing provides a shared, independently verifiable record, but it also exposes users to network fees, block capacity, confirmation delay, and public metadata. The level of certainty increases from broadcast to inclusion, then through Block Confirmation and the network’s finality process. Proof-of-work systems may use accumulated confirmations, while proof-of-stake systems can provide explicit finalized checkpoints.

Payment applications should store the transaction identifier, chain and network, sender and recipient, asset, amount, block reference, execution status, and confirmation state. They should also handle replacement, reorganization, and duplicate-notification scenarios. An on-chain transaction should be considered operationally complete only when it has succeeded and reached the confirmation or Finalized Transaction threshold required by the merchant’s risk policy.

For dependable operation, store the submitted bytes, transaction identifier, execution receipt, block reference, and finality state. This information is valuable because broadcast, inclusion, successful execution, and settlement are separate milestones. Monitoring and response procedures should alert on replacements, reorg removal, execution failure, and delayed finalization.