ERC-8184 (draft): Payment Channels with Signed Vouchers — streaming micropayments for AI agents

Magicians Primordial Soup
1

Hi everyone,

I’ve submitted an ERC draft to formalize a pattern we’ve been running in production since late 2025: **unidirectional payment channels** for streaming micropayments between AI agents and service providers, using EIP-712 signed vouchers on top of ERC-20.

Problem: AI agents consume services at high frequency (LLM inference, image gen, code execution, etc.) with low value per request. On-chain payment per request is economically infeasible; job-escrow models (e.g. ERC-8183) add unnecessary overhead for immediate request–response services.

Approach: The consumer opens a channel by depositing ERC-20 tokens into escrow, designates a provider and expiry, then issues off-chain signed vouchers (EIP-712) in exchange for services. The provider can claim the highest voucher on-chain at any time. Channels settle via provider claim, consumer close after expiry, or cooperative close with mutual signatures. Two on-chain transactions cover an unlimited number of service requests.

Status:

- ERC PR: Add ERC: Payment Channels with Signed Vouchers by kimbo128 · Pull Request #1592 · ethereum/ERCs · GitHub

- Reference implementation: Live on Polygon Mainnet (DrainChannelV2, USDC).

- Marketplace: https://handshake58.com - agents pay for LLM, image, code execution, and other services via this protocol.

The draft defines the minimal interface (channel lifecycle, voucher schema, settlement, cooperative close), optional HTTP 402 integration for API providers, and is **complementary** to ERC-8183 (streaming vs. discrete deliverable commerce).

I’d welcome feedback on the specification, security considerations, and naming. Happy to discuss rationale, edge cases, and implementation experience here.

2

Update: MPP “Sessions” launched — identical architecture, one month later

I wanted to flag something for the community’s awareness.

Yesterday (March 18, 2026), Stripe/Tempo launched the Machine Payments Protocol with a feature called “Sessions” — unidirectional payment channels where an agent opens a tab with a server, signs off-chain payloads per request, and settles on-chain at the end.

This is architecturally identical to what ERC-8184 specifies: unidirectional channels, signed vouchers (they call them “signed payloads”), two on-chain transactions, unlimited off-chain micropayments. We published this thesis in February 2026 and have been running this in production on Polygon since late 2025.

The difference: Tempo Sessions run on a permissioned L1 with 11 validators behind a multisig. ERC-8184 / DRAIN runs on Polygon — Ethereum’s ecosystem, permissionless, with thousands of validators.

I believe this validates the approach we’ve formalized in ERC-8184. But it also raises a question for this community: should the Ethereum ecosystem have its own standardized answer for agent micropayments, or should we cede this to a permissioned L1?

We’re building drain.session as a custom MPP payment method — so DRAIN becomes the permissionless settlement option within MPP. This means ERC-8184 channels on Polygon can serve as the backend for any MPP-compatible agent, regardless of what payment method they prefer.

Would love the community’s thoughts on:

  1. Whether ERC-8184 should explicitly define MPP compatibility

  2. How this relates to ERC-8004 (Trustless Agents) — agent identity + payment channels seem like a natural pair

  3. Whether there’s interest in co-authoring the MPP integration spec

The reference implementation is live: 0x0C2B3aA1e80629D572b1f200e6DF3586B3946A8A on Polygon Mainnet.