The hash-chained ledger

The ledger is the load-bearing artifact of the runtime. It is per-tenant, append-only, hash-chained, and periodically anchored with an Ed25519 signature.

Structure#

Every event is appended with the hash of the previous event:

SEQ 0416 · prev_hash = 8c31…a09d
SEQ 0417 · prev_hash = 4f9a…c7e1
SEQ 0418 · prev_hash = 3e12…b8ff

Where each prev_hash is SHA-256 over the canonical serialization of the previous event. Consequences:

• Modify any event → every subsequent hash mismatches.
• Delete an event → the chain breaks at the gap.
• Reorder events → hashes mismatch.

Per-tenant isolation#

Each organization’s chain starts at SEQ 1 and grows monotonically. A modification in one tenant’s chain cannot affect another tenant’s chain. Row-level security enforces the boundary at the query layer.

Anchors#

Hash chains detect tampering but not when a state was current — someone with enough privilege could re-hash the whole chain. The anchor closes this:

ANCHOR #0042
signed_at: 2026-08-15T09:14:22Z
seq_signed: 417
head_hash: 4f9a…c7e1
signature: 3e12b8…ffee1a

Periodically, the current chain head is signed with an Ed25519 private key. Once anchored, the chain up to that anchor cannot be modified without also modifying the anchor. The public key travels with every export, so verification is independent of Orkena.

What gets logged#

Every authorization, execution, approval and administrative action — the proposal, the policy evaluation, the execution, the outcome — committed in the same transaction as the step that produced it. There is no window in which an action exists without its evidence.

Tamper detection in practice#

Export a bundle, run verify.py, and alter a byte:

RESULT: FAILED — hash mismatch at SEQ 0212

The verifier identifies exactly which event failed.