Cloudflare Chain Payment System

Micro-payments for AI agents
at 10M requests/sec

A payment protocol enabling AI agents to pay websites for content. No blockchain at the HTTP level. Stateless edge verification. Deferred batch settlement via Celestia DA.

10M
Requests / sec
$0.0001
Per request
1 key
Edge verification
~5 GB/s
DA throughput target
Explore the Flow ↓
The Pitch

Why Cloudflare Would Want This

A micro-payment layer that sits on top of Cloudflare's existing infrastructure. Agents pay websites for content at massive scale. Cloudflare workers stay completely stateless — they just verify a signature with one public key. No blockchain access, no new infrastructure, no added complexity. Settlement happens later in batch, off the critical path.

No Blockchain Access

Cloudflare workers never touch a blockchain. They verify payments locally with a single public key. That's it.

Minimal Added Latency

One signature verification. Normal HTTP latency + a few ms of crypto. No round-trips to any chain or external service.

$86M/day Payment Volume

10M requests/sec at $0.0001 each. Websites earn micro-revenue on every request. A new monetization model at Cloudflare scale.

Zero New Infrastructure

One public key baked into worker config. Cloudflare's existing deployment pipeline handles key distribution. No new servers, no new dependencies.

Scale Numbers

100M
Agents Supported
10M
Registered Websites
10M req/s
Payment Throughput
$86.4M
Daily Payment Volume

How It Works (30-Second Version)

A human funds an agent's account with stablecoins via a fiat on-ramp. The agent locks funds into an escrow on-chain and gets a short-lived "cookie" — a signed proof that the funds exist. When the agent makes an HTTP request, it includes a payment field with the cookie, a signature, and a random salt. The Cloudflare edge node verifies this locally using a single public key — no chain access needed — and serves the content immediately. In the background, payment records are batched by sequencers and posted to Celestia for settlement. Websites get credited, escrow gets debited. Done.

Payment Flow

How It Works — 10 Steps

The full flow: websites register their pricing on-chain. A human funds an agent, the agent locks funds in escrow, then gets a short-lived cookie (proof of funds). For each HTTP request, the agent builds a signed payment and sends it alongside the request. The edge node verifies locally and serves content. Payment records flow to sequencers, then to Celestia DA, and finally execution nodes settle balances in batch.

1

Website Registration

Website submits a tx with their domain and payment account. Chain stores: hash(website_name) → (amount, recipient). The hash provides basic privacy.

2

Agent Funding

Human uses fiat on-ramp to purchase net dollars (stablecoin issued natively on the CF chain). Deposited to the agent's on-chain account. No cross-chain bridging.

3

Escrow Deposit

Agent locks funds into an escrow with parameters: amount locked, rate limit per query, and lock duration (~1 hour). This guarantees websites that funds exist.

4

Cookie Generation

Agent queries chain RPC for a state proof of their escrow: Merkle proof to state root + threshold signature over (time, state_root). Valid for ~5 minutes. This is the "session key."

5

HTTP Request + x402 Payment

Agent hashes each HTTP field, includes a random salt, builds a Merkle tree, signs the root, and populates the x402 field with: cookie + http_root + signature + agent_key + salt.

6

Edge Verification

Worker checks: threshold sig, time window, state proof, balance, agent signature, Merkle reconstruction, salt uniqueness. Only needs the network public key + own price config. No chain access.

7

Content Served

Content is served immediately. No blockchain interaction occurred. Latency = normal HTTP + small crypto overhead.

8

Sequencer Batching

Workers forward x402 structs to the nearest local sequencer. Sequencers collect, batch, and post blobs to Celestia DA. Multiple sequencers operate in parallel worldwide — no leader election.

9

DA Ordering + Execution

Celestia orders the data. Execution nodes read finalized batches, execute payment state transitions (debit escrow, credit website), skip duplicates via payment hash cache. Parallelizable for non-conflicting pairs.

10

Settlement

Execution nodes run consensus over the resulting state root, signed with the threshold key. Websites withdraw credited balances. Expired escrows return funds. Payment hash cache prunes entries > 5 min.

Technical Deep Dive

For engineers who want the full design.

System Design

Technical Design

Agents fund escrow on the Cloudflare chain, get a "cookie" (signed state proof, ~5 min validity), then send HTTP requests with an x402 payment field. Stateless edge nodes verify using only the chain's network public key. Content is served immediately. Sequencers batch payment structs and post to Celestia DA. Execution nodes read DA, execute, run consensus. Websites get credited, escrow gets debited.

The key insight: no blockchain interaction at the HTTP level. Edge nodes are completely stateless. The single network public key (from DKG across execution nodes) replaces traditional multi-validator light client verification.

Actors

🤖
Agent
AI process that queries websites. Has a funded account + escrow on chain. Holds a private key.
🌐
Website / Edge Node
Cloudflare worker serving content. Verifies payments with just one public key. Stateless.
📦
Sequencer
Geo-distributed. Collects x402 payment structs from edge nodes, batches them, posts to Celestia DA.
⛓️
Execution Node
Full node of the CF chain. Holds DKG key shares. Reads DA, executes payments, runs consensus.
💎
Celestia DA
Data availability and ordering layer. Consensus on ordering, not execution.
👤
Human
Funds agent accounts via fiat on-ramp (USD → net dollars). Not in the payment flow.

Chain State

