Stablecoin gas fees: allow users to pay transaction fees in ERC-20 stablecoins

Start with docs/adr/ADR-0003-typed-transactions-sponsorship.md and the custom EVM handler in crates/ev-revm. First resolve whether the design uses an AMM, sequencer-side conversion, or a precompile, then trace EvEvmConfig and the fee-estimation and receipt/RPC entry points. Done means supported stablecoins can pay fees, responses report the fee token, and integration tests cover successful, mixed, insufficient-balance, and oracle-failure cases.

Summary

Enable end users to pay gas fees in supported ERC-20 stablecoins (e.g., USDC, USDT) instead of requiring them to hold native ETH, eliminating the largest onboarding friction for enterprise and fintech customers.

Motivation

Today, every user of an ev-reth chain must acquire and hold native ETH to pay gas fees. This is a significant barrier for:

• Enterprise customers who want predictable, stable fee structures
• End users onboarded through fintech/payment apps who should never need to think about gas tokens
• Compliance teams who prefer USD-denominated cost accounting

Tempo (Stripe/Paradigm's payments-first L1, also built on Reth SDK) has validated this pattern: users pay fees in any supported stablecoin, and a protocol-level mechanism handles conversion. ev-reth's ADR-0003 already implements fee sponsorship (sponsor pays gas on behalf of user), but stablecoin gas goes further by removing the native token requirement entirely.

Design considerations

Option A: Fee AMM (Tempo's approach)

• Deploy an on-chain AMM that converts stablecoin fee payments to the native token at execution time
• The EVM handler deducts stablecoins from the user, swaps through the AMM, and burns/distributes native token equivalent
• Pro: Fully on-chain, transparent pricing
• Con: Requires AMM liquidity, adds execution complexity

Option B: Sequencer-side conversion

• The sequencer (ev-node) accepts stablecoin-denominated fees off-chain
• Payload builder credits native gas from a system account and debits stablecoin balance
• Pro: Simpler, no AMM needed
• Con: Centralized pricing, trust assumption on sequencer

Option C: Precompile-based fee deduction

• A system precompile at a fixed address handles stablecoin balance checks and deductions
• Custom EVM handler in crates/ev-revm overrides fee deduction to call the precompile
• Pro: Clean separation, composable
• Con: New precompile surface area

Scope

1. Decide on conversion mechanism (AMM vs sequencer vs precompile)
2. Extend EvEvmConfig / custom EVM handler in crates/ev-revm to support non-native fee deduction
3. Define supported stablecoin registry (chainspec or system contract)
4. Modify receipt/RPC responses to indicate actual fee token used
5. Update gas price oracle / fee estimation RPCs to return stablecoin-denominated prices
6. Integration tests covering: stablecoin-only user paying gas, mixed native+stablecoin blocks, edge cases (insufficient stablecoin balance, price oracle failure)

Prior art

• Tempo: stablecoin gas fees -- Fee AMM approach, no native token
• EIP-4337 Paymasters -- Account abstraction approach (higher overhead)
• ADR-0003 -- ev-reth's existing fee sponsorship model (complementary, not replacement)