Transactions and gas

Reading depth

Each view includes the earlier layers; the complete engineer or auditor page is shown by default.

BeginnerCore purpose and mental modelPractitionerAdds mechanisms and economicsEngineer or auditorAdds state and verification

Dependency check

Advanced detail assumes prerequisite knowledge

Before using practitioner mechanisms or engineer and auditor checks, review any unfamiliar dependency. These paths come from canonical depends_on relationships; Web3 Academy does not track completed lessons.

Review 2 dependencies

• BlockchainDirect prerequisite

  1. Transactions and gas
  2. Blockchain

• Wallets and keysDirect prerequisite

  1. Transactions and gas
  2. Wallets and keys

A transaction is an authorized request to change blockchain state, and gas meters the computation and storage resources that executing it consumes.

Category: Money and assetsCircle category cue

System record

Start with the economic purpose, participants, resources, and entitlements before studying implementation detail.

Why it exists

Transactions give the network an ordered, signed unit of work, while gas prices scarce execution capacity and bounds how much work one request can demand.

Traditional-finance analogy

Payment instruction plus metered processing fee is the closest comparison recorded for this concept.

Where the analogy stops

• A blockchain transaction can invoke arbitrary contract logic and compose several financial actions atomically, not merely transfer money between accounts.
• Resource fees may be charged for attempted execution even when contract logic reverts, because validators still performed the work.

Main actors

• ActorTransaction sender and signer
• ActorBlock builder, sequencer, or validator
• ActorContract or recipient account
• ActorFee-market participants

Assets and claims

Assets — controlled or transformed resources

Assets are resources the mechanism moves, holds, values, or transforms.

• AssetTransferred native asset or tokens
• AssetNative asset paid for execution resources

Claims — entitlements and corresponding dependencies

Claims are rights to value, repayment, redemption, control, or another party's performance; each depends on an obligation or system that must honor it.

• ClaimSigned state-change instruction awaiting inclusion
• ClaimTransaction receipt as evidence of execution outcome

A transaction asks the network to apply an authorized state change; gas puts a measured limit and price on the resources used to evaluate that request.

Why it exists

A shared state machine needs an ordered unit of work with an identifiable sender, replay protection, and a resource bound. Without metering, one caller could demand unbounded computation from every validating node. Fee markets also help allocate scarce block capacity when many users want execution at once.

Traditional-finance analogy

A payment instruction plus a metered processing fee is a useful analogy. The comparison ends because one transaction may call several programs, create and repay debt, exchange assets, and either commit all successful state changes or revert them together. Fees can still be consumed when execution reverts because the network performed the attempted work.

Actors, assets, and claims

The sender authorizes the request. A block builder, sequencer, or validator orders it. Recipient contracts interpret its data. The sender may transfer a native asset or tokens and separately pays the network’s fee asset. A pending signed request is not a settled financial claim; a receipt is execution evidence whose confirmation and finality still need evaluation.

Mechanism, equation, and flows

1. The wallet encodes destination, value, data, chain context, replay fields, fee parameters, and a gas limit.
2. The account’s authorization mechanism signs or validates the request.
3. The network admits and orders the request according to its rules.
4. Execution consumes gas as operations run and either commits the resulting state or reverts state changes.
5. A receipt records outcome and gas use; later consensus establishes the application’s required confirmation or finality state.

For an Ethereum-style transaction, the execution fee is:

transactionFeeNative = gasUsed × effectiveGasPriceNativePerGas

gasUsed is a count of gas units. effectiveGasPriceNativePerGas is native asset per gas unit, commonly quoted in gwei per gas on Ethereum. Their product is native asset. The sender’s gas limit is a maximum resource budget, not a promise that all of it will be spent. Other chains may meter and price execution differently.

Capital flow follows transferred value and paid fees. Claim flow follows any shares, debt, receipts, or rights created by called contracts. Information flow includes calldata, ordering, status, and receipts. Control flow begins with the signer and continues through every called authorization rule. Return flow sends user-paid fees to validators, sequencers, builders, or treasuries under network rules; issuance-funded rewards expand supply and dilute other holders unless another mechanism offsets them. Execution itself creates no investment return. Risk flow follows bad parameters, unexpected code paths, ordering, congestion, and finality.

State and loss allocation

Table: State and loss allocation

Outcome	Contract state	Transferred value	Execution fee
Not included	Unchanged	Unchanged	Not charged on-chain
Successful execution	Committed	Applied under called rules	Charged for gas used
Reverted execution	Reverted for the failed call context	Reverted with state	Gas for performed work remains charged
Included but later reorganized	Removed from canonical history	Must be reconciled	Depends on replacement history

