A meta-transaction is a transaction a user signs but does not send. The user signs a request, for example "call this function on this contract", and a relayer submits it to the blockchain and pays the gas. The contract still knows who the real user is. It is one of the oldest ways to make an application gasless, and it works with any wallet, including regular wallets such as MetaMask.
ERC-2771 is the standard that defines how this works securely: how the contract receives the request and how it learns the original sender. For an overview of all gasless methods, including paymasters and EIP-7702, see gasless transactions.
How ERC-2771 Works
- The user signs a request as an EIP-712 message: the target contract, the function call, a nonce, a gas limit and a deadline.
- The relayer submits it to a trusted forwarder contract and pays the gas.
- The forwarder verifies the signature, the nonce and the deadline, then calls the target contract with the original user's address appended to the call data.
- The target contract reads the real sender through
_msgSender()instead ofmsg.sender, but only when the call comes from the forwarder it trusts.
The result: the transaction is paid for by the relayer, but every permission check, balance and event in your contract is tied to the user.
What We Build
- ERC-2771-aware contracts: contracts that consistently use
_msgSender(), including in inherited code and access control. - Forwarder setup: deploying or reusing a well-reviewed forwarder, and deciding how the trusted forwarder can be changed, if at all.
- Relayer service: the backend that receives signed requests, checks your sponsorship rules, simulates the call, submits it and tracks it until confirmed.
- Front-end signing flow: clear signature requests that show users in plain language what they authorise.
Running a Relayer Properly
The relayer is where most of the operational work sits:
- Nonce and queue management: sending many transactions from relayer wallets without one stuck transaction blocking the rest.
- Fee handling: setting gas fees so requests confirm without overpaying, and replacing transactions that get stuck, see EIP-1559 fee handling.
- Simulation before sending: a request that reverts still costs the relayer gas, so every request is simulated first and rejected if it would fail.
- Sponsorship rules and limits: which users, contracts and functions are covered, and how much per user per day, so bots cannot drain the relayer.
- Funding and monitoring: relayer wallets topped up automatically, with alerts on balance, failure rates and unusual activity.
Security Pitfalls
- The forwarder is fully trusted: whoever controls it can act as any user towards your contract. Only trust a forwarder you have reviewed, and treat changing it as a critical admin action behind a multisig.
- Multicall combined with ERC-2771: in late 2023, contracts that combined ERC-2771 with a multicall function turned out to be vulnerable to address spoofing, because the appended sender could be forged inside a batched call. Libraries have since been fixed; any contract with both features needs explicit review.
- Mixing msg.sender and _msgSender: one function or inherited library that still uses
msg.sendertreats the relayer as the user. We check every path. - Replay: requests are bound to a chain, a forwarder, a nonce and a deadline, so they cannot be reused elsewhere or later.
ERC-2771, ERC-4337 or EIP-7702?
ERC-2771 works with any wallet, but every contract must support the forwarder, so it fits best when you control the contracts users interact with. ERC-4337 with paymasters moves the logic into smart accounts and works with any contract, but users need a smart account. EIP-7702 gives existing wallets smart account features, bridging both worlds. For token approvals and transfers alone, permit signatures and EIP-3009 are often simpler. We help you choose, and many projects combine methods.
Frequently Asked Questions about Meta-Transactions
Do users need a special wallet for meta-transactions?
No. Any wallet that can sign EIP-712 messages works, including MetaMask and hardware wallets. That is the main advantage over approaches that require smart accounts.
Can I add meta-transactions to an existing contract?
Only if the contract can be upgraded or redeployed. Support for the trusted forwarder has to be built into the contract; an immutable contract without it cannot accept meta-transactions.
Who pays for meta-transactions?
The relayer, which is usually operated by you or a relayer service you pay. You decide which requests to sponsor; requests outside your rules are simply not relayed.
Is ERC-2771 still relevant now that account abstraction exists?
Yes, especially for apps whose users have regular wallets and whose contracts you control. It is simple, well understood and cheap to run. For new smart-wallet based products, ERC-4337 or EIP-7702 is often the better long-term route.
Who owns the code?
Ownership of the source code is set out in the contract, and the code can be fully yours, including documentation and tests.
Part of our work on blockchain signatures. See also blind signing prevention.
Add Meta-Transactions to Your App
Tell us about your contracts and your users' wallets. We will tell you whether ERC-2771 is the right route and build the contracts and relayer to run it safely.