Product
A public ledger anyone can verify
Every entry OpenBooks records is hashed with SHA-256 over a canonical encoding that folds in the previous entry’s hash. A nightly checkpoint publishes the head hash so anyone can independently recompute and verify the record over time. This is a cryptographic hash chain — no token, no consensus.
SHA-256 chained entries under one published head hash.
Append-only
The database blocks updates and deletes on the events table via an immutability trigger.
Independently checkable
Anyone with the tenant slug can recompute the chain and compare against the published head.
Nightly anchoring
The head hash is anchored to a stable URL, and when configured, to OpenTimestamps.
How the chain is built
Each event is serialized to a canonical JSON encoding — a fixed field order and a fixed representation for every value, so the same event always produces the same bytes on any machine. Those bytes include the hash of the event before it. The result is hashed with SHA-256 to produce that event’s hash, which in turn feeds the next one. The algorithm is versioned as sha256-canonical-json-v1 and reported on every API response.
The first event in any tenant’s chain is a genesis record whose prior hash is sixty-four zeros. From there the chain is continuous: change any byte of any historical event and every hash after it fails to reproduce. Because verification recomputes from your side, you are not asked to trust OpenBooks’ assertion that the record is intact — you check it.
A hash chain, not a blockchain
There is no token, no mining, no consensus network, and nothing to buy. A blockchain solves the problem of strangers agreeing on a ledger with no trusted operator. That is not the problem here — your organization is the operator, and the question is whether anyone can catch you rewriting history.
A hash chain answers exactly that question, and does it without asking a nonprofit to hold cryptocurrency. Immutability is enforced in the database itself: a trigger rejects updates and deletes on the events table, so the append-only property is a property of the storage layer rather than a policy someone remembers to follow.
What anchoring adds
A chain proves internal consistency, but on its own it cannot prove when it existed. Anchoring closes that gap. A nightly checkpoint publishes the current head hash and sequence number at a stable URL, and where OpenTimestamps is configured, the head is additionally timestamped against the Bitcoin blockchain.
Anchoring is what makes silent backdating detectable. A rewritten history could be internally consistent, but it could not match a head hash you already published — or that a third party already witnessed.