Understanding the New Transaction Types on Ethereum

·

Ethereum has long supported various transaction types—sending ETH to an address, deploying smart contracts, interacting with dApps, and more. Before the Berlin upgrade, Ethereum operated with just four primary transaction formats. While seemingly simple, this system required developers and tools to deeply inspect every field within a transaction to determine its type and behavior. This became increasingly complex when handling advanced concepts like meta transactions or multisig operations—especially those developed before standardized frameworks.

That changed with EIP-2718, a pivotal Ethereum Improvement Proposal introduced by developer Micah Zoltu. This new standard established the Typed Transaction Envelope, laying the foundation for future innovations in transaction structure and functionality across the network.

In this article, we’ll explore how EIP-2718 redefines Ethereum’s transaction model, its role in enabling next-generation features like EIP-1559 and EIP-2711, and why it matters for developers, users, and the broader ecosystem.

The Evolution of Ethereum’s Transaction Format

Traditionally, Ethereum transactions followed a fixed format composed of nine fields:

These were encoded using RLP (Recursive Length Prefix) as:

RLP([nonce, gasPrice, gasLimit, to, value, data, v, r, s])

While functional, this rigid structure made it difficult to introduce new features without breaking compatibility. For example, EIP-155 added replay protection by encoding the chain ID into the v value—an elegant but convoluted workaround that complicated parsing logic.

👉 Discover how modern blockchain platforms streamline transaction processing

Introducing EIP-2718: The Typed Transaction Envelope

EIP-2718 introduces a flexible envelope format:

TransactionType || TransactionPayload

Where:

This design allows new transaction formats to coexist with legacy ones. Crucially, only the first byte needs to be read to identify the transaction type—no complex decoding required. This improves efficiency and ensures backward compatibility.

Old-style transactions—now referred to as legacy or raw transactions—remain valid. Since RLP-encoded legacy transactions always start with a byte ≥ 0xC0, they cannot conflict with typed transactions (which use bytes 0x00–0x7f). This means wallets, clients, and tools can continue functioning while gradually adopting newer standards.

Why Do We Need New Transaction Types?

Advanced use cases like sponsored transactions, batch execution, and time-bound transactions have traditionally relied on smart contracts or off-chain infrastructure. These workarounds add complexity, cost, and trust assumptions.

For instance:

With native support through typed transactions, these functions can be built directly into the protocol—reducing reliance on third-party solutions and improving security and efficiency.

Key EIPs Leveraging the New Standard

Several major proposals build on EIP-2718 to expand Ethereum’s capabilities:

🔹 EIP-1559: Dynamic Fee Market with Burn Mechanism

One of the most impactful upgrades post-Berlin is EIP-1559, which overhauls gas pricing by introducing:

Its transaction format is:

0x02 || RLP([
  chainId,
  nonce,
  maxPriorityFeePerGas,
  maxFeePerGas,
  gasLimit,
  to,
  value,
  data,
  accessList,
  signatureYParity,
  signatureR,
  signatureS
])

Notable changes:

Despite being incompatible with raw transactions at the protocol level, EIP-1559 maintains backward compatibility by treating legacy gasPrice as both maxPriorityFeePerGas and maxFeePerGas.

👉 Learn how efficient fee models enhance user experience on Layer 1 blockchains

🔹 EIP-2711: Native Support for Sponsored, Batch & Expiring Transactions

Proposed by Micah Zoltu alongside EIP-2718, EIP-2711 enables three powerful features natively:

  1. Sponsored Transactions (Meta Transactions)
    Allow users to send transactions without holding ETH. A third party (the "gas payer") covers fees while preserving sender intent.
  2. Batch Transactions
    Execute multiple operations in a single transaction—e.g., approve + transfer ERC-20 tokens atomically.
  3. Expiring Transactions
    Set a deadline after which a transaction becomes invalid, reducing front-running risks and enabling time-sensitive actions.

The proposed format uses transaction type 0x01 (subject to change due to conflicts):

0x01 || RLP([...SenderPayload, ...SenderSignature, ...GasPayerPayload, ...GasPayerSignature])

Subtypes define payloads—for example:

[1, [ChildTx[]], nonce, chainId, validUntil, gasLimit, gasPrice]

Where each ChildTx contains [to, value, data].

This opens doors for seamless UX improvements in wallets and dApps—no more juggling multiple approvals or worrying about gasless accounts.

🔹 EIP-2930: Optional Access Lists

EIP-2930 allows transactions to declare addresses and storage keys they will access. This reduces gas costs by pre-warming accounts and mitigates failures due to cold storage reads.

It uses transaction type 0x01 and includes an accessList field:

[[address, [slot1, slot2]], ...]

While less visible to end-users, it plays a crucial role in optimizing contract interactions under EIP-1559 and beyond.

Frequently Asked Questions (FAQ)

Q: What is EIP-2718 used for?

A: EIP-2718 defines a standardized envelope for typed transactions on Ethereum. It enables future upgrades like EIP-1559 and EIP-2711 by allowing new transaction formats without breaking existing infrastructure.

Q: Are old Ethereum transactions still valid?

A: Yes. Legacy transactions remain fully supported. Typed transactions are designed to coexist with them through backward-compatible encoding rules.

Q: How does EIP-1559 affect gas fees?

A: It replaces the auction-based model with a dynamic base fee (burned) and optional priority fee (paid to miners). Users benefit from more predictable pricing and reduced volatility.

Q: Can I use meta transactions today?

A: Yes—but mostly through third-party relays or dApp-specific contracts. Native support via EIP-2711 would make them more secure, efficient, and widely accessible.

Q: Why does transaction type matter?

A: Different types enable different features. For example, type 0x02 signals an EIP-1559 transaction with priority fees and access lists. Clients use this byte to route parsing logic correctly.

Q: Is EIP-2711 live on Ethereum mainnet?

A: As of now, EIP-2711 remains a draft. However, its core ideas may be split into smaller proposals (e.g., EIP-3074) for incremental adoption.

Final Thoughts

The introduction of typed transactions via EIP-2718 marks a turning point in Ethereum’s evolution. By decoupling transaction structure from functionality, it paves the way for innovation without sacrificing stability.

Features once confined to smart contracts—like gas sponsorship, batching, and expiration—are now candidates for native protocol support. Combined with EIP-1559’s improved fee market and EIP-2930’s optimization tools, we’re witnessing a shift toward a more scalable, user-friendly blockchain.

As adoption grows and tooling matures, expect wallets, explorers, and dApps to increasingly leverage these capabilities—delivering smoother experiences for everyone on Ethereum.

👉 Explore cutting-edge blockchain solutions that support next-gen Ethereum transactions