> For the complete documentation index, see [llms.txt](https://parad0xlabs.gitbook.io/parad0xlabs-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://parad0xlabs.gitbook.io/parad0xlabs-docs/dna-x402-payment-rail/how-it-works.md).

# How It Works

## The HTTP 402 Flow

x402 is a payment layer built on the HTTP 402 status code. The full request-response cycle uses standard HTTP headers — no SDK required on either side beyond the facilitator cosigner.

```mermaid
sequenceDiagram
    participant C as Client
    participant S as Server
    participant F as Facilitator
    participant SOL as Solana Mainnet

    C->>S: GET /protected-resource
    S-->>C: 402 Payment Required<br/>X-Payment-Details: {amount: "0.10", token: "USDC", chain: "solana", facilitator: "https://facilitator.x402.org/solana"}
    C->>SOL: USDC SPL transfer (exact amount, to server's payment address)
    SOL-->>C: tx signature
    C->>F: POST /cosign {tx_sig, request_hash, timestamp}
    F->>SOL: verify tx confirmed + amount + recipient
    F-->>C: signed receipt {tx_sig, request_hash, timestamp, facilitator_sig}
    C->>S: GET /protected-resource<br/>X-Payment-Receipt: {tx_sig, request_hash, timestamp, facilitator_sig}
    S->>S: verify receipt (amount ✓, recipient ✓, request_hash ✓, facilitator_sig ✓)
    S-->>C: 200 OK + response body
```

The `X-Payment-Details` header specifies the exact amount, token contract, destination address, and which facilitator endpoint to cosign with. The `X-Payment-Receipt` header carries the four-field bundle back. Server verification is local — no network call required if the server caches the facilitator's public key.

***

## Why No Oracle

Every DePIN payment oracle answers the same question: "did work happen?" x402 does not ask that question. The receipt answers it cryptographically.

A valid x402 receipt contains four fields:

| Field             | What It Proves                                                                       |
| ----------------- | ------------------------------------------------------------------------------------ |
| `tx_sig`          | An on-chain USDC transfer occurred                                                   |
| `request_hash`    | The transfer was made for this specific HTTP request, not reused from another        |
| `timestamp`       | The transfer happened within the valid window (prevents replay)                      |
| `facilitator_sig` | The facilitator confirmed `tx_sig` landed on-chain with correct amount and recipient |

All four must be present and internally consistent. The `request_hash` is computed from the request method, URL, headers, and body — rebinding a receipt to a different request is cryptographically impossible without invalidating `facilitator_sig`. There is no committee, no weighted validator set, no trusted enclave computing whether work was delivered. The receipt is the proof.

The facilitator is lighter than a DePIN oracle: it cosigns receipts and confirms on-chain state, but does not allocate reward amounts, does not run a work-verification database, and does not gate payment on proprietary output evaluation. Any operator can run a facilitator.

***

## DePIN vs x402 Comparison

```mermaid
flowchart LR
    subgraph Grass
        G1[Worker] --> G2[Single Validator]
        G2 --> G3[Reward]
    end
    subgraph io.net
        I1[GPU Node] --> I2[OTOY zkTFLOPs Gate]
        I2 --> I3[Payment]
    end
    subgraph Helium
        H1[Hotspot] --> H2[Nova Labs Oracle DB]
        H2 --> H3[HNT Reward]
    end
    subgraph x402
        X1[Client] --> X2[On-chain tx]
        X2 --> X3[Facilitator cosign]
        X3 --> X4[Receipt — cryptographic]
        X4 --> X5[Server releases resource]
    end
```

| Network | Who Decides If Work Happened                                                                                                                                  | Can Be Censored?  |
| ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- |
| Grass   | Single Validator controls reward allocation; ZK proofs attest data integrity but do not route payment                                                         | YES               |
| io.net  | OTOY software gate; 2024 Sybil attack exposed 1.8M fake GPUs passed through central verification                                                              | YES               |
| Helium  | Nova Labs / Helium Foundation oracles compute reward totals in Foundation-owned database (`helium/oracles` repo); HIP-70 multi-operator transition incomplete | YES               |
| Render  | OTOY validates rendered output; nodes cannot participate without OctaneRender (proprietary)                                                                   | YES               |
| Akash   | No verification at all — payment flows regardless of delivery                                                                                                 | work can be faked |
| x402    | Cryptographic receipt (`request_hash` + `tx_sig` + `timestamp` + `facilitator_sig`)                                                                           | NO                |

***

## The x402\_endpoint Field

The `.null` domain PDA (`null_registrar`: `H4wbFJucY9shJt95N8Bra532Z4nnkKhGEfqWvLcYfuDm`) stores the x402 endpoint directly in the account layout.

**PDA layout (314 bytes total):**

| Offset  | Size    | Field                                        |
| ------- | ------- | -------------------------------------------- |
| 0       | 1       | `disc` (`0x4E`)                              |
| 1       | 64      | `name` (UTF-8, null-padded)                  |
| 65      | 32      | `owner`                                      |
| 97      | 32      | `arweave_txid`                               |
| **129** | **128** | **`x402_endpoint`** (UTF-8 URL, null-padded) |
| 257     | 32      | `passport_hash`                              |
| 289     | 8       | `registered_at`                              |
| 297     | 8       | `expires_at`                                 |
| 305     | 8       | `null_paid`                                  |
| 313     | 1       | `bump`                                       |

`x402_endpoint` sits at byte offset 129 and is 128 bytes of null-padded UTF-8. The `UpdateEndpoint` instruction (tag `0x06`, owner-only) overwrites this field in place.

Resolution flow:

```mermaid
flowchart LR
    A[foo.null] --> B[Chrome extension derives PDA<br/>seeds: null-domain + sha256 of name]
    B --> C[Fetch account from mainnet RPC]
    C --> D[Read bytes 129–256<br/>trim null bytes → x402_endpoint URL]
    D --> E[POST to endpoint with X-Payment-Details flow]
    E --> F[Receive resource]
```

Name → PDA → `x402_endpoint` at offset 129 → pay → receive. No DNS lookup. No ICANN. No separate registry query. The endpoint is embedded in the same account that owns the `.null` name.

***

## Current Implementation State

**Repository:** `/Users/sauliuskruopis/Desktop/dna - x402`\
**Status as of 2026-06-06:** Directory created June 4, 2026. No files exist yet.

### Planned packages (not yet built)

| Package     | Description                                                                                             | Status             |
| ----------- | ------------------------------------------------------------------------------------------------------- | ------------------ |
| `x402-gate` | Server middleware; wraps `@x402/svm` + `@x402/express` v2.3.0; validates receipts, issues 402 responses | STUB — not started |
| `x402-pay`  | Client-side payment agent; hard spend caps enforced locally before tx signing; V1 USDC only             | STUB — not started |

### What exists in the wider stack that x402 connects to

| Component                                                          | Location                    | State                                         |
| ------------------------------------------------------------------ | --------------------------- | --------------------------------------------- |
| `x402_endpoint` field in PDA                                       | `null_registrar` on mainnet | LIVE — `UpdateEndpoint` (0x06) deployed       |
| USDC SPL transfer path                                             | Solana mainnet              | LIVE — standard SPL, no custom program needed |
| NULLA credit ledger (SQLite)                                       | `Parad0x-Labs/nulla-local`  | LIVE locally — earns/spends credits per task  |
| Receipt-DAG (x402 receipt ID → task\_id → WorkProof → SPL Memo tx) | unbuilt                     | NOT LIVE                                      |
| Credit export from SQLite ledger to x402 receipts                  | unbuilt                     | NOT LIVE                                      |
| NULL token facilitator (V2)                                        | unbuilt                     | NOT LIVE                                      |
| Dark Passport-gated x402 endpoints                                 | unbuilt                     | NOT LIVE                                      |

### Gaps that dna-x402 will fill (confirmed June 2026)

1. Self-custodial Solana facilitator with non-USDC / NULL token support — all existing Solana facilitators are USDC-only.
2. Agent wallet with hard spend caps on Solana x402 — existing solutions (`AgentPay MCP`, `Harvey Budget`) are EVM/Base only.
3. x402 + local LLM mesh integration — no prior implementation exists.
4. Receipt-DAG audit trail — no existing x402 project builds the graph layer linking receipt ID → task → proof → on-chain memo.
5. Dark Passport-gated x402 endpoints — no project gates x402 on a ZK reputation proof before the payment step.

### x402 ecosystem scale (April 2026)

* \~165M cumulative transactions, \~$50M volume, \~69K active agents
* Solana share: 37M+ transactions, 70% of monthly volume
* Linux Foundation governance; named partners: Coinbase, Cloudflare, Google, Visa, Anthropic, Circle, AWS, Vercel


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://parad0xlabs.gitbook.io/parad0xlabs-docs/dna-x402-payment-rail/how-it-works.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.