The Visa CLI Receipt envelope, in one document.
hive-vcr-1 is the smallest envelope you need to prove that an AI merchant call on the Visa Commerce Layer for Intelligence really happened the way the merchant says it did. It's MIT-licensed. It signs with ML-DSA-65 (the government's post-quantum signature standard, NIST FIPS 204). Courts can accept it under FRE 902(13) to (14) without needing an expert to testify. And you don't need a Hive endpoint to check it.
The 30 fields a Visa CLI Receipt must carry.
Every field below is required. If one is missing, that's not a default value, it's a failed check. The envelope is JSON, put in a fixed sorted order (RFC 8785), and then signed.
// hive-vcr-1: canonical envelope, MIT { "spec": "hive-vcr-1", "version": "1.0", "receipt_id": "vcr_01J9V...", "issued_at": "2026-05-28T17:24:00Z", "visa_auth_ref": "vca_...", // Visa CLI authorization reference "merchant": { "id": "merchant_...", "category": "image-gen | music-gen | datasets | llm | code-gen | video-gen | voice | embeddings | search | compute", "endpoint": "https://..." }, "request": { "hash": "sha256:...", "redaction": "none | pii-redacted | sealed" }, "response": { "hash": "sha256:...", "bytes": 12345, "redaction": "none | pii-redacted | sealed" }, "operator_attestation": { "model_class": "" , "region": "us-east | eu-west | ...", "hardware_class": "H100 | H200 | TPU-v5 | CPU", "training_region": "us | eu | none-disclosed", "rights_class": "licensed | open | mixed", "signature": "ml-dsa-65:...", "key_id": "did:hive:operator-..." }, "settlement": { "asset": "USDC", "chain": "base", "tx_hash": "0x...", "amount_minor": 10000, "currency_minor": "USDC-6" }, "countersignature": { "issuer": "did:hive:hivetrust-issuer-001", "signature": "ml-dsa-65:...", "public_key": "ed25519:i6-Wo01AwSD1eAhSSC3e3VCTEYFXehGNOVdC5iobuBc" } }
What a verifier has to do, and what it has to refuse to do.
Put the envelope in order, then check the operator's signature.
Re-save the envelope using RFC 8785 JSON ordering, leave out the two signature blocks, hash it with SHA-256, and check operator_attestation.signature against operator_attestation.key_id using ML-DSA-65. If it fails, the receipt is rejected.
Check the Hive countersignature on its own.
The countersignature is separate from the operator's. It ties the operator's signed envelope to a trust anchor Hive issued. A verifier can't require a network call to run this check. The public key is already built in.
Confirm the payment on-chain.
Settlement.tx_hash has to point to a successful USDC transfer on Base, amount_minor has to match the receipt, and the money has to land in the merchant's published settlement address. If anything doesn't match, the receipt is rejected.
Tie it to the Visa authorization.
visa_auth_ref has to be present and has to match an authorization that Visa CLI actually issued. The receipt doesn't replace the Visa-rails authorization. It's the proof that's tied to it. A receipt without a visa_auth_ref doesn't meet the spec.
It proves itself. That's how we built it.
A hive-vcr-1 receipt is built to satisfy Federal Rules of Evidence 902(13) (records made by an electronic process) and 902(14) (data copied from an electronic device, file, or storage system, and checked with a digital ID). The signing scheme is NIST FIPS 204 (ML-DSA-65), the integrity check is SHA-256 (NIST FIPS 180-4), and the ordering rule is RFC 8785. None of that depends on Hive staying in business. None of it depends on a custodian holding the file. The receipt can stand on its own in court.
MIT license. We won't come after you for patents if you follow the spec.
hive-vcr-1, its reference verifier, and the canonical envelope schema are published under the MIT License. Hive won't assert a patent against anyone building to this spec, whether that's a merchant, an operator, or an independent verifier.