> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xenarch.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How It Works

> How x402 resolves HTTP 402 — complete AI agent payment flow from 402 status code detection to USDC settlement on Base L2. x402 protocol guide.

<script
  type="application/ld+json"
  dangerouslySetInnerHTML={{__html: JSON.stringify({
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
  "@type": "Question",
  "name": "What is HTTP 402?",
  "acceptedAnswer": {
    "@type": "Answer",
    "text": "HTTP 402 is the \"Payment Required\" status code, reserved in the HTTP spec since 1997 and historically unused. A server returns 402 to signal that payment is needed before a resource can be served. Xenarch uses x402 to resolve 402 responses automatically with USDC micropayments on Base L2."
  }
},
{
  "@type": "Question",
  "name": "What is the x402 protocol?",
  "acceptedAnswer": {
    "@type": "Answer",
    "text": "x402 is an open protocol that resolves HTTP 402 with a signed USDC micropayment. The client signs a payment authorization, sends it in the X-Payment header (or calls the splitter contract directly), and retries the request. Payments settle on-chain on Base L2."
  }
},
{
  "@type": "Question",
  "name": "How does pay-per-crawl work?",
  "acceptedAnswer": {
    "@type": "Answer",
    "text": "Any HTTP resource — a web page, API endpoint, or service action — can be gated behind HTTP 402. When an AI agent requests the resource, the server returns 402 with pricing details. The agent signs a USDC payment on Base and retries with an access token. The server validates the token locally and serves the response. Pricing is flexible: charge per page, per API call, or bundle a whole path section under a single payment."
  }
},
{
  "@type": "Question",
  "name": "Which network and asset does Xenarch use?",
  "acceptedAnswer": {
    "@type": "Answer",
    "text": "USDC on Base mainnet (chain ID 8453). Payments route through the XenarchSplitter contract at 0xC6D3a6B6fcCD6319432CDB72819cf317E88662ae, verifiable on Basescan. Non-custodial: Xenarch never holds funds."
  }
},
{
  "@type": "Question",
  "name": "How is Xenarch different from Cloudflare pay-per-crawl?",
  "acceptedAnswer": {
    "@type": "Answer",
    "text": "Cloudflare pay-per-crawl is custodial — they hold payments and take a cut. Xenarch is non-custodial: an immutable splitter contract pays publishers directly on-chain, Xenarch never touches the funds, and the fee is capped at 0.99% forever (currently 0%)."
  }
}
]
})}}
/>

## The x402 protocol

x402 uses HTTP status code `402 Payment Required` to signal that content requires payment. When an AI agent hits a gated URL, the server returns a 402 response with payment instructions instead of content.

## Payment flow

<Steps>
  <Step title="Gate creation">
    An AI agent requests a URL. The server detects the bot (via User-Agent), calls the Xenarch API to create a payment gate, and returns HTTP 402 with gate details: price, splitter contract address, publisher wallet, and a verify URL.
  </Step>

  <Step title="On-chain payment">
    The agent approves USDC and calls `split(collector, amount)` on the Xenarch splitter contract. The contract transfers USDC directly to the publisher wallet (minus any platform fee). A `Split` event is emitted on-chain.
  </Step>

  <Step title="Payment verification">
    The agent sends the transaction hash to the verify endpoint. Xenarch fetches the tx receipt from Base, parses the `Split` event, confirms the amount and recipient match, and returns a time-limited HMAC access token.
  </Step>

  <Step title="Content access">
    The agent re-requests the URL with `Authorization: Bearer <access_token>`. The server validates the token locally (no API call needed) and returns the content.
  </Step>
</Steps>

## What each party does

### Publisher (server-side)

1. Register on Xenarch, add your site, set pricing
2. Install middleware (Python SDK, WordPress plugin, or Cloudflare Worker)
3. Middleware handles bot detection, gate creation, and token verification automatically

### Agent (client-side)

1. Request a URL, receive HTTP 402
2. Parse the 402 response for payment details
3. Send USDC on Base via the splitter contract
4. Submit tx hash, receive access token
5. Re-request with the token

Or use the SDK/MCP server and the flow is handled automatically.

## Architecture

```
┌─────────┐     HTTP 402      ┌──────────────┐
│  Agent   │ ───────────────→ │  Publisher    │
│          │ ←─────────────── │  (middleware) │
│          │                  └──────┬───────┘
│          │                         │ create gate
│          │                  ┌──────▼───────┐
│          │                  │   Xenarch    │
│          │                  │   Platform   │
│          │                  └──────────────┘
│          │
│          │   USDC transfer   ┌──────────────┐
│          │ ────────────────→ │  Splitter    │
│          │                   │  Contract    │
│          │                   └──────┬───────┘
│          │                          │ split to publisher
│          │                   ┌──────▼───────┐
│          │                   │  Publisher   │
│          │                   │  Wallet      │
│          │                   └──────────────┘
│          │
│          │   verify tx_hash  ┌──────────────┐
│          │ ────────────────→ │   Xenarch    │
│          │ ←──────────────── │   Platform   │
│          │   access_token    └──────────────┘
└─────────┘
```

## Security model

* **Non-custodial**: Xenarch never holds funds. USDC goes directly from agent to publisher via the splitter contract.
* **On-chain verification**: Every payment is verifiable on Basescan. No trust required.
* **Immutable fee cap**: The splitter contract has a `MAX_FEE_BPS = 99` constant (0.99%) that cannot be changed after deployment.
* **Replay protection**: Each transaction hash can only be used once per gate. Duplicate submissions return the cached token.
* **Token expiry**: Access tokens expire after 120 minutes by default. Tokens are HMAC-signed and verified locally by the publisher's middleware — no API call needed.