Meta-Transaction Explained in Detail
A meta-transaction separates authorization from submission. The user signs a request, and another party submits it on-chain.
In ERC2771, the recipient trusts a forwarder that verifies the request and appends the original signer to calldata.
Smart contract example
address user = _msgSender();
Meta-transaction-aware contracts often use _msgSender() instead of raw msg.sender.
Meta-Transaction in Auditing
Meta-transactions change caller assumptions. The relayer is not the user, and the recipient must recover the intended signer safely.
Auditors check forwarder trust, signature binding, nonce use, and replay protection.
Red flags in code
-
Access control uses raw
msg.senderafter adding meta-transaction support. -
Trusted forwarder can be changed by a weak admin.
-
Signed requests omit nonce, chain, target, calldata, or deadline.
-
Untrusted callers can spoof appended signer data.
-
Relayed and direct call paths behave differently in sensitive functions.
How to test or review it
-
Call functions directly and through the forwarder.
-
Try spoofing signer calldata from an untrusted address.
-
Replay the same signed request.
-
Test wrong chain, wrong target, expired deadline, and wrong nonce.
-
Verify
_msgSender()is used consistently in authorization logic.
Keep learning this topic
ERC2771
ERC2771 is a meta-transaction standard where a trusted forwarder calls a recipient contract and appends the original signer to calldata.
Trusted Forwarder
A trusted forwarder is the ERC2771 contract a recipient trusts to verify signed requests and relay calls with the original signer appended.
msg.sender
msg.sender is the address that directly called the current Solidity function in the current EVM call context.
Practice this in real audit scenarios
Definitions help, but auditors need reps. SCH turns concepts like Meta-Transaction into exploit labs, code review habits, and report-writing practice.
Start the free trial or see the full smart contract auditing course.