Ethereum has evolved significantly since its inception, and one of the most impactful upgrades in recent years is the introduction of typed transactions. These new transaction formats are redefining how users interact with the network by enabling advanced functionality while maintaining backward compatibility. This article explores the evolution of Ethereum transactions, the role of EIP-2718, and how new standards like EIP-1559 and EIP-2711 are shaping the future of decentralized interactions.
The Evolution of Ethereum Transactions
Before the Berlin upgrade, Ethereum relied on a single transaction format—commonly referred to as legacy transactions. These included standard fields such as nonce, gas price, gas limit, recipient address (to), value, data, and signature components (v, r, s). All were RLP-encoded into a uniform structure:
RLP([nonce, gasPrice, gasLimit, to, value, data, v, r, s])While simple in design, this format posed challenges when introducing new features. For example, EIP-155 added replay protection by embedding the chain ID into the v value of signatures—an elegant but increasingly complex workaround.
With growing demands for advanced capabilities like meta transactions, batch processing, and gas optimization, Ethereum needed a more scalable solution. That’s where EIP-2718: Typed Transaction Envelope comes in.
👉 Discover how next-gen blockchain interactions are being built today.
Introducing EIP-2718: A Universal Transaction Framework
EIP-2718 introduces a flexible envelope system that allows Ethereum to support multiple transaction types without disrupting existing infrastructure. Instead of a one-size-fits-all format, transactions now follow this pattern:
TransactionType || TransactionPayloadHere’s what that means:
TransactionType: A single byte (0x00 to 0x7f), allowing up to 128 distinct transaction types.TransactionPayload: An arbitrary byte array defined by the specific transaction type—encoded using RLP, SSZ, or any future format.
This structure makes it trivial for nodes and wallets to identify transaction types by reading just the first byte. More importantly, it enables future innovation without breaking legacy systems.
For instance, instead of overloading signature fields to carry chain IDs (as EIP-155 did), developers can now define entirely new transaction types with dedicated fields—cleaner, safer, and more extensible.
Backward Compatibility: Bridging Old and New
One of EIP-2718’s key strengths is its full backward compatibility. Legacy transactions remain valid because they begin with an RLP header byte ≥ 0xc0, while typed transactions use type identifiers ≤ 0x7f. This ensures no overlap between old and new formats.
Existing wallets, libraries, and tools continue functioning seamlessly—they simply won’t support newer transaction features until updated. This smooth transition lowers adoption barriers and accelerates network-wide integration.
Although EIP-2718 itself doesn’t define any new transaction behaviors, it serves as a foundation for several critical proposals:
- EIP-1559: Modernizes fee markets with base fee burning and priority fees.
- EIP-2930: Introduces optional access lists for gas optimization.
- EIP-2711: Enables sponsored (meta), expiring, and batch transactions natively.
Let’s dive into two of the most transformative ones.
EIP-1559: Rethinking Gas Fees
EIP-1559 revolutionized Ethereum’s economic model by replacing the volatile auction-based gas system with a predictable fee market. It also introduced a new transaction format:
0x02 || RLP([chainId, nonce, maxPriorityFeePerGas, maxFeePerGas, gasLimit, to, value, data, accessList, signatureYParity, signatureR, signatureS])Key improvements include:
- Predictable pricing: Users set
maxFeePerGasandmaxPriorityFeePerGas, reducing overpayment. - Fee burning: A portion of gas is burned, creating deflationary pressure on ETH.
- Simplified signatures: The
vfield is replaced withsignatureYParity(0 or 1), improving clarity.
Additionally, EIP-1559 supports access lists from EIP-2930—pre-specifying storage keys accessed during execution—to reduce gas costs for complex contracts.
Legacy transactions can be upgraded to EIP-1559 by treating the original gasPrice as both maxPriorityFeePerGas and maxFeePerGas, ensuring interoperability during the transition phase.
👉 Learn how modern transaction standards enhance user experience and efficiency.
EIP-2711: Native Meta and Batch Transactions
While meta transactions have existed via smart contracts (e.g., GSN), they require third-party relays and contract deployment. EIP-2711 changes that by bringing sponsored transactions directly into the protocol.
This proposal allows one party (the sender) to initiate a transaction while another (the gas payer) covers the fees—enabling walletless onboarding and frictionless dApp interactions.
The format includes dual payloads and signatures:
0x03 || RLP([...SenderPayload, ...SenderSignature, ...GasPayerPayload, ...GasPayerSignature])It supports multiple subtypes (1–4), including:
- Expiring transactions: Set a deadline (
ValidUntil) after which the transaction becomes invalid. - Batch transactions: Execute multiple operations (e.g.,
approve+transferFrom) in one call. - Sponsored execution: Users send ERC-20 tokens without holding ETH—ideal for onboarding new users.
Though still in draft form, EIP-2711 could be split into smaller EIPs like EIP-3074, which explores similar capabilities with account abstraction in mind.
Why Typed Transactions Matter
Typed transactions unlock native support for features previously limited to smart contracts or off-chain services. Benefits include:
- Reduced complexity: No need for proxy contracts or relay infrastructure.
- Improved security: Fewer moving parts mean fewer attack vectors.
- Enhanced UX: Predictable fees, multi-step actions in one tx, gasless interactions.
- Future-proofing: Easy integration of upcoming innovations like account abstraction.
Core keywords naturally integrated throughout: Ethereum transaction types, EIP-2718, typed transactions, EIP-1559, meta transactions, gas optimization, access lists, transaction envelope.
Frequently Asked Questions
Q: What is EIP-2718?
A: EIP-2718 defines a typed transaction envelope that allows Ethereum to support multiple transaction formats using a simple type-payload structure. It enables future upgrades without breaking legacy systems.
Q: How does EIP-1559 improve gas fees?
A: EIP-1559 replaces the auction model with a dynamic base fee (burned) and a tip (paid to miners). This results in more predictable transaction costs and reduced overpayment.
Q: Can legacy wallets handle typed transactions?
A: Yes—typed transactions are backward compatible. Legacy wallets will recognize them as valid but may not support advanced features unless updated.
Q: What are sponsored transactions?
A: Sponsored transactions (or meta transactions) let a third party pay gas fees on behalf of the sender. This enables gasless user experiences in dApps.
Q: Are typed transactions widely used today?
A: Adoption is growing—EIP-1559 transactions are now common thanks to major wallet support (e.g., MetaMask). Others like EIP-2711 are still in development but show strong potential.
Q: How do access lists reduce gas costs?
A: Access lists pre-declare storage locations a transaction will access. This avoids higher "cold" access costs during execution, especially beneficial for DeFi interactions.
👉 Explore tools that support the latest Ethereum transaction standards.
Final Thoughts
The shift to typed transactions marks a pivotal moment in Ethereum’s scalability journey. By decoupling transaction logic from a rigid format, EIP-2718 lays the groundwork for smarter, more efficient interactions. From EIP-1559’s fee market overhaul to the promise of native meta transactions in EIP-2711, these innovations are making blockchain technology more accessible and user-friendly than ever before.
As adoption grows and new EIPs emerge, Ethereum continues to evolve—not just in performance but in usability. Developers and users alike stand to benefit from a network that supports richer functionality out of the box.