Skip to content

Palynth engine v0.1: a live provenance experiment, verifiable in your browser — see it work

Verification

Trust the record, not the database.

A database can be edited by anyone who holds it, and an edited row looks exactly like a row that was always there. A chained record does not have that property. Every event carries a fingerprint of its own contents and the fingerprint of the event before it, so altering history leaves evidence in the history itself.

Check it yourself

This runs against a real project chain, in your browser, using the same canonical form and the same chaining as the server. Verify it, then edit an event and verify again.

LivePublic-safety station · U.S.76 eventsroot c2db4a7fa0ec36f7158d…

76 events · sha256 each · chained in order

76 events · 1 project root · awaiting verification.

Verify a chain you brought

Any Palynth chain, from any writer. Paste what the hosted API returns for a project, or the array of events itself, and every hash, every link, and every signature is checked here, with the browser port of the same kernel. The verdict does not depend on Palynth's servers, or on anyone's.

Nothing leaves this tab.

Get a chain: GET /v1/projects/:id/chain on the hosted API, or project(id).chain() in @palynth/client. The same check runs in Node as verifyLocal(), and in Python as palynth_provenance.verify.

What a fingerprint does and does not reveal

It proves

  • The document is byte for byte the one the record refers to.
  • The event has not been altered since it was written.
  • No event has been inserted, removed, or reordered.

It does not reveal

  • The contents of the document. A hash is one way.
  • Anything to a party who does not already hold the record.
  • That the original record was correct. Integrity is not accuracy.

That last distinction matters and is often blurred. Palynth proves a record has not changed since it was written. It cannot prove the person writing it was right.

What this does not protect against, today

The honest limit of the current design, stated here rather than left for you to find.

External anchoring operational

A project root can be attested in Sigstore's Rekor transparency log: a signed statement of the root, the event count, and the writer's key id, recorded in a public, append-only log that Palynth does not control. A chain rewritten after that no longer matches a value published before the rewrite, and the verifier checks the log's inclusion proof offline.

Every event is signed with its project's key, so an edit that keeps the hashes consistent still fails the signature unless the editor holds the key. Whether that key is a writer the project ever admitted is a second question, and it now has an answer: give the verifier above a trust root and it replays the project's key registry out of the chain's own KEY_REGISTERED and KEY_REVOKED events. A key cannot admit itself, a revoked key stops counting from the point it was revoked, and a key disowned as stolen stops counting for everything it ever signed.

Anchoring runs daily for every project whose chain has grown, and on demand. Between anchors, a party who holds the record and the key could still rewrite events newer than the last anchor: the window is a day, not forever. And one thing has to be told to you rather than proved: the trust root itself. Something must be trusted first or nothing can be, and no amount of chain structure removes that.