Ethereum Transaction Types Explained: Legacy and Types 1–4

An explorer shows type: 0x2, a rollup batch shows 0x3, and a newer wallet operation may show 0x4. Are these success codes, token standards, or different networks? None of those. They identify different Ethereum transaction formats within the same what is blockchain guide—and reading the type first tells you which fields and fee rules can apply.

This guide maps Ethereum's live mainnet transaction families as of September 2026: legacy transactions and typed formats 0x01 through 0x04. It also explains why “type 0” is a useful RPC label but not a literal EIP-2718 envelope, how wallets choose a format, and what the type cannot prove.

What an Ethereum transaction type is

Think of a parcel depot. Every parcel enters the same delivery network, but a colored label tells the sorter which form is inside: ordinary delivery, temperature-controlled cargo, or a return authorization. The label does not say whether the contents are valuable or safe. It only selects the rules for decoding and processing the parcel.

EIP-2718 created that sorting layer for Ethereum. A typed transaction is encoded conceptually as:

TransactionType || TransactionPayload

The first byte selects a payload definition supplied by another EIP. EIP-2718 reserves positive values from 0x01 through 0x7f for typed envelopes; legacy transactions remain their original RLP list. Because a legacy RLP list starts in a different byte range, clients can distinguish the old format from a typed one without trying multiple decoders.

This solved a protocol-design problem. Before the envelope, a new transaction feature had to fit around the legacy encoding without becoming ambiguous. After EIP-2718, a future format can define its own payload while sharing Ethereum's block, execution, and receipt machinery.

Ethereum transaction types at a glance

The currently live mainnet families are:

The table is not a ranking. A larger number is not faster, safer, or newer in every practical sense. Each format is a specialized tool.

How each format works

Legacy: commonly displayed as type 0

A legacy transaction is the original RLP-encoded list containing nonce, gas price, gas limit, destination, value, data, and signature values. It has no EIP-2718 type byte in front. JSON-RPC software commonly normalizes it as 0x0, which is why explorers and libraries call it type 0.

Legacy fees use a single gasPrice. Since EIP-1559, a legacy transaction can still be included, but it pays under compatibility rules and does not express separate maximum-fee and priority-fee caps. Legacy support matters for compatibility; it is rarely the most informative default for a new wallet transaction.

Type 1: EIP-2930 access-list

EIP-2930 defines type 0x01. It adds a chain ID and an access list: addresses and storage keys the transaction expects to touch. Declared entries are warmed before execution in exchange for an intrinsic charge.

Type 1 still uses a single gasPrice. The access list is not an allowlist and does not stop execution from reaching unlisted state. It can even increase total gas when entries are unused or duplicated.

Type 2: EIP-1559 dynamic-fee

EIP-1559 defines type 0x02. It replaces the one-price bid with max_fee_per_gas and max_priority_fee_per_gas. The protocol charges the block's base fee plus a priority fee, without exceeding the sender's caps; the base-fee portion is burned.

Type 2 also retains an access-list field, even when that list is empty. This is the normal format for many wallet transfers and contract calls because it lets the wallet bound the price while adapting to the base fee. For the difference between gas units, fee caps, and the final charge, use the Ethereum gas-fee guide.

Type 3: EIP-4844 blob

EIP-4844 defines type 0x03 for blob-carrying transactions. It builds on dynamic-fee fields and adds max_fee_per_blob_gas plus a list of blob versioned hashes. Rollups use blobs to publish data availability more cheaply than putting the same data into ordinary calldata.

The large blob data travels in a sidecar at the networking and consensus layers; the execution transaction commits to it through versioned hashes. Blob gas has a separate fee market, so gasUsed × effectiveGasPrice alone does not describe the complete cost. A type 3 transaction also cannot use a null destination for contract creation.

Type 4: EIP-7702 set-code

EIP-7702 defines type 0x04. Its authorization list lets an externally owned account (EOA) designate already-deployed code to execute in that account's context. The format supports wallet features such as batching and sponsored execution while the account retains its address.

Pectra activated EIP-7702 on Ethereum mainnet in May 2025, as documented by the Ethereum Foundation's mainnet announcement. Type 4 inherits dynamic-fee-style fields and an access list, but it is intentionally not a blob transaction and cannot create a contract through a null destination.

Delegation is a powerful permission, not a cosmetic upgrade. Verify target code, understand how revocation works, and treat unexpected authorization prompts as a phishing risk.

What fields are shared—and what changes

All these formats can represent an Ethereum state transition, but their serialized fields are not interchangeable.

Common concepts include a sender nonce, gas limit, destination, value, input data, and signature authorization. The exact signing preimage and fee fields depend on the format. Typed transaction EIPs generally include the type byte in the signed message so a signature for one format cannot be silently reinterpreted as another.

