linkex.ai, the first Open Tally instance

linkex.ai is a production AI API gateway: 40+ upstream providers (OpenAI, Anthropic, Google Gemini, and more) behind a single OpenAI-compatible endpoint, with per-token billing, agent-native stablecoin payments, and an admin console. Product docs live at docs.linkex.ai.

It is also the first production implementation of Open Tally: every billable call it serves is issued a signed receipt into the publicly verifiable ledger described on this site, with commitments time-fixed by RFC 3161 tokens (DigiCert) and anchored hourly on Base mainnet — every anchor window since go-live has a confirmed public transaction (live stats).

Why the instance pages exist

The protocol guarantees that what was recorded cannot be silently changed or dropped. Whether what was recorded is what actually happened is an engineering property of the implementation — the trust model is explicit about this. These pages document how linkex.ai carries that burden. None of it asks for trust in the abstract: each measure below is either visible in the ledger itself, stated in the specification handed to counterparties, or checkable against the public endpoints.

Honest metering

• Transactional capture. The settlement charge and the receipt-outbox event commit in the same database transaction. There is no window in which money moved but no ledger event was enqueued, and a unique index on the source event prevents duplicates. This is the engineering answer to the protocol's residual completeness gap: the gap can't be closed by cryptography, so it is made as small as transaction semantics allow.
• Independent token counting. The gateway does not simply copy upstream-reported token counts. It counts prompts with its own local tokenizer in parallel, records both numbers, and continuously tracks the deviation against a data-driven baseline. Receipts record the tokenizer id/version and the count mode (local / upstream / estimated / disabled) inside signed content — every number declares its provenance, and a count the gateway couldn't make honestly is labeled rather than laundered.
• Model identity observation. The gateway observes which model identity upstream actually served (including weight digests where available) and writes it into receipts; changes raise alerts. Provenance is graded, never inflated — an unobserved digest is recorded as unobserved, not fabricated.
• Synthetic traffic is refused signature. Health probes and other non-billable traffic are rejected at the sequencer's door, preserving the claim that every receipt on the chain is a real billing event. Every exemption path is explicitly counted and disclosed — no silent exemptions.
• Continuous self-reconciliation. Before any counterparty checks the books, the instance checks itself: per-call cross-checks of its own metering against upstream-reported numbers, supplier invoices run through the same six checks the instance asks others to run on it, and differences attributed to named causes with suggested resolutions — themselves recorded, not settled in a hallway.

Recomputable money

• Versioned prices. Contract prices and price books are versioned with a draft → active → superseded lifecycle; activation requires a second person (separation of duties). Receipts record which price-book version applied.
• Frozen FX. Exchange-rate snapshots record source and observation time and are write-protected: which rate a period used is a frozen fact, not an adjustable parameter.
• Periods close. Closing an accounting period computes a summary hash and freezes it against writes; adjustments and collections are validated against period state.
• Adjustments go through the front door. Post-hoc adjustments (refunds, rebills, reconciliation offsets) are themselves receipted events that occupy sequence numbers — even corrections are on the ledger.
• One implementation of the arithmetic. The billing path and the verifier call the same recomputation code, so "the one who keeps the books" and "the one who checks the books" cannot drift apart.

Operator self-restraint

• Configuration changes write to append-only audit logs — updates and deletes are rejected at the ORM layer, not merely discouraged.
• Dangerous switches require two different administrators (maker-checker) and a stated reason — and the switch controlling that rule protects itself the same way.
• Data reads are logged too (bounded, asynchronous access logging): a ledger whose access history is itself invisible would be a strange foundation for an argument about visibility.
• Fail-closed keys: if the signing key cannot be decrypted, the instance refuses to sign rather than minting a replacement — a second key would make the published key history unable to say which key signed which receipts. The first key of a stream can only ever be created once, on a single node. The trust model states the custody limits as plainly as the guarantees.

Engineering principles with receipts

The build history enforces a small set of principles worth stating because they are checkable against the ledger itself:

1. Signed history is never rewritten — formula evolution dispatches on section generations; a change that would have broken previously signed consistency vectors was rolled back and redone as a new generation rather than patched into history.
2. Fail closed — can't decrypt the key ⇒ refuse to sign; required master secrets unset ⇒ refuse to start; dubious proof ⇒ refuse to issue.
3. One-way doors are explicit — key-encryption migration and the anchor salt are documented as irreversible and gated on release checklists.
4. No silent exemptions — every path that excludes an event from billing or receipting is counted and disclosed.
5. Ship dark, then arm — new verification and anchoring capabilities run in record-only or shadow mode first, with readiness measured before enforcement is switched on, so "the mechanism works" is an observation rather than a hope.