Confirmed Transaction

Overview

A Confirmed Transaction has moved beyond pending broadcast and appears in canonical blockchain data. The system should identify the block hash, height or slot, transaction status, and current confirmation evidence.

Some interfaces call a transaction confirmed after the first block, while payment providers can require several blocks. Documentation should state whether confirmed means one inclusion or completion of Required Block Confirmations.

Execution success matters. An EVM transaction can be included and consume fees while reverting, so block inclusion alone does not establish a successful token payment or contract action.

Confirmation also does not establish business correctness. The transaction can send the wrong asset, amount, destination, or reference. Payment matching and Payment Finality are separate evaluations.

Records should avoid collapsing pending, included, confirmed, and finalized into one status. Clear stages improve customer communication and make exceptional reorganization or provider disagreement easier to handle.

A transaction can have several confirmation views at once. One provider may see it in the latest block, another may lag, and the merchant may still require more depth. Records should identify the source and threshold behind every confirmed label. This prevents support teams from comparing two statuses that use different definitions.

Customer-facing confirmation should include the asset and network, not only a green status. This prevents a deeply confirmed transfer on an unintended chain from appearing equivalent to the payment requested by the merchant.

APIs should return the threshold and evidence behind the label instead of exposing a bare confirmed boolean with unknown semantics.

Where several transaction versions exist, the confirmed record must identify which exact hash entered the canonical chain.