What Do You Need Before You Start?<\/h2>\n\n\n
Four things need to be in place before writing any code for this ERC-2771 implementation. Skipping one tends to surface as a confusing bug three steps later rather than an obvious error up front.<\/p>\n\n\n\n
- \n
- A contract you can still modify.<\/strong> Forwarder support has to be built in from the start \u2014 there’s no way to add ERC-2771 to a contract that’s already deployed and immutable (more on upgradeable contracts in the FAQ below).<\/li>\n\n\n\n
- A trusted forwarder<\/strong> \u2014 either your own deployment of OpenZeppelin’s ERC2771Forwarder, or one already running on your target network.<\/li>\n\n\n\n
- A signing library<\/strong> on the client side. ethers.js and viem both handle EIP-712 typed-data signing natively, which is the format a forwarder expects.<\/li>\n\n\n\n
- Something to relay the transaction<\/strong> \u2014 your own backend wallet, or a relayer network, covered in the comparison further down.<\/li>\n<\/ul>\n\n\n
Step 1: How Do You Make a Contract Forwarder-Aware?<\/h2>\n\n\n
Inheriting ERC2771Context<\/a> and passing a forwarder address to the constructor is the entire contract-side change. It overrides
_msgSender()<\/code> so the contract reads the real signer instead of the forwarder’s own address, without touching any of the contract’s actual logic:<\/p>\n\n\n\nimport {ERC2771Context} from \"@openzeppelin\/contracts\/metatx\/ERC2771Context.sol\";\n\ncontract MyDapp is ERC2771Context {\n constructor(address trustedForwarder) ERC2771Context(trustedForwarder) {}\n\n function doSomething() external {\n address user = _msgSender(); \/\/ the real signer, not the forwarder\n \/\/ your logic here, unchanged\n }\n}<\/code><\/pre>\n\n\n\nThat’s the whole change for a simple contract, and it’s the foundation every other part of an ERC-2771 implementation builds on. Two situations complicate it: multiple inheritance, where every parent contract reading
msg.sender<\/code> directly needs to call_msgSender()<\/code> instead, and any use ofMulticall<\/code>, which needs a specific fix covered in the security section rather than glossed over here.<\/p>\n\n\nStep 2: Where Does the Forwarder Contract Come From?<\/h2>\n\n\n
The choice is control versus setup time. Deploying your own forwarder gives you one dedicated, verified contract with no dependency on anyone else’s infrastructure. Pointing your contract at a forwarder a relayer network already runs means less deployment work, at the cost of trusting infrastructure you don’t control.<\/p>\n\n\n\n
![\"\"](\"https:\/\/nownodes.io\/blog\/wp-content\/uploads\/2026\/08\/image-38-1024x683.png\")
<\/figure>\n\n\n\nMost teams shipping a single dApp deploy their own, the simplest path to an ERC-2771 implementation with no external dependencies. It takes minutes: deploy
ERC2771Forwarder<\/code> with aname<\/code> string \u2014 used in its EIP-712 domain \u2014 then point your contract’s constructor at its address. The constructor signature is justconstructor(string memory name) EIP712(name, \"1\")<\/code>, and that name has to match exactly what your signing code uses in the next step.<\/p>\n\n\n\nEither way, the trusted forwarder’s address isn’t something to hardcode and forget. If it’s ever found to be compromised or buggy, a project needs a way to stop trusting it \u2014 which is why some teams deliberately keep
_trustedForwarder<\/code> upgradeable instead of immutable, a trade-off covered below.<\/p>\n\n\nStep 3: How Do You Build and Sign the Off-Chain Request?<\/h2>\n\n\n
The signer never touches the blockchain directly \u2014 that separation is the whole point of how you implement meta transactions this way. They sign a structured EIP-712 message describing the call they want made, and hand the signature to whatever relays it:<\/p>\n\n\n\n
javascript<\/p>\n\n\n\n
const domain = {\n name: \"MyForwarder\", \/\/ must match the name passed to the forwarder's constructor\n version: \"1\",\n chainId: 1,\n verifyingContract: forwarderAddress,\n};\n\nconst types = {\n ForwardRequest: [\n { name: \"from\", type: \"address\" },\n { name: \"to\", type: \"address\" },\n { name: \"value\", type: \"uint256\" },\n { name: \"gas\", type: \"uint256\" },\n { name: \"nonce\", type: \"uint256\" },\n { name: \"deadline\", type: \"uint48\" },\n { name: \"data\", type: \"bytes\" },\n ],\n};\n\nconst message = {\n from: signerAddress,\n to: targetContractAddress,\n value: 0,\n gas: 200000,\n nonce: await forwarder.nonces(signerAddress),\n deadline: Math.floor(Date.now() \/ 1000) + 3600,\n data: targetContract.interface.encodeFunctionData(\"doSomething\", []),\n};\n\nconst signature = await signer.signTypedData(domain, types, message);<\/code><\/pre>\n\n\n\nEIP-712 domain:<\/strong> a set of contract-specific values \u2014 name, version, chain ID, and verifying contract address \u2014 mixed into every signature so it can’t be replayed against a different contract or a different chain. See EIP-712<\/a> for the full specification.<\/p>\n\n\n\n
The
nonce<\/code> comes from the forwarder’s ownnonces()<\/code> mapping, anddeadline<\/code> is a plain Unix timestamp \u2014 an hour out in the example above. Both exist so a signed request can’t be replayed or left to sit indefinitely before someone finally submits it. <\/p>\n\n\nStep 4: How Does the Relayer Actually Submit It?<\/h2>\n\n\n
This is the one on-chain step, and the only place gas gets spent. The relayer takes the signed message and calls the forwarder’s
execute()<\/code> function \u2014 but the struct it submits isn’t identical to what got signed:<\/p>\n\n\n\nconst request = {\n from: signerAddress,\n to: targetContractAddress,\n value: 0,\n gas: 200000,\n deadline,\n data: callData,\n signature,\n};\n\nawait forwarder.execute(request); \/\/ relayer's wallet pays gas, not the signer's<\/code><\/pre>\n\n\n\nNotice
nonce<\/code> is missing here. The on-chainForwardRequestData<\/code> struct doesn’t store it \u2014 the forwarder looks up the current nonce itself<\/a> and checks it against what was signed, rather than trusting a value the caller provides. Assuming the signed struct and the submitted struct share the same shape is a common first-integration mistake.<\/p>\n\n\n\nCalling
verify()<\/code> beforeexecute()<\/code> costs nothing and confirms a request is still good \u2014 signature intact, nonce current, deadline not passed \u2014 which is worth doing before spending gas on a call that might revert anyway.<\/p>\n\n\nShould You Run Your Own Relayer or Use a Network?<\/h2>\n\n\n
Someone has to operate the piece that watches for signed requests, decides which ones to sponsor, and actually submits them. Whichever way you implement meta transactions in production, a few established options handle this piece differently enough that the choice matters:<\/p>\n\n\n\n
Relayer<\/th> Model<\/th> ERC-2771 support<\/th> Network reach<\/th> Notable number<\/th><\/tr><\/thead> OpenGSN<\/a><\/td> Open-source; self-host or integrate with its existing relay infrastructure<\/td> Native \u2014 the original reference implementation<\/td> 7 networks<\/a>: Ethereum, Polygon, Optimism, Arbitrum, Avalanche, BNB Smart Chain, Gnosis Chain<\/td> Longest production track record of the four<\/td><\/tr> Gelato Relay<\/a><\/td> Hosted, decentralized executor network<\/td> Native \u2014 dedicated sponsoredCallERC2771<\/code> andcallWithSyncFeeERC2771<\/code> methods<\/td>17 EVM networks<\/td> 1Balance lets one deposit cover gas across every supported chain<\/td><\/tr> Biconomy<\/a><\/td> Hosted, built around its own smart-account stack<\/td> Indirect \u2014 current tooling centers on ERC-4337 rather than ERC-2771 forwarding<\/td> Multiple EVM networks<\/td> 70M+ transactions processed, 4.5M+ smart accounts deployed<\/td><\/tr> OpenZeppelin Relayer<\/a><\/td> Open-source, self-hosted<\/td> General-purpose \u2014 pairs with any forwarder, not ERC-2771-specific<\/td> EVM, Solana, and Stellar<\/td> Licensed AGPL v3.0<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n OpenGSN and Gelato Relay are the two built specifically around the trusted-forwarder pattern, which makes either a faster starting point for an ERC-2771 implementation than wiring up general-purpose relay infrastructure yourself. Biconomy and OpenZeppelin Relayer are worth knowing about, but neither is an ERC-2771-first tool the way the other two are.<\/p>\n\n\n
How Do You Test Before Going to Mainnet?<\/h2>\n\n\n
Deploy the same ERC-2771 implementation \u2014 forwarder, forwarder-aware contract, signing code \u2014 to a testnet first, and run through the full signed-request-to-execute() flow with worthless test ETH before anything touches real funds. A forwarder bug is exactly the kind of thing that’s cheap to catch on a testnet and expensive to discover in production.<\/p>\n\n\n\n
Before that, use
verify()<\/code> and a plaineth_call<\/code> against the forwarder to simulate the request<\/a> without spending any gas at all \u2014 the same pre-flight check a wallet runs before you sign anything, just triggered from your own test script instead. Testnet access is the one piece of infrastructure every step in this ERC-2771 tutorial depends on; providers like NOWNodes<\/a> give RPC access to Ethereum and 120-plus other networks so a team can test a forwarder deployment without running and syncing a node just for that.<\/p>\n\n\nWhat Security Mistakes Have Actually Cost Real Projects?<\/h2>\n\n
The ERC2771Context + Multicall Address-Spoofing Bug<\/h3>\n\n\n
- A trusted forwarder<\/strong> \u2014 either your own deployment of OpenZeppelin’s ERC2771Forwarder, or one already running on your target network.<\/li>\n\n\n\n
![\"\"](\"https:\/\/nownodes.io\/blog\/wp-content\/uploads\/2026\/08\/image-39-1024x683.png\")
<\/figure>\n\n\n\n