Bitcoin-anchored · OpenTimestamps · tamper-evident

The books are open.
And they always will be.

Every routing decision and every token-usage event Tally records is committed to the Bitcoin blockchain. Not because we have anything to hide — but because you should never have to take our word for it.

The problem with trust

Any database can be edited.

Tally records every routing decision it makes — which model it recommended, why it chose it, what the expected outcome was. That record lives in a database. And any database, controlled by any company, can be edited after the fact.

We could quietly delete decisions that made us look bad. We could revise the logs when a recommendation turned out to be wrong. We could retroactively adjust regret estimates to make the routing engine look smarter than it was. We won't. But you have no reason to believe that based on our word alone.

So we don't ask you to take our word for it. Every hour, we take the routing decisions from that hour, hash them into a Merkle tree, and commit the root hash to the Bitcoin blockchain via OpenTimestamps. From that point forward, the record is sealed. No edit to our database can go undetected, because the blockchain proof will no longer match.

How it works

Two Merkle trees.
One Bitcoin block.
Forever.

Every 60 seconds, our anchor worker runs through a simple four-step pipeline — twice, once for each chain. No third-party service. No API keys. Just cryptographic math and the Bitcoin network.

  • 🕐

    Hourly windows

    Every routing decision and every token-usage event is tagged with the UTC calendar hour in which it was recorded — for example, 2026-03-02T14:00:00Z. At the top of each hour both windows seal simultaneously. Nothing more can be added to them.

  • 🌿

    Merkle tree

    Each decision in the window is serialised to a canonical JSON format (field order locked — id, shape, model, regret, policy version, timestamp) and hashed with SHA-256. Those leaf hashes are paired and hashed again, all the way up to a single 32-byte root. If even one decision is altered, the root changes entirely.

  • Bitcoin anchor

    The 32-byte root is posted to OpenTimestamps — a free, open protocol backed by Bitcoin calendar servers. The calendar batches digests from thousands of submitters and commits them into a Bitcoin block. Once included, the timestamp is permanent and cannot be forged without rewriting the Bitcoin blockchain itself.

  • Proof receipt stored

    We store the binary OTS receipt alongside each window. You can fetch it at any time from our inspect API. If you want to verify independently, download the receipt and the raw decisions, recompute the Merkle root yourself, and check it against the receipt using the open-source OpenTimestamps client.

Routing decision (or token-usage event) → Merkle root → Bitcoin, every hour
Decision ASHA-256 → a3f9…
Decision BSHA-256 → 7c21…
Decision CSHA-256 → e814…
Decision DSHA-256 → 2b56…
                   Merkle root: 4f53…
           ╱               ╲
     H(A+B): 9d2a…     H(C+D): c77e…
   ╱      ╲         ╱      ╲
 a3f9…  7c21…   e814…  2b56…
Merkle root (32 bytes)deterministic · collision-resistant
OpenTimestampsfree · no API key · open protocol
Bitcoin blockimmutable · ~24h to confirm

Empty windows — hours with no activity — still get a root. It is the SHA-256 hash of the literal string []. Neither chain has gaps. Every hour is accounted for, on both.

What this actually proves

We can't cook the books.
Not even a little.

The blockchain proof does not prevent us from making bad routing decisions. It does not stop us from having biases in the algorithm or making mistakes in our engineering. What it prevents is post-hoc revision of the record.

If we recommend model A for a given task shape and later decide that was a bad recommendation, we cannot quietly swap model B into the historical log. The Merkle root for that hour is already on Bitcoin. Any change to any decision in that window produces a different root — and the proof breaks.

This matters because routing decisions drive commercial outcomes. Providers pay based on traffic Tally sends them. Consumers pay based on the quality of recommendations. The routing log is, in effect, a financial ledger. We have as much reason to protect the integrity of that ledger as a bank has to protect its transaction records — and now there is a cryptographic mechanism that backs that commitment up.

What "tamper-evident" means in practice

To verify a window, you need three things: the raw routing decisions for that hour, the Merkle root we published, and the OTS receipt we stored. Recompute the root from the decisions. Check it matches what we published. Then verify the receipt against Bitcoin using the open-source ots verify tool. If any of the three don't align, something has been changed.

We publish the OTS receipt for every anchored window via our inspect API. You do not need our cooperation to run the check. You do not need to ask us for access. The receipts are there, the Bitcoin chain is there, and the open-source client is there. The verification is entirely in your hands.

Two chains, not one

Routing decisions and
token usage — both anchored.

We actually run two independent Merkle chains, anchored in parallel to Bitcoin every hour. They cover different parts of the record and serve different purposes.

Routing chain

Every model-selection decision — which model was recommended, why, and with what expected outcome. This is the algorithmic record. It proves the routing engine's behaviour is immutable.

Ledger chain

Every token-usage event — LLM completions (tokens in / tokens out) and MCP provider reports. This is the financial record. It proves the usage data that drives billing and marketplace accounting was never manipulated.

The two chains are structurally identical: hourly windows, SHA-256 Merkle roots, OpenTimestamps receipts, Bitcoin. Only the data they commit to is different. If you collected events via our webhooks, you can verify both chains independently — no Tally server required.

The ledger chain is the one that matters most for financial accountability. Token counts are the raw input to provider payments and marketplace settlement. An undetectable change to a token count could silently shift money. The Merkle proof makes that impossible without breaking the Bitcoin timestamp.

Data portability

What if Tally
goes away?

If you are using our webhooks to collect your routing data — and you should be — then you already have a local copy of every decision we made on your behalf. That is by design. We want your data to belong to you, not to us.

But raw data without provenance is just a file. Anyone can claim a spreadsheet is accurate. What the blockchain proof gives you is the ability to prove to anyone — a regulator, an auditor, a counterparty, a court — that the data you hold is exactly what it was at the time it was recorded. Not a reconstruction. Not an export. The original, verified against an immutable timestamp on the Bitcoin network.

If we shut down tomorrow, the Bitcoin blockchain does not shut down with us. The OTS receipts you have stored are self-contained. The proof exists independently of our servers. Your data's integrity is provable regardless of whether Tally is still a going concern.

Coming soon

Full disaster recovery
on the blockchain.

The Merkle proofs we create today cover routing decisions — the metadata of the routing engine. A future paid tier will extend this to your full dataset: every telemetry event, every outcome signal, every session record.

Trust earned, not assumed.

The open SDK, the public routing record, and the blockchain proof — three layers of accountability that don't ask you to take our word for anything.

Next up

Pricing

Simple, transparent pricing. Pay for what you use.