What is a meta transaction?
A meta transaction is a transaction that a user authorizes by signing a message off-chain, while a third party called a relayer submits it on-chain and pays the gas fee. The user never touches the native token needed for gas. They just sign, and the relayer handles the rest.
This is what makes "gasless" crypto experiences possible. A user sending USDC does not need to hold ETH for gas at all. Someone else, usually the app or platform they are using, covers that cost behind the scenes.
How does a meta transaction work?
A meta transaction involves four roles working together:
- Transaction signer: The user. They sign a message describing the transaction they want executed, typically using the EIP-712 standard, which shows exactly what is being signed rather than an opaque hash
- Relayer (gas relay): A third party that receives the signed message, pays the gas, and submits it as a real transaction on-chain
- Trusted forwarder: A smart contract that verifies the signature is valid and has not been tampered with, then forwards the original request
- Recipient contract: The contract the user actually intended to call, which executes the requested action
The signing step costs nothing, since it happens off-chain. Only the relayer's on-chain submission actually consumes gas.
Why does a meta transaction need a trusted forwarder?
Without a forwarder, a smart contract cannot tell who really initiated the transaction. When a relayer submits a transaction, the contract's built-in msg.sender value shows the relayer's address, not the user's. A contract using that value directly would treat every meta transaction as coming from the relayer, breaking any logic based on who the actual sender is.
ERC-2771, the standard that formalized this pattern in July 2020, solves it with a trusted forwarder contract. The forwarder verifies the user's signature, confirms it has not been reused or forged, and then extracts the true sender's address for the recipient contract to use. Contracts have to be written to support this pattern from the start, which is one of the standard's practical limitations.
Are meta transactions the same as account abstraction?
No, though they solve overlapping problems. Meta transactions, via ERC-2771, require a contract to be built with the standard in mind. This makes them hard to apply retroactively to contracts already deployed.
Account abstraction, formalized in ERC-4337, takes a different approach that does not require existing contracts to be modified. It has become the more common path for new gasless and sponsored-transaction products, while ERC-2771 remains widely used in existing systems built before ERC-4337 matured.
A related but distinct standard, EIP-2612 (Permit), lets ERC-20 tokens support gasless approvals specifically. Instead of a separate on-chain approval transaction, a user signs a message that grants spending permission directly, removing one of the two transactions a token swap traditionally requires.
Why do meta transactions matter for stablecoin payments?
This is the mechanism that solves one of the most common friction points in stablecoin payments: a user holding USDC or USDT but no ETH, SOL, or other native token to pay for the transfer. Without meta transactions or account abstraction, that user is stuck. They have the money they want to send, but cannot pay to send it.
Platforms building consumer-facing stablecoin products rely on this pattern constantly, whether through classic meta transactions, account abstraction, or a relayer built into a Wallet as a Service provider. The end user experience is the same either way: send stablecoins, never think about gas.