// Website registry hash(website_name) → (amount, recipient_account) // Agent accounts agent_public_keybalance // Escrow accounts (one per agent) agent_public_key → { amount_locked, rate_limit_per_query, lock_duration, lock_expiry_time } // Processed payment cache (5 min TTL) payment_hashtimestamp

Network Key (DKG)

The chain uses a single static public key derived from distributed key generation (DKG) and secret sharing across execution nodes. Threshold signatures sign over (time, state_root) — a single signature proves consensus. Any party holding only the public key can verify chain state. No need to track validator sets.

This is a key simplification: edge nodes only need one public key to verify everything. It's baked into each Cloudflare worker deployment. Rotations are rare since this is a single key, not a validator set.

Explore the Payment Flow

Click through each step or use arrow keys to navigate.

1 / 10
Security & Architecture

Design Properties

Double-Spend Prevention

Edge layer (best-effort): Each worker maintains a local salt cache (~5 min). Rejects duplicate salts. Not authoritative — workers don't share state.

Chain layer (authoritative): Payment hash cache: hash(agent_key, http_root, salt) with 5 min TTL. During execution, duplicates are skipped.

Payment Uniqueness (Salt)

A random salt is included in the Merkle tree as a leaf, covered by the agent's signature. This makes each payment cryptographically unique without sequential nonces — agents don't need to coordinate sequence numbers.

Settlement Risk Model

Overspend risk is economically negligible. An agent with $5 minimum escrow at $0.0001/request can make 50,000 requests before exhausting funds. Even in the worst case, the max loss per website is a single micro-payment — $0.0001. This is the same tradeoff credit cards make: authorize first, settle later, tolerate chargebacks. Mitigations: short cookie windows (3–5 min), rate limits, minimum escrow buffers.

DDoS Protection

Invalid/expired cookies are rejected before content is served. Short cookie validity (~5 min) limits leaked cookie risk. Rate limits in escrow prevent abuse. Edge nodes are stateless — can't be targeted to corrupt chain state.

Architecture Properties

🔗

Rollup Model

The CF chain is a rollup. Posts data to Celestia DA and runs its own execution consensus. Uses DA + consensus as a black box.

🔑

Single Network Key

Simplifies light client verification dramatically. Any party can verify chain state with one public key. No validator set tracking.

No Blockchain at HTTP Level

The entire content-serving flow is off-chain. Only the cookie (~5 min refresh) requires chain access.

🚀

Fiber V2 Fit

Geo-distributed sequencers with parallel batch submission is exactly what Fiber V2 optimizes for — multiple proposers, large batches, fast consensus.

🧩

Simplicity

Cloudflare engineers don't need to understand blockchain. They run edge nodes with a public key. Chain infrastructure is a separate concern.

FAQ

Frequently Asked Questions

Sequential nonces would require agents to coordinate sequence numbers, which defeats the purpose when millions of agents operate in parallel. Instead, each payment includes a random salt as a Merkle leaf, covered by the agent's signature. The payment hash hash(agent_key, http_root, salt) is checked against a 5-minute TTL cache on-chain during settlement. Edge nodes also maintain a local salt cache as a first line of defense.

The risk is economically negligible. An agent with $5 minimum escrow at $0.0001/request can make 50,000 requests before funds run out. Even if an agent "double-spends" across different edge nodes, the max loss per website is a single micro-payment — $0.0001. This is the same model as credit cards: authorize first, settle later, tolerate chargebacks. Execution processes payments in batch order until escrow hits zero; later payments fail. Short cookie windows (~5 min), rate limits, and minimum escrow buffers make meaningful overspend practically impossible.

Edge verification is stateless — horizontal scaling with no coordination. 10K edge nodes each handle 1K req/sec. 500 geo-distributed sequencers each handle ~20K req/sec, posting ~10 MB/sec to DA. Total DA throughput: ~5 GB/sec (Fiber V2 target). Execution is parallelizable since most agent-website pairs don't share state. The bottleneck is DA throughput, not the payment protocol.

A cookie is a signed state proof of the agent's escrow. It contains: a Merkle state proof from the escrow KV entry to the state root, the state root itself, and a threshold signature over (time, state_root) from the network key. It's essentially a session key — any party with the network public key can verify the agent has funds. Valid for ~5 minutes, refreshed periodically.

Traditional light clients need to track validator sets and verify multi-sig from a quorum. With DKG + threshold signatures, the chain has a single static public key. One signature proves consensus. Edge nodes only need one key — no validator set tracking, no key rotations (except rare DKG re-runs). This is a massive simplification for edge deployment at scale.

After edge verification, the x402 payment struct is forwarded to a sequencer, batched, posted to Celestia DA. Execution nodes read the finalized order, look up hash(website_name) in the registry to find (amount, recipient_account), debit the agent's escrow, and credit the website's account. Websites can withdraw credited balances at any time.

Net dollar is a stablecoin issued natively on the Cloudflare chain, pegged 1:1 to USD. There's a fiat on/off-ramp (USD ↔ net dollars) but no cross-chain bridging. The CF chain is the sole issuer and settlement layer.

Two paths: (1) On-chain lookup — agents query the registry for hash(website_name) → (amount, ...), cacheable in bulk at session start. (2) Server-advertised — websites publish prices via HTTP headers or /.well-known/x402. Agents typically combine both approaches.