Skip to main content
ImmutableLog logo
ENPT
ImmutableLog / Technical architecture

From event to evidence.
Trust by architecture.

Architecture built to turn every event into verifiable trust, from observation to cryptographic proof.

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

Explore the architecture
11 stages. None optional.01 / Core ↗02 / SIEM ↗03 / Verification ↗
01 / 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.

INRequestAuditable proofOUT

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

Mandatory stages
11
None optional
Consensus model
PoA
Proof of Authority
Nodes in consensus
N
Qualified majority
Destructive operations
0
No update, no delete
02 / The immutable core

Every stage,
a guarantee.

11 stages. None optional. This is what turns a log into something that can be proven.

  1. 01
    Role / Event origin

    Client

    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.

  2. 02
    Role / Entry point

    Ingestion API

    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.

  3. 03
    Role / Ledger gatekeeper

    Validation + Enrichment

    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.

  4. 04
    Role / Duplicate defense

    Idempotency

    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.

  5. 05
    Role / Ordered buffer

    Mempool

    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).

  6. 06
    Role / Cross-node distribution

    Gossip / Internal Propagation

    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.

  7. 07
    Role / Collective agreement

    PoA Consensus

    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.

  8. 08
    Role / Cryptographic chaining

    Block Production

    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.

  9. 09
    Role / Append-only storage

    Append-only Persistence

    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.

  10. 10
    Role / History redundancy

    Replication

    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.

  11. 11
    Role / Verifiable final state

    Independent Verification

    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.

03 / SIEM layer — processing & read

Two engines, one source of truth

The core seals events into the immutable chain. A hook feeds the SIEM, which normalizes to ECS and enriches — real user IP, geolocation, threat intel and rule-based detection. The panel reads from the SIEM through four endpoints, while the proof of inclusion still comes from the core.

Real end-to-end flow

  1. 01Browser
  2. 02Client backend (meta.client_ip)
  3. 03Core — seals in the chain
  4. 04Hook
  5. 05SIEM — ECS + GeoIP + threat + detection
  6. 06Customer panel
01 / CORE

Core — immutability & proof

Validation, sealing, ordering, consensus and append-only persistence. The Merkle proof of inclusion lives here.

02 / SIEM

SIEM — enriched read & security

ECS normalization, GeoIP, threat intel and rule-based alerts. Read-only and isolated per tenant.

Asynchronous processing

What the SIEM API does to every event

The core seals and fires a hook. From there the SIEM processes each event through an asynchronous pipeline — nothing here blocks sealing on the chain.

  1. 01

    Ingest (core hook)

    Receives the sealed event over an authenticated hook (service token, constant-time compare), deduplicates by idempotency and enqueues it.

    Guarantees: The async queue decouples the SIEM from the core — enrichment never delays sealing.

  2. 02

    ECS normalization

    Maps meta→ECS deterministically and derives event.action/category from the core's event_type.

    Guarantees: Every event becomes the same queryable schema, regardless of the format the client sent.

  3. 03

    Real end-user IP

    Resolves source.ip by precedence client_ip › XFF (1st hop) › X-Real-IP › connection, stamping provenance in source_ip_origin.

    Guarantees: Geo, threat and detection run over the real end user — not the proxy or load balancer.

  4. 04

    Enrichment (GeoIP + threat)

    Geolocates source.ip and cross-references threat intelligence feeds.

    Guarantees: Degrades gracefully: a feed being down does not block event indexing.

  5. 05

    Per-tenant indexing

    Persists the ECS document into the siem-logs index, isolated per tenant.

    Guarantees: Every read is tenant-scoped and server-side filtered — no cross-tenant leakage.

  6. 06

    Detection (scheduled queries)

    Each rule runs over a sliding window on a fixed interval (brute-force, new IP, threat hit); suppression prevents repeated alerts.

    Guarantees: A failing rule doesn't take down the others — resilient per-rule detection.

  7. 07

    Alerts & notification

    Detections become alerts linked to the event's exact tx and are delivered over a channel.

    Guarantees: From an alert you reach the immutable event — and its proof of inclusion in the core.

Four read endpoints

  • /searchenriched event listing
  • /aggregatenamed aggregations (timeline, IPs, countries…)
  • /alertsrule-based detections
  • /events/{tx}full ECS event + read audit
  • Tenant isolation on both ends — reads are always scoped by the User Token, filtered server-side.
  • Eventual consistency — the SIEM may lag the chain by a few seconds; the proof always comes from the core.
04 / Engineering choices

Design principles

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

  1. 01

    Proof

    over

    assumption

  2. 02

    Immutability

    over

    convenience

  3. 03

    Deterministic ordering

    over

    ambiguity

  4. 04

    Independent verification

    over

    operator trust

  5. 05

    Enterprise performance

    over

    public blockchain overhead

Permissioned network

Blockchain-grade cryptography, without the public network

ImmutableLog uses blockchain-grade cryptographic primitives, but it does not rely on public networks, tokens, mining, or external validators. It runs as a closed network operated by ImmutableLog, with multiple nodes for resilience.

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

  • No token
  • No mining
  • No public network
  • No third-party validators
05 / 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-proofIllustrative example
$ immutablelog verify --event evt_48291

✓ block_id        48291
✓ block_hash      0x4f2b...c9a1
✓ prev_hash       0x91a3...22ef
✓ merkle_proof    valid
✓ chain_integrity intact
status: VERIFIED
From architecture to your operations

Build the pipeline that turns events into visibility, detection, and verifiable proof.

Read the docs