See it happen.
Pick a scenario, watch the gate handle it, then recheck the result yourself. The numbers below are captured from a real four validator BFT testnet run; the cryptographic recompute is genuinely computed in your browser via the standard Web Crypto API. No network calls.
2. Verify it yourself
Once the message has been through the gate, recheck the proof. The checks below come from the real captured artefact (data.js) and from a live recomputation in this browser.
Three at the moment of decision. Three that hold over time.
The gate’s security properties partition naturally into two columns. Decision time properties hold at the moment the gate decides admission. Holding over time properties hold of the record after admission, across the history of the ledger, as time passes and as the world changes around the receipt.
Non bypass
No block is admitted that contains an action whose canonical descriptor hash is not bound to a valid quorum attestation against the active composed ruleset for the named tenant.
ProcessProposalBFT N=4 f=1
Hash binding
Every signature, every per action proof, and every violation record references the canonical hash H(d). Change any byte of the descriptor and the binding breaks.
cryptographic fingerprintdigital signature
Composed policy admissibility
Admission requires a ruleset whose hash is the deterministic composition of a regulator baseline and a tenant overlay, both co signed by their respective role typed signers.
ComposedRulesetHash
Refusal code completeness and soundness
Every refusal carries a code from a stable published taxonomy. Every named code is reproducible from on chain state by any third party. The gate does not fail silently or with an opaque code.
SELF_EXCLUDEDREFDATA_STALE...
Consensus time non admit
A block refused at height H cannot be retroactively admitted at any later height against the same descriptor and ruleset. Admissions are independently verifiable from on chain state.
tamper evident inclusion proofhash linked blocks
Freshness binding
Every permit is bound to the freshness of the reference data it relied on. Outside the named validity window, the permit is non admissible. A self exclusion registered between pre certification and send is honoured.
RefDataStampSLAWindowSeconds
The maths: how (vi) freshness binding works without a real time lookup
The sceptical question a regulator asks first: how do you verify a recipient is not self excluded without a real time lookup against the upstream register at the moment of every send?
The answer is named freshness. The per action proof carries, for each consulted register r:
RefDataStamp_r := ( RegisterID_r, // e.g. "GAMSTOP", "TPS", "OFAC", "DOB-bureau" VersionHash_r, // cryptographic identifier of the snapshot AppliedAtUnix_r, // when the snapshot was applied locally CheckedAtUnix_r, // when the gate read the local replica AgeAtCheckSeconds_r, // = CheckedAtUnix_r - AppliedAtUnix_r SLAWindowSeconds_r, // maximum age, set by the jointly signed rule set )
The policy includes a guard of the shape AgeAtCheckSeconds_r <= SLAWindowSeconds_r. If the local replica falls behind, the gate refuses with REFDATA_STALE. There is no “send anyway because the feed is down” path; the path does not exist by construction.
Between pre certification and send, fresh sync events keep an in window invalidation set. The per message step is “in the pre certified set, not in the invalidation set, token still fresh”. A self exclusion registered ten seconds before send is honoured.
The operator cannot widen the SLA without the regulator co signing the rule set. The check is local and fast; the freshness is named, signed, contracted, and stamped on the proof.
Freshness is not the absence of a real time lookup. It is a named, contracted, stamped, fail closed substitute for one, reconcilable against the upstream register’s published version log.
The maths: tamper evident inclusion proof (what runs in the tamper lab below)
The receipt’s leaf hash is folded with its sibling hashes (the audit path) one level at a time, using the same domain separated cryptographic hash the gate used:
node(L, R) := H( 0x01 || L || R ) leaf(d) := H( 0x00 || canonical(d) )
The leaf is the cryptographic hash of the canonical descriptor bytes with a leaf domain separation byte. Internal nodes are the cryptographic hash of the concatenation of left and right children with a node domain separation byte. The leading byte stops a chosen attacker from confusing a leaf for a node (the classic second preimage attack on tree hashes).
The verifier folds, at each level k of the path:
if (leafIndex >> k) & 1 == 0: // I am the left child h := node(h, sibling[k]) else: // I am the right child h := node(sibling[k], h)
After folding through the path, h should equal the published log root. The cryptographic hash is a 256 bit function with no known second preimage attack; flipping one nibble anywhere in the input diverges the output by roughly half its bits.
The fold runs in your browser via the standard Web Crypto API. The tamper lab below lets you flip a nibble on the leaf or on either sibling and watch the root diverge.
The maths: digital signatures and the role typed quorum
Each role typed signer holds a private key in an unforgeable digital signature scheme. The verification step is a constant time elliptic curve check the auditor reruns from the bundle.
The quorum policy is M-of-N with the rule that M includes at least one valid signature from RoleRegulatorBaseline AND at least one from RoleClient whose tenant identifier matches the descriptor. Neither alone is sufficient. The platform operator’s signatures cannot, in any number, activate the bundle alone.
Cross tenant binding: a signature from tenant Alpha’s key does not satisfy the RoleClient slot for tenant Beta. The validator’s quorum check rejects any attestation whose tenant required signature does not bind to the same tenant identifier as the descriptor under consideration. The refusal code is CROSS_TENANT_BINDING.
The maths: deterministic policy replay
Both rulebooks are written in a deterministic authorisation policy language with bounded time evaluation and a published static analyser. The policy decision engine is deterministic by construction: the evaluator is a pure function of the policy text and the input attributes. A regulator with the same policy text and the same descriptor reads the same verdict and the same refusal code on their own machine.
The composer is itself a deterministic merge whose source and version are ledger resident. The static analyser proves at compile time that the composition’s permit set is a subset of the baseline’s permit set. An overlay that tries to be more permissive than the baseline is rejected at compile time; the deviation has to be explicit and signed.
The deterministic descriptor canonicalisation rule is length prefixed binary encoding with sorted field order and no ambient state. Any independent implementation that follows the specification produces byte identical bytes from byte identical logical content.
The maths: hash linked blocks and consensus time non admit
The ledger is a hash linked chain of blocks. Each block carries the hash of its predecessor in its header; the contents of any block are summarised by a tamper evident tree of cryptographic hashes whose root sits in the block header.
A change to any historical record breaks the hash chain from that point forward, requiring remining every subsequent block and convincing every honest validator to accept the rewrite. Under the BFT honest supermajority assumption (N = 3f + 1; the reference embodiment runs N=4, f=1), this is infeasible.
The deterministic policy decision engine and the deterministic descriptor canonicalisation mean a third party can independently rederive the same verdict from the recorded state, every time, on any machine. The audit record is checkable, not merely auditable; the proof is the on chain state and the deterministic evaluator, not the vendor’s log.
Try to tamper.
If the seal is real, it should break the instant anyone changes the receipt. Below, the pristine receipt re folds in your browser to the same root the gate published. Flip even one nibble on the tampered side, re fold, and verification fails. Same maths. Same browser. Different inputs.
The tamper evident receipt recompute, live
A receipt’s leaf hash is folded with its sibling hashes (the audit path), one level at a time, using the same domain separated cryptographic hash the gate used. The final value should equal the published log root. This recomputation runs natively in your browser via the standard Web Crypto API: no network call, no Kronaxis code involved.
Pristine receipt untouched
Tampered receipt choose what to flip
The fold only verifies that this receipt belongs under this published root. Whether the published root itself is the one the wider chain anchored, and whether the original message description sent into the gate was honest in the first place, are checked by separate steps (the chain snapshot transaction, and the per tenant ingester signature on the descriptor). Both are documented on the For regulators page.