Compendium Token
A Ledger You Can Verify: Why We Hash-Chained Our Rewards Balance
Append-only double entry, cryptographic chaining, and public anchoring — what each one actually protects against, and why "trust our database" is not good enough for a balance.
If a company holds a balance on your behalf, you are trusting a row in their database. Usually that trust is fine. It is also entirely unverifiable — you have no way to know whether the number changed, or why, or when.
Three techniques, none exotic, remove most of that problem. Here is what each one actually protects against.
1. Double entry: catches mistakes
Every token movement is a transaction whose legs sum to exactly zero. Granting you $50 credits your account and debits an internal account by the same amount. Redemption is the reverse.
This catches ordinary errors. If code creates value from nowhere or loses it in transit, the transaction does not balance and is rejected at write time. A single-sided ledger — just increment a balance column — has no such property; a bug simply produces a wrong number that looks exactly like a right one.
It also gives a global invariant that is cheap to check continuously: the sum of every entry in the entire ledger must be zero. If it is ever not, something is wrong right now, and you know without needing to identify which account.
2. Append-only: preserves history
Nothing is updated or deleted. A correction is a new reversing transaction referencing the original.
This is what makes a statement trustworthy. If mistakes are fixed by editing the original row, the history you are shown is only the history that survived editing, and a reconstruction of how the balance got where it is becomes impossible. Append-only means your balance can always be re-derived from first principles, and every correction is visible as a correction rather than as an absence.
3. Hash chaining: detects tampering
The first two protect against error. Neither protects against someone with database access deliberately changing history — they can edit a row and nothing complains.
So each transaction is cryptographically linked to its predecessor: a hash over the transaction's contents plus the previous transaction's hash. Because each link depends on everything before it, changing any historic value invalidates every link after it. Verification recomputes the chain and reports the first point of divergence.
This is worth being precise about, because "blockchain" gets used loosely. A hash chain does not make tampering impossible — someone with full write access could recompute the entire chain forward. It makes tampering detectable, and undetectable tampering requires rewriting everything since. That is a large step up from "edit one row."
4. Public anchoring: closes the last gap
Which leaves the hole: if we control the whole chain, we could in principle rewrite all of it.
So we periodically publish just the head hash — 32 bytes — to a public blockchain. Once that is published, the ledger's state at that moment is fixed in a record we do not control. Rewriting history now requires producing a chain matching a hash that was published before the rewrite, which is not feasible.
This, for our money, is the genuinely useful application of a public chain for a business like ours. It costs a fraction of a cent, issues nothing, sells nothing, requires no token, and delivers the property people actually want when they say "put it on the blockchain": evidence that does not depend on trusting the operator.
What this does not do
It does not prove the balance is fair, only that it has not been altered since it was recorded. It does not prevent a wrong entry being made in the first place. And it does not make us solvent. Verifiability is a property of the record, not a guarantee about the company — anyone selling it as more than that is overselling.
The test that matters
A hash chain nobody verifies is an extra column. When we built ours, the assertions we cared about were the ones that tamper with the data and confirm verification fails: change an amount, edit a memo, delete a link. It is entirely possible to ship a chain that computes hashes cheerfully and detects nothing, and you only find that out by breaking it on purpose.
Common questions
What does a hash-chained ledger protect against?
It makes later alteration of history detectable. Each transaction is hashed together with the previous transaction's hash, so changing any historic value invalidates every subsequent link and verification reports where the divergence starts.
Is a hash chain the same as a blockchain?
It shares the core mechanism but not the distribution. A hash chain run by one operator makes tampering detectable rather than impossible, since the operator could recompute the whole chain. Publishing the head hash to a public chain closes that gap by fixing the state in a record the operator does not control.
Does a verifiable ledger guarantee my balance is safe?
No. It proves the record has not been altered since it was written. It does not prove an entry was correct when made, and it says nothing about the company's solvency.