Ethereum Gas Fees, Transactions, and Confirmations

A transaction is a signed request to change Ethereum state. The wallet prepares and signs it, an RPC endpoint broadcasts it, validators decide when to include it, and the EVM executes it inside a block. Each stage can fail independently. A DApp should not collapse that lifecycle into a spinner followed by success. It should explain what the user has approved, expose the transaction hash, monitor confirmation, and recover sensibly when the provider cannot give an immediate answer.

The transaction lifecycle

Before signing, the application validates inputs, destination, value, calldata, chain ID, and estimated execution. The wallet shows a confirmation request and may allow fee adjustment. After signing, the raw transaction is broadcast and receives a hash. It can remain pending, be replaced by another transaction from the same account and nonce, be included successfully, or be included and revert. A receipt exists only after inclusion. Additional confirmations are blocks built after that receipt's block according to the network's canonical history.

Gas units and fee parameters

Gas measures EVM work; it is not the same as the native currency fee. The gas limit caps how much execution the transaction may use. Fee parameters determine the price paid per unit under the network's transaction rules. Wallets and providers estimate both from current conditions and simulated execution, but estimation is not a guarantee. Contract state can change before inclusion, and a transaction can consume gas before reverting. Avoid displaying a universal fee promise or hard-coding live prices into educational UI.

Use estimation as guidance

Estimate against the exact sender, destination, value, and calldata that will be submitted. If estimation reverts, investigate the contract rule instead of adding a very large gas limit. Preserve a reasonable buffer only when the wallet or library workflow requires it and the cause is understood. Display estimated cost with units and explain that final cost depends on actual gas used and inclusion conditions. Server-side relayers need additional controls because they, rather than the visitor, may pay the fee.

Pending transactions and nonces

Each externally owned account uses sequential nonces. A transaction with a later nonce may wait behind an earlier pending one. A replacement uses the same nonce with acceptable fee changes, which can speed up or cancel the original intent depending on the wallet flow. Applications should monitor by hash and be prepared for replacement information from the client library. Do not submit an automatic duplicate because an RPC request timed out; first determine whether a hash was created or the account nonce advanced.

const transaction = await contract.submitOrder(orderId);
showSubmitted(transaction.hash);

try {
  const receipt = await transaction.wait(2); // application-specific policy
  if (!receipt || receipt.status !== 1) throw new Error("Execution reverted");
  showConfirmed(receipt.hash, receipt.blockNumber);
} catch (error) {
  showTransactionError(normalizeTransactionError(error));
}

Reverts and RPC failures are different

A revert is an EVM execution result: the intended state changes were not committed, though the sender may still pay for consumed execution. An RPC failure means the application could not complete a request to a node; the transaction may or may not exist. Preserve known hashes and query again through a healthy provider. Decode expected contract errors when possible, but do not expose raw internal messages as the only UI. Log provider identity, chain ID, method, and timing without collecting unnecessary wallet data.

Choose confirmations by consequence

One included block may be enough to update a low-risk interface optimistically, while settlement, fulfillment, or cross-system actions may require more confidence. Network characteristics differ, so store the policy by chain and action. Show the user when the transaction is included and when the product considers it final enough to proceed. If a reorganization removes the receipt, return the workflow to a pending or review state rather than preserving a false success.

Transaction UX best practices

• Explain the action and destination before opening the wallet.
• Use distinct states for awaiting signature, submitted, mined, and confirmed.
• Show a trusted explorer link from chain configuration, not user input.
• Preserve form context after rejection or failure so the user can correct and retry.
• Refetch authoritative contract state after confirmation.
• Never request private keys or recovery phrases to troubleshoot a transaction.

Plan for replacement and recovery

A pending transaction can be replaced by another transaction from the same account and nonce, whether the user speeds it up, cancels it, or submits a conflicting action through another interface. Track the original hash, but do not assume it will remain canonical. Provider libraries may expose replacement details while waiting; persist enough context to connect the replacement with the original product action. On reload, recover pending work from durable local or server-side state and query receipts instead of presenting an unconditional retry button.

Recovery logic must remain idempotent. A receipt observer, indexer webhook, and manual refresh can all report the same completion. Key the resulting application transition to a chain ID plus a stable transaction or log identity, and reject duplicate processing. This matters whenever confirmation unlocks off-chain fulfillment, credits an account, or sends notifications. The user sees one action, but production infrastructure may observe it through several paths.

Design around uncertainty

Transaction systems are asynchronous. Wallet approval, broadcast, mempool behavior, execution, receipts, and confirmations are separate evidence. Modeling those stages prevents duplicate writes and misleading success messages. The best DApp transaction flow gives the user a stable hash, honest progress, an explanation when recovery is possible, and a clear boundary between an RPC communication problem and an on-chain failure.