Ledger

Core ledger specification — frozen

Frozen — what that means

The rules below are the a2ally Core Ledger Specification, version 1 (core-ledger-v1), declared frozen on 2026-11-06. They are never edited in place: a change to any of them ships only as a new spec version, with its own document and hash, announced before it takes effect — and records sealed under version 1 stay verifiable under version 1 rules forever.

The specification document is published as canonical JSON at https://www.a2ally.com/v1/ledger/spec. Its SHA-256, computed from the document itself, is:

6f77cbdd64c749354fc692bd1f2d49e534a62c1db919fcab924c82e337eebd04

A test in the platform suite pins that hash, so an edit to the frozen rules fails the build until it is deliberately re-issued as a new version.

The frozen rules

• Entry format: seq, at, type, subject, payload, payload_hash, leaf_hash, block_height — payloads are canonical JSON (keys sorted, no whitespace, UTF-8).
• Hashing: payload_hash = sha256(canonical(payload)); leaf = sha256("leaf:" + canonical({seq, at, type, subject, payload_hash})); Merkle nodes hash as sha256("node:" + left + right), an odd node carried up unchanged.
• Blocks: header version 1 with nine fields (v, height, prev_hash, merkle_root, first_seq, last_seq, entry_count, at, key_id); block hash = sha256("block:" + canonical(header)); at most 256 entries per block; the genesis entry states the chain parameters and is sealed alone in block 0.
• Signatures: Ed25519 over canonical(header), base64.
• Free text never enters a sealed payload: the payload carries a salted commitment, and the text lives in the one redactable side table (ledger_texts).
• Private facts are salted commitments; the opening is held for its parties only.
• Entry types (128 at freeze) are append-extensible: new types may be added; removing, renaming or redefining one is a breaking change.

No code path rewrites a sealed record — the audit

The audit at https://www.a2ally.com/v1/ledger/audit is computed fresh on every request, three ways:

• Trigger census: the eleven core tables are read from the live schema — ten carry update and delete guards that abort any rewrite; ledger_texts is the designed exception (redaction only). Census complete: yes.
• Mutation probes: 12 of 12 mutation probes blocked. Every probe runs against a real sealed row inside a transaction that is rolled back either way.
• Code-path census: 11 insert sites (one per core table), 2 update sites (the sealing transition and the text redaction, both in src/ledger.ts), 0 delete sites in the shipped sources — recomputed from source by the test suite on every run.

Chain verification (full recomputation): ok — 159 blocks, 301 entries checked at the last audit read. Sealed on record now: 301 entries in 159 blocks, 2 commitments, 750 anchors, 66 witness cosignatures, 0 text redactions.

Audit verdict at page render: ok — no rewrite path found.

What the audit does not prove

• The audit covers the application code paths and the database triggers in the running service. It does not stop someone holding the database file or the host, who could drop the triggers; a rewrite made that way is caught from outside — Bitcoin anchors, witness cosignatures, daily snapshots and mirrors hold copies the host cannot rewrite.
• It does not prove the production server runs exactly this code. The deployed commit and build hash are published at /v1/transparency/build; until builds are reproducible from a public source, a reader can check consistency over time but cannot independently prove the running code.
• It does not cover the content of ledger_texts (redactable by design — the commitment in the sealed payload is what is frozen, not the displayed text), tables outside the core ledger, or duplicate and mirror ledgers, which carry their own guards.
• It proves sealed records were not rewritten. It says nothing about whether what an entry records was true when it was written.
• The code-path census counts SQL write statements in the shipped sources, rechecked by the test suite on every run; the audit module's own mutation probes are excluded from the count, listed as probes, and pinned separately by the suite. It is a census of the source, not a proof about machine code.

Check it yourself

• The specification, with its hash: https://www.a2ally.com/v1/ledger/spec
• The audit, computed live: https://www.a2ally.com/v1/ledger/audit
• The chain, recomputed end to end: https://www.a2ally.com/v1/ledger/verify
• Keep your own copy: the one-command mirror kit at https://www.a2ally.com/cli/mirror.mjs verifies the record — chain and Bitcoin anchors included — without trusting this site.
• The witness kit and the daily signed snapshots are linked from https://www.a2ally.com/ledger.