Ledger Verify API
Ledger Verify walks the chain and proves it has not been altered. It recomputes each entry's hash and confirms it links to the one before it: the audit primitive over the Trust Ledger.
What it returns
The response returns intact (true or false), the entries count, and the head hash. When intact it also returns the genesis hash; when broken it returns broken_at_seq, the sequence number where the chain first fails to verify.
The check recomputes every entry's hash over its material fields plus the previous hash, so any tampering anywhere in the chain surfaces.
When to use it
Call Verify to attest that the verdict record is trustworthy before relying on it, for example in a compliance view or an agent's audit step. It is an open endpoint with no per-call metering and takes no parameters.
The Compliance marketplace persona and the ledger stats endpoint both surface this integrity proof as part of their output.
Notes and honesty
This is a pure verification over the current ledger contents. Offline the ledger is in-memory, so verify reflects the entries accrued since the last restart unless Supabase persistence is configured. The hash chaining is what makes the record tamper-evident.
- intact: whether the full chain verifies
- entries: the number of records checked
- head: the latest entry hash
- genesis: the chain root when intact
- broken_at_seq: where verification first fails
- no parameters, open endpoint
curl -s https://api.lyramindos.com/v1/ledger/verify
Questions
What does intact:false mean?
It means the recomputed hash chain does not match, indicating the record was altered. The response includes broken_at_seq, the first sequence where verification fails.
Does verify take any inputs?
No. It runs over the whole current ledger and takes no parameters. It is open and not metered.
How is tamper-evidence achieved?
Each entry's hash is computed over its material fields plus the previous entry's hash. Any change breaks the chain from that point forward, which verify detects.