Skip to main content

ADR-002: ERC-4337 Paymaster over Custom Relayer for L2 (EB) Gas Sponsorship

StatusSuperseded by ADR-011
Date2026-03-10

Context​

The L2 encrypted balance model (shield, transfer, unshield) does not require a relayer for correctness — users generate ZK proofs client-side and could submit transactions directly. The current relayer exists primarily to support L3 (IMT witness generation for stake/unstake), with L2 gas sponsorship as a secondary convenience feature.

Meanwhile, ERC-4337 (Account Abstraction) provides a standardized mechanism for gas sponsorship via Paymasters. Base has mature ERC-4337 infrastructure, and Coinbase Smart Wallet already uses this pattern to sponsor USDC transfers on Base.

The question: should we maintain a custom relayer for L2 gas sponsorship, or replace it with an ERC-4337 Paymaster?

Proposal​

Replace the custom L2 relayer with a self-hosted ERC-4337 Paymaster.

Why self-hosted (not third-party):

  • Control over sponsorship policies (who gets free gas, rate limits, token allowlists)
  • No additional metadata exposure to external services
  • Operational independence

Why ERC-4337 over custom relayer:

  • Standard infrastructure — battle-tested, audited, well-supported on Base
  • Nonce management, retry logic, and bundling handled by the protocol
  • Users get smart contract wallets with potential for recovery, batching, session keys
  • Eliminates ~500 lines of custom boilerplate with no unique logic
  • Compatible with the broader ecosystem (any ERC-4337 bundler can submit UserOperations)

Privacy considerations: The L2 encrypted balance model hides amounts but the transaction graph is publicly visible on-chain. A paymaster/bundler learns nothing beyond what any blockchain observer already sees. The only additional exposure is the user's IP address, which the current relayer (and any RPC provider) also sees.

Consequences​

What becomes easier:

  • No custom relayer server to maintain, monitor, and keep online
  • Users benefit from smart account features (batching, recovery) for free
  • Gas sponsorship follows a well-documented standard
  • Easier for third-party integrators who already use ERC-4337

What becomes harder:

  • EBEMT contract functions need to be callable via UserOperations (may require an adapter contract or ensuring compatibility with the IAccount interface)
  • Initial setup of bundler + paymaster infrastructure
  • ZK proof calldata is large — need to verify UserOperation gas limits are sufficient

What stays the same:

  • User flow: sign proof client-side, submit, get tx hash
  • Privacy properties: amounts hidden, graph visible (unchanged)
  • On-chain contract logic: no changes to EBEMT core functions