Pick an attack on a wire transfer and watch execution refuse. The digests are computed in your own browser. Then take the record it hands you and check the second signature against a published key, again in your own browser.
What the demo does not do. It proves the instruction did not change in custody. It does not prove the answer was right or that any model was honest. The second signer is a separate key, a separate clock and a separate log operated by Hive, so it is not an outside party and the service reports that itself. It signs Ed25519, which is not post quantum. The operator side signs ML-DSA-65 under NIST FIPS 204. The second signer's log does not survive a redeploy today, and it says so too. Patent pending.
Private outbound brief · noindex · Hive is not a Stripe customer or partner
HiveHive Proof Architecture
proposed technical fit · one integration surface · nothing in Stripe's path changes
Stripe's agentic terms already require auditable records of authority at the time of each transaction.
The obligation is written down. The portable instrument that discharges it is still an open surface, and that is a question of timing.
Stripe has built the control layer for agentic commerce: scoped tokens, live limit enforcement, Radar decisioning, agent identity, and approval rules with a human in the loop. Hive is an additive, removable proof sidecar that binds an independently signed artifact beside those events, so a third party can check later, offline, that the authority existed, what its exact scope was, and that the action fell inside it. Stripe's route, authorization, limits, decisioning and merchant of record all stay exactly as they are.
4.2 Compliance Recordsthe agent platform retains auditable records of the customer's Authority at the time of each Agentic Transaction · Stripe Agentic Commerce terms
8.3 Unauthorized Transactionsresponsibility for transactions caused by bugs, hallucinations or misinterpretations, or by an agent acting outside its permitted authority · same document
2.8 Risk Standards for AgentsStripe may develop a framework for identifying trusted agents · same document
Both the Agentic Commerce Agent Services and Seller Services terms are marked Preview and were last modified April 20, 2026 (stripe.com/legal/ssa-services-terms).
new since this brief was written · runnable below
Five new receipts, on the authority behind an agentic charge
Clause 4.2 asks for auditable records of the customer's Authority at the time of each transaction. These five are about that word, authority. Where it came from, how far it reached, whether it had narrowed, whether it was still live, and whether it held across more than one acceptor. Every one of them runs live from your browser.
“the Agentic Transaction was not authorized by the Agentic Customer, exceeded User's Authority, or was caused by bugs, hallucinations or misinterpretations” and, separately, a transaction generated or initiated “due to error, malfunction, unauthorized action, or the agent acting without requisite authority or outside the scope of its permitted authority.”
“Stripe may develop a framework for identifying trusted agents. To qualify as a trusted agent, User must comply with the criteria for trusted agents that Stripe provides to User or publishes.”
Read through, in one line: the duty to prove the customer's authority at transaction time is already in writing, and the portable artifact that discharges that duty in front of a counterparty, an auditor or an insurer is the surface still open. Definitions in the same document set Authority as “the express scope of authority an Agentic Customer grants to any AI agent… including any applicable spending limits, merchant restrictions, or time-bound parameters” (Stripe terms). That definition is exactly the field set a signed authority record binds.
enforcement and evidence are two different products
Stripe enforces at transaction time. Hive makes the same facts checkable afterwards.
The right column is additive. Every item in the left column stays authoritative, stays in Stripe's hands, and keeps working exactly as it does today.
Stripe already enforces
The control layer, shipped and running
A Shared Payment Token is “a scoped grant to use the customer's payment method”, carrying usage_limits with currency, max_amount and expires_at, scoped to one seller's Stripe profile (Stripe docs).
Limits are enforced live and out of scope charges are declined: “in the off case that it's attempting to charge more than we agreed upon, then Stripe actually enforces those limits and declines the charge” (Steve Kaliski, Principal Software Engineer, Stripe, Sessions 2026).
“Radar now protects all of your Stripe payment volume” and exposes risk scores “via API for your off-Stripe volume” (Sessions 2026 opening remarks).
Agent-tagged API keys let a business treat an agent as “a new type of actor within your business with its own identity” (Michelle Bu, Head of Developer Experience and Product Platform, Stripe, Developer Keynote).
Approval rules keep a person in the decision: “we've given the agent power to act and we've kept a human in the loop for the most important decisions” (Michelle Bu, Developer Keynote), with safe-by-default guardrails that apply “whether the action comes from an agent or from a human, and whether it comes from the API, MCP, or the Dashboard” (Nilofer Rajpurkar, Product Lead, Agents and Developer Experience, Stripe, same).
What a third party can check later
The evidence layer, bound beside it
A signed authority record. The grant itself as an artifact: issuer, subject, and the moment it was made, signed by a party with no economic stake in the outcome.
Its exact scope. The declared amount ceiling, expiry and seller scope carried in the signed body, so scope is read from the artifact rather than reconstructed from a log.
The binding between grant and action. The action digest tied to the authority it ran under, so “inside scope” is a computation rather than an assertion.
Offline verification, no live dependency. A counterparty checks the signature against published key material with no call to Hive and no call to the agent platform.
A portable artifact that survives the dispute. One fixed export that counsel, audit, an insurer or a card network can check months later without either party being online.
“But even if the app is ready to accept agentic payments, how do we give an agent a payment credential in the first place and how can we trust them to use it responsibly?”
Hive's position is one sentence longer than that last line: granted, scoped, enforced in code, and then provable to someone who was not there. Two neutral voices from the same Stripe stage put the same point in their own terms: Guillaume Poncin, CTO, Alchemy, on agents, “you actually need a verification moment. You need to close the loop”, and Manik Surtani, CTO of the AAIF, Linux Foundation, on the trust layer, “it's still nascent. It's still too young” (both Sessions 2026).
Stripe keeps
The customer, the product, the price
Stripe would own the customer facing proof product, its packaging, its price and the relationship. Authorization, limit enforcement, Radar decisioning, settlement and merchant of record stay authoritative and unchanged. Nothing moves out of Stripe's control. This is a proposed structure, not a current commercial arrangement.
Hive provides
The independent signature
The signer and verifier underneath, so the artifact a counterparty checks has cryptographic separation from the operating record it references. Independence is the product. A receipt Stripe signs about itself proves less in a dispute than one signed by a party with no economic stake in the outcome.
the load bearing claim · test it here
Beside the path. Never in it.
The agent action path runs across the top and stays Stripe's. Hive receipts bind underneath as each step passes. Switch Hive off and watch what happens to the path.
0agent actions completed on Stripe's path
0receipts bound beside them
0receipts visibly absent
Hive online
Every step carries a signed receipt bound beside it. Emission is out of band, so the payment never waits on the evidence.
Hive is a sidecar. Hive fails open. If Hive is unavailable the payment proceeds and nothing is blocked. Take Hive out and Stripe's behavior is identical to today: there is no shim to unwind, no policy to restore, and no settlement dependency to migrate, because Hive never held any of them. Previously issued receipts remain independently verifiable offline from the artifact itself, against published key material, with no call to Hive.
three proposed surfaces · each one optional · the proof of concept asks for exactly one
Three places evidence could sit. None requires the others.
Timing favours a native fit. The Agentic Commerce Protocol is at API version 2026-01-30, which added capability negotiation, a payment-handlers framework and an extensions framework (ACP changelog), and the specification is still marked draft (ACP repository). An evidence extension therefore arrives as a native extension rather than a retrofit. And because Shared Payment Tokens already extend to Mastercard Agent Pay, Visa Intelligent Commerce, Affirm and Klarna (Stripe blog), an evidence layer beside the token sits at network scale rather than at one processor.
surface A in sequence · one route, one signed trail
Five steps. One artifact at the end.
1
The human grant. A person authorizes an agent to spend up to a ceiling, for a window, against a scope. Hive records the declared authority reference, the scope as declared, and the proof level fixed against it, then signs. Instruments: Stipryn™ and Authority Delegation, both PROPOSED. Hive does not evaluate, replace or relax the grant, and a Hive record is never a precondition for it to work.
2
The agent action. The agent calls a priced service. Which agent identity acted, which service served the call, and the request digest can be bound into the receipt. Instruments: SiGR line and AFiR, both PROPOSED. Request bodies do not cross the boundary; digests do.
3
The machine payment. The payment settles on Stripe's path. The Machine Payments Protocol already settles agent payments over x402 on Base in USDC, with a 0.01 USDC stablecoin minimum (Stripe docs). Hive holds no funds and touches no credential.
4
The receipt. After settlement, Hive Receipt (LIVE) emits a signed x402 and Base USDC settlement receipt recording the reference, the amount as declared and as observed, and the parties as declared, with the evidence tier stated plainly. Signing runs through Hive Typed Signer (LIVE). Emission is out of band. If it fails, the payment has already happened and is unaffected.
5
Offline verification. The grouped receipts become one signed export a counterparty checks against published key material, offline, with no call to Hive and no call to the agent platform. What was granted, what its scope was, what acted, and what was paid, in one artifact, with the weakest verified boundary stated rather than implied. Instruments: R3Pv™ and Protected Flow, both PROPOSED. On chain co-signature checking maps to an ERC-1271 secp256k1 co-signature verifier contract for Base, chain id 8453, BUILT AND TESTED, NOT DEPLOYED.
instrument and maturity map · every row carries a state
What each instrument fixes, and its exact maturity today.
Three states only, and nothing on this page is upgraded past them. LIVE means a Hive production endpoint answers today. BUILT AND TESTED, NOT DEPLOYED means the artifact exists with passing tests and no deployment. PROPOSED means designed for this brief and offered as proof of concept work.
correlated public matters · thirteen · none of them involve hive
The failure mode is not hypothetical. It has already been litigated.
Every matter below is a public court or regulator document, linked to the primary source. None of them involve Hive, Stripe, or any Hive customer. They are here for one reason. In each one the contested question was not whether the system worked. It was whether anyone outside the operator could check the record afterwards. The right hand column names the canon entry built for that exact failure. Maturity for each entry is stated in the instrument map above and in the canon explorer, and nothing on this page upgrades it.
Who the buyer actually was
United States v. Cartisim Corporation and Simon EbraniE.D.N.Y. · 2:21-cv-00212 · filed 14 Jan 2021 · complaint, allegations onlyWhether ticket purchases were made by automated bots using fictitious accounts and cards, or by the humans on the accounts.DOJ and FTC complaint, BOTS Act
FTC and State of Florida v. Global E-Trading, LLC (Chargebacks911)M.D. Fla. · 8:23-cv-00796 · stipulated final judgment 29 Nov 2023Whether screenshots submitted as chargeback compelling evidence were edited, and whether they matched the pages where the purchases actually occurred.Stipulated final judgment, Doc. 47
In the Matter of Block, Inc. (Cash App)CFPB · 2025-CFPB-0001 · consent order 16 Jan 2025Whether the provider retained the Regulation E investigation evidence, and reviewed its own account records, before denying unauthorized transfer claims.CFPB consent order
FTC v. Paddle.com Market Limited and Paddle.com, Inc.D.D.C. · 1:25-cv-01886 · stipulated order 20 Jun 2025Whether the merchant of record's own files showed it screened and monitored the schemes it processed for.Signed final order
United States v. Nexway SASU et al.D.D.C. · 1:23-cv-00900 · stipulated order 13 Apr 2023Whether the processor's client screening and complaint records showed what it knew about the charges it was putting through.Stipulated order for permanent injunction
What the model was actually given, and what it actually did
In the Matter of Delphia (USA) Inc.SEC · Admin. Proc. 3-21894 · order 18 Mar 2024Whether the firm could show that client data was in fact input into the machine learning models it advertised.SEC order, IA Release 6573
In the Matter of Presto Automation Inc.SEC · Admin. Proc. 3-22413 · order 14 Jan 2025Whether the company's own AI, rather than a third party's, produced the automated order handling it described.SEC administrative proceeding record
In the Matter of Hello Digit, LLCCFPB · 2022-CFPB-0007 · consent order 10 Aug 2022Whether the automated transfer decisions the algorithm actually made matched what the operator said the algorithm would do.CFPB consent order
FTC and State of Connecticut v. LeadClick Media, LLC2d Cir. · 15-1009-cv · decided 23 Sep 2016 · reversed as to the parentWhich party authored the pages that generated the leads and conversions being paid for.Second Circuit opinion
Whether the record was still there when someone asked
In the Matter of J.P. Morgan Securities LLCSEC · Admin. Proc. 3-20681 · order 17 Dec 2021Whether business communications were preserved and could be furnished to the Commission on request.SEC order, Exchange Act Release 93807
FTC v. James D. Noland, Jr., et al.D. Ariz. · 2:20-cv-00047 · sanctions order 30 Aug 2021 · affirmed, 9th Cir. 23-3757Whether auto deleting messages were destroyed after the duty to preserve had already attached.Order granting spoliation sanctions, Doc. 401
Whether the operator's own account of the incident held up
Robinhood Financial LLCFINRA · AWC 2020066971201 · accepted 30 Jun 2021Whether the firm's own systems records and customer communications accurately reflected the March 2020 outages.FINRA letter of acceptance, waiver and consent
TSB Bank plcFCA (UK) · Firm Reference No. 191240 · final notice 20 Dec 2022Whether the bank's own governance and incident records let it identify, manage and report the true customer impact of a migration failure.FCA final notice
Four honest notes. Cartisim is a complaint, so those are allegations that were never tested at trial. LeadClick was reversed as to the parent company, so it is cited only for the question of who authored the pages. Paddle and Nexway are consent documents in which the conduct was neither admitted nor denied. Robinhood and TSB are regulator findings about operational and systems records, not findings that a published incident report was wrong. Nothing above is a Hive claim, and none of it is evidence that Hive would have changed any of these outcomes. It is offered only as the public record of how often the contested fact turns out to be the record itself.
architecture · a design proposal, not a live integration
Stripe remains authoritative for the money event. Hive makes selected surrounding events portable and checkable.
Pick a boundary. Stripe stays authoritative for the money event, authorization, limit enforcement, Radar decisioning and merchant of record throughout.
Stripe remains authoritative for
Hive can bind beside it
Portable result
Sidecar placementHive sits beside the action, not between Stripe and its customer. It is invoked out of band, and its output is an artifact rather than a decision imposed on the flow.
Hash firstThe binding is over a one way SHA-256 fingerprint and content addressed roots, not the underlying text. Change one byte and the address changes, which breaks the signature.
No prompt or body storageThe request is receipted by fingerprint. Proof, not surveillance, is the standing rule across Hive surfaces.
No custody, no routingHive holds no keys to anyone's funds, never takes possession of value, and never selects a rail, a network or a counterparty. Authorization, routing and settlement stay entirely with Stripe and the networks.
No policy substitutionStripe's token scope and limit enforcement remain the enforcement point. Hive records the declared authority and the proof level demanded against it. It never becomes the gate.
Fail open and removableIf a Hive component is slow, unavailable or deleted, the action still runs. A missing receipt stays visibly missing rather than being backfilled or faked.
scope boundaries · precise limits on Hive, not criticisms of anything Stripe built
What Hive is, and the lines it does not cross.
Evidence, not controlHive does not authorize, submit, route or custody the payment. It produces an artifact after the fact and out of band. Every decision about whether money moves stays with Stripe, the networks and the human who set the scope.
Not a PSP, not a payment methodHive is not a payment service provider, not a payment method, not an agent platform, and not a merchant of record. It issues no credential and holds no position in any settlement chain.
Additive to Radar and to limitsHive is not a replacement for Radar and not a replacement for Stripe's limit enforcement. Those remain the decisioning and enforcement layer. Hive records what was decided, as declared, and signs it.
No card data, no credentialsHive holds no card data and no customer credential. Private keys, seeds, session material, raw call data and raw request bodies are never sent, held or stored. Digests, public references and declared values are the only inputs.
Beside the path, not in itReceipt emission is out of band from the payment path, so a slow or unavailable Hive component does not gate an authorization, a charge or a settlement. Hive is a sidecar and Hive fails open.
Stripe's marks stay Stripe'sThis page uses the word Stripe as a plain reference only. There is no Stripe logo, no lockup, and no imitation of Stripe trade dress. Product and company names belong to their respective owners.
Scope note on durability. Hive states that a previously issued receipt remains independently verifiable offline using published verifier behavior and published key material. Hive does not claim indefinite verifiability, and does not claim that any future verifier release will preserve a given format without change. A Hive receipt is evidence, and it is not a compliance determination, a regulatory approval, a fiduciary opinion, or a correctness or safety claim about a model or a payment.
prove it without us · no account, no key, no call
Four minutes, and you never talk to Hive.
If a buyer cannot prove the claim without a meeting, the demo is what is broken, not the buyer's calendar. Everything below runs against production right now. Paste it into a terminal.
# 1. pull a production signed authority record
curl -s https://proof.thehiveryiq.com/demo/authority-receipt > r.json
# 2. check it with the open verifier
curl -s -X POST https://proof.thehiveryiq.com/verify/delegation-link \
-H 'content-type: application/json' --data-binary @r.json
That is a signed authority record with an SPT shaped scope and a 250 dollar cap, checked by a verifier that needs no key and no account. You get valid: true and nine individually reported gates.
# 3. now raise the 250 cap to 25000 and send it again
sed 's/"max_amount":250/"max_amount":25000/' r.json | curl -s -X POST https://proof.thehiveryiq.com/verify/delegation-link \
-H 'content-type: application/json' --data-binary @-
# valid: false failed_gate: PAYLOAD_DIGEST
Nobody raises that limit after the fact, including us. If you would rather cut Hive out of the check entirely, the Ed25519 public key is published at /keys and you can validate the signature inside your own process with any standard library.
stated, not buried · because your engineers would find it anyway
What is not ready.
This list is published for the same reason the receipts are open. An evidence vendor that overstates its own maturity has disqualified itself from the category it is selling into.
ERC-1271 co-signature is measured, not deployedImplemented and tested, 23 tests passing with 13 of 13 EVM parity vectors. Compiled under solc 0.8.36 and executed against a real EVM, isValidSignature returns the magic value 0x1626ba7e at 6,740 gas on the valid path and rejects at 4,259, bound to a domain separator for Base chain 8453. There is no deployed address. What is missing is a deployment, not a design.
HiveSeal QPuF is simulatedA hardware root of trust design running on simulated entropy sources today. It is not a hardware claim and is not presented as one anywhere.
AFiR-Stream runs post quantum disabledEd25519 is in use. The post quantum path stays flagged off until upstream evidence supports turning it on.
Proof Credit and the Customer Console have no endpointBoth are composite views over receipts produced by other primitives. Neither mints anything of its own, and neither is an underwriting, rating or insurance outcome.
SPIRE attestation is an MCP serverIt exists, but it is not one of the typed canon contracts and is not covered by the canon acceptance run.
MoR Segments is a concept extensionNo code, no schema, no endpoint. It is named here only so it is not mistaken for something shipped.
And what is running, re-checked against production on August 7, 2026 UTC. 55 typed receipt contracts live on the Hive domain, each with a mint route and an open verify route. The last full authenticated acceptance run passed 238 of 238 checks on August 4, 2026 UTC, across the 45 public contracts that existed that day. The 46th, sequence.attestation, and the nine newest contracts were deployed after that run and are not covered by it. Those nine were separately accepted, smoke tested and benchmarked live on August 7, 2026 UTC. Signing is Ed25519 against published keys served at thehiveryiq.com/v1/keys, so receipts verify offline with no shared secret and no call back to Hive. Measured rather than marketed latency: mint p50 roughly 2.5 to 7.2 ms by contract, p95 up to about 20.4 ms, verify p50 roughly 2.0 ms. Hive Receipt is a working settlement receipt service on x402 version 2, Base mainnet, chain id 8453, denominated in USDC. Hive is patent pending across this work. There is no Stripe integration today and nothing on this page represents one.
reachable owners · titles and links from Stripe's own published material
Steve KaliskiPrincipal Software Engineer, Stripe. Shared Payment Token and Machine Payments Protocol engineering, and the most technically specific public voice on token mechanics.Sessions 2026, machine payments
Michelle BuHead of Developer Experience and Product Platform, Stripe. API design, agent-tagged keys, MCP, agent guardrails.Sessions 2026 Developer Keynote
Nilofer RajpurkarProduct Lead, Agents and Developer Experience, Stripe. Approval rules and observability over agent actions.Sessions 2026 Developer Keynote
Neetika BansalHead of Money Management and Crypto, Stripe. Stablecoins, Treasury and the crypto stack, which is where surface A settles.Sessions 2026 opening remarks
Emily Glassberg SandsHead of Data and AI, Stripe. Radar, AI native fraud and the payments foundation model.Sessions 2026 opening remarks
Matt HuangFounder and CEO of Tempo, co-founder and managing partner at Paradigm, Stripe board member. Tempo, the Machine Payments Protocol and the validator set.tempo.xyz/faq
Henri SternCEO and cofounder of Privy, a Stripe company. Wallet infrastructure, embedded custodial and non custodial.Ramp and Stripe · Deel and Stripe
There is also a published program path: the Agentic Commerce Protocol program lists acp@stripe.com as its contact address (agenticcommerce.dev). One surface, one owner, one message is enough to start.
the ask
PICK ONE SURFACE. HIVE RUNS THE POC.
A suitable scope is one x402 on Base route for 30 days, with a signed receipt bound beside each machine payment. Stripe's route, price, limits, decisioning and settlement logic stay exactly as they are.
The integration scope is limited to the proof fields and the signing path Stripe chooses to expose, and Hive removes itself on request at any point.
one surface · A, B, or Cadditive · nothing in the authorization or settlement path changesfail open · removable on request
Non customer notice. Hive is not a Stripe customer or partner. This is a private outbound technical brief prepared by Hive Civilization Inc. and it describes a proposed technical fit only. No live Stripe integration is represented anywhere on this page. Hive does not authorize, submit, route or custody payments, holds no card data and no customer credential, and is not a payment service provider, a payment method, an agent platform, a merchant of record, or a replacement for Radar or for Stripe's limit enforcement. Nothing on this page is a partnership, endorsement, deployment, agreement, certification, or regulatory or compliance outcome.
Hive is not a Stripe customer or partner, and no live Stripe integration is represented on this page. Private outbound brief · noindex, nofollow, noarchive · not affiliated with, endorsed by, or produced in cooperation with Stripe, Inc., and product and company names referred to here belong to their respective owners · every Stripe fact on this page is quoted or drawn from the linked Stripe owned pages above, read on August 5, 2026 · maturity labels use exactly three states, LIVE, BUILT AND TESTED, NOT DEPLOYED, and PROPOSED, and nothing on this page is presented above its state · LIVE covers Hive Receipt, the x402 and Base USDC settlement receipt service, and Hive Typed Signer, whose ML-DSA-65 typed fragment signing currently issues under a DEMO issuer key · BUILT AND TESTED, NOT DEPLOYED covers the ERC-1271 secp256k1 co-signature verifier contract for Base, chain id 8453, with 23 passing tests, 13 of 13 EVM parity checks, isValidSignature measured at 6,740 gas and the magic value 0x1626ba7e · every other instrument named here is PROPOSED · Hive Ledger and Proof Credit are composite views over receipts produced by other instruments and are not standalone endpoints · Stipryn™, R3Pv™ and Foretoken™ are Hive marks and Hive primitives are patent pending · prepared by Steve Rotzin, Founder, Hive Civilization Inc. · Wyoming, USA
new in the canon · runnable on this page
Make authority evidence easier to carry forward
These receipts add a precise record of screening and a repeatable check that a single agentic transaction fit one delegated mandate beside the authority, limits, divergence, parity, and sanctions themes already described here. They run in production today. The examples below are verified live against them. The Authority Line adds five more that follow one delegated mandate end to end: how it was admitted, whether the granter held it, whether every hop narrowed, whether it was still alive when the charge ran, and whether it was spent twice across acceptors who do not share a ledger.
screening.attestation
Preserve the screening context for an agentic payment
This receipt records the exact screening context associated with an agentic payment or counterparty. It binds the named engine, ruleset, reference lists, list versions, screening time, validity period, and declared verdict. The subject identifier and list records remain protected as commitments, while risk and compliance teams can inspect the evidence path later. A matched outcome remains tied to the screening context that produced it. That gives counsel and risk teams a portable record beside the payment authority evidence.
What it does not do. It does not show that any list is complete, accurate, current, or free of omissions, decide that a counterparty is actually restricted, catch every false negative, catch an engine that clears a match it found, or assess the adequacy of the program, its thresholds, lists, or validity period. It does not identify the counterparty, expose a list record or match score, prove custody of the commitment key or window secret, or admit, block, freeze, reverse, settle, report, or provide a legal, regulatory, or compliance conclusion about any transaction.
POST /verify/screening-attestation · case pass, a clean record
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
POST /verify/screening-attestation · case matched, a name matched the list
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
POST /verify/screening-attestation · case fail, a forged record
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
mandate.conformance
Check one agentic transaction against its stated mandate
This receipt compares a named agentic transaction with one delegated authority receipt signed before the transaction was authorized. It checks the declared amount, currency, timing, and scope against the constraints in that mandate. The service recomputes the result instead of accepting a caller supplied answer. That gives a reviewer a clear answer about whether this one transaction fits the supplied delegated limits. It can sit beside the existing authority and payment records without becoming part of the payment decision.
What it does not do. It does not prove that a cardholder granted the delegation, that the agent identity is genuine, that a network authorized or settled the transaction, that goods or services were delivered, or that a person read the displayed terms. It is not payment authorization, holds no cardholder credential, has no recognition as authentication data, compelling evidence, or liability shift from a network, issuer, or regulator, cannot resolve or affect a dispute or consumer rights, cannot assess aggregate spend or velocity, and cannot show that the supplied mandate remained unrevoked when the transaction was authorized.
POST /verify/mandate-conformance · case pass, a clean record
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
POST /verify/mandate-conformance · case fail, a forged record
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
admission.binding
Show that an agent is bound to the terms it joined under
Before an agent does anything, somebody has to be able to say which terms it came in under. This receipt fixes that at admission. It names the network, the agent, the terms document by fingerprint, and the moment the agent accepted them. Later, when a counterparty asks what this agent agreed to, the answer is a signed record from the day it joined, not a lookup in a table that has been edited since.
What it does not do. It does not say the terms are fair, enforceable, or the right terms. It does not say the agent behaved. It says which document this agent was bound to and when it was bound.
POST /verify/admission-binding · case bound, the agent is bound to the terms it joined under
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
authority.qualification
Show the granter actually held what it handed out
Every delegation scheme we could find checks the chain downward. Each link is signed, each link narrows, the math works. None of them check the very first step: whether the party at the root held the authority it delegated. UCAN says so in its own spec, that a cryptographically valid chain can still be semantically invalid and the executor has to go look. This receipt is that look, made into evidence. It reads an entitlement source and a grant instrument, verifies the grant instrument's own signature, and answers whether the grant sits inside the entitlement on scope, on amount, and on time. A third party who is neither the granter nor the grantee has to sign the check.
What it does not do. It does not judge whether the entitlement source is telling the truth. It proves the grant did not exceed what that source said the granter had.
POST /verify/authority-qualification · case qualified, the granter held what it granted
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
POST /verify/authority-qualification · case unqualified, the granter granted more than it held
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
delegation.attenuation
Show every hop narrowed and none of them widened
Authority is supposed to shrink as it passes down a chain. In practice a hop can quietly add a scope, raise a cap, or push an expiry out, and the chain still verifies because every signature is good. This receipt compares each hop against the one above it on scope, amount, and time, and reports whether the chain only ever narrowed. It reads the whole chain, not just the last link.
What it does not do. It does not decide whether the top of the chain should have had that authority. That is the qualification receipt. This one only answers whether anything widened on the way down.
POST /verify/delegation-attenuation · case conforms, every hop only narrowed
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
authority.revocation
Show whether the authority was still alive when the action ran
Revocation is easy to publish and hard to prove. The real question after an incident is whether the acting party could have known, at the moment it acted, that the authority had been pulled. This receipt binds the revocation event, the propagation bound the network committed to, and the time of the action, then classifies the action as before revocation or after the propagation bound. That turns an argument about stale caches into a signed answer.
What it does not do. It does not perform the revocation and it does not stop the action. It records where the action fell relative to a revocation the network already published.
POST /verify/authority-revocation · case before, the action ran before the pull
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
POST /verify/authority-revocation · case after, the action ran after the pull
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
mandate.crossacceptor
Show one mandate was not spent twice across parties who do not talk
A single delegated mandate can be presented to two acceptors who have no shared ledger and no reason to trust each other's books. Each one sees a valid mandate and each one is right about its own slice. This receipt fixes each acceptor's consumption as a commitment, then reports the cumulative relation of all of them against the mandate constraint, so the total is checkable without either acceptor handing the other its transaction history.
What it does not do. It does not reconcile the two ledgers, reverse anything, or say which acceptor should have declined. It says whether the sum of what was consumed stayed inside the constraint or went past it.
POST /verify/cross-acceptor · case within, spend stayed inside the mandate
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
POST /verify/cross-acceptor · case breached, spend went past the mandate
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Every run above posts a verified request body from this domain to the open verify route and prints what came back. The example receipts are signed with published example keys, so verify reports key_trust example_registry. That is on purpose. Nothing on this page is a production issuance, a customer record, or an endorsement. Patent Pending.
Canon cross reference
The exact canon entries behind this page
Each link opens that entry in the canon implementation explorer, where its schema, mint route, open verify route, auth requirement and implementation state are stated. The state shown here is read from the same registry file the explorer renders from, so the two cannot drift apart. Nothing here implies a customer, a deployment or an endorsement.
Hive
Hive Proof Architecture