Sigilbase is in early access, free while we're in beta. Your data and evidence are permanent.

Evidential custody for audit logs

Evidence that holds up

Your audit logs are rows in a database you control. To an auditor, a regulator, or the other side of a dispute, that is an assertion, not evidence. Sigilbase keeps your records in a tamper-evident ledger held by neither you nor your counterparty, and lets anyone verify them offline. Alter, delete or reorder a record and verification fails at the exact entry.

append-only log checkpoint #4192
user.role.granted seq 40917 root a3f9…c21e
record.updated seq 40918 root b71c…9d40
export.requested seq 40919 root 0e28…f5aa
checkpoint.sealed seq 40920 root 6c14…8b02 root matches, signature valid
Who holds the pen?

Where a record lives decides what it proves.

The same audit trail means three different things depending on who holds it. Only one custody arrangement takes the pen out of the hands of the party being audited.

01

In your database.

Your admins can rewrite it. Nothing shows the change. This is where most audit trails live.

02

In your app, hash-chained.

Better: tampering is detectable. But you still hold the keys and the checkpoints, so the party being audited still holds the pen.

03

In Sigilbase.

The record is held by a third party, anchored outside our reach, and verifiable by anyone with an open-source tool. Nobody has to take anyone's word, including ours.

The problem
01

Anyone with database access can rewrite an audit table.

02

Auditors are asked to trust screenshots and CSV exports.

03

Logging tools prove events were received, not that history is intact.

How it works

Four steps from event to evidence.

POST /v1/events step 1
POST /v1/events
{
  "actor":   "svc:billing",
  "action":  "invoice.voided",
  "payload": {
    "invoice_id": "inv_9f21",
    "reason": "duplicate"
  }
}
seq 40919  export.requested
  data      0e28…f5aa
  prev      b71c…9d40   (event 40918)

  hash = SHA256(data ‖ prev)
       →  0e28…f5aa

seq 40920  checkpoint.sealed
  prev      0e28…f5aa
       →  6c14…8b02
checkpoint #4192
  events       40901 – 40920
  merkle_root  6c14…8b02
  sealed_at    2026-07-08T09:14:02Z
  algo         ed25519
  key_id       key_9f0a…2d17
  signature    MEUCIQ…c4b1
$ sigil export --from 40901 --to 40920
  wrote evidence-bundle.tar
  2,481 events, 7 checkpoints

$ sigil-verify ./evidence-bundle.tar
  hash chain ......... ok
  inclusion proofs ... ok
  signatures ......... ok

The concepts behind these four steps: tamper-evident audit logs, explained in full

Verification

An auditor never has to take our word for it.

This is how the evidence holds up: export an evidence bundle, hand it to anyone, and let them check it, offline, with the open verifier, or in this browser, right now.

sigil-verify ./evidence-bundle.tar
reading evidence-bundle.tar
events            2,481
checkpoints           7
recomputing hash chain ... ok
verifying inclusion proofs ... ok
verifying Ed25519 signatures ... ok
verified: 2,481 events intact, 0 breaks
What the bundle contains

The events, their hash chain, the Merkle inclusion proof for each event, the signed checkpoints, and the public signing keys. One file, no database access required.

Why the verifier is standalone

It runs offline and depends on nothing from Sigilbase, your application, or your database. It reads the bundle, recomputes the chain, and checks every signature itself.

The plain-terms guarantee

A modified, deleted, or reordered event fails verification. The failure names the sequence number, so you know exactly which record broke.

More on the open verifier, or read its source on GitHub

For engineers The primitives, no marketing translation.
REST API
Idempotent writes
Batch ingestion
Inclusion proofs per event
Ed25519 signed checkpoints
Public signing keys
FAQ

Common questions, answered plainly.

What is Sigilbase?

Sigilbase is evidential custody for audit logs, delivered as a service. Your systems write events to a REST API; every event is hashed with SHA-256 and chained to the one before it, recent events are sealed into Merkle checkpoints signed with an Ed25519 key, and the record is held by Sigilbase rather than by the party it describes. The history exports as an evidence bundle that anyone can verify offline with a standalone open-source verifier.

Why does it matter who holds the audit log?

Because the party being audited holding its own log is exactly what an auditor, regulator, or counterparty has to discount. A record in your database is an assertion; your admins could rewrite it and nothing would show. A record held by a neutral third party, sealed as it is written and verifiable by anyone with an open tool, does not depend on anyone taking your word, or ours.

How does Sigilbase prove an audit log has not been tampered with?

Every event is chained to the previous event's hash, so editing, deleting, or reordering any record breaks the chain from that point forward. Checkpoints seal batches of events under a signed Merkle root, so history cannot be rewritten and re-sealed without invalidating signatures already issued. The verifier recomputes all of it and, if a record was touched, fails and names the sequence number.

Can an auditor verify Sigilbase evidence without a Sigilbase account?

Yes. That is the point of the design. An evidence bundle is one self-contained file, and the standalone verifier is an open-source tool, a single PHP file with no dependencies, that runs entirely offline with no connection to Sigilbase. An auditor checks the hash chain, inclusion proofs, and signatures themselves, without trusting us or you.

What does an evidence bundle contain?

The events in the exported range, their hash chain, a Merkle inclusion proof for each event, the signed checkpoints covering the range, and the public signing keys. One file, verifiable anywhere, with no access to Sigilbase or your database required.

How long does Sigilbase retain audit events?

Forever, on every plan, including the free one. Retention is never a paid feature, ingestion never stops because of billing, and if you stop paying your history is never deleted. Records built as evidence are only useful if they outlive the subscription that created them.

Does using Sigilbase make my company SOC 2 or PCI DSS compliant?

No single tool makes you compliant. Sigilbase strengthens the audit trail and log integrity controls those frameworks require, and gives your auditor evidence they can verify by computation instead of on trust. Certification still depends on your controls and your auditor's assessment.

How do I send audit events to Sigilbase?

Through a REST API. Each event carries an actor, an action, and a payload; writes are idempotent, so retries never create duplicate records, and batch ingestion is supported for high-volume streams. Most teams integrate from their application code in an afternoon.

Start recording provable history

Chained, sealed, independently verifiable audit logs, from the first event. Free while Sigilbase is in beta.

Start free

Questions first? Write to hello@sigilbase.io.

Privacy

This site runs no analytics and no trackers.

The site itself collects nothing. If you create a Sigilbase account, the data that involves is described in the privacy policy.

To have your email removed, contact hello@sigilbase.io.

Read the full privacy policy

Last updated July 2026