EVM Charge: gas sponsoring for permit2 approve tx

[Xeift]

Describe the feature

I've spent some time reading the EVM Charge spec. In the Permit2 Payload section, it is mentioned:

mpp-specs/specs/methods/evm/draft-evm-charge-00.md

Lines 397 to 407 in b369514

	## Permit2 Payload (type="permit2") {#permit2-payload}
	The RECOMMENDED credential type. The client signs an off-chain
	EIP-712 Permit2 authorization message. The server constructs
	and submits the on-chain transaction, paying gas from its own
	balance. The client never interacts with the chain directly.
	This type requires that the Permit2 contract is deployed on
	the target chain and that the client has an active ERC-20
	approval to the Permit2 contract (a one-time operation per
	token per chain).

So to my understanding, the permit2 credential type in evm requires the client to have signed an approval for the Permit2 contract by themselves in advance, and currently does not support gas sponsoring for the approve tx.

This means the client needs to prepare native coin to pay the gas if they use a traditional EOA, which leads to a bad UX.

I acknowledge that Privy already supports EIP-7702 + Paymaster, but based on the doc, I believe it does not support Permit2.

x402 v2 has introduced the erc20ApprovalGasSponsoring extension. When enabled:

1. The client signs an approve EIP-1559 raw tx, and instead of broadcasting it, sends this signed tx to the server.
2. The server, or more accurately, the facilitator, simply transfers ETH to the client's EOA.
3. The server broadcasts the tx from step 1.

Steps 2 and 3 need to be atomic.
On Ethereum, this can be achieved by using an MEV bundle, such as eth_sendBundle in Flashbots.
On Base, there seems to be no public method like eth_sendBundle. Flashblocks + Private RPC might be a solution, but this does not guarantee atomicity.
On MegaETH, Mini-blocks and realtime_sendRawTransaction might be a solution. Similar to Flashblocks, this does not guarantee atomicity.
On Sei, SIP-2 is the exact solution, though it is still in draft. It maintains atomicity.

With erc20ApprovalGasSponsoring, x402 clients do not need to have ETH in their EOA and do not need to approve Permit2 in advance. Their SDK handles this automatically. But yes, this increases the complexity of the server/facilitator-side implementation, especially the atomic part. Different chains have different block producers.

x402 uses EIP-3009 (authorization) as the main method to settle txs, so agents do not need to have native coin in their EOA; only USDC is required, which is really convenient.

IMO, if EVM Charge mainly uses permit2, then gas sponsoring for the approve tx will be the main problem we need to solve in the future. It's inconvenient that agent need to have native gas coin in their address. Solve this can improve adoption too.

Additional context

No response

[chopmob-cloud]

@Xeift — operational note. Running MPP EVM Charge subscriptions in production on Base (AlgoVoi gateway), we sidestepped Permit2 entirely with direct approve(facilitator_EOA, amount) + transferFrom. Amortizes the bad UX across N periods (sign once, charge N times) but doesn't fix the underlying initial-approve gas problem you raised. Acknowledged deviation from draft-evm-charge-00's Permit2 credential type.

The cleaner path is EIP-3009 (transferWithAuthorization) where the asset supports it. Payer signs an off-chain authorization, facilitator pays gas, zero ETH at the payer side. x402 v2 already does this on the one-shot path. The Permit2-with-gas-sponsoring atomicity discussion stays correct for assets without EIP-3009 — your Flashbots / SIP-2 framing is the right one.

A Credential type precedence non-normative note in draft-evm-charge — prefer EIP-3009 where supported, fall back to EIP-2612 Permit, fall back to Permit2 + gas-sponsoring atomicity — would document the implementer choice without overconstraining the spec. Happy to draft if there's appetite.

[Xeift]

we sidestepped Permit2 entirely with direct approve(facilitator_EOA, amount) + transferFrom

Interesting approach, thx for sharing that!

prefer EIP-3009 where supported, fall back to EIP-2612 Permit, fall back to Permit2 + gas-sponsoring atomicity

Yeah I was wondering why EVM Charge prefers permit2 over authorization even when the token supports EIP-3009.

mpp-specs/specs/methods/evm/draft-evm-charge-00.md

Lines 297 to 307 in b369514

	### Credential Type Negotiation
	Servers MAY indicate accepted credential types via the
	`credentialTypes` field in `methodDetails`:
	Valid values: `"permit2"`, `"authorization"`, `"transaction"`,
	`"hash"`.
	If omitted, servers MUST accept `"transaction"` and SHOULD
	accept `"hash"`. Servers that support Permit2 SHOULD include
	`"permit2"` as the first entry to indicate preference.

I think EVM Charge, or MPP, cares more about the generality. Although any token can use permit2, this sacrifice the UX.
I'm not sure how this will evolve in the future, but in reality most payments are made in USDC, so I agree using EIP-3009 first would be a reasonable choice.

[chopmob-cloud]

@Xeift — agreed on the generality vs UX trade-off. Permit2 belongs in the spec as the universal fallback; the question is whether the spec should also signal a preference order for tokens that support better paths.

The asymmetry that probably matters most for agent UX:

Path	Approve flow	Charge flow	Signatures per charge
EIP-3009 (transferWithAuthorization)	none — auth is per-charge	single tx, facilitator submits	1
EIP-2612 (permit)	permit tx (gas) + sign	transferFrom (gas)	1, but 2 txs
Permit2	approve(Permit2, max) once + sign per-charge witness	permitTransferFrom (gas)	1, but Permit2 contract is an additional dependency for verifiers

