A meta transaction is a transaction a user signs but never sends. Instead of broadcasting it and paying gas themselves, they hand the signed message to a third party — a relayer — who wraps it into a real Ethereum transaction and pays the fee. ERC-2771 is the standard that makes this handoff safe, giving a smart contract a reliable way to tell who actually signed a request instead of trusting whoever happened to submit it.
Here’s the short version: meta transactions let people use a dApp without holding any ETH first, and ERC-2771 is what stops a relayer from forging someone else’s signature in the process. The pattern shows up anywhere a project wants to remove the “buy gas before you can do anything” step from onboarding. This guide moves from the basic idea to the mechanics, the standard itself, and how it compares to newer alternatives like ERC-4337.
What Does “Gasless” Actually Mean?
“Gasless” is a bit of a simplification — gas still gets paid, just not by the person signing the transaction. A meta transaction separates two things that normally happen together: authorizing an action and paying for it to run.
Meta transaction: a transaction whose signer is not the account that broadcasts it or pays for it. The user signs a message describing what they want to do; a separate relayer submits that message as a real transaction and covers the gas. See EIP-2771 for the formal specification.
In a standard Ethereum transaction, one account does both jobs — it signs the transaction and pays the gas to get it mined. A meta transaction splits that in two, which sounds small but has a large practical effect: the end user no longer needs a native token balance to interact with a contract.
A Relayed Transaction vs. a Normal One
The mechanics are identical either way — same call, same target contract. What changes is who signs, who broadcasts, and who pays, laid out side by side below.
| Normal transaction | Meta transaction | |
|---|---|---|
| Who signs it | The user | The user |
| Who broadcasts it | The user’s wallet | A relayer |
| Who pays the gas | The user | The relayer (or a paymaster behind it) |
| Native token required from the user | Yes | No |
Everything about the underlying smart contract call stays identical. What changes is who’s holding the wallet that actually pushes the transaction onto the chain.
Why Do Users Need Someone Else to Cover Gas?
The problem meta transactions solve is a bootstrapping one: sending any Ethereum transaction — including the transaction that would buy you gas — requires already having some ETH in your wallet. A brand-new wallet with a zero balance is stuck before it starts.
Sachin Tomar, one of the engineers who co-authored EIP-2771 and later built gas-sponsorship tooling at Biconomy, put the problem plainly. “Having to hold ETH to interact with Dapps is a completely alien concept,” he wrote in a Biconomy engineering post. “More than that, it’s a huge inconvenience.” That’s the gap meta transactions close — not the dollar cost of gas, but the requirement to already hold a specific token before doing anything at all.
This is worth separating from the “gas is expensive” narrative, which is less true than it used to be — mainnet gas currently runs well under 1 gwei according to Etherscan’s live tracker, a fraction of a cent per transfer. The friction isn’t the price — it’s needing to own the right asset before your very first click.
That friction is measurable. One analysis of crypto activation funnels found only 32% of new wallet users complete a first transaction within their first week, versus more than 76% for typical fintech apps, according to a product case study on Web3 onboarding. Removing the “go acquire ETH first” step is one of the few onboarding fixes a dApp can make entirely on its own.
Who Actually Uses Gasless Transactions?
Meta transactions show up wherever a project wants a new user’s first action to feel like using a normal app, not a crypto wallet. A few patterns account for most real deployments:
- Consumer and gaming dApps that want a sign-up flow without a “first, buy some ETH” step scaring off non-crypto users.
- NFT platforms, where sponsoring the mint removes gas as a reason someone abandons a claim — a close cousin of lazy minting, which defers cost the same way for one mint function instead of a whole contract.
- DAOs and governance tools, where members sign a vote off-chain and the platform submits it — Snapshot’s gasless voting is the most widely used example at the governance layer.
- Wallet providers and embedded-wallet SDKs, which sponsor a user’s first few transactions before asking them to fund their own wallet.
How Does a Relayed Transaction Work, Step by Step?
Underneath the different products, the flow stays close to identical. Here’s the sequence a typical ERC-2771 meta transactions follow:
- The user signs an off-chain EIP-712 message describing the function call they want made, plus a nonce to stop it being replayed.
- The signed message goes to a relayer, typically over a normal API call rather than anything broadcast to the network.
- The relayer wraps the message in a real transaction and submits it to the chain, paying the gas itself.
- A trusted forwarder contract receives it, checks the signature and nonce, and — if valid — calls the target contract with the signer’s address appended to the calldata.
- The target contract reads that appended address through an overridden function instead of the raw caller, so its logic runs exactly as though the user had sent the transaction directly.
Before any of this reaches the chain, a relayer typically checks the call would actually succeed — the same kind of pre-broadcast simulation a wallet runs before you sign, just triggered by the relayer instead of the end user. There’s little point paying gas for a signed request that’s only going to revert.
What Is a Trusted Forwarder Contract?
Trusted forwarder: a smart contract a recipient contract explicitly agrees to trust. It verifies a signed request’s signature and nonce, then calls the recipient with the real signer’s address appended to the calldata, as defined in EIP-2771.
This is the piece that makes the pattern safe rather than just convenient. A contract that blindly trusted whatever address called it would let a relayer impersonate anyone, so the forwarder pattern instead makes the recipient check a signature before accepting who the “real” sender is. OpenZeppelin ships this as a ready-made building block — its ERC2771Context and ERC2771Forwarder contracts are how most Solidity projects add support without writing forwarder logic from scratch.
What Standard Makes This Safe to Implement?
ERC-2771, titled “Secure Protocol for Native Meta Transactions,” is the standard behind everything above. It was proposed on July 1, 2020 by eleven authors, including Ronan Sandford, Alex Forshtat, and Sachin Tomar, and now carries Final status on Ethereum’s standards track — meaning the specification is considered stable.
The problem it standardizes is narrower than “how to do meta transactions” — specifically, how a contract recognizes the real sender when different relayers and forwarders are involved. Before ERC-2771, every project built its own version of that sender-verification logic, so a forwarder from one provider rarely worked with a contract built for another.
The spec is also direct about the failure mode: “a malicious forwarder may forge the value of _msgSender() and effectively send transactions from any address.” That’s why a contract has to explicitly opt into trusting a specific forwarder rather than accepting one by default — get that trust relationship wrong, and every guarantee built on top of it collapses.
Who Pays the Relayer, and Why Would They Bother?
A relayer needs a reason to keep fronting gas for other people’s transactions. That reason is usually a paymaster — logic, sometimes a server and sometimes a contract, that decides whether a given request is worth sponsoring.
| Component | Role |
|---|---|
| User | Signs an off-chain request; never touches gas |
| Relayer | Wraps the request in a real transaction and pays the gas |
| Trusted forwarder | On-chain contract that checks the signature and nonce |
| Paymaster | Decides whether to accept the request — by whitelist, ERC-20 payment, or the app’s own rules |
| Recipient contract | The dApp’s contract, reading the real sender through _msgSender() |
OpenGSN, the most widely used open implementation of this pattern, runs the relayer/paymaster split across Ethereum, Polygon, Optimism, Arbitrum, Avalanche, BSC, and Gnosis Chain. A paymaster can reject spam, require extra verification, or simply charge a stablecoin instead of ETH — “gasless” for the end user doesn’t always mean free, just paid in a different token.
Running that relayer infrastructure is itself a node-access problem — reading the current nonce and gas price, broadcasting the signed result, watching for confirmation, the same RPC layer any dApp backend depends on. Providers like NOWNodes offer that access across 120-plus networks, so a relayer service doesn’t need to run and sync its own node just to keep sponsoring transactions.
How Does This Compare to Account Abstraction (ERC-4337)?
ERC-2771 isn’t the only way to take gas out of a user’s hands, and it’s worth knowing where it stops being the right tool. ERC-4337, Ethereum’s account abstraction standard, solves an overlapping problem with a different architecture — instead of a trusted forwarder relaying signed calls to an unmodified contract, it replaces the user’s wallet itself with a smart contract account.
| Factor | ERC-2771 (meta transactions) | ERC-4337 (account abstraction) |
|---|---|---|
| Contract changes needed | Target contract must inherit a forwarder-aware base like ERC2771Context | None — the target contract stays untouched |
| Wallet type | Any regular wallet (EOA) | A smart contract account |
| Who verifies the request | The trusted forwarder contract | The wallet’s own validation logic, checked by a bundler |
| Sponsorship logic | Off-chain, inside relayer/paymaster server code | On-chain, inside a paymaster contract |
| Best fit | One dApp sponsoring gas for its own contracts | Broader smart-account features: batching, session keys, flexible sponsorship |
Neither replaces the other cleanly. ERC-2771 is simpler to bolt onto one existing contract — inherit a base contract, point it at a forwarder, done. ERC-4337 asks for more setup, a smart contract wallet plus bundler infrastructure, but it never touches the target contract at all, since sponsorship logic lives at the wallet layer instead.
A newer piece of the roadmap blurs the line further. EIP-7702, live since Ethereum’s Pectra upgrade on May 7, 2025, lets a regular wallet temporarily delegate to smart-contract code and pick up features like sponsored transactions without switching wallets entirely. It still typically needs a bundler to relay anything, so the who-pays-who-verifies question doesn’t disappear — it just moves to a different standard.
What Are the Risks of Relying on a Relayer?
The security of this whole pattern rests on one assumption: the trusted forwarder is actually trustworthy. A forwarder with a bug, or one the project doesn’t fully control, lets an attacker forge the appended sender address and act as anyone — exactly why it’s a natural candidate for a proper security audit before real funds depend on it.
Liveness is a separate risk. A signed meta transaction still needs a relayer willing to submit it — if that relayer or its paymaster goes offline or runs dry, the message goes nowhere until another one picks it up, a form of centralization a plain, self-broadcast transaction doesn’t carry.
None of this shortens what happens on-chain, either. The call still has to succeed once it lands, gas still gets paid by someone, and a paymaster still needs rules sane enough not to get drained by spam dressed up as legitimate requests.
Conclusion
A meta transaction is a signature without a broadcast — the user authorizes an action, and a relayer turns that authorization into a real, paid-for transaction. ERC-2771 is what makes the handoff safe, giving contracts a standard way to trust an appended sender address instead of every provider inventing its own version of the same check.
Whether it’s the right tool depends on the project. A single dApp sponsoring gas for its own contracts can add ERC-2771 support with a few lines of inherited code; a team building broader wallet infrastructure is more likely to end up at ERC-4337 or EIP-7702 instead. Either way, the goal is the one Sachin Tomar described before the space had this many acronyms attached to it: nobody should have to solve a token-acquisition puzzle before they can use an application.
FAQ
Does “Gasless” Mean Something Different?
Not exactly. “Gasless” describes what the user experiences, while “meta transaction” describes the specific ERC-2771 mechanism behind it. Other approaches, like ERC-4337 sponsorship, also produce a gasless experience without using meta transactions at all.
Do I Have to Trust the Relayer With My Funds or Private Key?
No. A relayer only ever sees a signed message authorizing one specific action — it never receives your private key and can’t sign anything else on your behalf. The real trust decision sits with the forwarder contract’s logic, not with handing custody to the relayer.
Does This Standard Work on Chains Other Than Ethereum?
Yes. It’s an application-level standard rather than a change to Ethereum’s protocol, so any EVM-compatible chain — Polygon, BNB Smart Chain, Arbitrum, and others — can run the same trusted-forwarder pattern.
Do Gasless Transactions Really Cost the User Nothing?
Usually nothing in the network’s native token, but not always nothing at all. Some paymasters recover their cost by charging a stablecoin or the app’s own token instead of waiving the fee outright.
Is This Still the Right Standard to Use in 2026?
For a single dApp sponsoring gas on its own contracts, yes — it’s simple and has years of production use behind it. Teams building broader smart-account infrastructure increasingly reach for ERC-4337 or EIP-7702 instead, since neither requires modifying every contract a user might touch.
