Skip to content

Blockchain transactions: fees, confirmations, and finality

The full lifecycle of a blockchain transaction: signing, propagation, the mempool, validation, inclusion, fees, confirmations, and finality without confusing different states.

A blockchain transaction is a signed instruction asking the network to change its state: transfer an asset, approve spending, interact with a contract, or perform another operation allowed by the protocol. The signature authorises the request; by itself, it does not guarantee inclusion or the intended outcome.

In plain terms — Pressing “send” is the beginning. The network must receive, check, and include the instruction; the recipient then decides how many confirmations or what degree of finality it requires.

The lifecycle of a blockchain transaction Five states show preparation and signing, propagation, validation, inclusion, and finality plus application credit. The lifecycle of a blockchain transaction “Sent” does not yet mean included, successful, or final 1 · PREPARE Data and signature Network, recipient, value, fee, permissions LEGGI · READ · LEER 2 · PROPAGATE Hash and pool Broadcast to nodes; pending state LEGGI · READ · LEER 3 · VALIDATE Network rules Signature, funds, ordering, execution LEGGI · READ · LEER 4 · INCLUDE Block and receipt Included does not always mean successful LEGGI · READ · LEER 5 · FINALIZE Confirm and credit Network finality + service policy LEGGI · READ · LEER The concrete assurance depends on the protocol and the recipient policy Cyclepedia diagram · Emiciclo
Signed, propagated, included, and final are different states. An application may also add its own crediting step.
Select the highlighted points to explore the detail

1. The wallet prepares the instruction

The wallet constructs the data required by the network: destination, value, asset, any contract call, resource limit, and priority parameters. Account-based networks may use a sequence number such as a nonce; UTXO-based networks select previous outputs to spend. There is no universal format.

Before signing, check the network, address, asset, amount, and permissions. A valid signature proves that the key authorised those data under the protocol; it does not establish the recipient's human identity or the safety of the contract.

2. Signature, hash, and propagation

Once signed, a node can propagate the transaction to other nodes. The transaction hash is an identifier calculated from the serialised data. It is useful for finding and comparing the transaction, but its existence does not prove inclusion or finality.

Many networks maintain a temporary set of valid but unconfirmed transactions, often called a mempool or transaction pool. Nodes may have different views; a transaction can be rejected, replaced, dropped, or left pending according to network rules and congestion.

3. Validation and inclusion

Nodes, miners, or validators check the signature, available funds, operation ordering, and protocol rules. A block producer selects transactions and proposes a new state. Inclusion means that the transaction appears in a block recognised by the current chain.

Inclusion and application success are not always the same. On smart-contract networks, a transaction can be included but fail during execution; it may still consume part of its fee. The receipt, events, and final state should be read together.

Fees, gas, and priority

A fee compensates or incentivises participants for the resources required to propagate, validate, and include the operation, and helps protect the network from spam. Its calculation depends on the network. On Ethereum, gas measures computational work and the fee combines gas used with a price per unit; other protocols use byte weight, fee markets, or different rules.

A higher fee may increase priority in some systems, but does not guarantee success, a swap price, or immediate finality. Network fees, protocol fees, spreads, slippage, and intermediary charges must be separated.

Confirmations and finality are not the same

On proof-of-work chains, every subsequent block adds work above the one containing the transaction. The risk of reorganisation tends to fall, but the appropriate threshold depends on the network, amount, and recipient. “Six confirmations” is a historical Bitcoin practice, not a universal rule.

Some proof-of-stake networks have explicit states for justification and finality. Reverting a finalised Ethereum block would require a severe consensus failure and the destruction of stake. Other protocols define finality and thresholds differently. The application receiving a deposit may add further checks even after network finality.

Why a transaction remains pending or fails

Common causes include insufficient fees or priority, a nonce blocked by an earlier transaction, insufficient funds, a gas limit set too low, contract rules, congestion, a network error, or a reorganisation. An explorer provides a useful view, but does not replace checking the wallet, node, or receiving service.

Do not send a second operation blindly. Depending on the network, the same intention may produce either a duplicate payment or a replacement. First identify the actual state and the replacement rules.

Exchanges, bridges, and layers add more states

An exchange deposit can be final on-chain but not yet credited: the platform may require its own confirmation count, asset checks, or wallet maintenance. A bridge separates the source transaction, message, verification, and release on the destination. Rollups and layer 2 systems may distinguish local inclusion, data publication, and finality against the base network.

For this reason, “the blockchain says success” does not necessarily complete the whole economic process.

Checks before signing

  • Confirm the network, token contract, and recipient address.
  • Read the amount, approvals, and data shown by the wallet, not just the app's name.
  • Separate the maximum fee set, the fee actually paid, and the operation's other costs.
  • Save the hash and timestamp, then verify inclusion, outcome, and final state.
  • For material amounts, first run a test compatible with the network's costs and rules.
  • Check the recipient's policies for confirmations, memos or tags, and supported assets.

Professional level: assurance depends on the protocol

A professional control records the observed client or node, block height, fork choice rule, depth, finality state, receipt, logs, and application state. It models reorganisations, censorship, downtime, sequencer or bridge dependencies, and the possibility of replay or replacement.

“Immutable” is a summary, not an absolute property. NIST describes blockchains as tamper-evident and tamper-resistant under normal operating conditions. Concrete security depends on consensus, participants, software, and governance.

Sources

Digital assets and crypto markets · Crypto wallet · Self-custody · CEX, DEX, and OTC · Bridge