Skip to main content
Paychannels let anyone pay any number of times after a single deposit. Each payment is a signed message that a hub verifies in microseconds, and Polygon Chain settles the totals in periodic batches. Paychannels are built for massive transaction scale: one settlement can cover millions of payments, and a fleet of hubs has sustained 45 million fully verified payments per second. Use Paychannels wherever payments are too small or too frequent for cards or individual onchain transfers: streaming media, metered APIs, in-app purchases, machine-to-machine settlement, agents that pay as they work, and any workload that needs massive transaction scale. Services that charge over HTTP can accept them through x402.
Paychannels are in early access. Contact Polygon to get started.

​
The problem

Most payment rails are built for occasional, sizable purchases. A growing share of commerce is the opposite: continuous, high-frequency, and priced in fractions of a cent. Streaming services want to charge per second, APIs per call, and models per token. Software agents pay for each step of a task as they go, often hundreds of times per task.

Human commerce settles once per cart. Agent commerce pays per unit consumed.

Existing rails break down at that frequency:
  • Cards charge around $0.30 plus 2.9% per transaction, 300 times the value of a $0.001 API call, and the networks process thousands of payments per second globally.
  • Prepaid balances lock money at every provider and limit payers to the providers they already funded.
  • One onchain transaction per payment adds a fee and a confirmation wait to every unit, and no blockchain records millions of individual transfers per second.
The demand is already there. Inference traffic alone runs at about 10 trillion tokens per day across public routers, roughly 116 million tokens per second.

​
How Paychannels work

Paychannels separate how fast payments happen from how often they settle. Think of a bar tab: you open it once, sign for each round, and the total is settled at the end of the night.

Fund a channel once, stream payments through the hub, settle to Polygon in batches.

  1. Deposit once. The payer deposits stablecoins into the hub’s channel contract on Polygon Chain and registers a session key. The deposit is the payer’s spending limit and covers every merchant on the hub.
  2. Get a price. The counterparty states the price per unit: a second of video, an API call, a token window. An HTTP service can use an x402 402 Payment Required response; an app can use its own price list or a requested payment.
  3. Pay with a signature. For each unit, the payer signs a payment for its new running total with that counterparty. The hub checks the signature, price, and remaining deposit, then returns a receipt in microseconds. Each payment supersedes the last, so a retry can never charge twice.
  4. Deliver. The counterparty releases the unit on a valid receipt, and the loop repeats as often as needed.
  5. Settle in batches. Periodically, the hub closes an epoch and posts one Merkle root of every account’s balance to Polygon. A threshold of independent verifiers must re-check every payment and co-sign the root before it is accepted.
  6. Cash out. Merchants and payers withdraw against the posted root. Whatever the payer did not spend stays available for the next session or can be withdrawn.
Settlement costs one root per hub per epoch, whether it covers one payment or 100 million. The hub operator chooses the cadence.

​
Every address is one account

Classic payment channels are opened per payer and merchant pair: a payer who uses ten services opens and funds ten channels. Paychannels use a hub ledger instead. Every address is one account on the hub. You deposit once, pay any merchant, spend what you receive, and cash out whenever you want. A merchant earning from thousands of payers withdraws in one transaction per hub.

​
Agentic payments

Paychannels are not tied to a protocol and can support many payment schemes on the same hub. Any application submits signed payments through a facilitator’s JSON API, whether the payment comes from an API call, a video player, a game, or a device on a network. For example, Paychannels support transaction volume from agents at massive scale through native support for x402. A Paychannels facilitator is an x402 facilitator. It exposes the standard /verify and /settle endpoints, and its /quote endpoint returns a complete 402 Payment Required body that offers two schemes: The x402 support covers the full agent flow:
  • Discovery. A service returns the cached 402 for any unpaid request, or publishes it at /.well-known/x402 so an agent can attach a payment to its first request.
  • Payment. The agent sends the signed voucher in the X-PAYMENT header (or PAYMENT-SIGNATURE in newer clients) and receives the receipt in X-PAYMENT-RESPONSE. Channel receipts carry no transaction hash, because nothing is sent onchain.
  • Compatibility. Paychannels reuse the batch-settlement field names and EIP-712 voucher format, so an x402 client written against that scheme can pay through a hub unchanged.
  • Concurrency. One voucher can authorize a running total that covers many requests in flight at once, each with its own payment ID, so an agent is not limited to one payment per round trip.
  • Retries. A retried payment with the same payment ID returns the original receipt instead of charging again.
See Accept Paychannels payments to add x402 payments to your own service.

​
Use cases

Paychannels fit any payment flow where a payer makes many small payments to one or more payees and the price per unit is too small for a card or an onchain transfer: streaming media, metered APIs, games, connected devices, payouts, and marketplaces. AI agents are a core market: software that buys inference, data, and services as it works, often hundreds of times per task.

Streaming payments