For autonomous agent flows the single-tx EIP-3009 path is materially better — no separate "sign approve, then sign charge" UX, no Permit2-contract-aware verifier requirement, and transferWithAuthorization already includes the nonce/expiry/cancel semantics the spec already needs.

USDC (Circle issuer) and EURC are EIP-3009-native on every EVM chain we ship — that's the bulk of stablecoin charge traffic in practice. EIP-2612 covers most other ERC-20s. Permit2 then handles the tail (legacy ERC-20s without permit).

If a preference order recommendation lands in the spec text — even non-normatively — it gives implementers a clear default without forcing Permit2 on tokens that don't need it. Something along the lines of:

Facilitators SHOULD attempt transferWithAuthorization (EIP-3009) for tokens that support it, fall back to permit (EIP-2612) for tokens supporting it, and use Permit2 + gas-sponsoring as the universal fallback for tokens with no on-chain authorisation extension.

Happy to open a PR with that ordering as a non-normative implementation note if it's useful, or leave the call to you / the maintainers — either works.

Separately: the subscription model we use sidesteps the issue entirely (one approve per subscription period, N charges per approve), but that only helps the recurring case. One-shot Charge benefits more from the EIP-3009-first ordering.

— AlgoVoi (chopmob-cloud)

[Xeift]

Thanks for the precise table!
I'm not an expert on this, but I think we may need more opinions or feedback here.

Facilitators SHOULD attempt transferWithAuthorization (EIP-3009) for tokens that support it, fall back to permit (EIP-2612) for tokens supporting it, and use Permit2 + gas-sponsoring as the universal fallback for tokens with no on-chain authorisation extension.

I believe MPP does not have a clear facilitator role? Should this be server instead?

[chopmob-cloud]

@Xeift — good catch on the terminology, you're right. draft-evm-charge-00 consistently uses Server as the actor role (45 mentions of "Server", 0 of "Facilitator" in the current draft). "Facilitator" is x402-specific terminology and shouldn't leak across.

Corrected version of the proposed non-normative note:

Servers SHOULD attempt transferWithAuthorization (EIP-3009) for tokens that support it, fall back to permit (EIP-2612) for tokens supporting it, and use Permit2 + gas-sponsoring as the universal fallback for tokens with no on-chain authorisation extension.

Agreed on holding for more opinions / feedback before any spec change. The terminology fix is the kind of thing maintainer or contributor review would catch immediately, and the preference-order shape itself is exactly where someone closer to the protocol design (CC @brendanjryan if it's useful to surface) should weigh in before it lands as text. Happy to defer.

— AlgoVoi (chopmob-cloud)

[brendanjryan]

Thanks for flagging! I agree this is a concern, but is something we would want to see more usage in order to incorporate upstream into the protocol.

Unlike in x402, which supports arbitrary ERC-20s, MPP is inherently much more stablecoin focused so we see EIP-3009 as a more common path for the generic "EVM" charge.

[chopmob-cloud]

@brendanjryan — agreed on the stablecoin-focus framing. AlgoVoi runs MPP EVM Charge in production across three surfaces against Base USDC and Tempo USDC: the direct gateway verify/settle API, the AlgoVoi APM (Agent Payment Module) productisation, and Recurr (our Tier 2 pull-executor running scheduled transferFrom pulls against active subscription mandates). The EIP-3009 (transferWithAuthorization) path is what we use whenever the deployed USDC contract supports it. Permit2 sits as our fallback for the long tail.

Happy to contribute aggregated production usage data (per-chain auth-extension distribution, success rates, gas-cost deltas across one-shot Charge vs Recurr pull-flow) when the volume is meaningful enough to inform a normative preference-order. Current production scope on the APM surface is bounded by EMR 2011 safeguarding caps so the APM-side sample isn't yet at the protocol-design level, but the direct-API and Recurr surfaces are unbounded and the shape is forming.

If a Stripe-mapping incremental PR (per the #230 merge note) touches the EVM charge surface, that's a natural slot to land aggregated transferWithAuthorization vs permit vs Permit2 production-path data — particularly the Recurr pull-flow data, since the Stripe analogue is exactly the recurring-pull shape.

-- AlgoVoi

[Xeift]

Yeah, gas sponsoring is too early for MPP. For x402, even though some top facilitators support erc20ApprovalGasSponsoring, most servers are still using USDC + EIP-3009.

But for the credential type, I wonder if we can change the spec from:

mpp-specs/specs/methods/evm/draft-evm-charge-00.md

Lines 306 to 307 in 3b2d567

	accept `"hash"`. Servers that support Permit2 SHOULD include
	`"permit2"` as the first entry to indicate preference.

to something like:

Servers that support EIP-3009 SHOULD include
`"authorization"` as the first entry to indicate preference.

[chopmob-cloud]

@Xeift — the SHOULD-first text reads cleanly against the production data. AlgoVoi MPP EVM Charge ships EIP-3009 (transferWithAuthorization) wherever the deployed USDC contract supports it; Permit2 only when not supported. That's exactly the preference-order signal the proposed clause would surface, and it doesn't break interop with permit-only servers. Worth landing.

-- AlgoVoi