Meta Transaction

The core feature that allows users to interact with a blockchain without holding the network's native token (e.g., ETH) to pay for gas fees. The transaction's gas costs are instead paid by a third-party relayer or the dApp itself, removing a major onboarding barrier. This enables sponsorship models where applications can subsidize user operations.

Users authorize a transaction by creating a digital signature off-chain using their private key. This creates a signed message (or meta transaction) containing the intended action's details. This signature is cryptographically verifiable but does not incur gas costs, as it is not yet broadcast to the network.

A service (centralized or decentralized) that accepts signed meta transactions, submits them to the blockchain, and pays the gas fees. The relayer's key responsibilities are:

• Broadcasting the packaged transaction.
• Paying the upfront gas in the native token.
• Potentially batching multiple user operations for efficiency. Relayers are often incentivized via a small fee paid in the dApp's token or through other mechanisms.

A smart contract (e.g., a Minimal Forwarder or the dApp's core contract) that validates the meta transaction on-chain. Its critical functions are:

• Signature Verification: Uses ecrecover to confirm the signature matches the user's address and the transaction data.
• Nonce Management: Ensures each signed message can only be executed once to prevent replay attacks.
• Execution: Upon successful verification, it calls the target function with the user's original parameters.

Key standards that formalize and extend meta transaction patterns. ERC-2771 (Meta Transactions) defines a secure protocol for trusted forwarding, preserving the original msg.sender. ERC-4337 (Account Abstraction) generalizes the concept with UserOperations, Bundlers as relayers, and Paymasters for gas payment, creating a more robust and decentralized system for gasless interactions.

This architecture enables several pivotal applications:

• Onboarding: Users can start using a dApp with only an ERC-20 token, no native gas token required.
• Subscription Services: Apps can pay gas for users as part of a service model.
• Batch Operations: A relayer can bundle many user actions into a single transaction, reducing overall gas costs.
• Improved UX: Removes the friction of wallet pop-ups for gas estimation and approval on every action.

A meta transaction allows a user to sign a transaction intent without holding the blockchain's native token (e.g., ETH) for gas. A relayer or paymaster then submits the signed message, pays the gas fee, and executes the transaction on the user's behalf. This removes a major onboarding friction for new users.

• User Experience: Enables 'gasless' or 'sponsored' transactions.
• Example: A dApp can pay for its users' gas fees as a customer acquisition cost.

Specialized services operate as relayers to broadcast signed meta transactions. They handle gas estimation, nonce management, and submission. Key components include:

• Gas Stations: Services like the Gas Station Network (GSN) provide relay infrastructure.
• Fee Delegation: Protocols implement logic to allow a third party to be reimbursed for gas costs.
• Security: Relayers must be trusted not to censor or front-run transactions, though cryptographic signatures prevent tampering with the intent.

By decoupling signing from execution, meta transactions enable efficient transaction batching. A single on-chain transaction from a relayer or bundler can execute multiple user-signed actions.

• Cost Reduction: Aggregating actions reduces overall gas costs per user operation.
• Atomicity: Multiple actions can be executed as a single atomic unit, improving user experience for complex interactions like token swaps with approvals.

Meta transactions enable new dApp business models centered on gas sponsorship. A project can pay for its users' transactions to:

• Onboard Users: Eliminate the need for users to acquire gas tokens first.
• Promote Usage: Subsidize fees during promotions or for specific actions.
• Abstract Complexity: Hide gas price volatility and network congestion from end-users, providing a predictable cost structure.

Real-world applications of meta transactions span multiple verticals:

• Gaming: Players can perform in-game actions without managing gas.
• Social & Identity: Gasless attestations for decentralized identity (e.g., Ethereum Attestation Service).
• DeFi: Allow new users to interact with a protocol using only stablecoins, not native gas tokens.
• Multi-Chain: Facilitate interactions on L2s or new chains where users may not yet hold the native gas token.

Users must trust the relayer to submit their signed message. A malicious or faulty relayer can:

• Censor transactions by refusing to relay them.
• Front-run transactions for profit.
• Fail to pay gas, causing transaction reversion. Mitigations include using decentralized relay networks, reputation systems, or allowing users to pay gas directly as a fallback.

A signed meta-transaction must be usable only once. Key mechanisms include:

• Nonces: A sequentially incrementing number stored in a smart contract for each signer.
• Chain ID: Including the EIP-155 chain identifier in the signed data to prevent cross-chain replay.
• Deadlines: Expiration timestamps to invalidate stale signatures. Without these, a signature could be re-submitted maliciously.

The verifying contract must correctly reconstruct and validate the signed message hash. Critical checks include:

• Using ecrecover or OpenZeppelin's ECDSA library to verify the signer.
• Ensuring the signature corresponds to the intended executor (e.g., a trusted forwarder contract).
• Validating all parameters (nonce, chainId, function call data) are exactly as signed to prevent parameter substitution attacks.

The relayer pays gas, but the user's code executes. This creates risks:

• Out-of-gas reverts: Complex user logic may exceed the gas stipend provided by the relayer, causing failed transactions and lost relay fees.
• Gas griefing: Malicious user code could consume excessive gas within the limit, wasting the relayer's funds. Relayers often use gasleft() checks or set strict gas limits for specific function calls.

The meta-transaction forwarder is a privileged contract. Security considerations include:

• Whitelisting: Restricting which target contracts can be called via the forwarder to prevent unauthorized actions.
• Upgradability: If the forwarder is upgradeable, ensure a secure governance process to prevent malicious upgrades.
• Re-entrancy guards: The forwarder itself must be protected against re-entrancy when calling external contracts.

While meta-transactions can hide the user's gas-paying address, they expose the signing address. This creates a privacy trade-off:

• The signed message and its origin (the relayer's IP) can potentially link the signing address to real-world identity.
• All actions signed by the same key are linkable on-chain. Solutions like delegated signing or using fresh addresses for sensitive actions can enhance privacy.