Transaction execution itself does not produce investment return. Validators, sequencers, builders, or protocol treasuries may receive fees; the sender pays them. Bad destinations, approvals, calldata, ordering, or fee assumptions can make the sender or affected protocol users absorb loss.

Beginner lens

“Sent,” “included,” “successful,” and “final” are different statements. Check the destination and effect before signing, then inspect the receipt rather than assuming a transaction succeeded because it has a hash.

Practitioner lens

Monitor nonce policy, fee caps, replacement behavior, deadlines, slippage, allowances, simulation coverage, private or public order flow, chain ID, confirmation thresholds, and operational retry rules. A blind retry can create a second economic action even when byte-for-byte replay is blocked.

Engineer or auditor lens

Ethereum transactions carry fields such as recipient, nonce, value, input data, gas limit, and fee parameters. Ethereum gas schedules charge for EVM work, and the base-fee and priority-fee mechanism is specific to that protocol. Never copy its units or success semantics into a different execution environment without checking that chain’s primary specification.

Security review notes

Review signature validation, chain and replay domains, nonce lifecycle, gas bounds, revert behavior, allowance effects, fee arithmetic, receipt status, and finality. Ensure callers distinguish an out-of-gas or reverted request from a committed state change.

Common misunderstandings

• “A transaction hash means success.” It only identifies a submitted request; inspect inclusion, status, and finality.
• “Revert means free.” State can revert while resource fees remain paid.
• “Gas is a token.” Gas is a resource unit; a chain’s native asset pays the fee denominated from those units.

Prerequisites and learn next

Read blockchain and wallets and keys first. Continue to smart contracts to see how calldata selects programmable rules.

Sources

• Ethereum.org, Transactions — Ethereum transaction fields and lifecycle (accessed 2026-08-09).
• Ethereum.org, Gas and fees — Ethereum resource metering and fee arithmetic (accessed 2026-08-09).
• The supplied DeFi seed, sections 2, 12, and 14 — execution, control, and blockchain-learning questions.

Machine-readable model

Key equations

Canonical expressions come from the structured concept record. KaTeX renders the notation, while the plain-text expression and variable table keep its meaning and units inspectable without JavaScript. Read the narrative above for the model's domain, assumptions, and rounding rules.

1. Equation 1

   $$\mathrm{transactionFeeNative} = \mathrm{gasUsed} \times \mathrm{effectiveGasPriceNativePerGas}$$

   Plain-text equation: transactionFeeNative = gasUsed × effectiveGasPriceNativePerGas

   Variables and units for equation 1

   Symbol	Meaning	Unit
   transactionFeeNative	Transaction fee paid in the chain native asset	native-token units
   gasUsed	Gas Used	gas units
   effectiveGasPriceNativePerGas	Effective Gas Price Native Per Gas	native-token units per gas unit

Assurance contract

Security properties

These structured statements define desired behavior. Their stable IDs can bind tests, invariants, specifications, audit findings, or proof results without turning descriptive review advice into an assurance claim.

Desired · not evaluated: No test, audit, or proof result is implied until scoped evidence is linked to this property.

1. SP-01Desired · not evaluated

   Only a valid authorization for the sending account can create an accepted transaction

2. SP-02Desired · not evaluated

   Nonce and replay-domain rules prevent unintended duplicate execution

3. SP-03Desired · not evaluated

   Resource consumption never exceeds the sender's explicit gas limit

4. SP-04Desired · not evaluated

   A receipt distinguishes inclusion, execution success, and finality rather than treating them as one state

Prerequisites

Direct dependencies recorded by this concept's canonicaldepends_on relationships.

• BlockchainPath 10

  A blockchain is a replicated ledger and state-transition system whose participants use a consensus protocol to agree on an ordered history.

• Wallets and keysPath 11

  A wallet helps a person or system manage accounts and authorize actions, while cryptographic keys provide the signing authority behind those actions.

Learn next

Concepts that directly depend on this one, ranked by the recommended learning path. Check each page for additional prerequisites.

• Smart contractPath 13

  A smart contract is deployed code and persistent state that applies deterministic rules when a blockchain transaction or another contract calls it.

• Settlement and finalityPath 14

  Settlement records a state change, while finality describes the confidence that the accepted history will not later be replaced under the network's consensus rules.

Knowledge check

Quiz

Answer in your own words, then open the model answer.

Why can a reverted transaction still cost a fee?

Model answer

Validators performed computation before the revert, so the resource meter charges for that work even though the failed call's state changes do not persist.

Mark as understood