Ethereum has long supported various transaction types—sending ETH, deploying smart contracts, interacting with decentralized applications (dApps), and more. Prior to the Berlin upgrade, Ethereum operated with four primary transaction formats. These required clients, libraries, and tools to deeply parse each transaction's structure to determine its type—a process that became increasingly complex as new transaction patterns like meta-transactions and multisig transactions emerged.
With the introduction of EIP-2718, Ethereum adopted a new framework known as Typed Transaction Envelopes, paving the way for future scalability, flexibility, and backward compatibility. This article explores how this standard works, its implications for developers and users, and the exciting new transaction types it enables—such as those introduced in EIP-1559 and EIP-2711.
What Is EIP-2718? The Foundation of Typed Transactions
Before EIP-2718, Ethereum transactions followed a fixed RLP-encoded format:
RLP([nonce, gasPrice, gasLimit, to, value, data, v, r, s])This rigid structure made it difficult to introduce new features without breaking existing tooling. To solve this, developer Micah Zoltu proposed EIP-2718: Typed Transaction Envelope, which introduces a flexible wrapper format:
TransactionType || TransactionPayloadHere:
- TransactionType: A single byte (0x00 to 0x7F), allowing up to 128 unique transaction types.
- TransactionPayload: An arbitrary byte array defined by the specific transaction type.
This simple concatenation allows any Ethereum client or wallet to quickly identify a transaction’s type by reading just the first byte—no complex parsing required. More importantly, it enables future upgrades without disrupting legacy systems.
Backward Compatibility: Bridging Old and New
One of EIP-2718’s core principles is backward compatibility. Legacy transactions—now referred to as legacy or pre-EIP-2718 transactions—remain fully valid. Since RLP-encoded legacy transactions always start with a byte ≥ 0xC0, they cannot be mistaken for typed transactions (which use bytes 0x00–0x7F). This clear distinction ensures seamless coexistence.
While EIP-2718 itself doesn’t define new transaction behaviors, it serves as the foundation for several key Ethereum Improvement Proposals (EIPs), including:
- EIP-1559: Dynamic fee market with base fee burning
- EIP-2930: Optional access lists
- EIP-2711: Native support for batch, sponsored (meta), and expirable transactions
These proposals leverage the typed envelope model to introduce advanced functionality natively on Ethereum.
EIP-1559: A New Era of Gas Fees
Perhaps the most impactful implementation of EIP-2718 is EIP-1559, which revolutionized how gas fees work. Instead of a simple “gas price,” EIP-1559 introduces two components:
maxPriorityFeePerGas: The tip paid to minersmaxFeePerGas: The total maximum fee a user is willing to pay
The transaction format under EIP-1559 is:
0x02 || RLP([
chainId,
nonce,
maxPriorityFeePerGas,
maxFeePerGas,
gasLimit,
to,
value,
data,
accessList,
signatureYParity,
signatureR,
signatureS
])Key changes include:
- Chain ID separation: No longer embedded in the
vvalue, simplifying signature recovery. - Simplified signature parity: The
vvalue is replaced with a simple0or1indicating Y-coordinate parity. - Access lists via EIP-2930: Reduce gas costs by pre-declaring storage keys accessed during execution.
To maintain backward compatibility, legacy transactions can be upgraded by treating the original gasPrice as both maxPriorityFeePerGas and maxFeePerGas.
Enabling Advanced Use Cases: EIP-2711 and Beyond
While EIP-1559 focuses on fee mechanics, EIP-2711 unlocks powerful new transaction patterns—native support for:
- Sponsored transactions (meta-transactions)
- Batched transactions
- Expirable transactions
Previously, these required smart contracts or third-party relayers. Now, they’re built directly into Ethereum’s protocol.
How Sponsored Transactions Work
Sponsored transactions allow users to interact with dApps without holding ETH for gas. For example, a game player could mint an NFT using only their in-game tokens—while a sponsor (e.g., the game developer) pays the gas.
Under EIP-2711, the transaction structure becomes:
0x03 || RLP([...SenderPayload, ...SenderSignature, ...GasPayerPayload, ...GasPayerSignature])It includes:
- Sender’s payload and signature
- Gas payer’s payload and signature (who covers fees)
This eliminates the need for complex relay infrastructure and improves user experience across Web3 applications.
Batch Transactions: One Tx, Multiple Actions
Batching allows multiple operations in a single transaction. For instance:
SubTransaction[] = [
{ to: UniswapRouter, data: "approve(...)" },
{ to: UniswapRouter, data: "swapExactTokensForETH(...)" }
]This reduces friction and ensures atomic execution—either all actions succeed or none do.
👉 See how seamless multi-action transactions are transforming user onboarding in Web3.
Why Do We Need New Transaction Types?
Without native support, features like meta-transactions or expiration require:
- Dedicated smart contracts
- Specialized nodes
- Additional trust assumptions
By embedding these capabilities at the protocol level via typed transactions, Ethereum becomes more efficient, secure, and user-friendly.
For example:
- A DeFi dApp can let users sign trades off-chain while sponsors cover gas.
- A DAO can submit time-bound proposals that expire automatically.
- Users can bundle approvals and swaps into one click.
These improvements lower barriers to entry and enhance composability across the ecosystem.
Frequently Asked Questions (FAQ)
Q: Are legacy transactions obsolete after EIP-2718?
A: No. Legacy transactions remain fully supported. EIP-2718 ensures backward compatibility so older wallets and tools continue working.
Q: What are the main benefits of typed transactions?
A: They enable future innovation without breaking existing systems, simplify transaction parsing, and support advanced features like batched and sponsored transactions natively.
Q: Does EIP-2711 conflict with EIP-1559?
A: Not inherently. However, both use similar transaction type identifiers (e.g., 0x02), so coordination is needed. Some functionalities may be split into smaller EIPs like EIP-3074.
Q: Can I use meta-transactions today?
A: Yes—but mostly through third-party solutions like Biconomy or Gelato. Native support via EIP-2711 would make them more efficient and widely adoptable.
Q: How do access lists reduce gas costs?
A: By declaring which storage slots a transaction will access beforehand (via EIP-2930), you avoid costly cold storage reads, saving up to 100 gas per access.
Q: Is EIP-2711 live on mainnet?
A: As of now, it remains a draft proposal. Its adoption depends on community consensus and further testing.
Final Thoughts: The Future Is Typed
The introduction of typed transaction envelopes marks a pivotal moment in Ethereum’s evolution. By decoupling transaction format from semantics, EIP-2718 enables modular upgrades that keep the network agile and forward-compatible.
With standards like EIP-1559 already live and proposals like EIP-2711 on the horizon, Ethereum is laying the groundwork for a more scalable, accessible, and feature-rich ecosystem.
As developers build atop these new primitives—and as wallets and clients add support—the user experience across DeFi, NFTs, gaming, and social apps will improve dramatically.
Whether you're a developer designing gasless dApps or a user tired of high fees and clunky approvals, the era of smarter transactions has just begun.