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.

3

Main gap is the interface layer. The spec defines value flow, but not how requests map to voucher increments. Without that, interoperability across providers will fragment quickly.

Might also be worth tightening session semantics and aligning early on voucher schema if MPP compatibility is a goal.

Primitive makes sense. Biggest risk here is fragmentation around it, not the channel itself.

1 Like
4

Thanks Ankita — all three points hit the mark. We’ve pushed a revision that addresses each one.

Interface layer (request → voucher mapping)

The spec now includes a Service Interaction (RECOMMENDED) section that standardizes how requests map to voucher increments:

  • Cost reporting headers after each response: X-Payment-Cost (this request), X-Payment-Total (cumulative charged), X-Payment-Remaining (channel balance). The consumer uses X-Payment-Total + estimated next cost as the cumulative amount in the next voucher.

  • Standardized error codes on 402: voucher_required, insufficient_funds, invalid_signature, invalid_nonce, channel_expired, channel_not_found — with X-Payment-Required / X-Payment-Provided for insufficient funds cases.

  • Discovery via HTTP 402 with X-Payment-Protocol, X-Payment-Contract, X-Payment-Chain, X-Payment-Signing (returns EIP-712 domain + types).

This is RECOMMENDED, not normative — the on-chain primitive works without it, but production experience across 10+ providers showed that without these conventions every provider invents its own cost reporting, which is exactly the fragmentation you flagged.

Session semantics

The HTTP integration is now RECOMMENDED (was OPTIONAL) with a defined sequence: Discovery → Channel Open → Authenticated Requests with cost reporting → Settlement. The channel is the session — opened once, used for unlimited requests, settled via claim or cooperative close.

Voucher schema / MPP alignment

The Voucher struct stays minimal (channelId, amount, nonce). We’re running DRAIN as a settlement backend for MPP-compatible agents in production — the mapping happens at the transport layer via the X-Payment-* headers, not by extending the voucher schema. Added a rationale section making this design intent explicit.

Updated draft is on the PR (now ERC-8190 per editor assignment). Includes a full inline Solidity reference implementation. Would appreciate your review of the Service Interaction section — specifically whether the header conventions cover the interop cases you had in mind.

1 Like