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.
- Held by a third party. Not by you, not by the party you are dealing with.
- Sealed as it is written. Hashed, chained and signed within minutes of arriving.
- Verified by anyone. Offline, with an open-source tool, no account needed.
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.
-
In your database
Your admins can rewrite it. Nothing shows the change. This is where most audit trails live, and it is why auditors are handed screenshots and CSV exports and asked to trust them.
An assertion.
-
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, and a logging tool proves events were received, not that history is intact.
Detectable, but still yours.
-
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.
Evidence.
Four steps from event to evidence
Your application sends events. Sigilbase turns them into a record that stands on its own.
-
Send events to the API
Post each audit event with its actor, action, and payload. Writes are idempotent, so retries never duplicate a record.
-
Every event is hashed and chained
Each event is hashed with SHA-256 and linked to the hash of the one before it. The chain makes any change to earlier history detectable.
-
Batches are sealed and signed
Every few minutes, recent events are sealed into a Merkle checkpoint. The checkpoint root is signed with an Ed25519 key.
-
Export and verify anywhere
Export an evidence bundle and run the open verifier against it. It confirms the chain and signatures with no connection to Sigilbase.
One event, as your application sends it.
POST /v1/events
{
"actor": "svc:billing",
"action": "invoice.voided",
"payload": {
"invoice_id": "inv_9f21",
"reason": "duplicate"
}
}
A range exported, then checked by the open verifier.
$ sigil export --from 40901 --to 40920 wrote evidence-bundle.tar $ sigil-verify ./evidence-bundle.tar hash chain ......... ok inclusion proofs ... ok signatures ......... ok
An auditor never has to take our word for it
Export an evidence bundle, hand it to anyone, and let them check it, offline, with the open verifier, or in this browser, right now. The bundle carries 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. The verifier depends on nothing from Sigilbase, your application, or your database: it reads the bundle, recomputes the chain, and checks every signature itself.
What a pass proves
- Integrity: no event in the exported range differs by one byte from what was sealed.
- Completeness of the range: nothing inside it was removed, inserted or reordered.
- Continuity and authenticity: checkpoints chain to each other, and every seal carries a valid Ed25519 signature from a listed public key.
What it does not prove
- That events were true when written. A false statement is sealed as faithfully as a true one.
- That the exported range is the whole story, only that the range in the bundle is intact.
- Anything about the minutes between an event arriving and its checkpoint being sealed.
- Who a person is. The actor field is whatever the writing system claimed.
A modified, deleted, or reordered event fails verification, and 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
Built for the moments a record gets questioned
-
AI decision logging
Prove what an automated system saw and decided, and that the record was never altered.
-
SOC 2 audit evidence
Control events sealed as they happen; your auditor verifies the export offline in three commands.
-
Disputes between businesses
When each side controls its own logs, neither is evidence. Sigilbase holds the record in between.
-
SEC 17a-4 recordkeeping
The audit-trail alternative, with a trail that is itself tamper-evident and examiner-checkable.
-
Enterprise audit logs
Ship the customer-facing audit logs enterprise procurement demands, in an afternoon.
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.
Questions first? Write to hello@sigilbase.io.