ERC-2771 defines how a contract can accept “meta-transactions”: a user signs a request off-chain, a relayer submits it through a trusted forwarder contract and pays the gas, and the recipient contract treats the original signer as the sender. It was the first widely used approach to gasless dApps and remains a simple option for platforms that want to sponsor specific user actions.
Key takeaways
- The forwarder verifies the user’s signature and nonce, then calls the recipient, appending the user’s address to calldata.
- The recipient trusts the forwarder and uses
_msgSender()instead ofmsg.senderto find the real user. - Simpler than ERC-4337 but contract-specific: each recipient must opt in.
- Misconfiguration (e.g. combining with multicall) has caused real exploits — audit carefully.
How it works
- The user signs a
ForwardRequest(from, to, value, gas, nonce, deadline, data) using EIP-712. - A relayer sends the request to the forwarder and pays gas.
- The forwarder checks the signature and nonce and calls the target, appending the 20-byte signer address.
- The target, if
isTrustedForwarder(msg.sender), reads the last 20 bytes of calldata as the sender.
Use cases on tokenization platforms
- Gasless investor actions — claiming distributions, voting, accepting terms.
- Enterprise users — bank or corporate users who must not hold crypto for fees.
- Operational flows — relaying approvals from platform-managed wallets with spending policies in the relayer.
Security pitfalls
- Trusted forwarder must be trustworthy. A malicious or compromised forwarder can impersonate any user.
- Multicall + ERC-2771: delegatecall-based multicall can let attackers spoof
_msgSender; use implementations patched for this interaction. - Replay protection: nonces and deadlines must be enforced by the forwarder.
- Consistency: every function must use
_msgSender(); one straymsg.senderbreaks authorisation.
ERC-2771 vs ERC-4337 vs permit
| Approach | Scope | Best for |
|---|---|---|
| ERC-2771 | Per-contract opt-in | Sponsoring specific actions in your own contracts |
| ERC-4337 | Wallet-level | Full smart-wallet UX across any dApp |
| ERC-2612 | Token approvals | One-step approve-and-pay flows |
How _msgSender() is derived
// Simplified from common ERC-2771 context implementations.
function _msgSender() internal view override returns (address sender) {
if (isTrustedForwarder(msg.sender) && msg.data.length >= 20) {
// the forwarder appended the original signer's address to calldata
assembly { sender := shr(96, calldataload(sub(calldatasize(), 20))) }
} else {
sender = msg.sender;
}
}
Every authorisation check in the recipient — roles, ownership, balances — must use _msgSender(), never msg.sender.
Relayer operations
Running a relayer means paying gas on behalf of users, so it needs controls:
| Control | Purpose |
|---|---|
| Contract allow-list | Only relay calls to your own contracts |
| Function allow-list | Only sponsor specific actions (e.g. claim, vote) |
| Per-user rate limits | Prevent abuse and griefing |
| Gas price caps | Avoid paying for spikes |
| Monitoring and alerting | Detect failures and unusual volumes |
| Key management | Relayer hot wallet funded with limited balances |
Choosing between ERC-2771 and ERC-4337 for a tokenization platform
Use ERC-2771 if you control all target contracts and only want to sponsor a few actions quickly. Use ERC-4337 if you want investors to have smart wallets with recovery, policies and gasless interaction across contracts you do not control.
Frequently asked questions
No. The relayer pays gas; users only sign messages.
Only contracts written to trust a forwarder and use _msgSender(). Existing contracts must be upgraded.
Yes, for targeted sponsorship in your own contracts. For wallet-wide gasless UX, ERC-4337 is more general.
Usually the platform or a relayer service, with rate limits and policies to prevent abuse.
Yes, but every compliance check must use the resolved sender, and the forwarder becomes part of the token’s trust model — audit carefully.
For meta-transactions, yes. Users can still send direct transactions if they hold gas, so design fallbacks.
NUVZ is the RWA and Web3 engineering brand of ESS ENN Associates (est. 1993). Our team has designed and shipped tokenization platforms for real estate, education loans, solar PPAs, energy, carbon credits, bank deposits and trade documents. About us · Case studies
This article is for general information only and is not legal, tax or investment advice. Token standards evolve — always confirm the current status of an ERC at eips.ethereum.org and take advice from qualified counsel in each jurisdiction before issuing tokens.
