Technical architecture11 stages. None optional.

Architecture designed for proof, not just storage.

Every component exists for one reason: make critical events verifiable, tamper-evident, and defensible.

End-to-end pipeline

A request is not just stored. It is transformed into evidence.

When an event enters ImmutableLog, it goes through validation, idempotency, cryptographic sealing, ordering, consensus, and append-only persistence before becoming part of the ledger.

This is what turns a log into something that can be proven.

inRequest

outAuditable proof

Mandatory stages: 11
Consensus model: PoA
Nodes in consensus: N
Destructive operations: 0

Client

Role: Event origin

Your application sends critical events through a secure API.

Guarantees

Origin identified and authenticated by key and network address.

Without it

Without origin authentication, any external actor could inject forged events.

Ingestion API

Role: Entry point

The API receives events, validates structure, authenticates the request, and prepares the payload for ledger processing.

Guarantees

Every event enters with a server-side timestamp and a verified client identity.

Without it

Without a trusted server timestamp, chronological order would be controlled by the client — and tamperable.

Validation + Enrichment

Role: Ledger gatekeeper

Events are normalized, enriched with metadata, and checked before entering the ledger pipeline.

Guarantees

Malformed events are rejected before touching the ledger; the hash is computed from a single canonical representation.

Without it

Without canonicalization, two clients would serialize the same event differently and produce different hashes.

Idempotency

Role: Duplicate defense

Retries should not create duplicate truth. Idempotency ensures the same event is recorded only once, even across failures or repeated requests.

Guarantees

The same operation produces a single record, regardless of network or client retries.

Without it

Without idempotency, network instability becomes duplicate events — and duplication corrupts history.

Mempool

Role: Ordered buffer

Valid events enter a temporary pool where they are ordered and prepared for consensus.

Guarantees

Load spikes don't bring the system down; arrival order is preserved.

Without it

Without a mempool, you either process every event synchronously (slow) or drop them under load (lose history).

Gossip / Internal Propagation

Role: Cross-node distribution

Nodes exchange pending events internally so the network can converge on the same ledger state.

Guarantees

No single node controls what is being proposed to the network.

Without it

Without gossip, a compromised node could hide events from the others before consensus.

PoA Consensus

Role: Collective agreement

ImmutableLog uses a permissioned Proof of Authority model between trusted nodes. Blocks are agreed upon, not assumed.

Guarantees

History is an auditable collective decision, not the opinion of a single process.

Without it

Without consensus, an administrator with access to one node could rewrite history alone.

Block Production

Role: Cryptographic chaining

Events are batched into blocks. Each block references the previous one, creating a cryptographic chain of history.

Guarantees

Altering any past event breaks the block hash and every block after it — tampering becomes mathematically detectable.

Without it

Without hash chaining, old events could be edited without leaving a verifiable trace.

Append-only Persistence

Role: Append-only storage

Once written, records are not updated or deleted. Immutability is enforced by architecture, not policy.

Guarantees

Events cannot be edited or deleted, not even by database administrators.

Without it

Without append-only storage, any DBA with permissions can rewrite the past and the system becomes just another log.

Replication

Role: History redundancy

The ledger is replicated across nodes to preserve availability and prevent unilateral history manipulation.

Guarantees

Hardware failure or disaster on one node does not erase history.

Without it

Without replication, losing one node's disk means losing evidence.

Independent Verification

Role: Verifiable final state

Any authorized party can verify that an event exists and that the chain remains intact without trusting the operator.

Guarantees

Any auditor querying any node gets the same answer — and can verify the proof locally, without depending on the operator.

Without it

Without consistency, two auditors would get different answers to the same question — and the evidence loses probative value.

Design principles

Five choices that define how the infrastructure is built — and why.

Proof

over

assumption

Immutability

over

convenience

Deterministic ordering

over

ambiguity

Independent verification

over

operator trust

Enterprise performance

over

public blockchain overhead

Not a public blockchain. Not observability. Not analytics.

ImmutableLog uses blockchain-grade cryptographic primitives, but it does not rely on public networks, tokens, mining, or external validators.

It is a private, permissioned ledger designed for enterprise auditability.

✕No token

✕No mining

✕No public network

✕No external validator

Verification

The proof lives in the data.

Verification does not require trusting ImmutableLog, your database administrators, or your application logs.

If the hashes validate and the chain is intact, the event history can be proven. If something was changed, the break becomes visible.

verify-proof

$ immutablelog verify --event evt_48291

✓ block_id 48291

✓ block_hash 0x4f2b...c9a1

✓ prev_hash 0x91a3...22ef

✓ merkle_proof valid

✓ chain_integrity intact

status: VERIFIED

Build an evidence layer your auditors can verify.

Read the docs