Ethereum Transactions and Meta Transactions: A Comprehensive Guide

·

Ethereum transactions (Tx) are the lifeblood of the network, enabling value transfers and smart contract interactions. With continuous upgrades, Ethereum has evolved its transaction formats to improve scalability, security, and user experience. This guide explores standard transaction types—including EIP-2718, EIP-2930, EIP-1559, EIP-4844, and EIP-7702—and dives into meta transactions (Gasless Tx), a powerful mechanism that allows users to interact with dApps without holding ETH for gas fees.

Whether you're a developer building on Ethereum or a blockchain enthusiast, understanding these concepts is essential for navigating the modern Web3 ecosystem.

Understanding Ethereum Transaction Formats

Every action on Ethereum—sending ETH, interacting with smart contracts, deploying code—requires a transaction. These transactions must be properly formatted, signed, and broadcasted to the network via nodes using the eth_sendRawTransaction RPC method.

The raw transaction data includes critical fields such as:

A transaction hash is computed as Keccak256(RawTransaction) after signing. The signature ensures authenticity and integrity.

Evolution of Transaction Types

To support future extensibility and new features, Ethereum introduced a versioned transaction format through EIP-2718.

👉 Discover how next-gen wallets handle these advanced transaction types

EIP-2718: Typed Transactions for Future-Proofing

EIP-2718 defines two transaction formats:

LegacyTransaction
TransactionType || TransactionPayload

The key innovation is type identification via the first byte:

This allows backward compatibility while paving the way for new transaction types like those introduced in subsequent EIPs.

EIP-2930: Access List Transactions (Type 1)

EIP-2930 introduced transaction type 0x01, which includes an accessList. This list specifies addresses and storage keys the transaction will access, allowing nodes to pre-load data and reduce gas costs during execution.

Format:

0x01 || rlp([chainId, nonce, gasPrice, gasLimit, to, value, data, accessList, signatureYParity, signatureR, signatureS])

While useful for optimizing certain operations, EIP-2930 transactions are less commonly used today due to the rise of EIP-1559.

EIP-1559: Dynamic Fee Market (Type 2)

EIP-1559, activated in the London hard fork, revolutionized Ethereum’s fee market by introducing predictable pricing and partial fee burning.

Key components:

Users pay:
min((baseFeePerGas + maxPriorityFeePerGas) * gasUsed, maxFeePerGas * gasUsed)

Any difference between maxFeePerGas and actual cost is refunded.

Example:

baseFeePerGas = 100 gwei  
maxPriorityFeePerGas = 5 gwei  
maxFeePerGas = 200 gwei  
=> Effective fee = (100 + 5) * gasUsed = 105 * gasUsed

This system reduces overpayment and improves user experience across wallets and dApps.

EIP-4844: Blob Transactions (Type 3)

Part of the Dencun upgrade, EIP-4844 introduces blob-carrying transactions (type 0x03) to lower Layer 2 rollup costs.

These transactions carry temporary large data blobs (up to 128 KB) that are deleted after ~18 days, making them ideal for cheap data availability.

Format:

0x03 || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, max_fee_per_blob_gas, blob_versioned_hashes, y_parity, r, s])

This paves the way for scalable rollups and mass adoption by drastically cutting L2 transaction fees.

EIP-7702: Account Abstraction Enabler (Type 4)

EIP-7702 proposes transaction type 0x04, allowing externally owned accounts (EOAs) to temporarily become smart contract wallets via an authorization_list.

Format:

0x04 || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, authorization_list, y_parity, r, s])

Where authorization_list contains signed authorizations enabling EOAs to execute smart account logic—bridging the gap toward full account abstraction.

Meta Transactions: Enabling Gasless User Experiences

One of Ethereum’s biggest usability hurdles is requiring users to hold ETH for gas. Meta transactions (or Gasless Transactions) solve this by letting third parties—called Relayers—pay gas fees on behalf of users.

This enables:

But how does it work securely?

How Meta Transactions Work

A user signs a message containing their intended action (e.g., calling a function with specific parameters). Instead of sending this directly, they send it to a Relayer.

The Relayer then wraps this into a standard Ethereum transaction, pays the gas, and submits it. However, two key challenges must be solved:

  1. Tampering Prevention: The Relayer must not alter the user’s intent.
  2. Identity Preservation: The smart contract must know the original sender (msg.sender would otherwise be the Relayer).

👉 Learn how leading dApps implement gasless onboarding at scale

Core Mechanism: Signature Verification in Smart Contracts

To preserve intent and identity, smart contracts verify the user’s signature using cryptographic recovery (e.g., ecrecover in Solidity).

For example, a function originally defined as:

function func1(uint a, uint b) public {
    address user = msg.sender;
    // ...
}

Becomes:

function func1BySig(uint a, uint b, bytes memory signature) public {
    address user = recoverSigner(keccak256(abi.encodePacked(a, b)), signature);
    require(user != address(0), "Invalid signature");
    // Proceed with logic using 'user' as original sender
}

Best practices follow standards like:

See real-world implementations in projects like Compound’s delegateBySig.

Centralized vs Decentralized Relayers

Centralized Relayer

A single entity runs the relayer service. Simple to set up but introduces trust assumptions:

Commonly used in early-stage dApps or closed ecosystems.

Decentralized Relayer Networks

Solutions like OpenZeppelin’s Gas Station Network (GSN) distribute relaying across multiple nodes. Benefits include:

Though more complex to implement, decentralized relayers align better with Ethereum’s ethos.

Security Considerations

Even with proper design, risks remain:

Replay Attacks

Prevented using per-user nonces embedded in signed messages. Each signature includes the current nonce; once used, it increments and invalidates prior signatures.

Expiry Windows

Add timestamps or block numbers to signed messages so they expire after a set time. Prevents delayed execution of outdated actions.

Relayer Protection

Relayers risk financial loss from spam or failed transactions. Mitigations include:

Frequently Asked Questions (FAQ)

Q: What is the main benefit of EIP-1559?
A: It introduces a predictable fee market with base fee burning and priority tips, reducing overpayment and improving UX.

Q: Can legacy transactions still be used?
A: Yes. Ethereum maintains backward compatibility—legacy (EIP-155) transactions are still valid alongside newer types.

Q: Do meta transactions cost the user nothing?
A: They don’t pay gas directly—but dApp developers or sponsors cover costs. Users still bear opportunity cost via potential usage limits or indirect fees.

Q: Are blob transactions permanent?
A: No. Blob data is pruned after approximately 18 days. They’re designed for temporary data availability (e.g., rollup calldata).

Q: Is account abstraction fully implemented?
A: Not yet. EIP-7702 moves us closer by allowing EOAs to act as smart accounts temporarily—but full abstraction requires further upgrades.

Q: How do I choose between transaction types?
A: Wallets and tools usually auto-select based on network support. Developers should target EIP-1559+ unless targeting older environments.

👉 Start building with advanced Ethereum transaction features today

Understanding both standard and meta transactions empowers developers and users alike to leverage Ethereum’s full potential—from efficient fee management to seamless user onboarding. As core protocols evolve toward greater scalability and usability, staying informed ensures you’re ready for what’s next in Web3.