Ethereum Transactions and Meta Transactions: A Comprehensive Guide

·

Ethereum has evolved significantly since its inception, introducing new transaction formats and innovative mechanisms to enhance user experience, scalability, and usability. Among the most impactful developments are the evolution of transaction types through various Ethereum Improvement Proposals (EIPs) and the emergence of meta transactions—also known as gasless transactions—that enable users to interact with smart contracts without holding ETH for gas fees.

This guide explores the structure and broadcast process of Ethereum transactions, delves into key EIPs shaping modern transaction formats, and explains how meta transactions work, their security considerations, and real-world applications.

Understanding Ethereum Transaction Formats

When a user submits a transaction to the Ethereum network, they use the JSON-RPC method eth_sendRawTransaction to send signed transaction data to a node. The input for this method is a serialized, signed transaction that includes essential fields such as nonce, gas settings, destination address, value, and input data.

👉 Discover how blockchain transactions work under the hood.

The transaction hash is computed as:

TxHash = Keccak256(RawTransaction)

Where RawTransaction is the RLP-encoded signed transaction. The signature covers nine elements:

Before EIP-155, only the first six fields were signed, making transactions vulnerable to replay attacks across chains like Ethereum and Ethereum Classic. EIP-155 solved this by embedding the chain ID in the signature.

Core Keywords:

Evolution of Transaction Types: EIP-2718 and Beyond

To support future extensibility, EIP-2718 introduced a new transaction encoding format:

TransactionType || TransactionPayload

Transactions starting with bytes 0x00 to 0x7f are interpreted as typed transactions; all others default to legacy (EIP-155) format. This allows seamless backward compatibility while enabling innovation.

EIP-2930: Access List Transactions (Type 1)

Type 1 transactions (0x01) include an access list, which specifies addresses and storage keys the transaction will access. This helps reduce gas costs by pre-declaring state accesses, especially during network congestion.

Format:

0x01 || rlp([chainId, nonce, gasPrice, gasLimit, to, value, data, accessList, yParity, r, s])

While useful, EIP-2930 is largely superseded by EIP-1559 due to better fee efficiency.

EIP-1559: Dynamic Fee Market (Type 2)

Introduced in the London hard fork, EIP-1559 revolutionized Ethereum's fee mechanism by replacing the auction-based gas price model with a dynamic base fee that is burned.

Key fields:

Users pay:

min(maxFeePerGas, baseFeePerGas + maxPriorityFeePerGas) * gasUsed

Any difference between maxFeePerGas and actual cost is refunded. This leads to more predictable fees and reduces overpayment.

Example:

baseFeePerGas = 100 gwei  
maxPriorityFeePerGas = 5 gwei  
maxFeePerGas = 200 gwei  
=> Effective payment: 105 * gasUsed (since 100 + 5 < 200)

Legacy transactions are still supported, but EIP-1559 offers superior UX and economic efficiency.

👉 Learn how modern fee markets improve blockchain usability.

EIP-4844: Blob Transactions (Type 3)

Part of the Dencun upgrade, EIP-4844 introduces blob-carrying transactions designed to reduce rollup costs. These transactions carry large binary blobs (up to 128 KB) that are not stored in the state but are available temporarily for execution.

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 EIP drastically lowers Layer 2 transaction fees by providing cheap data availability—a critical step toward mass adoption.

EIP-7702: Account Abstraction Upgrade (Type 4)

EIP-7702 enhances account abstraction by allowing externally owned accounts (EOAs) to temporarily become smart contract wallets via an authorization_list. This enables EOAs to perform batched operations or use advanced signing schemes without permanent migration.

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])

authorization_list contains signed authorizations allowing designated contracts to act on behalf of EOAs. This paves the way for broader adoption of smart account features.

Meta Transactions: Enabling Gasless User Experiences

One of the biggest barriers to mainstream blockchain adoption is the need for users to hold ETH for gas fees. Meta transactions solve this by allowing users to sign transaction intents off-chain while a third party—called a relayer—submits and pays for the on-chain transaction.

This enables:

However, relayers cannot simply forward user-signed transactions—they must repackage them using their own signature. This creates two challenges:

  1. Tampering risk: Relayers could alter input data.
  2. Identity loss: msg.sender becomes the relayer’s address, not the user’s.

How Meta Transactions Work

To preserve intent and identity:

  1. The user signs a structured message containing function parameters.
  2. The signature is passed to the smart contract.
  3. The contract verifies the signature using ecrecover or EIP-712.
  4. The original sender’s address is recovered from the signature.

For example, converting a function:

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

Becomes:

function func1BySig(uint a, uint b, bytes memory signature) public {
    address user = recoverSigner(abi.encode(a, b), signature);
    require(validUser(user));
    // logic
}

Standards like EIP-191 and EIP-712 ensure secure and structured signing.

👉 Explore how dApps can offer gasless onboarding today.

Relayer Architectures: Centralized vs Decentralized

Centralized Relayer

A single entity runs the relayer service and pays gas for users. Simple to implement but introduces trust assumptions—users must trust the relayer won’t censor or manipulate transactions.

Common in early-stage dApps where control and monitoring are prioritized.

Decentralized Relayer Networks

Solutions like OpenZeppelin’s Gas Station Network (GSN) distribute relaying across multiple nodes. Benefits include censorship resistance and redundancy but come with higher complexity in coordination and incentive design.

Decentralized models often use staking mechanisms to ensure honest behavior and allow relayers to be compensated via dApp budgets or token incentives.

Security Considerations in Meta Transactions

Even with cryptographic safeguards, meta transactions require careful design:

Replay Protection

Use per-user nonces included in the signed message. Each time a user signs a transaction, the current nonce must be fetched from the contract. Incrementing nonces prevent duplicate execution.

Example from Compound’s delegateBySig:

require(nonce == userNonces[user]++);

Expiry Mechanisms

Include a deadline (expiry) in the signed message so that stale transactions become invalid after a set time.

require(block.timestamp <= expiry);

Relayer Safeguards

Relayers should enforce rate limits per user/dApp to prevent abuse and avoid excessive gas expenditure on failed transactions.

Frequently Asked Questions (FAQ)

Q: What is the main benefit of EIP-1559?
A: It introduces a predictable fee market with a base fee that’s burned, reducing price volatility and improving user experience compared to legacy gas auctions.

Q: Can I use meta transactions without modifying my smart contract?
A: No. Contracts must be designed to accept signatures and recover sender addresses instead of relying on msg.sender.

Q: Are blob transactions permanent?
A: No. Blob data is stored only temporarily (~18 days), providing cheap short-term data availability for rollups without bloating long-term state.

Q: Who pays for meta transactions?
A: A relayer submits and pays gas for the transaction. The dApp developer typically reimburses relayers through off-chain payments or token incentives.

Q: Is EIP-7702 live on mainnet?
A: As of early 2025, EIP-7702 is under active development and testing. Final deployment depends on network upgrades and consensus among stakeholders.

Q: How do I prevent my meta transaction from being front-run?
A: Use tight expiry windows, private mempools (via services like Flashbots), and consider bundling multiple operations into one atomic call.

By combining advanced transaction types with gasless architectures, Ethereum continues to evolve into a more scalable and user-friendly platform. Developers leveraging these tools can build inclusive dApps that lower entry barriers and drive mass adoption.