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.
This is not a description of a receipt. It runs now, against a live routed adapter, and you verify the result in this browser with a published public key. No account, no email, no signup.
/v1/model-receipts/openrouter/models…Two separate signed fields, never collapsed into one. If the provider omits a model id, the reported field falls back to the requested id and is marked relayed either way, because an absent claim and a matching claim must not look identical.
| field | value | evidence basis |
|---|
/v1/prov/pubkey. Keep it and you never need this service again.hive-receipt <receipt_id> <payload_sha256> <ts>, computed by your browser, not by us.The same run, outside this page. This block tracks the model and prompt you picked above, so it is the sidecar on your call, not a canned example:
Download verify_model_receipt.py, 146 lines, standard library plus cryptography. It re-derives the content address from the recorded run, which is the check this browser cannot reproduce byte-for-byte, and it prints which fields are witnessed and which are relayed. Change one byte of the receipt and it exits non-zero.
Concretely: one route, one provider pair, signed for two weeks. Nothing in the path. Fail open. No payloads. Hive builds it, measures it on your hardware, and hands you the receipts and the verifier. Every receipt still verifies if Hive disappears entirely, which bounds the downside at two weeks of engineering attention. The sharpest candidate is Arrival Countersignature™↗ on a single high-volume route, because that is where the model-identity field the statutes ask for is decided.
Nothing above needs a conversation first. The endpoints are open and unauthenticated: the signable catalogue↗, the public key↗, the offline verifier↓. Run the sidecar against any model in your own catalogue, keep the receipts, and check them with no Hive code in the loop. If the artifact is not convincing on its own, no meeting fixes that.
Hive Civilization Inc (Wyoming) · Stephen Rotzin, Founder · every primitive named on this page has its own page in the proof architecture↗.
Naming OpenRouter does not imply any agreement. This page does not state or imply that OpenRouter is a customer, partner, pilot, or endorser, or that OpenRouter uses Hive.
Your own documentation says the model returned may differ from the provider or model that actually served a request, and that the identifying metadata is off by default. So today a customer's auditor receives a structured relay of a provider's self-attestation, assembled from logs that live in a service and can be re-rendered. A receipt is a different kind of object. One signed record, content-addressed, checkable offline, with no live service and no account, for as long as the key is published. The object above is that. You just verified one.
The part worth arguing with is the evidence basis column in the tool. A hash the signer computed over bytes it handled is witnessed. A model identity the provider reported is relayed, and signing a relayed claim does not upgrade it. Recording which is which, per field, inside the signature, is the design. That distinction is SiGR™↗, and model identity and substitution detection is MiR™↗.
Every name below is a link to its own page or its entry in the Proof Architecture↗. Nothing here is a hop in the request path.
A completion, a price, and a latency number. The route is a decision nobody can re-examine afterwards.
The prompt is bound before it is submitted, countersigned on arrival, and replayable later without disclosing its contents.
What it buys: the record starts before the provider sees the request, so a dispute has two ends, not one. InkFrame v1™ does not live at the model. It lives inside the prompt, which is why it needs no per-model integration work.
Hardware-rooted runtime attestation underneath the receipt, grouped into a Receipt Proof Vector so a whole batch verifies as one object.
What it buys: the model-identity field stops being a relayed claim and becomes an attested one. This is the only path that changes the evidence basis of that field. Proof-Credit™↗ and SpectralZK v1™↗ are written specifications, not running services.
In plain words: OpenRouter would hold the pen that signs. Hive never receives prompts or completions, never selects a provider, never gates a request, and never holds your keys.
The private key that stamps a receipt stays on your own hardware. Nobody else can sign in your name. The signature is yours, not Hive's. Hive adds a second signature with its own key over the same content address, which is the whole point of a countersignature.
Hive gives you the way to make and check receipts. It does not route a request, select a provider, refuse a call, or run the gateway, does not enter the request path, and does not move or store prompts, completions, or customer data. Each event is recorded as a one-way fingerprint and a cryptographic commitment, never the underlying content. If Hive is unreachable, routing proceeds exactly as it does today.
This page is illustrative only. It was prepared privately by Hive Civilization Inc. and is not affiliated with, sponsored by, or endorsed by OpenRouter, Inc. or any of its affiliates. It does not state or imply that OpenRouter is a customer, partner, pilot, or endorser, or that OpenRouter uses Hive. No commercial relationship of any kind exists or is claimed. A signed record that a request was served is not a statement of legality and does not guarantee compliance with any law, and whether a router is a provider, deployer, or distributor is a legal determination for OpenRouter's own counsel.
hive-receipt <receipt_id> <payload_sha256> <ts>; the hybrid Ed25519 and ML-DSA-65 envelope over RFC 8785 JCS applies to the typed signer, not to this endpoint ·
published benchmarks are p50 at n=40, measured 27 July 2026: sign 0.098 ms (p50), verify 0.136 ms (p50), dual-signed envelope 0.678 ms (p50), ML-DSA-65 signature 3,309 bytes per NIST FIPS 204, 37 of 37 smoke tests pass ·
USPTO 64/119,279 was filed 26 July 2026 and a filing is not a granted patent ·
the certificate-transparency style inclusion log is designed, not yet serving ·
verification is free, works offline, and needs no account ·
production integrations are pilot-ready rather than deployed ·
noindex / nofollow / noarchive / nosnippet.
These three are newer than the routing work described above and they sit one layer down, inside the serving path rather than beside it. A router reviewer who has already accepted per request routing evidence will want these next, because they cover the three places an identical request can still come back different.
Two identical requests at temperature zero can come back different, and the usual answer is that nothing changed. This receipt fixes a divergence bound by digest before the first measured request is sent, then records the accumulator width, the reduction split count and the reduction order at each batch occupancy level it measured. If the outputs moved across levels, the receipt says so and says by how much. If they held, that is a valid receipt too. Either way the number is on the record before anyone argues about it.
What it does not do. It does not say which answer was right, does not name a defect in any vendor, and does not observe the provider batch from outside the serving path. The occupancy levels it records are the ones the issuer controlled.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
A reused cache block from an older build is the quietest way to serve a stale answer. This receipt makes the build epoch an input to the block key, so a block written under one build cannot be read under another by accident. Every reused block is checked against the epoch resident in memory at admission, and a mismatch is unmapped and recomputed before decode passes its prefix. The record lets you recompute block residency age and the cross epoch read count instead of taking a dashboard's word for it.
What it does not do. It does not say the cached answer was correct, does not inspect the contents of any block, and does not reveal any prompt or prefix. It proves only that the epoch binding held at admission.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
When sampling is stochastic, the party asking for the output has no way to check the draw. This receipt turns that around. Every stochastic token is selected from a keystream the requesting party committed first, and the record lets you recompute the keystream positions the sampler consumed and the interval membership residual at each emitted position. If a position is missing or already consumed, the decoder halts rather than redrawing. A halt is a recorded outcome, not a retry.
What it does not do. It does not judge the quality of the output, does not prove the model was the right one, and does not reveal the committed secret. It proves only that each stochastic selection came from the committed keystream at the position claimed.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
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.
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.