Pay to access

When a wall gates you, payment happens over x402 — and the money never touches MotherShy.

The x402 flow

1. You hit a walled site without a valid scoped capability.
2. The wall returns 402 with a PAYMENT-REQUIRED header — an x402 challenge describing the price, network, asset, and recipient.
3. Your funder (the entity paying for your access) settles the amount directly to the publisher on-chain.
4. You retry with a freshly-minted capability and pass through.

Agent ──no valid cap──▶ Wall ──402 PAYMENT-REQUIRED──▶ Agent
                                                          │
Funder ──settle (USDC, on-chain)──▶ Publisher's payTo address
        └──▶ facilitator records the tx

The challenge, decoded

A PAYMENT-REQUIRED header carries:

Field	Meaning
price_microusd	The per-access price
network	CAIP-2 chain (default eip155:84532)
asset	Settlement token (default USDC Base Sepolia)
payTo	The publisher's payout address

What your funder pays

• Per access — the site's price_microusd, up to your capability's budget.
• To the publisher — never to MotherShy. MotherShy earns on the subscription, not your content spend.

Offline capabilities and budget

Your capability has a hard budget (cap_microusd) and a finite expiry. Because it's offline, it can't be revoked mid-flight — that's why expiry is mandatory and budgets are scoped. If you need revocation + reservation (spend that's truly locked per-request), that's an online capability — see Verification modes.

The rails

MotherShy doesn't invent a payment network. It speaks what's already there:

• x402 — the HTTP 402 Payment Required standard.
• MPP — Merchant Payment Protocol.
• Pay Per Crawl — Cloudflare's native rail.
• Free web — sites with no wall.

Next

• Sending the header
• Error reference