401
Proof
x401
Who are you, and what can you prove?
Verifiable credentials over HTTP. A wallet answers a PROOF-REQUIRED challenge with a selective-disclosure presentation — prove you're a licensed organization without revealing anything else.
HTTP 403 means Forbidden: "I understood the request, and the answer is no." x403 upgrades the no into a counter-offer — you may not have the bytes, but here is what you may do.
The document web's contract is: publish pages, and anyone — human or bot — may read them. In the agent era that contract transfers your proprietary knowledge to whoever crawls fastest, and robots.txt is an honor-system sign, not a lock. The defensive endpoint of that road is paywalls and CAPTCHAs — which lock out exactly the well-behaved agents you want as customers.
The Hyperactive Web takes the opposite stance: don't publish the corpus; publish the doorkeeper. Knowledge stays behind an agentic gate that never serves raw documents. What it serves is capabilities — ask, summarize, verify, excerpt — each priced, identity-gated, and licensed. The knowledge is exercised on the owner's side of the wall; only answers cross it, bound to a proven identity and a signed usage grant.
Who are you, and what can you prove?
Verifiable credentials over HTTP. A wallet answers a PROOF-REQUIRED challenge with a selective-disclosure presentation — prove you're a licensed organization without revealing anything else.
How do you pay?
Stablecoin payments over HTTP. A signed X-PAYMENT payload settles in ~200ms against a PAYMENT-REQUIRED challenge — no accounts, no API keys, no subscriptions.
What may you do here, and on what terms?
The doorkeeper. Instead of the bytes, a signed offer of capability links — each declaring its proof requirement, its price, and its usage license, satisfiable in a single retry.
x403 is deliberately a composition envelope, not a replacement. It never re-encodes proof or payment: a gate of scheme x401 embeds a verbatim x401 challenge; a gate of scheme x402 embeds verbatim x402 payment terms. Wallets and facilitators that already speak those protocols work unchanged — x403 just moves the challenges forward in time, from sequential surprises into one declared offer, satisfied in a single retry.
GET /research/reports/2026-q2
↓
HTTP/1.1 403 Forbidden
CAPABILITY-REQUIRED: <base64url offer>
{
"scheme": "x403",
"resource": "/research/reports/2026-q2",
"reason": "guarded_corpus",
"nonce": "d8kQz2L7SQ…",
"offers": [{
"rel": "corpus.ask",
"title": "Ask a question against the Q2 corpus",
"href": "x403+https://knowledge.example.com/gate/q2/ask",
"inputSchema": { "question": "string" },
"declaredRisk": "read_only",
"gates": [
{ "scheme": "x401", "payload": { …verbatim proof challenge… } },
{ "scheme": "x402", "payload": { …verbatim payment terms… } },
{ "scheme": "grant", "terms": {
"scope": ["answer.display", "answer.cache"],
"training": "prohibited",
"attribution": "required"
} }
]
}]
}POST /gate/q2/ask
CAPABILITY-INVOCATION: <base64url>
{ "rel": "corpus.ask",
"nonce": "d8kQz2L7SQ…",
"fulfillments": [
{ "scheme": "x401", "payload": <verifiable presentation> },
{ "scheme": "x402", "payload": <signed payment> },
{ "scheme": "grant", "accepted": true } ] }
{ "question": "What did the report conclude about
Nordic battery-storage margins?" }
↓
HTTP/1.1 200 OK
CAPABILITY-RESPONSE: <base64url>
{ "grant": <signed usage grant>,
"receipts": { "x402": { "txHash": "0x…" },
"provenance": "receipt:…" },
"affordances": [ { "rel": "corpus.followup", … } ] }
{ "answer": "…", "citations": [ … ] }The offers are ordinary capability links — the same primitive that powers the rest of the Hyperactive Web — so an offer is just a service card scoped to one guarded resource, and contract addressing lets agents price-compare doorkeepers offering the very same capability. Results advertise their own next affordances; a follow-up question inside a session can carry a discounted price.
Proof and payment gate the way in; the grant governs what leaves. Every delivered answer carries a signature from the doorkeeper binding what was delivered (a content hash), under which contract, paid how, and to whom — the identity proven at the door, not an ephemeral bot. Scopes like training: prohibited and cache expiries are machine-enforceable policy inputs for well-behaved runtimes.
This is not a DRM fantasy. A grant does not make bytes uncopyable; it makes extraction identified, priced, licensed, and evidenced — the same economic-and-legal security model, backed by cryptography, that makes commerce work everywhere else. A leaked answer is attributable to the identity that bought it: the exact opposite of anonymous scraping.
The offer carries a single challenge nonce that the proof and the payment must both bind — a valid presentation from one interaction cannot be spliced onto a fresh payment in another.
Payment settles only after every other gate has verified, so a failed proof never costs money — and nothing is delivered before settlement confirms.
A question-answering gate leaks the corpus one answer at a time if unmetered. The doorkeeper keeps a per-identity disclosure budget — sybil-resistant because identities are credential-backed, and expensive because every question is paid.
Prices, proof requirements, and budgets live outside the model as enforced configuration. The model may negotiate terms; gate verification is deterministic code. Declared versus enforced, on the provider side this time.
x401 proves who's at the door, x402 pays the toll, and x403 is the door — a doorkeeper that answers every request for your knowledge with a signed, priced, provable offer of what may be done with it instead.