The Six Checks
The complete verification semantics — for each check, what a PASS proves and what it deliberately does not prove.
A verification report gives a separate verdict per check. The defining feature of Open Tally's verification semantics is that every check states both what a PASS proves and what it does not prove — and the limit is part of the output, printed beside the result, not left in a specification nobody reads. The "does not prove" column is not fine print: it is what makes the "proves" column credible, because a check whose limits are unstated will be read as proving more than it does, and the first time that is discovered the whole report loses credibility.
| # | Check | PASS proves | PASS does not prove |
|---|---|---|---|
| 1 | Signature validity | Every receipt was signed by the key its key_id names, valid for that stream and sequence range in the published key history | That the signer was entitled to sign, or that the content is true |
| 2 | Sequence continuity | Within the period and across its boundaries, sequence numbers are continuous — no holes, duplicates, or reordering | That every event that physically happened was assigned a number (see the residual gap) |
| 3 | Hash-chain continuity | Each receipt's prev_hash equals the previous receipt's self-hash on the same stream | Anything about other streams |
| 4 | Merkle inclusion | Every receipt provably belongs to its period commitment; the commitment's declared extent and count match the leaves | That the commitment covers all receipts that ever existed — that is check 2's job |
| 5 | Time fixing | Each commitment hash carries a verified RFC 3161 token, and — for anchored windows — a confirmed on-chain anchor: the content has not changed since that moment | That the content was correct at the moment it was fixed — only that it hasn't changed since |
| 6 | Deterministic recomputation | Recomputing amounts from the unit prices, price-book version, and metering parameters recorded inside the receipts reproduces the reported totals | That the recorded price is the contractually correct price — that belongs to reconciliation and commercial process. Check 6 confirms arithmetic, not policy. |
The seventh row
In the linkex.ai instance the verifier's report actually carries a seventh row, retail itemization: for receipts whose customer section carries an itemized breakdown (generation 5 onward), the customer-side line items must multiply out and fold to the retail amount signed beside them.
It is listed separately because it is disclosure-scoped by design. A receipt is split into a supplier side and a customer side precisely so that neither counterparty sees the operator's full margin:
- a supplier bundle carries the supplier section — checks 1–6 run, retail itemization is SKIPPED, and the skip reason says why;
- a customer examining their own charges cares about retail itemization and not the supplier side.
No single counterparty ever sees all seven rows green — that is the purpose of the split, not a gap in it. For a supplier bundle, 6 passed, 1 skipped is a full score.
How to read the table
- Checks 1, 3, 4, 5 answer integrity: has anything been altered since issue?
- Check 2 answers completeness: is anything missing from what was issued? Integrity and completeness are different questions — a Merkle proof establishes that a record belongs to a set, and says nothing about whether that set is the whole population. A party could decline to record thirty events out of a hundred and the remaining seventy would each verify perfectly. Completeness is what the sequence-continuity rules exist for — and the question a counterparty usually cares about is this one.
- Checks 6–7 answer recomputability: does the money follow mechanically from the recorded inputs?
What one bundle can and cannot establish
The same checks have different reach depending on what you hold:
| Check | From a single-receipt bundle | From a period bundle (no receipts) |
|---|---|---|
| 1 signature | full, for that receipt | every commitment signature, over the whole period |
| 2 sequence | neighbors contiguous, plus the covering commitment's count-vs-range | the whole chain: no gap, overlap, or reordering across the period |
| 3 chain | the links the bundle carries | the commitment chain, link by link |
| 4 inclusion | full, against the commitment's root | nothing — there are no leaves in a period bundle |
| 5 time fixing | the covering commitment's token / anchor | PASS only if every commitment's token verifies; partial coverage is SKIPPED with the count, never PASS |
| 6 recomputation | full, if section payloads are disclosed | nothing — it reads values inside receipts |
The ordinary verdict for a period bundle is therefore "passes on 1/2/3/5, skips on 4/6" — that is what a period bundle is, not a defect in one: the artifact exists precisely to avoid carrying hundreds of millions of receipts. Proof bundles explains how sampling fills the gap with stated odds.
Hard rules of the verifier
- A skipped check is not a passed check. Every check reports PASS / FAIL / SKIPPED, and a skip always carries a reason. A tool reporting all-green when a check silently did nothing would forfeit trust in everything else it said the moment someone asked what that check actually did. In strict mode (
-strict), an unfulfillable precondition — say, TSA roots that cannot be loaded — is a fatal error, not a skip. - Failures are named, not summarized. On a chain of millions, "chain invalid" is not actionable; the verifier reports which failure occurred (wrong self-hash, broken link, skipped sequence — three different incidents) and at which position.
- Verification uses the same computation code as billing. In the linkex.ai instance, the settlement path and the verifier call one shared implementation — "the one who keeps the books" and "the one who checks the books" cannot drift apart algorithmically.
- Checks that cannot run for structural reasons say so honestly. Early-generation receipts don't carry every recomputation input; for those, check 6 reports SKIPPED with the reason — reporting FAIL would blame a receipt for a limit of the generation it was issued under, and reporting PASS would be a lie.
Time anchoring
Fixing commitments in time — RFC 3161 timestamps and on-chain anchoring on Base, what each provides, the exact anchor construction, and how to walk an anchor down to the chain.
Trust model and boundaries
What Open Tally does not claim — the residual gap in completeness, the limits of cryptographic proof, and where engineering and process must carry the argument.