Transaction Execution

Overview

Execution begins after the network or sequencer accepts the transaction for processing. The runtime loads the required accounts, contract storage, or UTXOs and evaluates the transaction in the ordered context of the block.

For a simple transfer, execution may subtract value and fees from the sender and credit the recipient. A contract call can trigger nested calls, token transfers, storage updates, and events. Resource meters such as gas or compute units limit how much work the transaction can perform.

A transaction can be structurally valid yet fail during execution. The contract may reject the caller, a price may move beyond a slippage limit, or the transaction may run out of resources. Many networks still charge fees for the computation performed before failure.

State changes are generally atomic within the transaction boundary: if execution reverts, intermediate application changes do not persist. External effects outside that boundary, such as a previously sent message on another chain, may not roll back.

Simulation can predict execution against a selected state, but the real result can differ if state changes before inclusion. Monitoring should therefore use the canonical receipt and final state.

Transaction execution is distinct from consensus. Consensus orders and accepts the block, while the execution engine determines how each transaction changes state.

Execution monitoring should differentiate deterministic contract failure from infrastructure failure. A reverted transaction was processed by consensus, while a provider timeout may only mean the application did not receive the result. Retry strategies differ: resubmitting the same failed call without changing state or parameters can waste more fees, while rebroadcasting after an uncertain network response may be appropriate. Clear reason codes and traces help operators choose the correct action.