Documentation Index
Fetch the complete documentation index at: https://docs.getimmutable.dev/llms.txt
Use this file to discover all available pages before exploring further.
The Problem
Every audit log vendor asks you to trust them. Trust that they won’t modify your data. Trust that their employees can’t tamper with records. Trust that a breach won’t silently corrupt your audit trail. We built Immutable so you don’t have to.Four Layers of Trust
Immutable’s trust architecture is defense-in-depth. Each layer independently detects tampering. No single point of failure. No single party to trust.Layer 1: Cryptographic Hash Chain
Every event is hashed using SHA-256 across all 22 fields, including the hash of the previous event. This creates a tamper-evident chain — modify any field on any event, and every subsequent hash breaks. The chain is per-workspace and uses PostgreSQL advisory locks to guarantee ordering under concurrent writes. Deep dive into the hash chainLayer 2: Blockchain Anchoring
Once per day, Immutable computes a Merkle root over all events in the period and publishes it to the Base blockchain (an Ethereum L2). The on-chain record is permanent and immutable — even if we rewrote our entire database, the Merkle roots on-chain would not match. Anchors are themselves chained, so deleting an anchor is also detectable. Deep dive into blockchain anchoringLayer 3: Append-Only Database
A PostgreSQL trigger (enforce_append_only_events) blocks all UPDATE and DELETE operations on the events table at the database engine level — not at the application level. This fires for every database connection, including the application’s own. There is no application-level bypass.
Deep dive into the append-only database
Layer 4: Public Verification
Two API endpoints require no authentication at all. Anyone — your customers, their auditors, regulators — can independently verify that an anchor’s Merkle root matches what is recorded on-chain. Zero trust in Immutable required. Deep dive into public verificationWhat This Means
| Threat | Layer that detects it |
|---|---|
| Immutable modifies an event field | Layer 1 (hash mismatch) |
| Immutable deletes an event | Layer 1 (chain break) + Layer 3 (trigger blocks it) |
| Immutable inserts a backdated event | Layer 1 (chain break) + Layer 2 (Merkle root mismatch) |
| Immutable rewrites the database | Layer 2 (on-chain Merkle roots don’t match) |
| Immutable deletes blockchain anchors | Layer 2 (anchor chain break) + on-chain data is permanent |
| A rogue DBA runs UPDATE | Layer 3 (trigger blocks it) + Layer 1 (hash mismatch if bypassed) |
| Immutable lies about verification results | Layer 4 (verify on-chain yourself, no API needed) |
Verify It Yourself
Don’t take our word for it. Every claim on this page is verifiable:Verify your hash chain
Call
GET /api/v1/verify to validate every event hash and chain link.
Verify eventsVerify blockchain anchors
Call
GET /api/v1/anchors/{id}/verify to check Merkle roots match.
Verify anchorsVerify on-chain directly
Read the smart contract on Basescan. No Immutable API needed.
Verify on-chain