Design a Gasless Meta-Transaction System

Problem statement

Design a gasless meta-transaction platform for a consumer dApp. Users sign a typed message off-chain with their wallet; a relayer service wraps that signature into a real on-chain transaction, pays the gas from its own funds, and gets the user's intended action executed as if the user had sent it themselves. The dApp sponsor pays for gas as a customer-acquisition cost, the user never holds native gas tokens, and the smart contract must still see the correct logical sender.

This is not a thin API proxy. The system must defeat replay attacks across chains, contracts, and time; keep relayer hot wallets funded without exposing a large treasury; manage per-wallet transaction nonces under concurrency while gas prices move; survive RPC provider outages and chain reorgs; and enforce sponsor budgets so one abusive user cannot drain the treasury. Every one of those is a hard distributed-systems problem wrapped around a cryptographic primitive.

Why the problem is distinctive

A normal web backend can retry an idempotent write. On Ethereum, a retry with the same nonce and same fee can be silently dropped, a retry with a higher fee replaces the transaction, and a retry after the chain state moved can execute a stale intent the user would no longer want. Public mainnet has historically sustained only about 1M-1.7M transactions per day - roughly 12-17 TPS average (publicly reported network figures) - and during past congestion peaks simple transfers have cost the equivalent of several dollars while complex DeFi calls reached tens of dollars. That friction is exactly what kills mainstream onboarding, and it is why meta-transaction relays exist.

The defining split in this design is between intent and execution. The user produces a signed intent (an EIP-712 typed-data signature over the action, a nonce, a deadline, and the verifying contract). The relayer produces execution (a funded, broadcast, eventually-included transaction). Neither half is trustworthy alone: a signature without relay discipline is stuck forever; a relay without signature verification is an open faucet that lets anyone spend the sponsor's funds.

Public operating baseline versus design assumptions

Public evidence establishes the category. OpenZeppelin Defender's Relay product is documented as managing server-side nonces for meta-transactions and is publicly described as used by teams such as PoolTogether and Opyn. Biconomy's Mexa SDK documents a trusted-forwarder gasless pattern widely deployed on Polygon. Gelato Relay documents sponsored calls and ERC-20 fee collection. The Gas Station Network (now OpenGSN) documents RelayHub staking and penalization. EIP-4337 account abstraction, proposed in September 2021 with its mainnet EntryPoint deployed in 2023, is the publicly documented successor pattern with bundlers and paymasters. These are cited reference points, not requirements for our system.

For capacity planning this answer explicitly assumes a mature product with 1M monthly active users, 150K daily active users, and 300,000 sponsored meta-transactions per day across Ethereum mainnet, Polygon PoS, and Base, with an 8x event peak (token drops and NFT mints). Unless a number is tied to a public source, it is a stated design assumption, target, or budget.

The four architectural planes

1. Signing plane: dApp frontend plus wallet produce EIP-712 typed-data signatures with a replay-safe payload.
2. Relay plane: intake API, validation pipeline, job ledger, gas oracle, nonce manager, relayer workers, and receipt reconciliation.
3. On-chain plane: trusted forwarder (EIP-2771 style) verifying signatures and exposing the true sender to application contracts.
4. Economics plane: sponsor budgets, per-user caps, treasury refills, settlement, and cost observability.

A strong interview answer keeps these planes separate. The relay plane may degrade or queue; the on-chain plane must never accept a replayed or forged intent; the economics plane must be able to halt intake without corrupting in-flight jobs.