What is Open Tally?
An open protocol for verifiable AI usage accounting — signed receipts, tamper-evident chains, period commitments, third-party time fixing, and deterministic recomputation.
Open Tally is an open protocol for verifiable AI usage accounting. An implementing gateway issues a cryptographic receipt for every billable AI call; receipts form chains, chains form period commitments, and commitments are fixed in time by third parties. Any party — customer, supplier, or auditor — can re-verify the entire ledger offline with open-source tools, without trusting the bookkeeper.
Why a protocol?
AI usage billing is a unilateral claim in both directions:
- Downstream (customers, resellers): the usage and amounts a gateway reports cannot be independently checked.
- Upstream (model suppliers): when the supplier's invoice disagrees with the gateway's own metering, there is no neutral evidence base — only negotiation.
Open Tally replaces "trust + spot checks + arbitration" with evidence. The core design commitments:
- Every billable event — including failures — gets a signed receipt. A skipped event leaves a hole in the sequence numbers.
- Receipts form a hash chain per channel. Altering one receipt breaks the chain at that link.
- Each period's receipts aggregate into a Merkle commitment, and commitments themselves form a chain.
- Commitment hashes are fixed in time by third parties — RFC 3161 timestamp authorities and a public blockchain, through unrelated trust paths. Once fixed, rewriting history is cryptographically infeasible.
- Amounts recompute deterministically from the unit prices, price-book versions, and metering parameters recorded inside each receipt's signed content.
- All of the above is verifiable offline by a counterparty using a zero-dependency open-source verifier — and precisely enough specified that a counterparty can build their own verifier without ever reading the operator's code.
The shape of the ledger
Each layer answers a different attack:
| Layer | Defends against |
|---|---|
| Signed receipt with sequence number | Fabricating or omitting individual events |
| Hash chain | Silently editing a past receipt |
| Merkle period commitment | Re-issuing a whole period with holes smoothed over |
| Commitment chain | Dropping or reordering periods |
| Third-party time fixing | Rewriting history after the fact, even by the operator |
Underneath all five sits one foundation: a canonical serialization in which the same content has exactly one byte representation, so a hash or signature over those bytes is a commitment to the content and not to an accident of formatting. Receipts covers it first, because every construction above depends on it.
Evidence is layered, and each layer states its reach
A production ledger holds hundreds of millions of receipts. Open Tally does not pretend a counterparty will download all of them. Instead evidence comes in layers, each with an explicitly stated scope:
| Layer | Size | Establishes |
|---|---|---|
| Period bundle — the commitment chain, key history, timestamp tokens | O(commitments): a few MB per stream-month, independent of traffic volume | signatures, sequence continuity, chain continuity, and time fixing over the whole period |
| Sampled receipts — drawn by a published deterministic rule, each with its Merkle proof | O(sample) | inclusion for the drawn set, with the miss probability printed in the report |
| Single-receipt bundle — one receipt, its neighbors, its proof | ~6 KB | all checks for that one receipt |
The sampling rule is public and the seed is a value fixed before the draw could be made, so the operator cannot pick a flattering sample — details in proof bundles.
What "verifiable" means here — precisely
Verification is not a vibe; it is six specific checks, each of which states both what a PASS proves and what it does not prove. Checks 1/3/4/5 answer integrity (was anything altered?); check 2 answers completeness (is anything missing?); check 6 answers recomputability (does the money follow from the recorded prices?).
The protocol is equally explicit about its trust model and residual gaps — cryptography guarantees that what was recorded cannot be silently changed; it cannot by itself guarantee that what was recorded is true. That second half is the implementing gateway's engineering burden, and it is part of what this site documents for the linkex.ai instance.
Protocol components
Receipts
Canonical serialization, the receipt envelope, failure receipts, sections and selective disclosure, section generations.
Sequences, chains, commitments
How receipts become a tamper-evident, hole-evident ledger — with the exact hash constructions.
Time anchoring
RFC 3161 timestamps and on-chain anchoring on Base: why both, and how to walk an anchor down to the chain.
The Six Checks
The complete verification semantics.
Naming and openness
Open Tally is the protocol; linkex is the product implementing it. The protocol specification and verification tooling publish as open source under the GitHub org opentallyprotocol and the npm scope @opentally. The gateway product itself is not required to be open source — the point of the protocol is that you don't need to see the bookkeeper's code to check the books. The receipt specification ships with a conformance-vector suite (exact input bytes, exact expected output bytes, and their SHA-256) precisely so that an independent implementation can prove itself right without reference to the operator's implementation.
linkex.ai, documented as an Open Tally instance
linkex.cc documents linkex.ai — a production AI API gateway — as the first implementation of Open Tally, an open protocol for verifiable AI usage accounting.
Receipts
The atom of the ledger — canonical serialization, the signed receipt envelope, failure receipts, sections with selective disclosure, and section generations.