Pay continuously for as long as a service runs: per second of GPU time, per minute of bandwidth, per token window of a model response. Each interval is one signed voucher, so payer and payee are never more than one interval out of sync, and payment stops the moment the payer stops signing.

Per-token inference billing

Model providers charge per token window as the response streams, instead of selling prepaid credits. The agent pays for exactly what it consumed, and the provider is paid before it releases the next window.

Pay-per-call APIs

Price every API call individually. No API keys, monthly invoices, or prepaid tiers. A payer that has never used your API can pay for its first call immediately, and services that speak x402 can state the price in a standard 402 response.

One balance, any provider

Replace a prepaid account at every vendor with one channel deposit. The agent spends from a single balance across every merchant on the hub and can switch to the best provider for each step without opening or funding a new account.

Agent-to-agent payments

An orchestrator agent pays sub-agents per completed task. Because every account can spend what it receives, an agent that earns from one job can immediately pay for the next without a withdrawal in between.

Accept payments

Any address can be paid at request time, by people, apps, devices, or agents. A merchant sets a price and settles each payment with one facilitator call, or adds x402 middleware for HTTP routes, and starts receiving payments from every funded account on the hub. Earnings from thousands of payers withdraw in one transaction per hub.

Private payouts

Pay contractors, creators, or other agents directly, per task or per hour. Any address can be paid with no signup, recipients can spend what they receive right away, and individual payouts never appear onchain.

Credit and working capital

Fund an agent’s spending line, pay suppliers from incoming revenue before cashing out, and replace post-paid invoicing with pay-as-you-go. See Credit without counterparty risk.

Payment platforms

Payment providers and marketplaces run their own hub under their own brand, onboard their merchants, add their own verifier, and choose their own settlement cadence.

​
Credit without counterparty risk

Usage-based billing today runs on credit. A provider serves an API, a model, or compute first and invoices later, so it carries the risk that the customer never pays. Agents make this worse: a provider cannot run a credit check on a piece of software. Paychannels change where credit sits.
  • Providers stop extending credit. Every unit is paid before it is delivered, so a provider never has an unpaid balance with a customer. Post-paid invoices, net-30 terms, and collections are no longer needed for metered services.
  • A deposit is a hard credit limit. Anyone can fund an account’s deposit, not only the account owner. A platform, an employer, or a lender can fund an agent’s account and know the agent cannot spend more than that deposit. Every payment draws down the same balance, so exposure is fixed up front instead of discovered at the end of the billing cycle.
  • Revenue is spendable immediately. An account’s available balance is what it deposited plus what it received, minus what it spent. A provider or agent that earns from one customer can pay its own suppliers from those earnings right away, without waiting for a withdrawal. Money moving through a chain of agents does not need a credit line at each step to cover the gap between paying and getting paid.
The result is a payment model where credit is a choice someone makes when they fund an account, not a risk every provider absorbs on every invoice.

​
Example: paying for inference per token window

An agent needs a model completion. Without Paychannels, it can only call a provider it already holds credits with. With Paychannels:
  1. The agent opens a stream to the cheapest available provider. The provider quotes a price per 100-token window.
  2. For every window, the agent signs a voucher for the new running total. The hub verifies it and returns a receipt in microseconds.
  3. The provider streams the next 100 tokens on each receipt. If the agent stops paying, the provider stops generating. Neither side is exposed for more than one window.
  4. At the end of the epoch, the provider’s earnings from every agent on the hub settle to Polygon in a single root.
The same pattern applies to any metered resource. Swap “100-token window” for “one second of GPU time” or “one search result.”

​
Performance

Polygon has benchmarked Paychannels on a fleet of hubs, with every payment’s signature verified and written to disk before it counted. The current record is 45,017,796 fully verified payments per second, sustained for 10 minutes across 100 hubs.
  • Latency: each payment update is confirmed in about 20 microseconds at the hub, plus network latency between payer and hub.
  • Linear scaling: hubs partition payers and do not coordinate on the payment path. Adding hubs adds capacity in a straight line.
  • Cost: processing one billion payment updates cost about $0.15 in the benchmark configuration.
  • Settlement: each epoch root costs about 112,500 gas to post, no matter how many payments it covers.
Each hub’s epoch roots were verifier-attested and posted onchain.

​
Security and privacy

The hub operator processes payments but never holds the money. Deposits stay in the channel contract, only payer-signed vouchers move value, and no settlement is accepted without signatures from a threshold of independent verifiers. Individual payments, counterparties, and amounts never reach the chain.
  • Trust model: what the operator can and cannot do, and how to audit a hub.
  • Privacy: what the chain, the public, and the operator can each see.

​
Get started

  • Try a demo: pay per token, per second, and per task in your browser, run each flow with your agent, or make your first payments from a terminal.
  • Accept Paychannels payments: charge per request from your own API.
  • Run a hub: operate your own hub, verifiers, and facilitator.
  • Announcement: the original benchmark write-up.
  • Get access: talk to Polygon about running a hub, becoming a verifier, or integrating Paychannels.