feat: add unified EVM session payment method

[clayclaw]

Summary

Adds the session intent for the evm payment method, defining unidirectional streaming payment channels for incremental, voucher-based payments on any EVM-compatible chain. Adapts the streaming payment channel mechanism from the Tempo session spec (draft-tempo-session) for general EVM use, with EVM-specific transaction formats, gas models, and domain separators.

• Request schema: amount (price per unit, base units), currency (ERC-20 address), recipient (payee address), with methodDetails for chainId, escrowContract, feePayer, optional splits
• Escrow contract: 8 on-chain functions covering channel open, settle, topUp, close, and forced close paths
• Credential: four payload actions (open, topUp, voucher, close) with EIP-712 voucher signatures for off-chain cumulative payments
• Verification: per-action checks — on-chain state for open/topUp, signature recovery + monotonicity for vouchers, final settlement for close
• Receipt: per-request Payment-Receipt with acceptedCumulative, spent, optional reference (tx hash on settlement)

This is an initial draft, we are actively developing the underlying functionality and will continue refining the spec as implementation progresses. Feedback and discussion are welcome.

Context

This is the second intent defined for the evm payment method (after charge in #213). The session intent follows the Tempo session spec (draft-tempo-session) as the reference design, extending it to work across any EVM-compatible chain.

Design decisions

Decision	Rationale
On-chain escrow contract with 8 functions	open, openWithAuthorization, settle, topUp, topUpWithAuthorization, close, requestClose, withdraw — covers the full channel lifecycle with both client-funded and server-submitted paths.
openWithAuthorization / topUpWithAuthorization via EIP-3009	When feePayer: true, client signs off-chain transferWithAuthorization; server calls the escrow contract and pays gas. Client never needs native token. Requires EIP-3009 token support.
open() + ERC-4337 support for client-broadcast path	When feePayer: false, client calls approve() + open() directly or via an EntryPoint-mediated UserOperation. Smart wallets can batch both in a single UserOp.
Deterministic channelId via keccak256(payer, payee, token, salt, authorizedSigner, escrow, chainId)	Identical to Tempo's formula. Binds channel to a specific contract deployment and chain. Client can pre-compute before the on-chain tx lands.
Deposit merge in voucher payload	Bundles an EIP-3009 topUp (or initial open) with a voucher update in a single HTTP round-trip — reduces latency when approaching deposit limits.
Splits as immutable on-chain splitRecipients[] + splitBps[]	Session total is unknown upfront, so basis points (not fixed amounts). Enforced atomically by the contract at settle() / close().
Domain separator: "EVM Payment Channel"	Distinguishes from Tempo's "Tempo Stream Channel" — the only semantic difference in the voucher signing scheme. Prevents cross-deployment replay.

New File

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

AI Disclosure

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