Ledger parity receipt · runnable
Two books.
One answer
neither side has to hand over.
Two systems are supposed to hold the same book. When they drift, whoever finds it first has to prove what both sides looked like at the same moment, and neither side wants to hand over its book to do it.
A ledger parity receipt fixes that. Each side commits a keyed digest over the agreed fields, signs it with its own key, and the verifier recomputes the comparison from those two commitments. Exchanges, transfer agents, custodians, and banks get a shared fact about the break without anyone disclosing a position or a balance.
Plain English
What your team actually gets.
You get a signed record that says two named records were observed at named cursors, at named instants, by two different attestor keys, and that the comparison outcome was recomputed rather than asserted. When the books match, you can show it. When they break, you can show that too, with the timing on both observations, so the argument starts from a shared fact instead of two spreadsheets.
The honest limit
It does not decide which of the two records is right. It never sees a position or a balance. If the two sides diverge, this receipt tells you they diverged and pins exactly what each side committed to and when. Who is correct is still your investigation.
Runnable examples
Press the button.
The verifier answers, live.
Each panel posts a real request body to https://thehiveryiq.com/v1/verify/ledger-parity from your browser. Nothing is precomputed on this page. You see the HTTP status, the verdict, the failed gate when there is one, and the whole JSON response.
Read this before you trust anything below
These example receipts are signed with published demonstration keys. Their key ids all start with did:hive:example: and their seeds are public. Nothing here is secret.
Anyone can regenerate them. That is the point. It shows the API is doing real signature and gate work on the bytes you send, not handing back a canned answer.
Because the seeds are public, an example receipt is a demonstration and it is never evidence of a real event. The response says so itself, in the field key_trust: example_registry. Read that field on every result below.
Both books agree
Expect valid true. Two attestor keys committed the same digest over the same agreed fields, inside the declared window. The verifier recomputes the match rather than taking the receipt's word for it.
Show the full request body
The books genuinely disagree
Expect valid true with comparison.result reporting a divergence. A real break still produces a valid receipt. The receipt is honest about the break instead of hiding it, and that is what makes it useful on the day it matters.
Show the full request body
A disagreement relabelled as a match
Expect valid false with the failed gate COMMITMENT_EQUALITY_RECOMPUTE. The receipt claims the two books matched. The verifier recomputes from the two committed digests and the claim does not hold, so it fails.
Show the full request body
The canon contract
What the receipt proves,
and what it refuses to prove.
Both blocks below are copied word for word from the Hive canon registry entry for ledger.parity. We do not soften them for a sales page.
Proves
This receipt attests that two named records, each observed at a named cursor and at a named instant, and each committed by a distinct registered attestor key to a keyed digest computed over the same declared list of fields, produced the comparison outcome that this service recomputed from those two committed digests and those two instants against the declared window tolerance.
Does not prove
It does not disclose any position, balance, holder identity, or account identifier. It does not attest that either committed digest is a correct digest of the record it names, because confirming that requires read access which this receipt does not confer. It does not decide which record is correct when the two records diverge, assigns no fault to either operator, does not decide whether the underlying settlement, transfer, or register update was proper, and does not effect or reverse any settlement. A window_exceeded outcome records only that the two observations were too far apart for the comparison to be decisive.
Verbatim from canon/registry/hive-canon-registry.json, anchor ledger-parity
For engineers
The route, the auth, and the schema.
Verify is open and unauthenticated, so it is the fastest honest check you can run. Mint requires a bearer token and fails closed with 401 when the token is missing or wrong.
# no credentials needed. swap in any receipt of this type curl -sS -X POST https://thehiveryiq.com/v1/verify/ledger-parity \ -H 'content-type: application/json' \ -d '{"receipt": RECEIPT_JSON }' # mint needs a bearer token and fails closed without one curl -sS -X POST https://thehiveryiq.com/v1/mint/ledger/parity \ -H 'content-type: application/json' \ -H "authorization: Bearer $HIVE_TYPED_MINT_TOKEN" \ -d '{"receipt": RECEIPT_JSON }'
Schema for this type is published at https://thehiveryiq.com/.well-known/schemas/ledger-parity-v1.json.