Skip to content
Mars® Protocol

§02b Jupiter — Certification & Attestation — ON_CHAIN_ANCHOR — verification-gated distributed-ledger commitment

Mars® Spec › §02b Jupiter — Certification & Attestation › ON_CHAIN_ANCHOR — verification-gated distributed-ledger commitment

← Deployment manifest · Section index · Externally-observable properties →

7. ON_CHAIN_ANCHOR — verification-gated distributed-ledger commitment

The ON_CHAIN_ANCHOR pattern extends the audit chain to an externally-witnessed distributed ledger. Its defining structural property is the verify-then-commit inversion: the procedural-verification gate (§02a §3a battery execution) runs before any ledger commitment occurs. Only a hash of a CERTIFY verdict reaches the ledger. A REFER or REFUSE verdict never commits. This is the structural inversion of the commit-then-audit pattern in which state transitions reach the ledger before verification — a pattern whose failure mode is an immutable record of a non-compliant transition.

What the pattern closes. Standard commit-then-audit tamper-evidence makes whatever was committed immutable. It does not make non-compliant transitions impossible; it makes them immutably recorded. ON_CHAIN_ANCHOR closes this: the ledger accumulates only verified verdicts. The ledger’s immutability is preserved and repurposed — it now attests to compliance rather than to mere occurrence.

7.1 The five structural elements

Element 1 — Proposed state transition. An application layer proposes a state transition — a custody handoff, a transaction, a configuration change, a manifest update, or any other typed state-change — characterized by typed fields including proposing-party identity, target-asset or target-entity identity, transition timestamp, and transition-specific payload fields. The state transition is the input to the verification gate; it does not reach the ledger.

Element 2 — Procedural-verification gate. The proposed state transition is discharged through the §02a battery against the formally-encoded governing specification (§01 §7 five-component bundle, §01 §12.1 governing collection). The discharge runs the required passes per the specification’s soundness declaration. The output is the mechanical tri-state verdict (§02a §3a.2): CERTIFY, REFER, or REFUSE. The gate is the same gate as in every other governed invocation; no separate verification mechanism is introduced.

Element 3 — Chaincode-commitment field on the audit record. The PassRecord (§02a §3a.1) is extended by an optional chaincode_commitment field. When present, this field declares:

chaincode_commitment {
  target_chain_id:            identifier of the distributed ledger
                              (non-limiting: Hyperledger Fabric channel,
                              Ethereum chain id, Cosmos zone id, or any
                              chaincode-or-contract-addressable ledger),
  chaincode_or_contract_address: the chaincode or smart-contract to write to,
  serialization_format:       how the audit record is serialized for the call,
  txid:                       the ledger transaction identifier recorded after
                              commitment — null before commitment, populated
                              after; creates bidirectional linkage between the
                              audit record and the ledger entry
}

The chaincode_commitment field is a declared registered output structure. A PassRecord carrying a chaincode_commitment field with a null txid after a CERTIFY verdict has been issued is structurally incomplete.

Element 4 — Commitment mechanism (conditioned on CERTIFY). If and only if the verdict is CERTIFY, the commitment mechanism executes: the audit-record’s chain hash (SHA256 over the PassRecord content and prior chain hash per §02a §3a.1) is submitted as a write call to the target ledger via the declared chaincode or smart-contract address. Only the hash reaches the ledger — 32 bytes for SHA-256. The state transition’s content, the audit-record’s content, the specification’s content, and the predicate content all remain off-chain. The committed hash is independently verifiable by any party with chain read access: they recompute the hash of the presented audit record and compare against the on-chain value. Upon successful commitment, the ledger transaction identifier (txid) is recorded back into the chaincode_commitment field of the audit record, completing the bidirectional linkage.

Element 5 — Structural orthogonality to internal tamper evidence. The ON_CHAIN_ANCHOR mechanism is structurally orthogonal to the internal hash-chain tamper-evidence of the audit chain (§02a §3a.1: H(n) = SHA256(H(n-1) ‖ payload(n))). Internal tamper-evidence provides cryptographic integrity within the verification system’s boundary — detectable by any party with access to the audit chain. ON_CHAIN_ANCHOR adds an external layer of tamper-evidence by anchoring to a distributed ledger witnessed by a separate party (the ledger operator): a party in possession of the deployment’s private key can tamper with the internal audit chain, but cannot rewrite the ledger’s record of the chain hash. The two mechanisms compose; neither replaces the other. A conforming ON_CHAIN_ANCHOR deployment maintains both.

7.2 Multi-chain abstraction

The target_chain_id and chaincode_or_contract_address fields are parameterized — no specific ledger is required. Non-limiting admitted ledger classes:

Ledger class Addressing mechanism
Hyperledger Fabric Chaincode-addressable per channel
Ethereum / Quorum / EVM-compatible Smart-contract address (EVM)
Cosmos / CosmWasm CosmWasm contract address
Any chaincode-or-contract-addressable distributed ledger Declared address in the commitment field

A multi-chain abstraction layer (unified API for ledger writes) is an admitted embodiment. Where one is used, its identity and version are declared parameters in the chaincode_commitment field.

7.3 DDIL edge-queuing for commitment

Under DDIL conditions (Disconnected, Degraded, Intermittent, or Limited connectivity), the procedural-verification gate continues operating on local cache and local specification. The DDIL-state absoluteness rule (§02a §3a.2) applies without relaxation: a REFUSE verdict under any DDIL state remains REFUSE; no deployment configuration may convert it to REFER for connectivity reasons.

Where the verification verdict is CERTIFY but the target ledger is unreachable, the audit record and its pending chain-hash commitment are queued in a tamper-evident edge log — an append-only structure signed by the edge identity (non-limiting: a Merkle-tree append-only log). The edge log satisfies the same tamper-evidence requirements as the internal audit chain. Upon ledger reconnection:

  1. Queued commitments are submitted to the ledger in causal order — the order in which verdicts were issued — preserving the causal sequence of verified transitions.
  2. The txid returned for each committed hash is recorded back into the corresponding audit record’s chaincode_commitment field.
  3. A reconnection-commitment record is appended to the audit chain declaring the reconnection event, the range of queued records committed, and the ledger positions of the resulting entries.

A CERTIFY verdict whose commitment remains queued in the edge log is not treated as uncommitted for the purposes of downstream consumption — the verdict itself is final; only the external attestation is deferred. The edge log entry is the interim tamper-evident record until ledger commitment completes.

7.4 Non-limiting application classes

The ON_CHAIN_ANCHOR pattern applies to any domain whose governing specification can be encoded as a Mars® formal specification bundle (§01 §7). Non-limiting examples:

  • Pharmaceutical chain-of-custody (DSCSA) — FDA chain-of-custody requirements compiled into the governing specification; a custody handoff proposal is discharged against it; only verified handoffs reach the traceability ledger.
  • Military in-transit visibility (ITV) — logistics doctrine compiled into the governing specification; custody handoff proposals discharged before reaching the ITV ledger.
  • Financial AML/KYC compliance — Bank Secrecy Act / FinCEN rules compiled into the governing specification; transaction proposals discharged before any compliance ledger record is written.
  • Food-safety traceability (FSMA) — cold-chain and traceability requirements compiled into the governing specification; supply-chain events discharged before ledger commitment.

In each case the structural property is identical: the ledger records only what has been verified; the governing specification is the registered, version-stamped artifact against which verification is discharged; and the on-chain record is a hash, not the content.

← Deployment manifest · Section index · Externally-observable properties →