This proposal introduces a standardized off-chain relayer architecture for smart accounts. It defines a relayer_* JSON-RPC namespace that complements existing wallet standards, covering fee discovery, transaction submission (including multichain), capability discovery, and status tracking. The goal is to provide a consistent interface for gasless and sponsored transaction flows across any smart account implementation.
PR: Add ERC: Generic Relayer Architecture for Smart Accounts by seansing · Pull Request #1716 · ethereum/ERCs · GitHub
The ERC introduces five JSON-RPC methods under the relayer_* namespace:
| Method |
Purpose |
relayer_getFeeData |
Query the relayer for supported fee tokens, gas estimates, and pricing for a given transaction |
relayer_sendTransaction |
Submit a signed transaction to the relayer for execution on a single chain |
relayer_sendTransactionMultichain |
Submit a transaction that targets multiple chains in a single request |
relayer_getCapabilities |
Discover what features a relayer supports (e.g., sponsorship, batching, multichain) |
relayer_getStatus |
Poll the status of a previously submitted relayed transaction via a task ID |
There are gas savings to this solution as we can see in these transactions that perform a transfer + payment to the paymaster/relayer.
Relayer solution (87k gas):
4337 Solution (185k gas)
Another 4337 example, without payment to paymaster (142k gas)
1 Like
Could you clarify the threat model you have in mind? In ERC-8249, the relayer never holds user keys since the user signs the transaction themselves, and the smart account verifies that signature on-chain before executing. A kernel-level compromise of the relayer infrastructure would let an attacker censor or drop submissions, or drain the relayer operator’s own gas-paying EOA, but it cannot forge user transactions or move user funds. Users can also switch relayers freely, since the standard is just an RPC interface.
If you’re pointing at a specific attack path beyond DoS and operator-fund risk, I’d be happy to dig into it but I don’t think relayer hardware integrity is part of the user trust assumption here.