Transaction Result

Overview

The transaction result describes what happened when the network processed a transaction. In smart-contract systems it may include a success status, error, gas or compute consumed, logs, return data, and references to the containing block. In UTXO systems, a valid included transaction generally applies its inputs and outputs, while invalid transactions are not included under normal consensus rules.

A transaction can be signed and included yet fail during execution. Contract logic can revert, resource limits can be exceeded, or an instruction can return an error. The sender may still pay fees even though the intended state change did not occur. Applications should therefore never equate a Block Confirmation or transaction hash with successful payment or contract completion.

The result can also contain transaction events that describe detailed activity, but logs must be interpreted in the context of overall success. A successful top-level transaction can call several contracts and produce effects that differ from a user’s expected outcome. Business validation may need to confirm asset, amount, recipient, and state changes in addition to the protocol status.

Systems should store raw receipt data, decoded errors, execution metrics, events, and finality status. Result polling and webhook processing must be idempotent, and reorganization handling must remove results from blocks that leave the canonical chain. A final business state should be assigned only after the transaction both succeeded and reached the organization’s required settlement threshold.

Audit and recovery workflows should preserve the raw receipt, status, consumed resources, decoded errors, events, block reference, and finality level. These records help because an included transaction may revert, partially affect related systems, or disappear during reorganization. Production safeguards need to assign a final business state only after validating both execution outcome and settlement threshold.