What Is a Forwarder in Crypto? How Smart Contracts Relay Transactions and Move Funds
A user clicks Withdraw.
A wallet asks for a signature.
A smart contract executes a transaction.
From the outside, this can look like one simple action. Under the hood, however, several different components may be involved—and one of them may be something called a forwarder.
The confusing part is that “forwarder” does not describe one universal piece of blockchain infrastructure. Depending on the system, it can refer to a smart contract that forwards an authorized request to another contract, or to wallet infrastructure that forwards deposited assets from one address to another.
Both involve moving something forward.
But they are not doing the same job.
What Is a Smart Contract Forwarder?
In one of the best-known Ethereum implementations, a forwarder is a smart contract that sits between a user and another smart contract.
Instead of the user directly submitting an on-chain transaction, the user can sign a request off-chain. That request is then submitted to a trusted forwarder, which verifies it and calls the destination contract on the user's behalf.
This model is standardized by ERC-2771, Ethereum's protocol for native meta-transactions. The standard defines four basic participants:
• the transaction signer, who authorizes the action;
• the gas relay, which submits the transaction and pays the blockchain gas;
• the trusted forwarder, which verifies the signed request;
• the recipient contract, which ultimately performs the requested action.
The flow can be simplified like this:
User → signs request → Relayer → Forwarder → Smart Contract
The important distinction is that the user does not necessarily broadcast the blockchain transaction personally.
The user authorizes it.
Someone—or something—else delivers it.
Why Use a Forwarder at All?
Normally, interacting with an Ethereum smart contract requires the user's account to submit a transaction and pay gas in the network's native currency.
That creates a usability problem.
Imagine a user who owns USDC but has no ETH. They may have enough money for the action they want to perform, yet still be unable to execute it because they cannot pay the gas fee.
Meta-transactions can separate those two responsibilities.
The user signs an authorization, while another party submits the actual transaction and pays the gas. ERC-2771 was designed specifically to support this type of interaction.
For a consumer application, that can make blockchain infrastructure feel much more like a traditional app:
Click → sign → done.
The blockchain machinery remains underneath, but the user does not have to manage every part of it directly.
What Does the Forwarder Actually Verify?
A forwarder should not simply accept a message saying:
Send this transaction as Alice.
It needs cryptographic evidence that Alice actually authorized it.
Modern ERC-2771 implementations can verify a signed request containing information such as:
• the user's address;
• the destination contract;
• the amount of native currency attached to the call;
• gas parameters;
• a nonce;
• an expiration deadline;
• the encoded contract call itself.
OpenZeppelin's current ERC2771Forwarder, for example, verifies that the request's signer matches the claimed sender, that the request has not expired, and that the destination contract trusts that forwarder.
The nonce is particularly important.
Without replay protection, someone could potentially take a valid signed authorization and submit it more than once.
For example, a user might intend:
Withdraw $100 once.
A poorly designed system must not allow the same signature to become:
Withdraw $100 again. And again. And again.
Signed structured data is commonly handled using EIP-712, which standardizes how wallets sign structured messages rather than opaque arbitrary bytes. The EIP also explicitly notes that applications must handle replay protection correctly.
How Does the Final Smart Contract Know Who the User Is?
This is where forwarders become technically interesting.
Suppose Alice directly calls a smart contract.
Inside that contract, Ethereum normally exposes Alice as:
msg.sender
But if a forwarder calls the contract, Ethereum sees the forwarder contract as msg.sender.
That creates a problem.
The destination contract needs to know:
Who actually authorized this action?
ERC-2771 solves this by having the trusted forwarder append the original signer's address to the call data.
The recipient contract first verifies that the call came from a forwarder it trusts. It can then recover the original user's address and treat that address as the effective sender.
OpenZeppelin implements this model through ERC2771Context, which allows compatible contracts to use an effective _msgSender() rather than blindly treating the forwarder itself as the user.
So the forwarder is doing more than passing a message.
It is carrying authenticated identity context from one side of the transaction to the other.
Are Forwarders Connected to Crypto Withdrawals?
They can be.
But a forwarder is not inherently a withdrawal contract.
Consider a DeFi application with a function such as:
withdraw(amount)
A user could call that function directly.
Or, if the application supports meta-transactions, the user could sign a request authorizing:
Call withdraw(100) on Contract X.
A relayer could then submit that authorization through a trusted forwarder.
The forwarder verifies the authorization and passes the call to the withdrawal contract.
In that architecture, the forwarder participates in the withdrawal process.
But the forwarder does not necessarily hold the user's assets, determine their balance, or decide whether the withdrawal is economically valid. Those rules usually belong to the destination smart contract.
Conceptually:
User authorization → Forwarder → Withdrawal contract → Asset transfer
The forwarder is the messenger and verifier.
The withdrawal contract is the component that actually enforces the financial logic.
There Is Another Kind of Crypto Forwarder
This is where terminology gets tricky.
Some institutional wallet systems also use forwarder smart contracts for deposit infrastructure.
Here the job is very different.
A platform may want to generate many receive addresses while ultimately keeping funds inside one central wallet structure.
A forwarder address can receive assets and then consolidate them into a wallet's base address.
BitGo, for example, documents multisignature smart-contract wallets that use forwarder contracts to provide multiple receive addresses. On Arbitrum, its forwarders can automatically consolidate received native assets into the wallet's base address, while ERC-20 tokens use a separate consolidation transaction.
That flow looks more like:
Customer deposit → Forwarder address → Base wallet
This is not ERC-2771 meta-transaction forwarding.
It is asset-routing infrastructure.
And that distinction matters enormously.
Deposit Forwarding Is Not the Same as Withdrawal
A wallet provider may deliberately allow a forwarder contract to move deposited tokens into the primary wallet while preventing it from sending those assets anywhere else.
BitGo's documentation provides a useful real-world example. In one multisignature architecture, ERC-20 tokens can be consolidated from forwarder addresses with fewer signing requirements than an external withdrawal. The company explicitly distinguishes this consolidation capability from the authority required to withdraw assets from the wallet.
That means seeing a blockchain transaction labeled with words such as:
forward, flush, consolidate, or forwarder
does not automatically mean a customer withdrawal occurred.
The funds might simply be moving inside a wallet provider's own architecture.
The visible blockchain movement can look similar.
The authorization model underneath it can be completely different.
Forwarder vs. Relayer
These two terms are often mixed together.
They should not be.
A relayer is usually an off-chain service or account that submits transactions to the blockchain and pays gas.
A forwarder is usually the smart contract that validates the user's signed request and forwards the call to the recipient.
So, in an ERC-2771 system:
Signer → Relayer → Forwarder → Recipient
The relayer pays to put the transaction on-chain.
The forwarder validates who authorized it.
The recipient performs the application logic.
One company may operate several of these components, which is why the distinction is often invisible to the end user.
What Does “Trusted Forwarder” Mean?
The word trusted is not cosmetic.
It is a security boundary.
A recipient contract relying on ERC-2771 accepts the forwarder's representation of who originally signed the request.
If a malicious forwarder could falsely claim that a transaction came from another address, authorization checks inside the recipient could become meaningless.
The ERC-2771 specification warns that a malicious forwarder may forge the effective sender address. It therefore recommends extreme care when choosing trusted forwarders and restricting who can change the trusted-forwarder configuration.
In plain English:
If a contract says,
I trust this forwarder to tell me who the real user is,
then compromising that forwarder can become much more serious than compromising an ordinary message-delivery service.
Forwarders Can Create Unexpected Security Problems
Even when individual components are well designed, combining them incorrectly can introduce vulnerabilities.
A notable example appeared in 2023, when researchers disclosed an address-spoofing vulnerability involving contracts that combined ERC-2771-style sender handling with certain Multicall patterns using delegatecall.
Under vulnerable configurations, an attacker could manipulate how the effective sender was interpreted during nested calls. OpenZeppelin described the issue as affecting integrations of ERC-2771 with self-delegate calls using user-controlled data.
Current OpenZeppelin documentation still warns developers that delegatecall can corrupt ERC-2771 execution context if used incorrectly.
The lesson is broader than one vulnerability:
A secure smart-contract standard does not automatically make every architecture built around it secure.
Security also depends on how the pieces interact.
How Does This Compare With Account Abstraction?
Forwarders are also part of a broader effort to make blockchain transactions less dependent on the traditional model where every user directly sends a transaction from a private-key-controlled account.
ERC-4337 account abstraction approaches the problem differently.
Instead of an ERC-2771-style signed forward request, ERC-4337 introduces a higher-level object called a UserOperation. Specialized actors called bundlers collect these operations and submit them through an EntryPoint contract. Optional paymasters can sponsor transaction fees.
So the ecosystem now contains several related concepts:
ERC-2771
User → signed request → relayer → forwarder → contract
ERC-4337
User → UserOperation → bundler → EntryPoint → smart account
Custodial wallet forwarding
Deposit address → forwarder contract → base wallet
They solve different problems, even though all of them insert infrastructure between the user's intent and the final blockchain state.
The Most Important Question Is Not “Was There a Forwarder?”
When analyzing a crypto transaction or smart-contract architecture, the more useful questions are:
What exactly is being forwarded?
Is it:
• a signed instruction?
• contract calldata?
• the identity of the original signer?
• gas payment?
• ETH?
• an ERC-20 token?
• assets being consolidated into another wallet?
Then ask:
Who has authority at each step?
A forwarder that can execute only cryptographically authorized requests is very different from a contract that has discretionary control over assets.
And a deposit forwarder that can move tokens only to a predetermined base wallet is very different from a withdrawal mechanism capable of sending assets to arbitrary external addresses.
The Bottom Line
A forwarder is best understood as infrastructure between an origin and a destination.
In meta-transaction systems, it forwards authorized smart-contract calls.
In some wallet architectures, it forwards assets from receive addresses into a primary wallet.
And in a withdrawal workflow, it may participate in delivering a user's signed instruction to the contract that actually releases the funds.
That is why simply seeing the word forwarder does not tell you who controls the crypto.
The important questions are what the forwarder is allowed to forward, what it verifies before doing so, which contracts trust it, and where the assets are ultimately allowed to go.
On a blockchain, the transaction shows that something moved.
The architecture explains why it was allowed to move.