Anchoring and the audit log

Audience: developers · Read route: rebuild · Reflects specification v0.1

Every exchange is anchored to the public audit layer: a shared, append-only, tamper-evident record that no single party controls or can rewrite. Any party may anchor to it directly, and no participant owns it or can gate access to it. That absence of an owner is precisely what lets an anchored proof be verified by anyone and keeps the layer free of network-level lock-in.

Audit trail

The anchor fixes an ordered, chained position for each recorded action. A party's actions form an unbroken chain, so any gap or reordering is detectable rather than silent. This chained, ordered, tamper-evident sequence is the audit trail: not merely a list of what was appended, but a record whose order and completeness are themselves verifiable. The anchor carries a cryptographic commitment to the record's fields, and a proof that a record was anchored as claimed is independently verifiable, requiring no trust in the party that submitted the anchor.

Cross-domain references that carry their own proof

A reference from one domain to a record in another carries its proof with it. A party in domain B, holding a reference and its self-verifiable inclusion proof, can confirm the referenced record without any access to domain A's storage and without contacting the originating party. This is a chained reference with an independently verifiable proof: the point-in-time fact is fixed, and verifying it needs no live connection back to the origin.

One commitment key per action

Each recorded action derives a unique commitment key, so that no two actions collide on the audit layer. The chaining container links each action to the one before it, which is what turns a set of separate anchors into a single ordered chain.

Provisional item PROV-1 (settlement-layer naming and anchoring mechanics), pending technical review. This reference names the settlement layer that the audit layer resolves to only as "the public audit layer". The script-level mechanics that make anchoring interoperable, encrypted field bytes and commitments carried in spendable output data rather than in metadata-only outputs, the chaining container that links each action to the previous one, the self-verifiable inclusion proofs, and the per-action commitment-key derivation, are interop-load-bearing and are fixed by the utxo-chaining and cross-domain-refs test-vector suites named in the specification, Section 6. The naming of the underlying settlement layer, and the framing of the standards citations for these mechanics, are subject to technical review; see the specification, Section 9, PROV-1. A rebuilder verifies against the suites once they are published.

The rules behind this page

The MUST rules for chained ordered anchoring, the per-field commitment, independently verifiable proofs, cross-domain references that carry their proof, and the unique per-action commitment key are in the specification, Section 3.4. This page explains the mechanism behind them.