Important differences include:

• Fee expression: legacy and type 1 use gasPrice; types 2–4 use maximum and priority-fee fields.
• Access lists: type 1 introduced them, and types 2–4 carry the field too.
• Blob commitment: only type 3 has blob-specific fee and versioned-hash fields among the live formats above.
• Authorization list: type 4 carries EIP-7702 delegation authorizations.
• Contract creation: legacy, type 1, and type 2 can represent creation with an empty destination; types 3 and 4 forbid it.

Do not decode a raw transaction by assuming every list position means the same thing. Read the envelope first, then apply that type's specification. RLP supplies the byte and list boundaries underneath most of these formats, but the selected transaction EIP supplies their meaning.

How wallets, RPCs, and receipts expose the type

Most users should not manually choose a transaction type. A wallet or library selects a supported format from the requested operation, configured fee fields, network capabilities, and provider response. A normal transfer with dynamic fee caps is typically type 2. A rollup's blob publisher deliberately constructs type 3. A wallet flow using an EIP-7702 authorization requires type 4-aware software.

When inspecting JSON-RPC:

1. Read type before interpreting type-specific fields.
2. Treat a missing or 0x0 type as legacy only after considering the API's schema and client behavior.
3. For type 2 or later fee formats, compare caps with the receipt's effective price rather than assuming the maximum was paid.
4. For type 3, include blob gas fields in cost accounting.
5. For type 4, inspect the authorization and current delegation state, not merely the outer sender.

EIP-2718 also pairs typed transactions with typed receipts whose type matches the transaction. The transaction receipt guide explains why the receipt records execution outcome but not the full original payload.

Risks and common mistakes

Type is not status or finality

0x2 means dynamic-fee format, not “successful.” Execution can revert, and an included block can still be short of the finality policy your application requires. Check the receipt status and block context separately.

A fee cap is not the final fee

The gas limit bounds gas units, while fee fields price those units. Type 2-style maxFeePerGas is a ceiling, not necessarily the amount paid. Blob fees are a separate lane for type 3.

Network support is contextual

A type defined by a Final EIP is not automatically usable on every EVM-compatible chain, historical block, RPC service, hardware wallet, or signing library. Confirm the target network and tool versions. Never “fix” an unknown type by stripping its first byte.

New capability expands the security surface

An access list does not validate a contract. A blob commitment does not certify rollup behavior. An EIP-7702 authorization can delegate broad account power to code. Simulate the exact call when practical, verify addresses through trusted channels, and understand what the signature authorizes.

Practical inspection checklist

• Confirm the chain and RPC schema
• Read the transaction type
• Decode fields using that type's EIP
• Verify nonce, destination, value, and calldata
• Separate gas limit from per-gas fee fields
• Include blob fees for type 3
• Review every EIP-7702 authorization for type 4
• Simulate contract calls when trustworthy tooling is available
• Check the receipt status and effective fee after inclusion
• Apply an explicit confirmation or finality policy

FAQ

Is a legacy transaction literally type 0x00 on the wire?

No. A legacy transaction is its original RLP list without an EIP-2718 prefix. RPC and explorer interfaces commonly report it as 0x0 for a uniform API.

Is type 2 always cheaper than a legacy transaction?

No. Type 2 offers clearer fee caps and base-fee handling, but the final cost depends on gas used and network conditions. The type number does not guarantee savings.

Can a type 2 transaction include an access list?

Yes. EIP-1559's type 2 payload includes an access-list field. Type 1 introduced the feature but does not own it exclusively.

Are blobs available to smart contracts as calldata?

No. Type 3 execution exposes commitments through versioned hashes; the blob contents are not ordinary EVM calldata. Rollups retrieve and interpret the associated data through the blob data-availability path.

Is type 4 automatically safer than a normal wallet transaction?

No. It enables useful smart-account behavior, but security depends heavily on the delegated code, authorization scope, wallet interface, and user verification.

Primary sources

• EIP-2718: Typed Transaction Envelope
• EIP-2930: Optional access lists
• EIP-1559: Fee market change
• EIP-4844: Shard blob transactions
• EIP-7702: Set code for EOAs
• Ethereum.org: Transactions
• Ethereum Foundation: Pectra mainnet announcement

Read the envelope before the payload

Ethereum transaction types are versioned envelopes, not quality scores. Legacy transactions preserve the original format; types 1–4 add access lists, dynamic fees, blobs, and set-code authorizations for different jobs. Identify the type, decode only by its specification, then verify the actual intent and receipt.

This article is educational, not financial advice. Ethereum transactions can be irreversible, smart-contract systems can fail, and crypto assets are volatile. Test carefully, use only funds you can afford to lose, verify current primary documentation, and do your own research (DYOR).