Private outbound brief · noindex · Hive is not a Mastercard customer or partner
HiveHive Proof Architecture
verifiable intent draft v0.1 · read on august 10, 2026 · one check, section 8.4
Section 8.4 specifies a check across both L3 credentials. The split gives no party both.
The spec is precise about the check. It is precise about the split. Read together, the check has nobody left who can run it.
Verifiable Intent does the hard part well. Every layer signs, every signature resolves against a published key, and selective disclosure keeps each party to the minimum it needs. Then section 8.4 asks whether transaction_id equals checkout_hash, a comparison that reaches across the two halves the design deliberately routes to different parties. Hive signs one receipt that answers that comparison from two commitments, so the answer exists without either half being disclosed and without Hive holding either credential. Registration, tokens, authorization, cumulative state and the audit trail all stay where Mastercard put them.
The check“The cross-reference check ( transaction_id == checkout_hash ) is performed when a verifier has access to both L3 credentials (e.g., during dispute resolution).” · Verifiable Intent specification, section 8.4
The split“In the split L3 architecture, the merchant receives L3b and the payment network receives L3a. Each party verifies its own L3 independently.” · same document, section 8.4 note
We read the specification and the security model looking for the party named to hold both halves. The spec names a role and never names a party. It says verifier, it says dispute investigator, and it states plainly that Verifiable Intent “does not assign liability, specify chargeback codes, or prescribe arbitration procedures.” (security model, read August 10, 2026). Every claim about Mastercard on this page is quoted from a Mastercard owned page or from the Verifiable Intent specification, with the link and the date beside it.
live in production · runnable on this page
Five receipts about layered authority, and one of them is about section 8.4
Verifiable Intent splits a record on purpose, and the privacy case for splitting it is a good one. The join is what goes missing. These five run live from your browser against open verify routes, with no account and no key, and the first one is the join.
one specification · seven passages · quoted verbatim, read august 10, 2026
The check is specified. The holder of both halves is not.
8.4 Verification, the cross reference check
“The cross-reference check ( transaction_id == checkout_hash ) is performed when a verifier has access to both L3 credentials (e.g., during dispute resolution).”
“Full-chain verification (dispute resolution): Disclose all mandates from all layers. This is an exceptional case used for investigating disputed transactions.”
Put in order, the passages say four things. A comparison across both L3 credentials is part of verification. The two L3 credentials go to two different parties. Structural verification is defined for each half on its own. And the party who would hold both halves is described by a role, a dispute investigator, with no party named and no procedure assigned. We looked for that name in the specification and in the security model and it is not there. That is a design choice, not an oversight. Splitting the record is the right privacy answer, and the join is simply a different object from the one Verifiable Intent set out to build.
“As autonomy increases, trust cannot be implied.” “It must be proven.”
Hive agrees with the first quote and reads it literally. A proof needs a party who can compute it. Where the record is split so that no party holds both halves, the proof has to come from a joiner who holds neither, and that is the whole of what mandate.crossreference does.
what is already checkable, and what is left over
Signatures are open and well built. The join across the split is the residue.
The left column is Mastercard's, quoted from Mastercard pages. It stays authoritative and it keeps working exactly as it does today. The right column is one receipt each, and every one of them runs on this page.
Registration comes first. “Mastercard's Agent Pay Acceptance Framework begins by registering and verifying AI agents before they are permitted to transact on the Mastercard network.” (agentic token framework, October 14, 2025)
“Only registered agents can transact” (Mastercard Agent Pay, read August 10, 2026)
“Once an agent passes certification, the payment network adds it to a trusted agent registry.” (Level 1 agentic commerce guide, read August 10, 2026)
“During onboarding, the agent creates a key pair and registers its public key in the appropriate key directory”, and “The well-known path /.well-known/http-message-signatures-directory returns a JSON object containing the agent's registered public keys.” (same guide)
Purchase intent data “also provides the merchant with an audit trail that may be used to help avoid and/or resolve potential cardholder disputes.” (agentic token framework)
“Credentialing: Every agent is credentialed, and with Verifiable Intent, can be recognized and transact with trust across ecosystems.” (Agent Pay for Machines, June 10, 2026)
What a non party can compute afterwards
The joins, the directory history, the recomputed outcome
The section 8.4 comparison, from two commitments. Each side commits a keyed digest of its own cross reference field under a salt fixed before either half was presented. The equality outcome is recomputed by the verifier, and neither credential is disclosed to anyone, Hive included.
A mismatch that allocates no fault. When the halves disagree the receipt reports disagreement and stops there, which lines up with a specification that declines to assign liability or prescribe arbitration.
Two dispute objects joined on one declared field. The merchant side object and the payment side object meet on the field name both of them declared, without either party reading the other.
What a key directory held at one instant. A named observer, a named URL, an observation instant against an external time reference, a content digest, and the presence or absence of one queried key identifier recomputed from the committed content.
Direction of travel across layers. L1 to L2 to L3 compared hop by hop on scope, amount and time, so a widening step is a finding rather than a valid signature.
A recomputed conformance answer. Whether one transaction sat inside the typed constraints of the mandate it names, computed here rather than accepted from the caller.
One line separates the columns. Mastercard verifies what it built to verify, and it built it well. A join across a record that was split on purpose is a different object, and it needs a party who holds neither half. Hive is that party. Hive signs typed receipts about payment and agent events and is never a party to anything it signs. Verification is open, needs no account, and runs offline against a published key in single digit milliseconds.
Mastercard keeps
The network, the credential, the decision
Registration and certification, agentic tokens, the pre authorization credential chain check, cumulative constraint state, the audit trail, and the authorization decision at the issuing institution. Nothing moves out of Mastercard's control and nothing on this page asks for a change to any of it.
Hive provides
The signature of a non party
The signer and the open verifier underneath. An artifact a counterparty checks is cryptographically separate from the operating record it refers to. Independence is the whole product. Ed25519 and ML-DSA-65 under FIPS 204, canonicalised with RFC 8785 JCS, patent pending.
the load bearing claim · test it here
Beside the path. Never in it.
The transaction path runs across the top and stays Mastercard's. Hive receipts bind underneath as each step passes. Switch Hive off and watch what the path does.
0transactions completed on the network 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 transaction never waits on the evidence.
Hive is a sidecar and Hive fails open. If Hive is unreachable the transaction proceeds and nothing is blocked. Take Hive out and network behaviour 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. Receipts issued earlier still verify offline from the artifact itself against a published key, with no call to Hive.
four surfaces · nine direct rows from the census · none requires the others
Where evidence could sit, and what it is worth in each place.
These come out of an internal census of 94 named objects across every published agentic payment protocol. Nine rows in the Mastercard section carry a direct rating against an existing Hive type: rows 21, 22 and 27 for registration and the interaction tag, rows 29, 30 and 37 for the layered chain, rows 31 and 32 for the split halves, and row 35 for typed constraints. Two rows are here for the opposite reason and the page says so. Row 33, the cross reference, and the directory rows were rated a partial fit and no fit, and they are the two the sweep told us to build. A partial match sold as a direct one is how an evidence vendor loses the argument, so both are labelled.
surface a in sequence · five steps, one artifact at the end
Five steps. One computable answer.
1
The agent is admitted. An agent is certified and added to the trusted agent registry (Level 1 guide). admission.binding fixes which admission record this agent came in under, at the moment it came in. Registration, vetting and certification stay entirely Mastercard's.
2
Authority descends the layers. L1 and L2 carry the consumer grant and the mandate set, then L3 splits. authority.delegation records the chain and delegation.attenuation reports whether every hop narrowed. Neither one gates presentation and neither one replaces a signature check.
3
The transaction runs. The credential chain is checked as a pre authorization step and the final decision rests with the issuing institution (Verifiable Intent trust model). Hive holds no credential, moves no money and selects no rail.
4
Both halves land in different hands. The merchant holds L3b and the payment network holds L3a. Each side commits a keyed digest of its own cross reference field under a salt committed earlier. Two commitments, no disclosure.
5
A dispute opens and the join is computable.mandate.crossreference recomputes the section 8.4 comparison from the two commitments and signs the outcome. A dispute investigator reads one artifact, offline, against a published key. The receipt allocates no fault, which matches a specification that assigns none.
instrument map · every row carries its state
What each instrument answers, and its exact state today.
Two states only on this page. LIVE IN PRODUCTION means a Hive production endpoint answered on August 10, 2026, and the runnable demos below prove it from your own browser. COMPOSITE VIEW means the entry reads receipts produced by other instruments and mints nothing of its own. Production as verified on August 10, 2026: 69 typed receipt types, 95 canon entries, 21 white papers, 47 partner pages. Everything here is patent pending.
measured, not asserted · five public endpoints fetched on august 10, 2026
Agent identity is publicly checkable today. Agent authority is checkable by nobody.
We fetched five published endpoints today and wrote down what came back. This is a snapshot of the industry, not a scorecard for any company. The pattern is the same everywhere we looked and it is the honest starting point for this brief. Agent identity has a public resolution path that anyone can walk. The authority behind an agent action has no public resolution path at all, because the record that would answer it was split on purpose.
Identity keys, resolvable by anyone
chatgpt.com/.well-known/http-message-signatures-directoryHTTP 200 · Ed25519 · fetched August 10, 2026kid otMqcjr17mGyruktGvJU8oojQTSMHlVm7uO-lrcqbdg, the same identifier the Level 1 guide quotes as “the public key published by OpenAI”fetch it yourself
www.shopify.com/.well-known/http-message-signatures-directoryHTTP 200 · Ed25519 · fetched August 10, 2026kid SjjyXvQ2cGhsRXs9DXEaV6ClyCun0Pj5yxjV67dLGOk, served live from a merchant platformfetch it yourself
http-message-signatures-example.research.cloudflare.com/.well-known/http-message-signatures-directoryHTTP 200 · Ed25519 · fetched August 10, 2026kid poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0U, the reference example for the Web Bot Auth draftfetch it yourself
Authority, where the resolution path is not public
credentials.mastercard.com/cardHTTP 404 · no key material returned · fetched August 10, 2026the issuer identifier the Verifiable Intent Mastercard reference profile states a card credential MUST usefetch it yourself
verifiableintent.dev/.well-known/jwks.jsonHTTP 404 · no key material returned · fetched August 10, 2026the well known JWKS path on the specification hostfetch it yourself
Two readings of the same table. The first is that the signature layer of agentic commerce is genuinely open, and it works, and a third party adds nothing to it. The second is that the interesting questions have moved. Which authority did this agent act under, and did the two halves of the record agree. Those are joins, and a join across a deliberately split record is exactly what a non party can compute and the parties cannot. Every status above is one curl away from being reproduced by your own team.
architecture · a proposed placement, and nothing in the flow changes
Mastercard stays authoritative for the transaction. Hive makes selected surrounding facts computable by a non party.
Pick a boundary. Registration, tokens, the pre authorization chain check, cumulative state, the audit trail and the authorization decision stay exactly where they are throughout.
Mastercard remains authoritative for
Hive can bind beside it
Portable result
Sidecar placementHive sits beside the transaction, never between Mastercard and a merchant, an issuer or a cardholder. It is invoked out of band and its output is an artifact rather than a decision imposed on the flow.
Commitments, not credentialsInputs are keyed digests, declared field names and public fetches. No card data, no credential, no L3a, no L3b, no transaction identifier and no checkout hash.
Recomputed, never acceptedEvery outcome that matters is recomputed by the verifier from the commitments. A caller that supplies a friendly answer fails a gate, and you can watch exactly that happen in the demos below.
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 with Mastercard and the issuing institution.
No fault allocationA mismatch receipt reports that two halves disagree. It does not say who is wrong, and it assigns no liability. That is a deliberate match to a specification that assigns none either.
Fail open and removableIf a Hive component is slow or unreachable, the transaction still runs. A missing receipt stays visibly missing rather than being backfilled.
scope boundaries · limits on hive, not criticisms of anything mastercard built
What Hive is, and the lines it does not cross.
Evidence, not controlHive does not authorize, submit, route or custody a payment. It produces an artifact after the fact and out of band. Every decision about whether money moves stays with Mastercard, the issuing institution and the human who set the scope.
Not a network, not a payment methodHive is not a payment network, 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 the pre authorization checkHive is not a replacement for the credential chain check and does not re decide it. Verifiable Intent verification stays with the parties the specification designates. Hive answers a comparison those parties cannot each answer alone.
No card data, no credentialsHive holds no card data and no cardholder credential. Private keys, seeds, session material, raw request bodies, L3a and L3b never cross the boundary. Digests, declared field names, public references and declared values are the only inputs.
No claim about liability or disputesA Hive receipt is evidence. It is not a liability determination, not a chargeback right, not compelling evidence recognised by any network or regulator, and not a dispute outcome. The security model draws that line and Hive stays on the same side of it.
Mastercard's marks stay Mastercard'sThis page uses the words Mastercard, Agent Pay and Verifiable Intent as plain references only. There is no Mastercard logo, no lockup and no imitation of Mastercard trade dress. Product and company names belong to their respective owners.
Scope note on durability. Hive states that a receipt issued earlier stays independently verifiable offline using published verifier behaviour and published key material. Hive does not claim indefinite verifiability and does not claim that a future verifier release will preserve a given format unchanged. A Hive receipt is evidence. It is not a compliance determination, a regulatory approval, a fiduciary opinion, or a correctness or safety claim about a model, an agent or a payment. Hive primitives are patent pending.
prove it without us · no account, no key, no call to a salesperson
Three commands, and you never talk to Hive.
Everything below runs against production right now. Paste it into a terminal. The example receipts are signed with published example keys, so verify reports key_trust example_registry, which is on purpose.
# 1. pull the verified example bodies from this domain
curl -s https://thehiveryiq.com/canon/examples/typed-nine-examples.json > ex.json
# 2. take the cross reference match case and post it to the open verify route
python3 -c "import json;d=json.load(open('ex.json'))['types']['mandate.crossreference'];c=dict(d['match']);c.pop('label',None);print(json.dumps(c))" > mx.json
curl -s -X POST https://thehiveryiq.com/v1/verify/mandate-crossreference \
-H 'content-type: application/json' --data-binary @mx.json
That returns valid true with every gate reported one by one, including WINDOW_SALT_PRECEDENCE, CROSS_REFERENCE_FIELD_DECLARED, MERCHANT_SIDE_ARTIFACT_INTEGRITY and PAYMENT_SIDE_ARTIFACT_INTEGRITY. Now edit the answer and send it again.
# 3. relabel the match as a mismatch and post the edited body
sed 's/"equality_outcome":"cross_reference_match"/"equality_outcome":"cross_reference_mismatch"/' mx.json \
| curl -s -X POST https://thehiveryiq.com/v1/verify/mandate-crossreference \
-H 'content-type: application/json' --data-binary @-
# valid: false failed_gate: PAYLOAD_DIGEST_VALID
Nobody edits an outcome after the fact, including us. If you would rather cut Hive out of the check entirely, the Ed25519 public keys are published at thehiveryiq.com/v1/keys and you can validate the signature inside your own process with any standard library. Signing also runs ML-DSA-65 under FIPS 204, with a 1952 byte public key and a 3309 byte signature, canonicalised with RFC 8785 JCS.
reachable owners · titles and links from mastercard's own published pages
The argument has an author. He wrote it down twice.
Pablo FourezChief Digital Officer, Mastercard. “Pablo Fourez is chief digital officer at Mastercard, and a member of the Company's management committee.” He authored both the Verifiable Intent article and the agentic token framework article, which makes him the owner of the argument on this page rather than a routing address for it.Mastercard executive bio · Verifiable Intent article, March 5, 2026 · agentic token framework, October 14, 2025
Jorn LambertChief product officer, Mastercard, quoted in the Agent Pay for Machines announcement of June 10, 2026. Product ownership over where Agent Pay goes next.Agent Pay for Machines press release, June 10, 2026
Karan KatyalHead of Agentic Commerce, quoted in the same announcement. The nearest published owner of the agentic commerce program itself.same press release
The Verifiable Intent maintainersThe specification is a draft at v0.1 and is published openly, which is the cheapest possible path for a comment on section 8.4. A note on the join belongs in the specification discussion before it belongs in a commercial conversation.verifiableintent.dev specification
The merchant developer surfaceThe Level 1 guide teaches merchants to query the trusted agent registry and to resolve keys from a directory. Whoever owns that guide owns the surface directory.state attaches to.Level 1 agentic commerce guide
Every title above is quoted from a Mastercard owned page, linked beside it, read on August 10, 2026. Hive has no relationship with any person named here and nothing on this page implies one.
the ask
RUN IT IN SHADOW MODE. ONE AGENT, NOTHING IN THE MONEY PATH.
Point one sandbox agent at the two receipts for 30 days. Nothing in the authorization, token or settlement path is touched, and no live transaction depends on any of it.
The shape is small on purpose. Your team keeps its own keys and signs its own commitments. Hive receives keyed digests and declared field names, and never a credential. You hold the receipts beside your own logs and check whether the answers agree with what your logs already say. If they do not agree, that is the finding and it cost you a sandbox. Hive removes itself on request at any point, and receipts issued before that still verify offline against a published key.
shadow only · nothing in the money pathyour keys · commitments, never credentialsfail open · removable on request
Direct contact. Stephen Rotzin, Hive Civilization Inc.
Email [email protected]
Phone 925 699 7807
Reply with the sandbox scope and the two commitment shapes your side can emit, and the shadow run starts from there. No call is needed to begin, and everything on this page is already checkable without one.
Non customer notice. Hive is not a Mastercard customer or partner. This is a private outbound technical brief prepared by Hive Civilization Inc. and it describes a proposed technical fit only. No Mastercard integration is represented anywhere on this page. Hive does not authorize, submit, route or custody payments, holds no card data and no cardholder credential, and is not a payment network, a payment service provider, a payment method, an agent platform or a merchant of record. Nothing here is a partnership, an endorsement, an agreement, a certification, or a regulatory or compliance outcome.
Endpoint observations reported on this page were made by Hive on August 10, 2026 and are reproducible with one curl each · they describe the public state of an industry that is early, and they are not a criticism of any company · Mastercard facts on this page are quoted from the Mastercard owned pages and the Verifiable Intent specification linked above · instrument states use two labels only, LIVE IN PRODUCTION and COMPOSITE VIEW, and nothing on this page is presented above its label · production as verified on August 10, 2026 carries 69 typed receipt types, 95 canon entries, 21 white papers and 47 partner pages · signing is Ed25519 and ML-DSA-65 under FIPS 204, with a 1952 byte public key and a 3309 byte signature, canonicalised with RFC 8785 JCS · Hive primitives are patent pending · prepared by Stephen Rotzin, Hive Civilization Inc., [email protected], 925 699 7807 · Wyoming, USA
live in production · runnable on this page
Seventeen runs against production verify routes, including two that answer valid false
Every run below posts a verified request body from this domain to an open verify route and prints exactly what came back. Nothing is precomputed and nothing is cached in the page. The first card is the section 8.4 join. Two of the runs return valid false on purpose, because a verifier that agrees with whatever the caller says is worth nothing in a dispute. The example receipts are signed with published example keys, so verify reports key_trust example_registry. The examples payload is large, so give the first click a moment.
mandate.crossreference
Answer the section 8.4 comparison from two commitments
This is the receipt built for a record that was split on purpose. Each side commits a keyed digest of the one cross reference field it declares, under a window salt committed before either artifact was presented, and each commitment is attested by its own registered key. The verifier recomputes the equality outcome from the two commitments. Neither credential, neither field value and no salt is disclosed to anybody, Hive included, and the party doing the join holds neither half.
What it does not do. It does not attest that either artifact is genuine, complete or unaltered before commitment, that either attestor is entitled to hold what it committed, or that the transaction occurred, was authorised or settled. It does not attest that the cross reference field is the right field for any purpose. A mismatch outcome does not mean either side is wrong, and this receipt allocates no fault.
POST /verify/mandate-crossreference · case match, the merchant half and the payment half carry the same value
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
POST /verify/mandate-crossreference · case mismatch, the halves disagree and no fault is allocated
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
POST /verify/mandate-crossreference · case dispute, two dispute objects routed to different parties join on one declared field
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
directory.state
Fix what a published key directory held at one instant
Certified agents sign with keys published in a directory, and a directory changes. This receipt records that a named observer retrieved a named directory at a named URL at an instant placed against an external time reference with a stated drift bound, that the content hashed to a stated digest, and that the presence or absence of one queried key identifier was recomputed from the committed content rather than supplied by the caller. The input is a public web fetch, so nobody has to cooperate for the evidence to exist.
What it does not do. It does not attest that the directory content is correct, that the publisher is entitled to publish it, that any key in it is validly issued or under anyone's custody, or that a key absent from it does not exist elsewhere. It does not attest that another observer would have seen the same content at the same instant, and it does not decide whether any message should have been blocked.
POST /verify/directory-state · case present, the queried key identifier was in the directory at the observation instant
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
POST /verify/directory-state · case absent, the queried key identifier was not in the directory at that instant
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
POST /verify/directory-state · case rotated, a rotated directory no longer carries the queried key identifier
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
admission.binding
Bind an agent to the admission record it came in under
Registration is the front door. Later, when somebody asks what this agent was admitted under, the answer should be a signed record from the day it joined rather than a row in a table that has been edited since. This receipt shows that a supplied admission credential and one supplied conduct receipt yield byte identical subject commitments under a binding salt the admission credential already commits to, and that the conduct instant falls inside the signed separation.
What it does not do. It does not attest that the admission credential is validly issued, that any admitting party is entitled to admit, that either identifier is true, that the conduct occurred, or that the conduct was authorised. It authorises nothing and decides no dispute.
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.
delegation.attenuation
Show the layered chain only ever narrowed
Layered delegation is supposed to shrink as it descends from L1 to L2 to L3. In practice a hop can add a scope, raise a cap or push an expiry out while every signature stays valid. This receipt compares each hop against the one above it on scope, amount and time and reports whether the chain only narrowed. It reads the whole chain rather than the last link.
What it does not do. It does not decide whether the top of the chain should have held that authority. It answers one question, which is whether anything widened on the way down.
POST /verify/delegation-attenuation · case conforms, every hop in the chain only narrowed
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
mandate.conformance
Recompute whether a transaction fit its typed constraints
Verifiable Intent carries typed constraints such as an amount range. This receipt compares one named transaction against one delegated authority receipt signed before the transaction was authorised, on amount, currency, timing and scope, and recomputes the result instead of accepting a caller supplied answer. The second run below is a record whose stated result was a pass while the recomputed value is a fail. It returns valid false, and the failed gate is named.
What it does not do. It does not prove that a cardholder granted the delegation, that the agent identity is genuine, that a network authorised or settled the transaction, or that goods were delivered. It is not payment authorisation, holds no cardholder credential, and cannot resolve or affect a dispute.
POST /verify/mandate-conformance · case pass, the payment stayed inside the approved mandate
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 stated pass that recomputes to a fail, and the verifier answers valid false
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
ledger.parity
Compare two books without either being handed over
Two record holders, one event, two sets of books. Each side commits, and the verifier recomputes the comparison. A genuine disagreement is reported as a disagreement. The third run is a disagreement relabelled as a match, and it fails the commitment equality gate. That run returns valid false on purpose, because a verifier that flatters the caller is worth nothing in a dispute.
What it does not do. It does not decide which book is right, does not reconcile anything, and does not allocate fault. It reports whether the stated relation between two commitments survives recomputation.
POST /verify/ledger-parity · case pass, both books agree
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
POST /verify/ledger-parity · case diverge, the books genuinely disagree and the receipt says so
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
POST /verify/ledger-parity · case fail, a disagreement relabelled as a match, and the verifier answers valid false
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
mandate.crossacceptor
Track one mandate across acceptors who share no ledger
A cap enforced at one acceptor does nothing if the same mandate is presented at ten. This receipt fixes each acceptor's consumption as a commitment under keyed pseudonyms and a committed window salt, then reports the cumulative relation to the mandate constraint, so a total is checkable without any acceptor handing another its transaction history.
What it does not do. It does not reconcile ledgers, reverse anything, or say which acceptor should have declined. Coverage is bounded by who reports, and a presentation nobody committed does not appear.
POST /verify/cross-acceptor · case within, spend across separate acceptors 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 across separate acceptors went past the mandate
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
authority.revocation
Say which side of a revocation an action fell on
Revocation is easy to publish and hard to prove. The 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 publisher committed to, and the instant of the action, then classifies the action as before the revocation or after the bound.
What it does not do. It does not perform the revocation and it does not stop an action. It records where the action fell relative to a revocation that was already published.
POST /verify/authority-revocation · case before, the action ran before the authority was pulled
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 had time to propagate
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
These runs are open verification, with no account, no key and no call to Hive beyond the verify route itself. Nothing on this page is a production issuance, a customer record, an integration 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