Add Evm method

[xinweb4]

We’re preparing to support similar functionality. It is currently under development. We have used AI to produce an initial EVM version translated in the MPP format, and we will continue refining it over time. Feedback and discussion are welcome.

[clayclaw]

Summary

Adds a unified evm payment method covering two intents:

• charge — one-time ERC-20 token transfers on any EVM-compatible chain
• session — streaming payment channels with off-chain vouchers for incremental billing

Here we propose charge intent with a rich credential model (EIP-3009, Permit2, ERC-7710 delegation) and split payment support, alongside a new session intent for streaming payment channels — enabling use cases like pay-per-token LLM inference.

Charge Intent (draft-evm-charge-00)

Two credential types, with authorization sub-types under type="transaction":

type="transaction" (RECOMMENDED)

Client provides an off-chain authorization; server submits on-chain. Three authorization mechanisms:

• authorization.type="eip-3009" (RECOMMENDED) — EIP-3009 transferWithAuthorization. Server sponsors gas. Zero setup — no Permit2 approval needed. Challenge binding via on-chain nonce. Supports splits
  via batched transferWithAuthorization calls.
• authorization.type="permit2" — Permit2 off-chain signed approval. Server sponsors gas. Atomic split payments via permitBatchWitnessTransferFrom(). Cryptographic challenge binding via
  PaymentWitness witness data. Requires one-time ERC-20 approval to the Permit2 contract.
• authorization.type="delegation" — ERC-7710 smart account delegation. Server sponsors gas. Supports ERC-4337 smart accounts, EIP-7702 EOAs. Atomic splits via batched execution. Delegation caveats
  enable fine-grained constraints.

type="hash" (fallback)

Client broadcasts transaction, presents tx hash. For custodial wallets / hardware signers. Client pays gas. Weaker challenge binding.

Session Intent (draft-evm-session-00) — NEW

Defines streaming payment channels for incremental, voucher-based payments. Adapted from the Tempo session spec for any EVM chain.

• On-chain escrow holds deposited funds; off-chain EIP-712 vouchers authorize increasing cumulative amounts
• Two open modes: client-broadcast (feePayer: false) and server-submitted via EIP-3009 (feePayer: true)
• Voucher + deposit merge: single round-trip for top-up and voucher update
• Ratio-based splits via basis points, enforced by the escrow contract at settlement
• Forced close with grace period protects both client and server
• SSE integration: payment-need-voucher events for mid-stream balance requests
• Use case: LLM token streaming — client pays exactly for tokens received

Key Design Decisions

Decision	Rationale
EIP-3009 as recommended auth type	Zero setup, no Permit2 approval prerequisite. Most tokens that matter (USDC, EURC) implement it natively
Three authorization mechanisms under type="transaction"	Covers EOAs (EIP-3009, Permit2), smart accounts (delegation), and EIP-7702 hybrid wallets
Gas sponsorship is structural	Off-chain signature types → server always pays gas. On-chain type="hash" → client pays. No ambiguity
Session splits use basis points, not fixed amounts	Total session cost is unknown upfront; ratio-based splits scale with consumption
Cumulative voucher semantics	Monotonically increasing amounts prevent rollback; server holds latest voucher as irrevocable claim
session as experimental intent	Defined in the method spec per contribution guidelines, pending extraction into a standalone intent spec once a second method implements the pattern
No chain-specific appendix	Chain IDs reference chainlist.org. Implementation details belong in chain documentation
Confirmation depth is server policy	Spec requires 1-block inclusion; finality depth left to server discretion
Native token transfers out of scope	ERC-20 only

New Files

• specs/methods/evm/draft-evm-charge-00.md
• specs/methods/evm/draft-evm-session-00.md

References

• Tempo charge spec: specs/methods/tempo/draft-tempo-charge-00.md
• Tempo session spec: specs/methods/tempo/draft-tempo-session-00.md

AI Disclosure

These specs were drafted with AI assistance (Claude). All content has been reviewed for technical accuracy, RFC compliance, and alignment with STYLE.md / CONTRIBUTING.md.

[brendanjryan]

Can we move discussion here? #213