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

Inizia da docs/adr/ADR-0003-typed-transactions-sponsorship.md e dal gestore EVM personalizzato in crates/ev-revm. Determina innanzitutto se il design utilizza una AMM, una conversione lato sequencer o un precompile, quindi traccia EvEvmConfig e gli entry point per la stima delle fee e per receipt/RPC. Il lavoro è completato quando le stablecoin supportate possono pagare le fee, le risposte riportano il token delle fee e i test di integrazione coprono i casi di successo, misti, saldo insufficiente e errore dell’oracolo.

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)