Screening attestation receipt · runnable
Which list version,
and who signed
the answer.
You screened a counterparty against a sanctions list. Six months later you have to prove which version of the list you used and who signed off on the answer, and your screening vendor has shipped forty updates since then.
A screening attestation receipt binds all of it at the moment of the screen. Banks, card networks, payment processors, and exchanges get the engine, the ruleset digest, the named list version with a digest over its contents, the verdict, the countersigners, and the clock, in one record anyone can check later.
Plain English
What your team actually gets.
You get a record that survives the list changing under you. The primary list version is bound by a digest over that version's contents, supplemental lists carry their own versions and digests, the screening instant is placed against a declared time reference, and the verdict is recorded under a signing authority requirement the verifier recomputes. Reliance windows are explicit, so a stale screen fails instead of quietly passing.
The honest limit
No gate can catch an engine that lies about its own result. If the matcher found a hit and the engine reports a clear verdict, nothing here detects that. What the receipt does is bind the engine, the list version, the verdict, and the clock together, so a lie is attributable to a named engine at a named version. That changes who carries it.
Runnable examples
Press the button.
The verifier answers, live.
Each panel posts a real request body to https://thehiveryiq.com/v1/verify/screening-attestation 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.
Cleared against a named list version
Expect valid true. The clear verdict is inside its declared validity period, the list version digest checks out, and the signing authority requirement is met.
Show the full request body
A hit, countersigned by a compliance officer
Expect valid true with the verdict reported as a match and a countersignature attached. A hit is a normal, valid outcome. The quorum signed it, so the receipt records who stood behind the call.
Show the full request body
Relied on a day after it expired
Expect valid false with the failed gate TTL_FRESHNESS. The screen was fine when it ran. Reliance came after the declared validity period ended, and the gate refuses to let a stale screen pass as current.
Show the full request body
A hit with nobody signing off on it
Expect valid false with the failed gate VERDICT_AUTHORITY_QUORUM. A match verdict needs the countersignatures its own policy demands. Without them there is no one attached to the decision, 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 screening.attestation. We do not soften them for a sales page.
Proves
This receipt attests that a named screening engine, at a named ruleset version bound by a ruleset digest, evaluated a keyed commitment to a counterparty identifier against one named primary reference list at a named version bound by a digest over that version's contents, together with any named supplemental lists at their own named versions and digests, at a screening instant placed against a declared external time reference with a declared drift bound, and recorded the stated verdict under a recomputed signing authority requirement together with a declared validity period measured from that screening instant.
Does not prove
It does not attest that the reference list itself is complete, accurate, current as published, or free of omission, and it does not attest that the publisher of that list acted correctly. It does not decide whether the counterparty is in fact a sanctioned, restricted or prohibited party, a false negative produced by an honest screening against a correctly bound list version remains a false negative that this receipt does not detect, does not correct and does not disclose, and no gate here detects an engine that reports a clear verdict where its own matching computation produced a match. It does not assess whether the screening program as a whole is adequate, whether the ruleset thresholds are appropriately calibrated, whether the set of lists screened is the correct set for any obligation, or whether the declared validity period is short enough for any purpose. It does not identify the counterparty, does not disclose any list record, does not disclose any match score, and does not confirm that the commitment key or the window salt has remained under the custody of any particular party. It does not authorize, block, freeze, reverse or settle any transaction, does not admit or reject any counterparty, does not constitute a report or notification to any authority, does not constitute legal, regulatory or compliance advice, and whether any obligation is satisfied by the screening it records is determined solely by the applicable law and by the parties' own arrangements.
Verbatim from canon/registry/hive-canon-registry.json, anchor screening-attestation
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/screening-attestation \ -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/screening/attestation \ -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/screening-attestation-v1.json.