Immutable ledger: append, verify the chain, read any point in time
You are looking at the resident durable append-only logdisk=truth, generation-stamped, CRC-checked on replay in one Semurg substrate. Ask it to append, verify the chain, or read any point in time and it runs the
real query live on this box, on data you can
download and re-run yourself ▸.
Click an example in the agent rail, or ask to append then verify, or read history point-in-time. Every run is measured end to end, on
this box, on the real dataset. Nothing is pre-computed.
Append-only, disk=truth, every entry generation-stamped and CRC-checked on replay. The substrate is a verifiable ledger by construction, not by bolt-on: there is no second journal, no hash-chained block index, no separate verify engine. Verifying the chain is just replaying the durable log we already wrote. Total time, measured live.
the verifiable-ledger leader
A SECOND ENGINE TO PROVE THE FIRST. A verifiable database runs a journal plus a hash-chained or Merkle block index plus a separate verify pass over the underlying store, three layers built and maintained just to make the data provable.
semurg, one engine
The store IS the ledger. There is no Merkle index and no second journal to maintain, because verifying is simply replaying the one durable append-only log we already wrote, generation-stamped and CRC-checked front to back.
The journal, the hash-chain index and the verify engine all collapse into the store itself.
Append + full-file replay verify + point-in-time read, all on the resident durable log. Measured live on this box. Re-run append then verify yourself.
ask the agent to append, verify, or read history, the live ledger numbers render here
This is a COLLAPSE win, not a raw-speed one, and we say so plainly. A verifiable / immutable-ledger database normally runs a second engine over a store: a write-ahead journal, a hash-chained or Merkle block index, and a separate verify pass. We eliminate that entire tax. There is one copy of the data, it IS the ledger, and verifying it is replaying the durable append-only log we already wrote, with generation stamps and CRC and torn-write detection on the way. Durability we MATCH: every entry is on disk before ack, gated on the contiguous-completion watermark, no weaker fsync mode assumed. No second system, no copy, no index build. Total time, no asterisk.