Private outbound brief · noindex · Hive is not a Visa customer, vendor or partner
HiveIndependently signed receipts
you got here from a short post, so the whole argument is on this screen
A four party network is one of the four parties. So it can't be the one who settles what happened.
That isn't a gap in what you built. It's what being a network means. And it's why a neutral signer is worth more to a four party network than to anyone else on the rails.
Visa Intelligent Commerce already compares an agent's transaction against the user's authenticated instruction. Visa states it: “New controls to ensure that payment credential requests match the user’s authenticated instructions and to validate that authorizations received by VisaNet match the original instruction.” When the issuer bank, the acquirer, the merchant and the agent developer disagree about that comparison, the record they're arguing over belongs to Visa. You're a party to it. Every other participant knows that, and you're the one who has to get thousands of independent institutions to accept the same answer about the same event.
Hive signs a typed receipt about that same comparison. Hive doesn't issue the card, acquire the transaction, build the agent or take the payment, so Hive has nothing to gain from the answer. Anyone can check the receipt offline against a published key, with no account and no call to us, in single digit milliseconds. Nine runs further down this page hit the production verifier from your browser, and one of them comes back refusing a receipt.
Payment Instructions matchingVisa compares the credential request and the VisaNet authorization against the user's authenticated instruction · Visa Developer, Visa Intelligent Commerce
A key directory a signature resolves againstthe Trusted Agent Protocol names a key store where relying parties retrieve the public keys, and says a message should be blocked if the key can't be retrieved or has expired · Trusted Agent Protocol specification
Two receipt types, both in productionmandate.conformance and directory.state, live on the open verifier today, 69 typed receipt types deployed and 95 canon entries as of August 10, 2026 · thehiveryiq.com/v1/health
Front loaded, so you can stop reading whenever you want
one
Visa runs the comparison, and Visa is a party to it
The Visa Intelligent Commerce platform validates the credential request and the authorization against the authenticated user instruction. That's Visa's own description of Payment Instructions. It's also Visa validating a record Visa holds.
A neutral signer is worth more to a network than to a bank
An issuer can settle an argument with its own cardholder. A merchant can settle one with its own acquirer. A network has to get an issuer bank, an acquirer, a merchant and an agent developer, who share no books and no incentive, to agree about one event. That's the hardest version of the problem and it's the version where a signature from a non party carries the most weight.
three
The first match is per transaction authority
mandate.conformance proves that a transaction's amount, currency, timing and scope were compared against one specific delegated authority receipt that was signed before authorization, with the outcome recomputed by the verifier instead of accepted from whoever asked. It holds no cardholder credential and it isn't a payment authorization.
four
The second match needs nothing from Visa at all
directory.state fixes what a published key directory held at a stated instant. Its only inputs are a public web fetch and an external time reference, so it can run today against any published directory, with no integration, no data and no permission from anyone.
five, the honest summaryAgent identity is publicly checkable today. Agent authority isn't checkable by anyone. Signature verification in agentic payments is genuinely open and well built, and we say so on the record. What no participant publishes is an artifact fixing what a directory held when a signature was made, or an independent record that one transaction stayed inside one delegated authority. Those two are the whole of what's below.
quoted exactly, every line read on August 10, 2026
What Visa says, in Visa's words
Nothing on this page paraphrases Visa. If a sentence matters to the argument, it's here verbatim with its source and its date. Anything we couldn't confirm at a live URL today was dropped.
Payment Instructions · Visa Developer, Visa Intelligent Commerce
“New controls to ensure that payment credential requests match the user’s authenticated instructions and to validate that authorizations received by VisaNet match the original instruction.”
“Collection of commerce signals that will provide the user’s original instruction and the details of each authorized purchase allow for the quick resolution of most disputes.”
Europe, live transactions · Visa newsroom, 2 July 2026
“Each transaction is securely authorised and directly linked to a verified user and their explicit instruction, keeping the consumer fully in control of when and how payments are made.”
An agentic dispute has four seats at the table and Visa occupies one of them. The issuer bank holds the cardholder relationship and the authenticated instruction it approved. The acquirer holds the merchant relationship. The merchant holds the cart and the fulfilment. The agent developer holds the prompt, the plan and the code path. Visa holds the network record of the authorization and the comparison against the instruction.
Each of those five records is accurate about its own slice, and each one is held by somebody with a position in the outcome. That's the structure of a four party network working as designed. It also means that when the five records don't line up, the only records available are records held by parties, and Visa's is one of them. Nobody at the table is neutral, so nobody at the table can be the neutral answer.
what a party can do, and does well
Visa validates its own rails, and that validation is the right thing to build
Provision an agent specific token and manage its life cycle
Enforce network level controls when the authorization reaches VisaNet
Compare the credential request against the authenticated user instruction
Collect commerce signals and use them to resolve most disputes quickly
Verify participants for a directory of agents and merchants
Every item there is Visa's own published description of Visa Intelligent Commerce. None of it needs an outside instrument to work.
what only a non party can do
Sign the same comparison without holding a seat at the table
Recompute the comparison from the supplied commitments instead of restating a verdict
Publish a verify route that needs no account, so the issuer, the acquirer, the merchant and the agent developer all check the same artifact
Sign under Ed25519 and ML-DSA-65 (FIPS 204, public key 1952 bytes, signature 3309 bytes), canonicalized with RFC 8785 JCS, so the check runs offline years later
Say plainly what the receipt doesn't prove, in the receipt itself
Gain nothing from the answer, because Hive has no position in the transaction
Hive is patent pending on these primitives. Hive doesn't issue cards, run a network, acquire transactions, take payments or build agents.
the part we won't overstate
A receipt from a non party doesn't make anybody agree, doesn't shift liability, and doesn't outrank Visa's own record. It removes one argument from the table, which is the argument about whose copy of the comparison to trust. That's a narrow claim and it's the only one we make.
two surfaces, both scored direct in a 94 object sweep of published agentic payment objects
The two places a signed receipt fits
We enumerated the named objects every serious agentic payments participant has published, then rated each one against the Hive canon under a strict rule. Two Visa surfaces came out as direct matches. Anything weaker than direct was left off this page rather than dressed up to fill it.
Visa surface
Receipt type
What the receipt proves
Needs Visa's cooperation
Payment Instructions matching. Controls that the credential request and the VisaNet authorization match the user's authenticated instruction. Visa Developer, Visa Intelligent Commerce
mandate.conformance production
That the named transaction's amount, currency, timing and scope were compared against the constraints of one specific delegated authority receipt signed before the transaction was authorized, and that the outcome was recomputed by the verifier rather than supplied by the caller.
Yes. Somebody has to emit the delegated authority receipt and the transaction commitment. That's a sandbox agent, not a change to VisaNet.
The key directory a signature resolves against. The Trusted Agent Protocol names the key store as the place relying parties retrieve the public keys, and requires that a message be blocked if the key can't be retrieved or has expired. Trusted Agent Protocol specification
directory.state production
That a named observer fetched a named directory at a named URL at an instant placed against an external time reference with a declared drift bound, that the content hashed to the stated digest, and that the presence or absence of one queried key identifier was recomputed by the verifier from the committed content.
None at all. The inputs are a public web fetch and a time reference. It runs against any published directory today.
The agent identity side of Trusted Agent Protocol maps to a third type, admission.binding, which binds the agent that acted to the credential it came in under. It's on the page because it runs, and it's the smallest of the three claims. It says nothing about whether the credential was validly issued or whether the admitting party was entitled to admit, and the receipt says so itself.
nine live runs · real production routes · nothing on this page is precomputed
Run the verifier from your browser
Each button posts a request body to a route on https://thehiveryiq.com/v1 and prints the verdict that came back. Three of the nine come back valid false, because an instrument that only ever agrees isn't worth having. The example receipts are signed with published example keys, so verify reports key_trust example_registry. That's deliberate. Nothing here is a production issuance, a Visa record or an endorsement.
mandate.conformance
Did this one transaction stay inside one delegated authority
This is the receipt that sits beside Payment Instructions matching. It compares a named transaction against the constraints of one delegated authority receipt that was signed before the transaction was authorized, on amount, currency, timing and scope, and the verifier recomputes the outcome instead of trusting a supplied answer. The second run below is a charge that went past the mandate limit, and the verifier refuses it with a failed CONFORMANCE_RECOMPUTE gate.
What it doesn't do. It doesn't attest that the cardholder granted the delegation, that the declared agent identity is genuine, that any network authorized or settled the transaction, or that goods were delivered. It isn't a payment authorization and it carries no cardholder credential. No network, issuer or regulator recognises it as authentication data, as compelling evidence or as a liability shift, and it doesn't create one. It doesn't resolve or affect any dispute and it doesn't limit any consumer right. It looks at one transaction against a per transaction constraint, so it can't see cumulative spend or velocity, and it inherits the supplied authority receipt's revocation limits.
POST /v1/verify/mandate-conformance · case pass, the charge stayed inside the mandate
Nothing has run yet. Click Run it. The answer below is the answer the verifier returns to your browser. The first run fetches the example bodies first, so give it up to 35 seconds.
POST /v1/verify/mandate-conformance · case fail, the charge went past the mandate limit and the verifier refuses it
Nothing has run yet. Click Run it. The answer below is the answer the verifier returns to your browser. The first run fetches the example bodies first, so give it up to 35 seconds.
POST /v1/verify/mandate-conformance · case empty body, nothing to check, so the schema gate refuses
Nothing has run yet. This one posts an empty JSON object to the same production route. Click Run it.
directory.state
What the key directory held at the instant the signature was made
Trusted Agent Protocol tells a relying party to block a message when the key can't be retrieved or has expired. Months later, when the argument is whether a key was registered, rotated or withdrawn at the moment a signature was made, the evidence available is the directory as it stands now. This receipt fixes the directory at an instant: the URL, the content digest, the key identifiers present, the observation instant against an external time reference, and a recomputed answer about one queried key. The absent and rotated runs below are the interesting ones, because they're the shape a signature dispute actually takes.
What it doesn't do. It doesn't attest that the directory content is correct, that the publisher is entitled to publish it, that any key in it is validly issued or in anybody's custody, or that a key absent from it doesn't exist elsewhere. It doesn't attest that another observer would have seen the same content at the same instant, or that any signature made under any key was authorized. It doesn't decide whether a message should have been blocked.
POST /v1/verify/directory-state · case present, the queried key was in the directory at that instant
Nothing has run yet. Click Run it. The answer below is the answer the verifier returns to your browser. The first run fetches the example bodies first, so give it up to 35 seconds.
POST /v1/verify/directory-state · case absent, the queried key was not in the directory at that instant
Nothing has run yet. Click Run it. The answer below is the answer the verifier returns to your browser. The first run fetches the example bodies first, so give it up to 35 seconds.
POST /v1/verify/directory-state · case rotated, the directory rotated and no longer carries the queried key
Nothing has run yet. Click Run it. The answer below is the answer the verifier returns to your browser. The first run fetches the example bodies first, so give it up to 35 seconds.
POST /v1/verify/directory-state · case empty body, nothing to check, so the schema gate refuses
Nothing has run yet. This one posts an empty JSON object to the same production route. Click Run it.
admission.binding
Bind the agent that acted to the credential it came in under
Trusted Agent Protocol has an agent sign the request with a key a relying party resolves from the key store, and a successful validation implies the signer is a trusted agent. This receipt records the join between the credential and one later conduct record: byte identical subject commitments under one disclosed binding salt the credential already commits to, with the conduct instant at or after the admission instant and inside the signed maximum separation.
What it doesn't do. It doesn't attest that the admission credential was validly issued, that the admitting party was entitled to admit, that either identifier is true, that the conduct occurred, or that the conduct was authorized. The admission decision behind the credential belongs to whoever made it, and no receipt substitutes for that.
POST /v1/verify/admission-binding · case bound, the acting agent is bound to the credential it came in under
Nothing has run yet. Click Run it. The answer below is the answer the verifier returns to your browser. The first run fetches the example bodies first, so give it up to 35 seconds.
POST /v1/verify/admission-binding · case empty body, nothing to check, so the schema gate refuses
Nothing has run yet. This one posts an empty JSON object to the same production route. Click Run it.
Every run above posts to an open verify route on this domain and prints what came back. A route that doesn't exist answers 404, and a request with no receipt in it answers 200 with valid false and a failed SCHEMA gate, which is how you tell a live route from a missing one. Patent pending.
run from this workspace on August 10, 2026 · public web fetches only
Published directories, checked today
Because directory.state needs nothing from anyone, we pointed it at the public web and wrote down what came back. This is industry state on one day, reported as we found it. It isn't a scorecard on any company.
One live key, crv Ed25519, with nbf set and a declared purpose
Agent directory hosts we probed under visa.com
no DNS record
None of the hostnames we guessed resolved, so there was nothing to fetch. The Agentic Directory Visa announced on June 10, 2026 is described as a verified participant directory for merchants and agents, and Visa doesn't publish it as a well known key path, so a guessed hostname is the wrong way to look for it. We're reporting our probe, not a finding about Visa.
what that means, stated carefully
Three published directories answered a plain web fetch with live Ed25519 keys, which is exactly why agent identity is publicly checkable today. The Trusted Agent Protocol names Visa's own key store as the retrieval point for the keys that verify agent signatures Trusted Agent Protocol specification. What nobody publishes, Visa included and every other participant included, is a signed artifact that fixes what any of those directories held at a stated past instant. And no participant publishes an independent record that one transaction stayed inside one delegated authority. That's the honest summary: identity is checkable, authority isn't checkable by anyone.
scope, so nothing here reads as a replacement
What stays Visa's, in full
unchanged
The rails
VisaNet, the authorization path, network level controls, token provisioning and life cycle, the passkey and step up flows, Trusted Agent Protocol, the directory, and every dispute rule. Hive touches none of it and asks for no change to any of it.
unchanged
The decision
Visa decides what Visa decides. A receipt is evidence about a comparison, and it doesn't approve, decline, block, reverse or settle anything. It doesn't sit in the money path and it can't slow an authorization down, because emission is out of band.
added
One signed artifact, beside the event
A typed receipt, signed by a signer with no seat at the table, checkable offline by any of the four parties against a published key with no account and no call to Hive.
removable
Out on request, any time
Nothing depends on Hive staying. Receipts already issued keep verifying against the published key whether or not Hive is still involved, which is the point of an offline check.
the limits, written down before you ask
What these receipts don't do
Every Hive receipt type carries its own limits in the canon entry and in the verifier's answer. Here are the ones that matter to a network.
no liability shift
No network, issuer or regulator recognises a Hive receipt
It isn't authentication data and it isn't compelling evidence. It doesn't shift liability and this page doesn't imply that it does. It also doesn't resolve, deny or affect any dispute, and it doesn't limit a right anybody holds under Regulation E, Regulation Z or an equivalent rule.
no card data
Hive never receives a credential
No primary account number, no card security code, no token vault state, no decryption key, no cardholder personal data. The inputs are commitments, digests, instants and declared field names. Objects whose verification needs card data are out of bounds for Hive by rule, and we left every one of them off this page.
no identity claim
Visa's identity attestations need nothing from us
When Visa signs an attestation that a consumer was identified by the scheme, that's Visa attesting to something only Visa knows, and it's already checkable by any relying party against Visa's published key. There's no independent version of that fact and we don't claim one.
no completeness
A receipt only sees what it was given
mandate.conformance looks at one transaction against one per transaction constraint, so it can't see aggregate spend or velocity. directory.state reports one observer's fetch at one instant and doesn't claim another observer saw the same bytes. Both say so in their own text.
who this brief is written for
Two names, both confirmed at a live source today
primary
Rubail Birwadker
Senior Vice President, Head of Growth Products and Partnerships, Visa. Confirmed verbatim in the Linux Foundation announcement of the operational launch of the x402 Foundation, dated July 14, 2026, where Visa is named a member. That's the surface an independent signer would come in through, and it's why this brief is addressed here first.
His stated position on the record is interoperability across platforms, networks and payment types. A receipt anyone can verify offline, with no account, is an interoperability artifact before it's anything else.
Chief Product and Strategy Officer, Visa. Confirmed on Visa's own Intelligent Commerce page, where he's the named executive voice, and in the June 10, 2026 Visa Payments Forum release, which titles him Chief Product & Strategy Officer at Visa.
He's on record that trust and security are the infrastructure that makes the whole system work. This brief is one narrow piece of that infrastructure, offered by somebody with no position in the outcome.
One sandbox agent, in shadow mode, with nothing in the money path and nothing in the authorization path. Your team holds its own keys. We emit receipts beside the flow, and then you hold them against your own logs and see whether they say what your logs say.
If the receipts match your logs, you've got an artifact the issuer, the acquirer, the merchant and the agent developer can each check without asking you for a copy. If they don't match, you've learned that in a sandbox for the cost of one agent, and Hive removes itself on request at any point.
The directory.state half needs nothing from Visa to start. It runs on public web fetches, so it can start accumulating directory observations against any published directory the day somebody says go.
Non customer notice. Hive is not a Visa customer, vendor or partner. This is a private outbound technical brief prepared by Hive Civilization Inc. and it describes a proposed technical fit only. No Visa integration is represented anywhere on this page. Hive does not authorize, submit, route, acquire or custody payments, holds no card data and no cardholder credential, and is not a payment network, a payment service provider, an issuer, an acquirer, an agent platform or a merchant of record. Nothing on this page is a partnership, endorsement, agreement, certification, or a regulatory or compliance outcome. Every statement about Visa on this page is quoted from the Visa owned or Linux Foundation pages linked below, each fetched on August 10, 2026.
Hive production state, verified live on August 10, 2026 against thehiveryiq.com/v1/health · 69 typed receipt types deployed · 95 canon entries · Ed25519 and ML-DSA-65 (FIPS 204, public key 1952 bytes, signature 3309 bytes) · RFC 8785 JCS canonicalization · every Hive primitive named here is patent pending · the example receipts behind the runs above are signed with published example keys and verify reports key_trust example_registry, so nothing on this page can be mistaken for a production issuance · prepared by Steve Rotzin, Founder, Hive Civilization Inc. · Wyoming, USA
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
Independently signed receipts