Updated 2026-11-03: no session holds funds, and the draft does not freeze before a live end-to-end run of the complete profile. Updated 2026-10-19: the operator’s name.
Cloudflare announced a per-call price on resources behind its Monetization Gateway on 1 July 2026. That move put a question in front of every API seller on the open web: how much do you need to know about the buyer? According to that announcement, the gateway’s tiers answer the question as a ladder: open to anyone, better terms for agents the gateway has verified, and the full identity-and-payment treatment where the risk warrants it.
We argued in July that the middle rung is the interesting one, and that no product we know of fills it. Between an anonymous buyer and a fully identified one, a zero-knowledge proof can show that an agent is human-backed, in scope and unrevoked. It does this without revealing who the human is. Since July, we have moved from describing that level to specifying it. MintID now has a standards-track draft profile with machine-readable schemas and a validation suite. The profile carries this identity check over x402, the pay-per-request protocol built on HTTP’s 402 status code, and Web Bot Auth, which signs bots’ HTTP requests.
Levels of buyer verification in agent commerce
| Tier | What the seller learns | Mechanism |
|---|---|---|
| anonymous | a payment cleared | This is the x402 default. A wallet pays the quoted price and the request proceeds. The seller learns nothing about who is on the other end, and nothing carries over to the next request. |
| identified software | this call came from operator X’s fleet | Web Bot Auth uses HTTP message signatures checked against a published key directory. It authenticates the agent software, and it works because the signing population is small and named. It says nothing about whether an accountable party stands behind the agent. |
| identified software, unrevealed accountable human | a KYC-verified principal, who is the verified person behind the agent, is answerable for this agent at a stated assurance grade and within a delegated scope covering this action | The profile fills this slot. A zero-knowledge presentation adds the accountability layer to the signature. It does not add a name, a registry entry, or a handle that joins this seller’s log to any other. |
| full KYC | who the counterparty is | This tier sits outside MintID’s lane by design. Where the law demands identification, identification is the answer. It should be the exception at the top of the ladder, not the default at the bottom. |
We expect most agent commerce to sit on the third rung. This level scales beyond a few named crawler operators without building a public index of who runs which agent.
Adding an identity check to an unmodified x402 payment cycle
Our design constraint was to leave x402 unchanged. The profile attaches an identity step to the existing payment flow and keeps the payment protocol intact.
The seller’s payment-required response carries an identity requirement. It states which claims the buyer must prove, which issuers are acceptable, where to obtain a challenge, and the session mode. The claims are that the agent is human-backed and that its assurance is at least the grade the seller requires. They also require that a delegated scope covers this action, this seller and this value, and that the credential is active. The buyer’s agent then obtains a challenge and produces its proof. It retries the original request with both the unchanged x402 payment and a presentation alongside it.
The payment facilitator already verifies the payment, and it now gains an identity step. It acts as a registered verifier for its own origin and validates the presentation against its own self-deployed verifying core. The facilitator returns a decision, and the seller consumes that verdict over the existing trust relationship for payment verification. This flow needs no new verifier class and changes none of the binding rules. The claim policy names the seller, while the audience stays fixed to the verifying party’s registered origin and never names the seller.
A seller that wants to verify identity directly registers as a verifier itself and runs the identity leg first-party. The profile is identical when the seller is the verifying party, and only the deployment moves.
How the profile handles micropayment sessions
A fresh presentation is valid for ten seconds, so requiring one on every request is unusable at micropayment cadence. The profile answers this objection with session design. It never uses a longer-lived proof.
One accepted presentation bridges to a scoped, short-lived token that carries the proven predicates as its authorisation basis. The rest of the session presents this token, whose lifetime and scope follow the verifying party’s local policy. That mode needs nothing beyond the identity rail.
The draft also keeps one name, reserved sessions, as a reserved value with no use. The protocol has no financial layer, so no session holds, locks or reserves funds.
Key binding and session association are kept apart
Web Bot Auth gives an agent’s HTTP requests a verifiable key identity and authenticates the software. A MintID presentation adds the claim that a signature cannot carry: an accountable human stands behind this. The human remains unrevealed.
The profile carries that claim at two distinct levels of strength and keeps them apart. The stronger level is key binding, which binds the bot’s signing key into the agent credential. The presentation then proves that the key signing the request belongs to the credentialled agent. This is the same attested key material that the credential’s custody attributes already describe.
The weaker level is a session-level association. After verifying a request signature, a relying party runs the ordinary challenge, presentation and decision flow within the same session. It then associates the accepted decision with the signing key for that session only, under its own session policy. This matches the trust construction of any authenticated session. The draft states that the two levels are not interchangeable. An implementation that stops at session association must not claim key-binding semantics.
How the schemas enforce protocol invariants
The invariants are structural. The profile ships machine-readable schemas for the policy extension and the payment-identity envelope, along with worked examples and a validation suite.
The schemas are closed, so any unknown field causes a validation rejection. No field exists to set a presentation lifetime, skip an acceptance condition, or override staleness or audience checks. The ten-second lifetime is a protocol constant that the extension cannot lengthen, shorten or mention. All nine acceptance conditions run in full on every presentation. Freshness tolerance remains local deployment policy and is never sent over the wire. A presentation is short-lived and non-transferable by construction, so there is no persistent “verified” badge.
The validation suite proves that these mutations fail: any configuration knob smuggled into the extension fails schema validation.
Current status of the draft and the network
Public standards for agent payments are taking shape right now, and the people with text on the table are deciding the identity layer at the same time. Our profile is written, with schemas and tests, and labelled for what it is: a Draft under the project’s standards process. Some decisions remain open, and the draft does not freeze before the live end-to-end run of the complete profile.
The draft shows that the middle rung of the ladder is buildable. It needs no new verifier class, no changes to the payment protocol, and no registry of who runs which agent. The rest of MintID is unchanged underneath. It uses agent KYC, presentations that never enter the chain, and a proof core in production on the single-node production chain. That chain has been in production since 20 September 2026, operated by Conectia, and is designed to scale to a public proof-of-stake network.