Don’t trust us. Recompute.
A compliance gate is only useful to a regulator if the regulator can rederive the verdict from scratch, without our cooperation, against the same evidence we hold. This page hands you the evidence and the tools to do exactly that.
Read the evidence, rederive the verdict.
Pick whichever step matches the depth of the assessment you are doing. Step one is the visual re fold for desk review; step two is the offline download you read in your own tools; step three is the binary that rederives the verdict from scratch on your own machine.
1. Verify in browser
Go to the See the proof page and recompute the tamper evident inclusion proof live. The browser does the cryptographic recompute itself. Then go to the tamper test and flip a nibble: the root diverges, verification fails. About thirty seconds.
2. Download the bundle
Use the download below to save the real proof bundle as a single JSON file. Open it in your own tools, hash it, archive it, hand it to a third party verifier. A few seconds.
3. CLI: kc verify
Run the open source verifier kc-verify against the bundle on your own machine. It rederives the descriptor fingerprint, replays the policy decision engine, recomputes the tamper evident inclusion proof, and checks every digital signature. A few minutes to build.
Download the bundle
This is a real proof bundle from the gambling demo run captured on 2026-06-07. The bundle is plain JSON: open it in any tool. It carries the descriptor, the per action proof record, the inclusion proof (leaf hash plus audit path plus log root), the ruleset text, the quorum policy, and the two role typed digital signatures. No PII.
kxc_proof_bundle_2026-06-07.json
Real gambling artefact · UKGC LCCP baseline + tenant alpha overlay · permit case.
- Descriptor: the canonical fields the rule set reads (recipient flags, content class, jurisdiction, hour, kind).
- Proof record: issued at timestamp, action ID, action hash, envelope hash, leaf index.
- Inclusion proof: leaf hash, audit path siblings, published log root.
- Rule set text: the regulator baseline (policy text) and the client overlay (policy text) verbatim, with version hash.
- Quorum policy: required roles and the threshold (regulator baseline + client, threshold 2).
- Public keys: the digital signature public keys for each signer DID.
- Signatures: two role typed digital signatures over the canonical envelope bytes, one per role.
CLI verify with kc verify.
kc-verify is a small Go program that reads the bundle JSON
and rederives every claim in it from scratch, against the bundle alone.
It does not call Kronaxis. It does not depend on the chain being
reachable. It is a deterministic local function of the bundle.
Build and run
From the source repository (Go 1.22+):
cd kronaxis-compliance/tools/kc-verify go build -o ./bin/kc-verify ./cmd/kc-verify ./bin/kc-verify --bundle path/to/kxc_proof_bundle_2026-06-07.json
For the bundled regulator self verify kit (one step Makefile plus tamper test scaffold):
cd kronaxis-compliance/tools/kc-sandbox make all # runs 6 scenarios + 4 tamper modes, expects PASS ./run_sandbox.sh # one scenario at a time ./tamper_test.sh # confirms 4 tamper modes are rejected
What kc verify checks
| Check | What it rederives | Pass criterion |
|---|---|---|
| Envelope | Canonical encoding of the descriptor + ruleset version + tenant binding. | Re encodes byte identical to envelope_canonical_hex in the bundle. |
| Signatures | Each role typed digital signature over the canonical envelope bytes. | Verifies with the public key listed for the signer DID. |
| Quorum | The set of signing DIDs covers every required role and meets the threshold. |
Required roles all present; threshold met. |
| Policy replay | Re runs the regulator baseline AND the client overlay against the descriptor. | Verdict and refusal code match what the bundle claims. |
| Inclusion | Standard tamper evident inclusion fold of the leaf hash up through the audit path. | Folded root equals log_root_hex in the bundle. |
| Descriptor hash | Hash of the canonical descriptor bytes. | Equals action_hash_hex in the bundle’s proof record. |
From bundle to verdict, step by step.
This section walks a regulator’s technical reviewer through
what happens when kc-verify is pointed at the proof
bundle above. Every step is a deterministic local function of
the bundle, executed without calling Kronaxis or any external
service.
Step 1: parse the bundle
The verifier reads the JSON, validates the schema, and confirms
the version field. The bundle’s version string
pins the schema; the verifier rejects any bundle whose version
it does not understand.
$ ./bin/kc-verify --bundle kxc_proof_bundle_2026-06-07.json --verbose [1/6] parse bundle schema kc-verify/microsite/v1 OK [1/6] parse tenant tenant-alpha OK [1/6] parse rule_set_id tenant-alpha/ukgc-gambling-marketing/v1 OK
Step 2: recompute the descriptor hash
The verifier serialises the descriptor with the canonical encoding
(length prefixed binary, sorted field order), hashes the bytes
with a standard cryptographic fingerprint, and compares the result against
action_hash_hex in the bundle.
[2/6] descriptor canonical bytes 642 bytes OK [2/6] descriptor fingerprint 5a33e68d8df7ede9... OK [2/6] descriptor matches bundle action_hash_hex OK
Step 3: verify the digital signatures
The verifier reads the public keys for each signing DID from the
bundle, then verifies each digital signature against the canonical
envelope bytes. Both signatures must verify; the role typed
quorum check confirms at least one signature satisfies
RoleRegulatorBaseline and at least one satisfies
RoleClient for the named tenant.
[3/6] signatures did:kxc:regulator-baseline:kronaxis valid OK [3/6] signatures did:kxc:client-signer:tenant-alpha valid OK [3/6] quorum RoleRegulatorBaseline present OK [3/6] quorum RoleClient bound to tenant-alpha match OK [3/6] quorum threshold 2 of N met OK
Step 4: replay the policy
The verifier runs the deterministic policy decision engine against the descriptor, against both the regulator baseline and the tenant overlay, and confirms the verdict matches the bundle’s recorded outcome. The refusal code (if any) must match.
[4/6] policy baseline policies 17 evaluated OK [4/6] policy overlay policies 5 evaluated OK [4/6] policy verdict permit OK [4/6] policy refusal_code (empty, permit path) OK [4/6] policy matches bundle expected_verdict OK
Step 5: recompute the tamper evident inclusion proof
Starting from the leaf hash, the verifier folds upwards through the audit path siblings using a standard domain separated cryptographic hash. The final value must equal the published log root.
[5/6] inclusion leaf hash 4238c7085fbb3f9b... OK [5/6] inclusion audit path depth 2 OK [5/6] inclusion folded root e7428978ec4680d2... OK [5/6] inclusion matches bundle log_root_hex OK
Step 6: confirm reference data freshness
For every consulted register, the verifier reads the freshness
stamp from the bundle (VersionHash,
AppliedAtUnix, CheckedAtUnix,
AgeAtCheckSeconds, SLAWindowSeconds)
and confirms the age was within the SLA at decision time. A
stale stamp is a verifier failure with
REFDATA_STALE.
[6/6] freshness GAMSTOP age 142s <= SLA 900s OK [6/6] freshness DOB-bureau age 84s <= SLA 86400s OK [6/6] freshness operating hours in window 09:00-21:00 OK ========================================================= RESULT: OVERALL=PASS 6 of 6 checks bundle integrity OK =========================================================
The verifier exits with code 0 on PASS and a non zero exit
code per failure class on any failure. A regulator’s
review script can call kc-verify against every
bundle the firm hands over and produce a contractable verdict
without operator cooperation.
Four tamper modes, four named failures.
The verifier is built to fail closed on any tamper. The
regulator self verify kit at
kronaxis-compliance/tools/kc-sandbox/ exercises the
four named tamper modes below and confirms each produces the
expected failure exit code.
| Tamper | Where in the bundle | Failed step | Exit code |
|---|---|---|---|
| Envelope flip | Change one byte of the canonical envelope hex. | Step 3 (signatures) and Step 4 (policy replay) both fail. | 2 |
| Sibling flip | Change one nibble of any audit path sibling. | Step 5 (inclusion) fails: folded root does not equal published root. | 3 |
| Descriptor flag flip | Change the self_excluded flag in the descriptor. |
Step 2 (descriptor hash) and Step 3 (signatures) both fail; replay also yields a different verdict. | 4 |
| Refusal code flip | Change the recorded refusal code in the bundle. | Step 4 (policy replay) fails: replay refusal code does not match the bundle’s claim. | 5 |
make all in
kronaxis-compliance/tools/kc-sandbox/. The script
runs six named scenarios through the verifier (one permit, five
refusals exercising the named codes) and then runs the four
tamper modes above. Expected output: 6 of 6 OVERALL=PASS plus
4 of 4 tamper modes correctly rejected. The kit is self
contained; no Kronaxis network call is made.
What this does not prove.
The verifier proves four things from a single bundle: the descriptor is hash bound to the envelope, the envelope is signed by the two required roles, the inclusion proof folds to the published log root, and the policies re evaluate to the verdict the bundle claims. That is the cryptographic core. Four further questions the verifier does not answer are listed below in plain words.
1. Input fidelity
The descriptor is the buyer’s ingester’s view of the original action. Whether that view was honest in the first place (a self excluded recipient flagged correctly, the right content class assigned) is a separate check: the per tenant ingester signature on the descriptor.
2. Log root provenance
The fold confirms the receipt belongs under the published log root. Whether that root itself is the one the wider chain anchored is checked by the chain snapshot transaction, signed by the consensus committee.
3. Key registration
The bundle’s public keys are the keys the gate registered. Whether those keys are the right keys for “the regulator” and “tenant alpha” in the wider world is a separate identity question handled by DID resolution against the registry.
4. Rule set text
The verifier replays the policy text inside the bundle. Whether that policy text is the text the regulator has deposited (or the text the buyer’s General Counsel signed) is a separate check against the ruleset registry hash. The ruleset content is the regulator’s own.