Meta Transaction

Overview

A user first signs structured data describing the intended action rather than broadcasting a standard network transaction. The signed message can specify the contract, function, parameters, chain, nonce, and deadline. A relayer packages that message into an on-chain transaction and pays the native network fee.

A trusted forwarder or application contract verifies the signature and recovers the original user identity. The contract must not confuse the relayer’s address with the user’s address. Standards and frameworks define patterns for forwarding and typed-message signing, but implementations still need careful review.

Meta transactions improve onboarding because users can interact without first acquiring a native fee asset. A platform can sponsor fees, charge them in another token, or include them in service pricing.

Risks include replay across chains or contracts, overly broad signatures, malicious relayers, and hidden fee recovery. The relayer may delay or refuse submission even though it generally cannot alter the signed action.

Applications should show the exact action and any service cost before signing. Nonces and deadlines should make each authorization one-time and time-bounded. Meta transactions separate user authorization from network submission; they do not eliminate transaction fees or smart-contract risk.

Relayer economics need explicit design. A service may sponsor only approved actions, require authentication, limit daily usage, or recover cost through the application. Without abuse controls, attackers can consume the sponsor’s balance with valid but unwanted transactions. Relayers should simulate requests before submission and enforce contract, function, value, and gas limits. Users should also have a fallback path when the relayer is unavailable.