Live prices are currently unavailable — the exchange feed could not be reached and no recent cached reading is held.

Bitcoin Data GuideBitcoin Reference

Research · Ethereum

Transactions and nonces

Every Ethereum transaction is signed, ordered by a per-account counter, and wrapped in a typed envelope that declares which fields it carries. The nonce is the part that surprises people: it makes transactions from one key strictly sequential and makes a stuck transaction block everything behind it.

Last reviewed 2026-09-21Source: EIP-2718, EIP-1559, EIP-4844 and ethereum.org transaction documentationField semantics as specified; wallet behaviour is described only where the specification constrains it.

What a transaction carries

A transaction is a signed message that instructs the network to do one of three things: transfer value, call a contract, or create a contract. It names a recipient, an amount of ether, a gas limit, a fee, a nonce, and optionally some data. The signature over those fields is what authorises the state change, and it is verified against the address derived from the sender's public key.

The nonce is the field that makes the whole scheme replay-resistant. It is a counter, starting at zero for a fresh account, that must equal the number of transactions the account has already sent. A transaction with a nonce the network has already seen is rejected as a replay; a transaction with a nonce higher than expected is held until the gap is filled. That single rule gives Ethereum a strict ordering guarantee per account, and it is the reason a wallet cannot simply broadcast two transactions from the same key and expect them to be mined in either order.

The ordering guarantee has a sharp edge. If a transaction with nonce n is underpriced and sits in the mempool, every transaction with a higher nonce from the same account waits behind it, even if those later transactions would pay more. The account is effectively blocked until the stuck transaction is mined, replaced with a higher-fee transaction carrying the same nonce, or dropped by enough nodes that the gap closes. This is why wallets surface a pending transaction prominently and offer a speed-up or cancel action: both are replacements at the same nonce with a higher fee.

Typed transaction envelopes

Ethereum's transaction format has been extended three times without breaking existing transactions, by prefixing each transaction with a type byte that declares which fields follow.

The typed transaction envelopes Ethereum has introduced, what each added, and what it is used for.
EnvelopeWhat it addedUsed for
Legacy (pre-typed)A single gas price fieldTransactions that predate the typed format; still valid
EIP-2718A type byte prefixing the payloadThe framework that lets new transaction types be added without breaking old ones
EIP-1559Max fee, max priority fee, and a per-transaction access list optionOrdinary transfers and contract calls under the base-fee market
EIP-4844A separate blob fee field and blob commitmentsRollup data availability, where the payload is posted as blobs rather than calldata

Last reviewed 2026-09-21Source: Ethereum Improvement ProposalsEach envelope is specified in its own EIP; the table summarises what each one introduced.

The envelope design is worth understanding because it explains how Ethereum changes without a flag day. A node that does not recognise a transaction type treats it as invalid and ignores it, but it continues to process every type it does recognise. A new type can therefore be introduced and adopted gradually, and a transaction written in the old format remains valid indefinitely. The type byte is the whole mechanism: it is a version tag that lets the payload format change while the outer framing stays the same.

EIP-1559's envelope is the one most users encounter, because it is what wallets produce by default. It replaces the single gas price with a maximum fee and a maximum priority fee, and it optionally carries an access list: a declaration of the addresses and storage slots the transaction will touch. The access list exists to let a transaction pay a lower per-item cost for storage it has declared in advance, which matters for contracts that read many slots. It is an optimisation, not a requirement, and a transaction without one is perfectly valid.

EIP-4844's envelope is the one that changed what a rollup pays. It adds a separate fee market for blob data and a set of commitments to that data, so a rollup can post its transaction batch as blobs rather than as calldata. Blobs are priced independently of ordinary gas, which is what decouples the cost of posting data from the cost of executing on the base layer. The blobs and data availability page in this cluster covers the mechanism in detail.

From signature to inclusion

A signed transaction is broadcast to peers, each of which validates it against the current state and its own policy before relaying it. Validation checks the signature, the nonce, the sender's balance against the maximum possible fee, and the gas limit against the block gas limit. Policy is a separate matter: a node may refuse to relay a transaction whose fee is below its own minimum, and it may drop transactions from its mempool when the pool is full. A transaction that is valid but unattractive can therefore sit unrelayed without being invalid.

Inclusion happens when a block producer selects the transaction for a block. The producer orders transactions by the fee they offer, and because nonces must be sequential, it can only include a transaction whose predecessors from the same account are already included or included in the same block in the right order. That constraint is what makes block building a scheduling problem rather than a simple sort, and it is one of the reasons the block-building market described in the MEV page of this cluster exists.

Once included, a transaction is not immediately final. Ethereum's proof-of-stake chain reaches finality through attestations, and a block that has been finalised cannot be reverted without a slashable offence. Before finality, a transaction can in principle be reorganised out of the chain, which is why an application that credits a deposit should wait for finality rather than for a single confirmation. The finality page in this cluster covers the mechanism and the reorg limits that follow from it.

Sources and references

The transaction fields, the nonce rule and the typed envelopes described above are taken from the relevant EIPs and from Ethereum's developer documentation.

  • Transactions and their fields. ethereum.org, Transactions: the nonce, gas fields, recipient, value and data, and how a transaction is signed and broadcast.
  • The typed envelope framework. Ethereum Improvement Proposals, EIP-2718: Typed Transaction Envelope: a transaction is a type byte followed by an opaque payload.
  • The fee-market envelope. Ethereum Improvement Proposals, EIP-1559: Fee market change for ETH 1.0 chain: the max-fee and max-priority-fee fields and the optional access list.
  • The blob-carrying envelope. Ethereum Improvement Proposals, EIP-4844: Shard Blob Transactions: the blob fee field and the commitments a blob transaction carries.

Related reading