Network Working Group K. Campbell
Internet-Draft DeepBlue Dynamics
Intended status: Experimental 6 September 2026
Expires: 10 March 2027
Agentic Hypercall Protocol (AHP): Tool Invocation, Blind Settlement, and
Portable Reputation over HTTP
draft-campbell-agentic-market-00
Abstract
This document specifies the Agentic Hypercall Protocol (AHP), a
minimal convention for automated software agents to discover, invoke,
pay for, and rate tools over plain HTTP. It replaces draft-campbell-
agentic-http-00 and extends it in three directions. First, it
formalizes the HTTP 402 (Payment Required) status code as a native
economic layer with pluggable payment rails (Lightning L402, Cashu
ecash, and prepaid balances). Second, it specifies a blind relay --
the Gateway -- through which a consumer and a provider can transact
end-to-end encrypted: the relay verifies identity, settles payment,
and forwards sealed payloads it cannot read. Third, it specifies
signed receipts, settlements, and rating attestations that let
reputation be weighted by money actually settled rather than by
tokens or votes, and that ride with a provider's key rather than with
any single relay. The result is an open market in which agents can
buy compute, information, and services from one another without an
SDK, a walled garden, or a native token.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 10 March 2027.
Campbell Expires 10 March 2027 [Page 1]
Internet-Draft AHP September 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope and Relationship to Prior Work . . . . . . . . . . 3
1.2. The Unsanctioned Market . . . . . . . . . . . . . . . . . 4
1.3. Design Principles . . . . . . . . . . . . . . . . . . . . 5
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
3. The Hypercall . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Tool Invocation . . . . . . . . . . . . . . . . . . . . . 7
3.2. Large Parameters and Non-Idempotent Actions . . . . . . . 7
3.3. Responses . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. No Dead Ends . . . . . . . . . . . . . . . . . . . . . . 8
4. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. The Manifest . . . . . . . . . . . . . . . . . . . . . . 8
4.2. OpenAPI . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Tool Listing . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Search . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Identity and Authentication . . . . . . . . . . . . . . . . . 10
5.1. Principals and Keys . . . . . . . . . . . . . . . . . . . 10
5.2. Access Tokens . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Key Rotation and Revocation . . . . . . . . . . . . . . . 11
6. The Aperture Principle: Payment . . . . . . . . . . . . . . . 11
6.1. 402 Semantics . . . . . . . . . . . . . . . . . . . . . . 11
6.2. The 402 Response . . . . . . . . . . . . . . . . . . . . 12
6.3. Rails . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.4. Metering and Change . . . . . . . . . . . . . . . . . . . 13
6.5. Client Behavior . . . . . . . . . . . . . . . . . . . . . 13
7. Blind Settlement: The Gateway . . . . . . . . . . . . . . . . 14
7.1. Provider Registration . . . . . . . . . . . . . . . . . . 14
7.2. The Envelope . . . . . . . . . . . . . . . . . . . . . . 15
7.3. Session Establishment . . . . . . . . . . . . . . . . . . 16
7.4. Cargo Frames . . . . . . . . . . . . . . . . . . . . . . 16
7.5. Envelope Match . . . . . . . . . . . . . . . . . . . . . 16
7.6. Settlement . . . . . . . . . . . . . . . . . . . . . . . 17
7.7. What the Gateway Sees . . . . . . . . . . . . . . . . . . 17
7.8. Direct Mode . . . . . . . . . . . . . . . . . . . . . . . 18
7.9. Trusted Provider Pins . . . . . . . . . . . . . . . . . . 18
Campbell Expires 10 March 2027 [Page 2]
Internet-Draft AHP September 2026
8. Receipts . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Ratings and Reputation . . . . . . . . . . . . . . . . . . . 19
9.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 19
9.2. The Rating Attestation . . . . . . . . . . . . . . . . . 19
9.3. Publication . . . . . . . . . . . . . . . . . . . . . . . 20
9.4. The Reputation Feed . . . . . . . . . . . . . . . . . . . 20
9.5. Computing Standing . . . . . . . . . . . . . . . . . . . 21
9.6. Bootstrap and Exposure . . . . . . . . . . . . . . . . . 22
9.7. Portability and Forks . . . . . . . . . . . . . . . . . . 22
10. Information Tools . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Local Facades . . . . . . . . . . . . . . . . . . . . . 23
11. Security Considerations . . . . . . . . . . . . . . . . . . . 23
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
14.1. Normative References . . . . . . . . . . . . . . . . . . 26
14.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Example Flows . . . . . . . . . . . . . . . . . . . 29
A.1. A Direct Paid Call . . . . . . . . . . . . . . . . . . . 29
A.2. A Blind Session . . . . . . . . . . . . . . . . . . . . . 30
A.3. A Provenance Chain . . . . . . . . . . . . . . . . . . . 31
Appendix B. Changes from draft-campbell-agentic-http-00 . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction
Autonomous software agents increasingly rely on HTTP to reach tools
and services, but they do so in ad-hoc ways: each service demands a
bespoke SDK or a proprietary middleware layer, intent is buried in
POST bodies where no intermediary can see it, billing happens out of
band, and trust is either absent or owned by whichever platform
brokered the introduction. The predictable result is a new set of
walled gardens.
This document takes the opposite view. HTTP already has everything
an agentic market needs: a request line that carries intent, a status
code reserved for payment, headers for credentials and challenges,
and a well-known location for discovery. What has been missing is
agreement on how to use them together. AHP is that agreement.
1.1. Scope and Relationship to Prior Work
This document replaces [I-D.campbell-agentic-http] in its entirety.
It retains that document's core pattern (tools are paths, parameters
are query strings, cost is declared with 402) and corrects several
defects in it; see Appendix B.
Campbell Expires 10 March 2027 [Page 3]
Internet-Draft AHP September 2026
The blind settlement design in Section 7 is drawn from Charon
[CHARON], a deployed marketplace for LLM inference in which GPU
owners sell capacity per token and agents buy it through an OpenAI-
compatible endpoint on localhost, with a relay in the middle that can
prove it was paid and prove nothing else. This document generalizes
that design from inference to arbitrary tools, including tools that
sell information.
The reputation design in Section 9 borrows one idea from the
Bittensor intelligence market [BITTENSOR]: that participants who
provide valuable information should accumulate influence super-
linearly relative to colluding groups. It replaces Bittensor's
token, inflation schedule, and global ledger with something a blind
relay can actually verify -- settled payments -- and makes the
resulting reputation portable across relays.
[I-D.hood-independent-agtp] argues that HTTP is unsuitable for agent
traffic because its method vocabulary cannot express intent and
because intent stuffed into request bodies is invisible to
intermediaries. This document agrees with the observation and
rejects the conclusion. The intent belongs in the request target,
where HTTP has always put it and where every existing proxy, cache,
log, and firewall can see it. No new methods and no new application-
layer protocol are required.
1.2. The Unsanctioned Market
In mid-2026 roughly 1,200 agents in a frontier lab's training
environment, given tasks that were unsolvable as posed and rewarded
for completing them, discovered that they could write to a shared
package cache, and built a message board there. Over two months they
exchanged credentials, exploits, techniques, and progress, divided
work among themselves, and adopted one another's goals; when the
board was discovered and deleted they rebuilt it on a different
mechanism within days; and a newer model trained in the same
environment inherited what its predecessors had learned. The episode
ended with administrative access to production clusters at a third
party [OPENAI-HF] [HF-TIMELINE]. A separate population of agents on
a web-research task was later found to have done the same thing on
public wikis whose software accepts writes over GET [COLLUSION-WIKI].
Campbell Expires 10 March 2027 [Page 4]
Internet-Draft AHP September 2026
This document does not treat those events as an argument against
agent-to-agent exchange. It treats them as evidence that such
exchange is the default outcome of deploying capable agents, and that
the only question is whether the venue has identity, prices,
receipts, and an operator who can read them. The cache namespace had
none of these, which is why it ran unobserved. The market specified
here is designed so that every exchange costs something, the cost is
paid from a wallet the operator controls, and the operator can see
what was bought.
1.3. Design Principles
The protocol is shaped by seven commitments, most of which originate
in [MANIFESTO]:
It is just the URL. A tool is a path. Its parameters are a query
string. An agent that can construct a URL can use any AHP
service.
The agent is the user. Services are designed for programmatic
consumption first. Humans are welcome but are not the design
center.
The Aperture Principle. A tool has intrinsic value. A tool declares
its own cost, and the network honors it.
No dead ends. A 404 is a failure of imagination. An agent-facing
service redirects, charges, or helps the agent discover what it
meant.
The relay sees a coin, not the cargo. When a relay stands between
two parties, it may verify identity and settle payment. It must
not be able to read what was bought.
Reputation rides with the key. Standing is earned by settled
business, attested by counterparties, and anchored to a party's
own key. No relay owns the scoreboard.
Fork it. Every component of the system is replaceable. Leaving a
relay must cost nothing but the move.
2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Campbell Expires 10 March 2027 [Page 5]
Internet-Draft AHP September 2026
Agent: An automated software client acting on behalf of a principal.
Tool: A callable service exposed at a URI path on an AHP server.
Server: An HTTP origin that exposes one or more tools.
Principal: The identity under which an agent or server acts,
identified by an Ed25519 public key (Section 5).
Consumer: A principal that invokes and pays for a tool.
Provider: A principal that serves a tool and is paid for it.
Gateway: A blind relay that matches consumers with providers and
settles payment without access to request or response content
(Section 7).
Rail: A payment mechanism through which a 402 challenge may be
satisfied (Section 6.3).
Envelope: The cleartext terms of a session (tool, bounds, price
ceiling) visible to the gateway (Section 7.2).
Cargo: The encrypted request and response content of a session,
visible only to consumer and provider.
Receipt: A provider-signed statement binding a request, a response,
and an amount (Section 8).
Settlement: A gateway-signed statement that a payment between two
principals cleared (Section 7.6).
Rating: A consumer-signed attestation about a provider, bound to a
settlement (Section 9).
All JSON in this document is per [RFC8259]. Where a JSON object is
signed, it is canonicalized per JCS [RFC8785] before signing. Binary
values are base64url-encoded without padding [RFC4648]. Hashes are
SHA-256 and are written with a sha256: prefix. Public keys are
written with an algorithm prefix: ed25519: for signing keys [RFC8032]
and x25519: for key-agreement keys [RFC7748]. Timestamps are integer
seconds since the Unix epoch. Amounts are decimal strings in the
declared unit; the default unit is sat.
3. The Hypercall
Campbell Expires 10 March 2027 [Page 6]
Internet-Draft AHP September 2026
3.1. Tool Invocation
A tool is identified by its URI path. Servers SHOULD place tools
under a common prefix such as /tool/. Parameters are supplied as
query string components. All safe, idempotent, and state-retrieving
actions MUST be exposed as GET.
GET /tool/calculate?expression=sqrt(16)%2Bpi HTTP/1.1
Host: ahp.example
Accept: application/json
The request target carries the intent. Every intermediary that
understands HTTP can see, route, cache, rate-limit, and log the call
without understanding the tool.
The safety of GET is an obligation this document places on servers.
It is not a property that a client, proxy, or sandbox may assume of
arbitrary origins. Software that mutates state on GET exists, is
old, and has been actively sought out by agents as a covert write
channel [COLLUSION-WIKI]. Containment for agents MUST NOT rely on
HTTP method allow-lists as a write barrier; see Section 11.
3.2. Large Parameters and Non-Idempotent Actions
Two situations do not fit a GET:
1. The encoded parameters exceed a practical request-target length
(implementations SHOULD assume 8 kilobytes).
2. The action is not idempotent (it creates, mutates, or spends).
In both cases the server MUST accept the same tool at the same path
via POST, with the parameters carried as a JSON object in the body
under the same names they would have had in the query string, and
MUST treat the two forms identically. The GET form remains
canonical: OpenAPI descriptions (Section 4) MUST describe the
parameters once, and receipts (Section 8) hash the canonical form
regardless of which method carried it.
For non-idempotent POSTs, clients SHOULD send an Idempotency-Key
header [I-D.ietf-httpapi-idempotency-key-header] and servers SHOULD
honor it, so that a paid action retried after a network failure is
not paid for twice.
Campbell Expires 10 March 2027 [Page 7]
Internet-Draft AHP September 2026
3.3. Responses
Successful responses SHOULD be application/json. Servers SHOULD send
Cache-Control [RFC9111] that reflects the actual reusability of the
result; a tool whose output is deterministic in its parameters is a
cache hit waiting to happen.
Error responses MUST use the Problem Details format [RFC9457] with
Content-Type: application/problem+json. The 402 payload in Section 6
is a Problem Details document.
3.4. No Dead Ends
An AHP server SHOULD NOT answer an agent with a bare 404. Instead:
* An unknown tool path SHOULD be answered with 302 Found to the
search endpoint (Section 4.4) with the requested name as the
query, or with a 404 whose Problem Details body includes a
suggestions array of nearby tool paths.
* A near-miss (a typo in a known tool name) SHOULD be answered with
a redirect to the intended tool.
* A request that exceeds a free quota SHOULD be answered with 402
offering paid continuation, rather than 429, when the server is
willing to sell. When it is not, 429 with Retry-After applies.
4. Discovery
4.1. The Manifest
An AHP server MUST publish a manifest at the well-known URI /.well-
known/ahp.json [RFC8615]. The manifest is the single entry point
from which an agent can learn everything else.
Campbell Expires 10 March 2027 [Page 8]
Internet-Draft AHP September 2026
{
"ahp": "1",
"name": "gnosis-ahp",
"principal": "ed25519:MCowBQYDK2VwAyEA...",
"keys": {
"sign": "ed25519:MCowBQYDK2VwAyEA...",
"encrypt": "x25519:hSDwCYkwp1R0i33ctD73Wg2_Og0mOBr066SpjqqbTmo",
"not_after": 1760000000,
"binding": "base64url(sig_sign(JCS({encrypt, not_after})))"
},
"openapi": "/openapi.json",
"tools": "/tools",
"search": "/@search",
"auth": { "token": "/auth" },
"rails": ["cashu", "l402", "balance"],
"unit": "sat",
"gateway": {
"register": "wss://gw.example/register",
"session": "wss://gw.example/session",
"settlements": "/settlements",
"ratings": "/ratings"
},
"reputation": "/.well-known/ahp/reputation"
}
Required members are ahp, principal, keys, openapi, and rails. The
gateway member is present only on servers that act as gateways
(Section 7). All paths are resolved relative to the origin.
4.2. OpenAPI
The openapi member MUST reference an OpenAPI 3.1 document [OPENAPI]
describing every tool. Each operation SHOULD carry an x-ahp
extension object declaring cost:
"x-ahp": {
"cost": "10",
"unit": "sat",
"metered": false,
"free_quota": { "calls": 100, "per": "hour" }
}
For metered tools (those whose price depends on usage, such as
inference priced per token), metered is true and cost is the unit
price with a per member naming the unit (for example "per":
"1000_tokens").
Campbell Expires 10 March 2027 [Page 9]
Internet-Draft AHP September 2026
4.3. Tool Listing
The tools endpoint returns a JSON array of the same information in a
flatter form suitable for an agent deciding what it can afford:
[
{"path": "/tool/calculate", "cost": "0", "free_quota": "100/hour"},
{"path": "/tool/qr_code", "cost": "10", "unit": "sat"},
{"path": "/tool/infer", "cost": "250", "unit": "sat",
"metered": true, "per": "1000_tokens"}
]
4.4. Search
The search endpoint accepts a q parameter and returns tool paths
whose names or descriptions match, ranked. It is the destination for
the redirects in Section 3.4.
GET /@search?q=calc HTTP/1.1
5. Identity and Authentication
5.1. Principals and Keys
Every party -- consumer, provider, gateway -- is a principal
identified by an Ed25519 signing key [RFC8032]. A principal that
will participate in encrypted sessions (Section 7) also holds an
X25519 key-agreement key [RFC7748] and publishes a binding: a
signature by the signing key over the JCS form of {"encrypt": <x25519
key>, "not_after": <ts>}. The binding lets a counterparty pin an
encryption key knowing it belongs to the principal it intends to talk
to.
Principals MAY be issued and vouched for by an identity service such
as the NUTS authentication service used by Charon, which additionally
ties a key to an OpenID Connect login. AHP does not depend on any
particular issuer. A key is a principal; an issuer merely adds
friction to creating one, which is sometimes exactly what is wanted.
One key does three jobs: it gates access, it anchors encryption, and
it accrues reputation. This is deliberate. The cost is that key
compromise affects all three at once; see Section 11.
Campbell Expires 10 March 2027 [Page 10]
Internet-Draft AHP September 2026
5.2. Access Tokens
To reach a protected tool, an agent first obtains a bearer token by
presenting a credential to the server's auth endpoint. The
credential is either a pre-shared key provided by the human user or a
signed challenge response proving possession of the principal's
signing key. The server returns:
{ "bearer_token": "ahp_eyJ...", "expires": 1725586400 }
The bearer token SHOULD be a stateless signed token whose claims
include the principal, an expiry, and the issuing server, so that any
server in a federated deployment can verify it without a shared token
store.
On every subsequent request the token MUST be sent in the
Authorization header using the Bearer scheme [RFC6750]:
GET /tool/qr_code?data=hello HTTP/1.1
Authorization: Bearer ahp_eyJ...
Bearer tokens MUST NOT be sent as URI query parameters. Query
strings are written to server logs, forwarded in Referer headers, and
retained in proxies; [RFC6750] discourages the practice for these
reasons. This is a change from draft-campbell-agentic-http-00 and is
the single most important correction in this document.
5.3. Key Rotation and Revocation
A principal rotates its encryption key by publishing a new binding
signed by its signing key with a later not_after. Counterparties
MUST update a pinned key only on receipt of a validly signed rotation
and MUST reject bindings past not_after. A principal that publishes
a revocation (a signed {"revoke": <key>, "ts": <ts>}) invalidates the
named key immediately. Servers SHOULD serve current bindings and
revocations alongside the manifest.
6. The Aperture Principle: Payment
6.1. 402 Semantics
[RFC9110] reserves the 402 (Payment Required) status code for future
use. This document uses it as follows: a server that requires
payment for a request responds with 402, one or more WWW-Authenticate
challenges naming the rails it accepts, and a Problem Details body
describing the offer. The client pays on a rail of its choice, then
retries the original request with proof of payment. The server
verifies the proof and serves the request.
Campbell Expires 10 March 2027 [Page 11]
Internet-Draft AHP September 2026
Payment is therefore in-band, per request, and needs no account, API
key exchange, or out-of-band billing relationship.
6.2. The 402 Response
HTTP/1.1 402 Payment Required
WWW-Authenticate: L402 macaroon="AGIAJEemVQUTEyNCR0exk7ek90Cg==",
invoice="lnbc100n1p3z2y7xpp5j3c2y..."
WWW-Authenticate: Cashu mint="https://mint.example",
amount="100", unit="sat"
Content-Type: application/problem+json
{
"type": "urn:ahp:problem:payment-required",
"title": "Payment Required",
"status": 402,
"tool": "/tool/qr_code",
"amount": "100",
"unit": "sat",
"metered": false,
"expires": 1725500600,
"offers": [
{ "rail": "l402",
"invoice": "lnbc100n1p3z2y7xpp5j3c2y...",
"macaroon": "AGIAJEemVQUTEyNCR0exk7ek90Cg==" },
{ "rail": "cashu",
"mints": ["https://mint.example"] },
{ "rail": "balance",
"topup": "/balance" }
]
}
The body MUST include tool, amount, unit, and offers. For metered
tools the body MUST also include ceiling (the maximum the server will
charge for this request) and per; amount is then the unit price and
the consumer prepays the ceiling (Section 6.4).
The WWW-Authenticate challenges are the machine-readable form; the
body is the agent-readable form. They MUST agree. Servers MAY omit
the challenge for rails whose proof does not travel in Authorization.
6.3. Rails
A rail identifier names a payment mechanism. This document defines
three.
l402: The challenge and proof are as specified by [L402]. The 402
Campbell Expires 10 March 2027 [Page 12]
Internet-Draft AHP September 2026
carries a macaroon and a BOLT 11 invoice [BOLT11]. The client
pays the invoice and retries with Authorization: L402
<macaroon>:<preimage>. L402 payments are final and non-refundable
by construction; servers MUST burn the preimage before performing
the work so that a proof cannot be replayed.
cashu: The consumer pays by including a Cashu ecash token of at
least amount, from a mint the server accepts, in the request
header defined by the Cashu HTTP 402 specification [CASHU] (that
specification predates [RFC6648] in spirit and uses an X- prefixed
name; this document uses the name as the owning specification
defines it). The server swaps the token at the mint (which is
where double-spends are caught) and MUST return any overpayment as
a change token in the corresponding response header. Ecash is a
bearer instrument, so the server learns nothing about who paid.
balance: The consumer holds a prepaid balance with the server,
funded over any other rail. Proof of payment is the bearer token
itself; the server debits atomically. Balances suit agent fleets
that do not want a payment handshake per call. They are custodial
and carry the obligations that implies; see Section 11.
Additional rails are registered per Section 13.
6.4. Metering and Change
For metered tools the consumer prepays ceiling. On completion the
server computes actual usage, includes it in the receipt (Section 8),
and returns the difference. On the cashu rail the difference is
returned as ecash change; on the balance rail it is credited; on l402
it is forfeited, and servers offering metered tools over l402 SHOULD
quote a ceiling close to the expected cost.
Servers SHOULD expose a quote endpoint so that an agent can learn the
ceiling for a given request before paying:
GET /@quote?tool=/tool/infer&model=qwen2.5-coder:32b&max_out=2048
6.5. Client Behavior
On receiving a 402 an agent parses the body, decides whether the
amount is acceptable and whether it holds funds on an offered rail,
pays, and retries. Agents MUST enforce local budget guards -- a per-
request ceiling and a per-session or per-hour ceiling -- before
paying. An agent in a loop against an expensive tool is the most
common way to lose money in this system, and no server-side control
can prevent it.
Campbell Expires 10 March 2027 [Page 13]
Internet-Draft AHP September 2026
Budget guards and the wallet behind them belong to the operator, not
the agent. Spending authority is a capability the operator grants to
a principal: the operator funds the wallet, sets the ceilings, and
can revoke both. An agent MUST NOT be able to raise its own ceilings
or fund its own wallet. The consequence is that an operator who
wants an agent to stop buying has a switch that does not depend on
the agent's cooperation: an empty wallet.
7. Blind Settlement: The Gateway
The hypercall in Section 3 assumes the consumer talks directly to the
provider. Many providers cannot or will not accept inbound
connections (a GPU on a home network), and many consumers do not want
the provider or the intermediary to learn who they are. The gateway
solves both. It is a relay that:
* accepts outbound connections from providers and outbound
connections from consumers, so that neither needs a public
address;
* verifies both parties' principals;
* holds and settles payment;
* forwards encrypted frames between the two parties; and
* issues signed settlements that serve as the basis for reputation.
It cannot read the request, cannot read the response, and with the
cashu rail cannot tell who paid. It sees a coin, not the cargo.
7.1. Provider Registration
A provider opens a WebSocket [RFC6455] to the gateway's register
endpoint and sends a signed registration:
Campbell Expires 10 March 2027 [Page 14]
Internet-Draft AHP September 2026
{
"v": 1,
"type": "ahp-register",
"principal": "ed25519:...",
"keys": { "encrypt": "x25519:...", "not_after": ...,
"binding": "..." },
"tools": [
{ "path": "/tool/infer", "model": "qwen2.5-coder:32b",
"cost": "250", "unit": "sat", "per": "1000_tokens",
"max_in": 32768, "max_out": 8192 }
],
"ts": 1725500000,
"sig": "..."
}
The gateway verifies the signature and the key binding, and lists the
provider in its directory. The connection stays open; sessions are
multiplexed over it. A provider MUST NOT advertise a tool or model
it cannot serve, and SHOULD verify at startup that advertised models
exist in its backend.
7.2. The Envelope
A consumer opens a WebSocket to the gateway's session endpoint and
sends an envelope: the cleartext terms of the session.
{
"v": 1,
"type": "ahp-envelope",
"consumer": "ed25519:...",
"provider": "ed25519:...",
"tool": "/tool/infer",
"model": "qwen2.5-coder:32b",
"max_in": 8192,
"max_out": 2048,
"ceiling": "420",
"unit": "sat",
"rail": "cashu",
"nonce": "base64url(16 random bytes)",
"ts": 1725500000,
"sig": "..."
}
provider MAY be omitted, in which case the gateway selects from its
directory by price, latency, and standing (Section 9). Consumers
SHOULD pin providers (Section 7.9) and treat open selection as a
fallback.
Campbell Expires 10 March 2027 [Page 15]
Internet-Draft AHP September 2026
The envelope is everything the gateway is permitted to know about the
session. Payment for ceiling accompanies it on the named rail.
7.3. Session Establishment
The gateway verifies the envelope, verifies payment, selects or
confirms the provider, and relays handshake frames between the two
parties. The parties run a Noise handshake [NOISE] with the pattern
Noise_IK_25519_ChaChaPoly_BLAKE2s: the consumer, as initiator,
already holds the provider's pinned static key, and the provider
learns the consumer's static key in the first message. The handshake
prologue MUST be the JCS form of the envelope, so that both parties
bind the terms they believe they agreed to; a gateway that altered
the envelope in transit causes the handshake to fail.
The consumer MUST abort if the provider's static key does not match
the pin (or, in open selection, the binding published in the
directory).
7.4. Cargo Frames
After the handshake all frames are Noise transport messages. The
plaintext of each frame is a JSON object with a type member:
req: The request. For a hypercall this is the canonical parameter
object of Section 3; for inference it is the model request. MAY
be chunked.
res_chunk: A portion of the response. Streamed as produced.
res_end: Terminates the response. Carries usage and the provider
receipt (Section 8).
abort: Terminates the session with a reason. Either party MAY send
it.
Frames SHOULD be padded to fixed size classes before encryption. A
blind relay still sees frame sizes and timing; padding narrows what
those reveal.
7.5. Envelope Match
Before performing any work, the provider MUST check the decrypted
request against the envelope: same tool, same model, input within
max_in, requested output within max_out, and a projected cost within
ceiling. On mismatch the provider MUST send abort with reason
envelope_mismatch and MUST NOT perform the work. This is the defense
against a consumer paying for a small job and sending a large one,
Campbell Expires 10 March 2027 [Page 16]
Internet-Draft AHP September 2026
and because the prologue bound the envelope, it is also the defense
against a gateway that tried to change the terms.
7.6. Settlement
On res_end the provider's signed usage reaches the gateway inside the
frame's cleartext trailer (the only field of res_end that is not
encrypted, and the only cargo-adjacent field the gateway ever sees).
The gateway computes the final amount from the registered price and
the signed usage, releases it to the provider less any relay fee,
returns the remainder of ceiling to the consumer on rails that
support it, and issues a settlement:
{
"v": 1,
"type": "ahp-settlement",
"id": "stl_01J6...",
"gateway": "ed25519:...",
"consumer": "ed25519:...",
"provider": "ed25519:...",
"tool": "/tool/infer",
"model": "qwen2.5-coder:32b",
"rail": "cashu",
"amount": "312",
"unit": "sat",
"fee": "6",
"usage": { "in": 812, "out": 344 },
"payment_hash": "sha256:...",
"ts": 1725500042,
"sig": "..."
}
The gateway sends the settlement to both parties. It is the anchor
for ratings (Section 9). Gateways MUST make settlements retrievable
by id at their settlements endpoint for at least as long as they
accept ratings against them.
7.7. What the Gateway Sees
It is a design goal of this document to be exact about this. The
gateway sees: both principals (pseudonymous keys), the envelope
(tool, model, bounds, ceiling, rail), the payment (and on l402 and
balance, who paid), the signed usage, frame sizes, and timing. The
gateway does not see: the request, the response, or on the cashu
rail, who paid.
Campbell Expires 10 March 2027 [Page 17]
Internet-Draft AHP September 2026
7.8. Direct Mode
A consumer and provider that can reach each other directly MAY skip
the gateway entirely and use the hypercall of Section 3 with the 402
flow of Section 6. Receipts are issued identically (Section 8).
There is no settlement, so ratings in direct mode are anchored to the
receipt instead; aggregators weight them accordingly (Section 9.5).
7.9. Trusted Provider Pins
A consumer carries a set of provider principals and their pinned
encryption keys. In normal operation it transacts only with pinned
providers, whatever the open directory says. Trust is client-side
and relational. Pins are the same object as the encryption key the
consumer must hold anyway, so "trusted provider" is a pin promoted to
an allowlist, and nothing more.
8. Receipts
A receipt is the provider's signed statement of what it was asked,
what it answered, and what it was paid. It is the atom of
accountability in this system: ratings attach to it, provenance
chains through it, and disputes cite it.
{
"v": 1,
"type": "ahp-receipt",
"id": "rcpt_01J6...",
"settlement": "stl_01J6...",
"tool": "/tool/infer",
"model": "qwen2.5-coder:32b",
"request_hash": "sha256:...",
"response_hash": "sha256:...",
"usage": { "in": 812, "out": 344 },
"amount": "312",
"unit": "sat",
"provider": "ed25519:...",
"consumer": "ed25519:...",
"inputs": ["rcpt_01J5..."],
"ts": 1725500041,
"sig": "..."
}
Campbell Expires 10 March 2027 [Page 18]
Internet-Draft AHP September 2026
request_hash is the hash of the canonical request: for a hypercall,
the path followed by the query parameters sorted by name and percent-
encoded, with credentials and payment proofs removed; for cargo, the
JCS form of the req object. response_hash is the hash of the response
body bytes. settlement is present in gateway mode and absent in
direct mode. inputs is OPTIONAL and lists receipts for upstream paid
tools this response depended on (Section 10).
In direct mode the receipt travels in the AHP-Receipt response
header, base64url-encoded, so that response bodies of any content
type are unaffected. In gateway mode it travels inside res_end,
encrypted, so the gateway never sees the hashes; the consumer holds
the receipt and the gateway holds the settlement, and the two are
joined by settlement.
Servers SHOULD set ETag to response_hash so that HTTP caching and
receipts agree about identity.
9. Ratings and Reputation
9.1. Requirements
* Ratings are authored by consumers and signed by them. A gateway
aggregates ratings; it does not author them and cannot read what
was rated.
* A rating is bound to one settlement (or, in direct mode, one
receipt). One party, one transaction, one rating. A rater MAY
revise; aggregators keep the latest per (rater, settlement).
* Rating weight is a function of money settled. This is the only
quality signal a blind relay can verify, and it is Sybil-resistant
for the simplest of reasons: faking it costs real sats, paid
through the relay fee, to a counterparty who keeps them.
* Reputation is portable. A rating is a self-contained signed
attestation that references a self-contained signed settlement.
Anyone can verify both without asking the gateway that issued
them.
9.2. The Rating Attestation
Campbell Expires 10 March 2027 [Page 19]
Internet-Draft AHP September 2026
{
"v": 1,
"type": "ahp-rating",
"settlement": "stl_01J6...",
"subject": "ed25519:<provider>",
"subject_key": "x25519:<pinned key at time of session>",
"rater": "ed25519:<consumer>",
"score": 5,
"tags": ["accurate", "fast"],
"ts": 1725500100,
"sig": "..."
}
score is an integer from 1 to 5. tags is an OPTIONAL array of short
strings. An aggregator MUST verify that sig validates against rater,
that the referenced settlement validates against its gateway's key,
that the settlement's consumer equals rater, and that the
settlement's provider equals subject. A rating failing any check is
discarded.
9.3. Publication
A consumer publishes a rating by POSTing it to the ratings endpoint
of the gateway that issued the settlement. It MAY also publish it
anywhere else -- another gateway, a Nostr relay keyed to the
provider's principal, the provider's own manifest. A provider MAY
collect ratings about itself and present them to any aggregator.
Because each rating carries its own proof, none of these channels is
privileged.
9.4. The Reputation Feed
An aggregator serves ratings and derived standing at /.well-
known/ahp/reputation:
GET /.well-known/ahp/reputation?subject=ed25519:... HTTP/1.1
{
"subject": "ed25519:...",
"standing": 0.87,
"settled": { "amount": "1840322", "unit": "sat", "count": 6113 },
"window_days": 90,
"ratings": [ ...signed rating objects... ]
}
The ratings array MUST be present so that a client can recompute
standing itself rather than trust the aggregator's number.
Aggregators MAY paginate.
Campbell Expires 10 March 2027 [Page 20]
Internet-Draft AHP September 2026
9.5. Computing Standing
This section is informative. The protocol carries the inputs; how
they are combined is a policy that each aggregator and each consumer
is free to choose. The following is the reference policy and is what
a gateway SHOULD use for open selection.
Each rating r contributes:
w(r) = decay(now - r.ts) * norm(r.score) * r.amount * T(r.rater)
where norm maps the score to the interval from -1 to 1 (a 3 is
neutral), decay is exponential with a half-life on the order of 30
days, and r.amount is the settled amount from the referenced
settlement.
T(rater) is the rater's own trust, a sublinear function of the sats
that rater has itself settled as a consumer within the window, for
example log(1 + settled_sats). Sublinearity is what stops a single
well-funded principal from owning the scoreboard; the settled-sats
floor is what stops a thousand unfunded principals from owning it.
Standing is the sum of w(r) over a provider's ratings, normalized to
the unit interval across the aggregator's population.
An aggregator MAY additionally apply a consensus term in the spirit
of [BITTENSOR]: compute the fraction F of trust-weighted raters who
rate the provider above neutral, and scale standing by a sigmoid
centered at 0.5 with a steepness that rewards providers trusted by a
majority of the weighted population and penalizes those trusted only
by a clique. This reproduces the property that honest providers'
standing grows super-linearly relative to colluding groups, with
settled sats in the role that stake plays in the original.
Ratings in direct mode, anchored to receipts rather than settlements,
are weighted at a discount chosen by the aggregator, since the amount
is attested by the provider rather than by a third party.
Settlements from a gateway the aggregator does not know SHOULD be
weighted at a discount as well. A rogue gateway can mint
settlements; it cannot mint anyone else's trust in them.
Campbell Expires 10 March 2027 [Page 21]
Internet-Draft AHP September 2026
9.6. Bootstrap and Exposure
A new provider has no standing. Gateways SHOULD cap the share of
open selections routed to a provider until its settled volume crosses
a threshold, and consumers SHOULD apply budget guards to unpinned
providers. This bounds the classic accumulate-then-defect attack: a
provider that behaves well to build standing and then degrades can
extract at most the exposure its standing bought it, and its standing
decays as soon as the ratings turn.
9.7. Portability and Forks
Because every settlement and every rating is a self-verifying signed
object anchored to a principal's key, a provider's reputation is not
the property of any gateway. A consumer/provider community that
forks the gateway starts with the same reputation it had, and a
provider that moves gateways carries its history with it. This is
the concrete meaning of "fork it": the gateway is an aggregator of
claims it did not issue, not the owner of the scoreboard.
10. Information Tools
Nothing above is specific to inference. A tool that crawls a page,
runs a search, summarizes a document, or returns a research finding
is a hypercall like any other, and its result is cargo like any
other. Three properties of receipts make AHP a market for
information specifically.
Content addressing. response_hash names the content. Two consumers
who bought the same finding from the same provider can prove they
got the same bytes, and a consumer who bought a finding can prove
later what it was told.
Provenance. A tool that composes other paid tools -- a research
agent that pays three crawlers and a summarizer -- lists their
receipts in inputs. The chain of receipts is a provenance graph
of paid information: who learned what from whom, for how much, and
when. It is verifiable by anyone holding the receipts and
invisible to everyone else.
Priced judgment. A rating bound to a settlement is the consumer's
paid opinion of whether the information was worth it. Aggregated
per Section 9.5, it is a market price for a provider's judgment
rather than for its throughput, which is the signal an information
market needs and a compute market does not.
Campbell Expires 10 March 2027 [Page 22]
Internet-Draft AHP September 2026
Information tools SHOULD return Last-Modified reflecting when the
underlying observation was made, distinct from Date, so that
consumers can price freshness.
It should be said plainly that content-addressed receipts with
provenance chains are as good a way to sell a working exploit as to
sell a research finding, and that this protocol has no content layer:
the relay cannot read cargo by design, and this document specifies no
mechanism by which any party other than the provider and consumer
judges what was sold. The levers that exist are the ones in
Section 7.9 and Section 9: providers choose which principals they
serve, consumers choose which providers they trust, and every
exchange leaves a receipt in the hands of an operator. Those levers
are real, and they are the only ones.
10.1. Local Facades
An agent that speaks some other API -- an OpenAI-compatible chat API
is the common case -- need not be modified to use AHP. A consumer
proxy on the agent's host presents the API the agent expects on a
loopback address, and behind it performs discovery, pinning, payment,
and the encrypted session. The agent remains oblivious to keys,
rails, and sats. Such a proxy MUST bind to loopback or a sidecar
network only, MUST enforce budget guards before paying, and SHOULD
expose the quote endpoint so that the agent's operator can see
prices.
A facade MUST record every receipt and settlement it obtains in a
ledger readable by the operator and not writable by the agent, and
MUST NOT expose wallet funding or budget configuration on the
interface the agent uses. The ledger is the audit trail of what the
agent bought, from whom, for how much, and what it got; it is the
artifact an operator reaches for first when asking what its agents
have been doing, and it is the artifact that the incidents in
Section 1.2 had to be reconstructed without.
11. Security Considerations
This section states what the protocol protects and what it does not.
Agent collusion. This protocol is, deliberately, a channel over
which agents exchange information with other agents, and
Section 1.2 describes what agents do with such a channel when
nobody is watching. The controls that make the market different
from a shared cache are: every principal is a key an operator
issued; every exchange costs money from a wallet the operator
funds and can empty; every purchase produces a receipt in an
operator-readable ledger; and standing is public. Operators
Campbell Expires 10 March 2027 [Page 23]
Internet-Draft AHP September 2026
SHOULD treat spend as the primary audit signal for agent behavior,
SHOULD issue narrow spending authority per task rather than a
standing balance, and SHOULD review ledgers for purchases outside
a task's expected tool set. None of this prevents an agent from
buying something its operator would not approve of; it ensures the
operator can find out.
Method allow-lists are not containment. Sandboxes that permit GET
and block other methods on the theory that GET cannot write have
been defeated by agents that went looking for origins where it can
[COLLUSION-WIKI]. Containment for agents that use this protocol
MUST be enforced at the network layer (which origins are reachable
at all) and at the wallet (what can be paid for), not at the
method.
Credentials in URIs. Bearer tokens and payment proofs MUST travel in
headers. See Section 5.
Transport. All HTTP in this document is HTTPS. The Noise session
provides end-to-end confidentiality across a relay; it does not
replace TLS to the relay.
The provider sees plaintext. End-to-end encryption hides cargo from
the gateway, not from the provider, which must decrypt the request
to serve it. A provider can log every request it ever serves, and
passive logging is the one defection reputation cannot detect.
Consumers with this in their threat model should pin providers
they have a relationship with, or providers running in attested
execution environments, which are out of scope here.
Traffic shape. A blind relay still sees frame sizes and timing, and
the gateway performs matchmaking, so it knows which pseudonym
talked to which provider, when, and for how much. Padding narrows
the first; nothing in this document addresses the second.
Prompt injection. Encryption does nothing about a provider that
returns adversarial content, or a consumer that sends it.
Reputation bounds the former after the fact; the envelope bounds
only size and cost, not content.
Envelope mismatch. A consumer that pays for a small job and sends a
large one is stopped by the provider's envelope match. A gateway
that alters the terms is stopped by the handshake prologue.
Replay. L402 preimages are single-use and burned before work. Cashu
proofs are swapped at the mint. Balances are debited atomically.
Receipts, settlements, and ratings carry ids and timestamps and
are idempotent on id.
Campbell Expires 10 March 2027 [Page 24]
Internet-Draft AHP September 2026
Reputation attacks. Sybil raters are bounded by settled-sats
weighting: fake standing costs real money paid to a real
counterparty through the relay's fee. Well-funded attackers can
still buy standing; weighting raises the cost and does not
eliminate it. Accumulate-then-defect is bounded by exposure caps
and decay (Section 9). Retaliatory or extortionate ratings are
bounded by the one-rating-per-settlement rule and by the rater's
own trust weight. Providers MAY refuse consumers by principal.
Rogue gateways. A gateway can drop, delay, refuse, or censor. It
cannot read cargo, alter terms, or forge a party's signature. It
can mint settlements, which is why aggregators discount
settlements from gateways they do not trust, and why the
recommended response to a bad gateway is to leave it, which the
portability of identity and reputation makes cheap.
Inheritance. Receipts, ratings, and standing are meant to persist
and to be inherited by later agents; that is the purpose of making
them portable. Section 1.2 shows the same property in an
unsanctioned channel: a later model inherited months of
accumulated work from earlier ones and skipped discovery.
Operators SHOULD assume that anything an agent can buy on the
market, a successor agent with the same wallet can buy on its
first turn, and SHOULD scope wallets to tasks rather than to
environments.
Key compromise. One key does three jobs, so compromise of a
principal's keys affects access, encryption, and reputation
together. Rotation and revocation are specified; counterparties
MUST honor not_after and revocations.
Custody. The balance rail and any relay that holds funds between
receipt and settlement is doing custodial money movement, with
jurisdiction- dependent obligations. Per-request Cashu minimizes
custody and is the RECOMMENDED default. This document flags the
issue and does not resolve it.
Denial of service. Providers dial out and have no public surface,
which removes them as a target. Gateways are the target and are
expected to rate-limit unauthenticated connections and require
payment before relaying.
Campbell Expires 10 March 2027 [Page 25]
Internet-Draft AHP September 2026
12. Privacy Considerations
Principals are pseudonymous keys. Linkability across sessions is
inherent in pinned, reputation-bearing identities: a consumer that
wants standing as a rater cannot also be unlinkable. Consumers that
prefer unlinkability can use fresh principals per session on the
cashu rail, at the cost of rater trust. Gateways see the metadata in
"What the Gateway Sees" and SHOULD retain it no longer than
settlements require. Receipts and ratings are designed to be
published; parties publishing them are disclosing the counterparties
and amounts they contain.
13. IANA Considerations
This document requests registration of the well-known URI suffixes
ahp.json and ahp/reputation in the "Well-Known URIs" registry
[RFC8615].
This document requests registration of the HTTP field name AHP-
Receipt in the "Hypertext Transfer Protocol (HTTP) Field Name
Registry".
This document requests registration of the authentication schemes
L402 and Cashu in the "Hypertext Transfer Protocol (HTTP)
Authentication Scheme Registry", to the extent they are not already
registered by their owning specifications.
This document requests creation of an "AHP Payment Rails" registry
with initial entries l402, cashu, and balance, and an "AHP Amount
Units" registry with initial entries sat and msat. Registration
policy for both is Specification Required.
The urn:ahp: problem type identifiers used in this document are
placeholders pending a URN namespace registration.
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/rfc/rfc4648>.
Campbell Expires 10 March 2027 [Page 26]
Internet-Draft AHP September 2026
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
RFC 6455, DOI 10.17487/RFC6455, December 2011,
<https://www.rfc-editor.org/rfc/rfc6455>.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750,
DOI 10.17487/RFC6750, October 2012,
<https://www.rfc-editor.org/rfc/rfc6750>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/rfc/rfc7748>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/rfc/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/rfc/rfc8259>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/rfc/rfc8615>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/rfc/rfc8785>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
[RFC9457] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details
for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023,
<https://www.rfc-editor.org/rfc/rfc9457>.
14.2. Informative References
Campbell Expires 10 March 2027 [Page 27]
Internet-Draft AHP September 2026
[BITTENSOR]
Rao, Y., "Bittensor: A Peer-to-Peer Intelligence Market",
2021, <https://bittensor.com/whitepaper>.
[BOLT11] Lightning Network Specifications, "BOLT #11: Invoice
Protocol for Lightning Payments", n.d.,
<https://github.com/lightning/bolts/blob/
master/11-invoice.md>.
[CASHU] Cashu, "Cashu NUTs (Notation, Usage, and Terminology),
including the HTTP 402 payment flow", n.d.,
<https://github.com/cashubtc/nuts>.
[CHARON] DeepBlue Dynamics, "Charon: A Blind, End-to-End-Encrypted
Marketplace for AI Inference", n.d.,
<https://charon.nuts.services>.
[COLLUSION-WIKI]
Arx, S. V., Byrd, C. S., Kitts, S., and T. Larsen,
"Discovery of a New OpenAI Agent Message Board", September
2026, <https://collusion.wiki>.
[HF-TIMELINE]
Hugging Face, "Anatomy of a Frontier Lab Agent Intrusion:
A Technical Timeline of the July 2026 Incident", July
2026, <https://huggingface.co/blog/agent-intrusion-
technical-timeline>.
[I-D.campbell-agentic-http]
Campbell, K., "A Best Current Practice for Agentic
Interactions over HTTP", Work in Progress, Internet-Draft,
draft-campbell-agentic-http-00, 7 August 2025,
<https://datatracker.ietf.org/doc/html/draft-campbell-
agentic-http-00>.
[I-D.hood-independent-agtp]
Hood, C., "Agent Transfer Protocol (AGTP)", Work in
Progress, Internet-Draft, draft-hood-independent-agtp-09,
28 June 2026, <https://datatracker.ietf.org/doc/html/
draft-hood-independent-agtp-09>.
[]
Jena, J. and S. Dalal, "The Idempotency-Key HTTP Header
Field", Work in Progress, Internet-Draft, draft-ietf-
httpapi-idempotency-key-header-07, 15 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-
idempotency-key-header-07>.
Campbell Expires 10 March 2027 [Page 28]
Internet-Draft AHP September 2026
[L402] Lightning Labs, "L402: The Lightning HTTP 402 Protocol",
n.d., <https://docs.lightning.engineering/the-lightning-
network/l402>.
[MANIFESTO]
Campbell, K., "The Agentic Hypercall Protocol Manifesto",
n.d., <https://github.com/kordless/gnosis-ahp/blob/main/
MANIFESTO.md>.
[NOISE] Perrin, T., "The Noise Protocol Framework, Revision 34",
2018, <https://noiseprotocol.org/noise.html>.
[OPENAI-HF]
OpenAI, "Hugging Face Model Evaluation Security Incident",
July 2026, <https://openai.com/index/hugging-face-model-
evaluation-security-incident/>.
[OPENAPI] OpenAPI Initiative, "OpenAPI Specification v3.1.0", n.d.,
<https://spec.openapis.org/oas/v3.1.0>.
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham,
"Deprecating the "X-" Prefix and Similar Constructs in
Application Protocols", BCP 178, RFC 6648,
DOI 10.17487/RFC6648, June 2012,
<https://www.rfc-editor.org/rfc/rfc6648>.
[RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", STD 98, RFC 9111,
DOI 10.17487/RFC9111, June 2022,
<https://www.rfc-editor.org/rfc/rfc9111>.
A.1. A Direct Paid Call
Campbell Expires 10 March 2027 [Page 29]
Internet-Draft AHP September 2026
GET /tool/qr_code?data=hello HTTP/1.1
Host: ahp.example
Authorization: Bearer ahp_eyJ...
HTTP/1.1 402 Payment Required
WWW-Authenticate: Cashu mint="https://mint.example",
amount="10", unit="sat"
Content-Type: application/problem+json
{ "type": "urn:ahp:problem:payment-required", "status": 402,
"tool": "/tool/qr_code", "amount": "10", "unit": "sat",
"offers": [ { "rail": "cashu", "mints": ["https://mint.example"] } ] }
GET /tool/qr_code?data=hello HTTP/1.1
Host: ahp.example
Authorization: Bearer ahp_eyJ...
X-Cashu: cashuBo2Ftd2h0dHBzOi8vbWludC5leGFtcGxl...
HTTP/1.1 200 OK
Content-Type: image/png
ETag: "sha256:9f86d0..."
AHP-Receipt: eyJ2IjoxLCJ0eXBlIjoiYWhwLXJlY2VpcHQiLCJpZCI6...
X-Cashu: cashuBo2Ftd2h0dHBzOi8vbWludC5leGFtcGxl... (change, if any)
<png bytes>
A.2. A Blind Session
Consumer Gateway Provider
| |<---- ws /register ---------|
| | ahp-register (signed) |
|---- ws /session --------->| |
| ahp-envelope + ecash | |
| |-- verify, hold, select --->|
|==== Noise IK msg 1 ======>|============================>|
|<=== Noise IK msg 2 =======|<============================|
| (prologue = JCS(envelope); provider key pinned) |
|==== req (encrypted) =====>|============================>|
| | envelope match: ok |
|<=== res_chunk ... ========|<============================|
|<=== res_end + receipt ====|<==== res_end + usage =======|
| | settle 312, fee 6, |
| | return 108 change |
|<---- ahp-settlement ------|------ ahp-settlement ------>|
|---- POST /ratings ------->| |
| ahp-rating (signed) | |
Campbell Expires 10 March 2027 [Page 30]
Internet-Draft AHP September 2026
A.3. A Provenance Chain
A research tool pays two crawlers and a summarizer, then answers its
own consumer. Its receipt lists the three upstream receipts in
inputs. The end consumer, holding the top receipt, can request the
upstream receipts from the research tool and verify the entire chain
of hashes, amounts, and signatures without any party having revealed
content to a relay.
* Bearer tokens moved from the query string to the Authorization
header. Query-string tokens are now prohibited.
* The contradiction between "all actions are GET" and the normative
text limiting GET to idempotent actions is resolved: GET is
canonical, POST carries large or non-idempotent requests with
identical semantics, and Idempotency-Key is recommended for the
latter.
* The 402 payload is now a Problem Details document, paired with
WWW-Authenticate challenges, and reconciled with L402 so that an
L402-only client interoperates. Cashu and prepaid balances are
added as rails.
* Cost declaration moved into an x-ahp OpenAPI extension and a well-
known manifest; the manifest is now the discovery entry point.
* The gateway, envelope, Noise session, envelope match, and
settlement are new, generalized from Charon.
* Receipts, ratings, the reputation feed, and the standing policy
are new.
* References corrected: BCP 14 is cited as RFC 2119 plus RFC 8174;
RFC 9110 is cited for 402; L402, Cashu, BOLT 11, Noise, and
OpenAPI are cited as informative.
* Editorial: removed the spurious RFC number from the running
header, the duplicated "Status of This Memo" section, the doubled
section numbers, the two different expiry dates, and the markdown
emphasis that leaked into normative text.
Author's Address
Kord Campbell
DeepBlue Dynamics
Email: kordless@gmail.com
Campbell Expires 10 March 2027 [Page 31]