Trust model and boundaries

A verification protocol earns credibility by being precise about its limits. These are Open Tally's, stated as plainly as the guarantees — the specification spends a disproportionate share of its text on "does not prove," and this page does the same on purpose: hiding a boundary at the end of a document is the same as hiding it.

The residual gap in completeness

The mechanisms of this protocol evidence that issued receipts were not deleted or altered. They do not evidence that a receipt was issued for every event that actually occurred. Nothing inside a signed-record scheme can: the scheme starts at the moment of issue, and an event that never entered the sequencer leaves no hole.

Cryptography cannot close this gap. It is narrowed from two directions:

• Implementation engineering — in the linkex.ai instance, the charge and the receipt-outbox event commit in the same database transaction, so there is no window where money moved but no ledger event was enqueued; and the gateway meters usage with its own tokenizer alongside upstream-reported numbers, reconciling continuously (instance guarantees).
• Evidence from outside the system — your own call logs, your own gateway counts, or an independent meter. Reconciling the ledger against external evidence is exactly what the ledger's verifiability makes cheap.

The protocol documents this gap rather than papering over it. A counterparty evaluating any Open Tally instance should ask precisely these questions about capture engineering — and should not read any PASS as "the books are complete against reality."

PASS ≠ true

• A valid signature proves who signed and that content is unchanged since — not that the signed content was correct.
• Sequence continuity proves nothing was removed from what was issued — not that everything was issued.
• Deterministic recomputation proves the total follows from the prices recorded in the receipts — not that those prices match the contract. Price correctness belongs to reconciliation against contracts and price books: commercial process supported by, not replaced by, the ledger.
• More broadly: a verified receipt is corroborating evidence that a record has not been altered since issue. It is not by itself proof that the underlying service was delivered, nor that the metering that produced the numbers was correct — metering honesty is an engineering property of the instance, addressed by independent cross-counting, not by signatures.

Time fixing is forward-only, and its two legs differ

RFC 3161 tokens and on-chain anchors prove content is unchanged since the fixing moment. They cannot retroactively prove the content was correct at that moment. The value is monotonic: the earlier and more regularly commitments are fixed, the smaller the window in which any falsification could have occurred.

The two mechanisms also carry different trust assumptions, which is why the protocol uses both:

• A timestamp token rests on one authority — whoever holds the TSA's key could in principle issue a token bearing any time. The guarantee is as good as that party, and as good as the verifier's discipline in pinning the TSA's roots rather than trusting whatever their operating system happens to trust.
• A public-chain anchor replaces that single party with the chain's consensus — but anchoring has a start moment: commitments issued before it are fixed by tokens only.

Both fix content at a time; they do not fix it against the same adversary.

Sampling bounds tampering; it does not exclude it

Period verification at scale uses sampled receipts drawn by a public deterministic rule. A sample that verifies bounds the probability of undetected tampering — it does not reduce it to zero, and the verifier prints the actual miss probability rather than the word PASS. Drawing 1,000 receipts from 100,000 misses ten tampered receipts about nine times in ten; the number, not the green row, is the conclusion. Proof bundles gives the semantics in full.

Key custody, stated honestly

In the linkex.ai instance the Ed25519 signing key is encrypted at rest under a master secret held outside the database — so a database dump alone yields ciphertext, and an attacker needs two systems rather than one. This is not an HSM, and the instance does not claim it is: the master secret is readable by the signing process, so whoever can read the process environment can decrypt. What matters more than the encryption are two fail-closed behaviors: a key that cannot be decrypted stops the signer — no replacement key is ever minted, because a second key would make the published key history unable to say which key signed which receipts; and a stored key that does not match its stored fingerprint is refused outright.

Operator discipline is part of the system

Verifiability constrains the ledger; it does not by itself constrain the operator's configuration. An honest instance therefore binds itself operationally — in linkex.ai's case: append-only audit logs for configuration changes, two-person (maker-checker) control over dangerous switches, access logging on reads, and the fail-closed key handling above. These measures are documented per instance, because they are instance properties, not protocol properties.

What this buys in practice

The honest summary: Open Tally converts "trust me" into "check me" for everything after the moment of capture, and makes the capture moment itself as small and as audited as engineering allows. Disputes stop being competing spreadsheets; they become a shared, machine-checkable evidence base with a precisely known boundary.