Record Integrity Anchors Reference

​

Five-Layer Architecture Summary

​

Protected Record Types

​

Layer 1: Record Hashing

​

Algorithm

​

Canonical Serialization

1. All keys are sorted alphabetically.
2. undefined values are omitted; null values are preserved.
3. The result is JSON-stringified.
4. If the record has a predecessor in the chain, the previous hash is prepended with a colon separator: {previousHash}:{canonicalJSON}.

Input: { technician: "John", type: "inspection", date: "2026-03-15" }
Canonical: {"date":"2026-03-15","technician":"John","type":"inspection"}
With chain: "a1b2c3...previous_hash:{"date":"2026-03-15","technician":"John","type":"inspection"}"

​

Hash Result

interface HashResult {
  hash: string; // Lowercase hex-encoded digest
  algorithm: "sha2-384" | "sha2-256";
}

​

Layer 2: Hash Chain

​

Chain Structure

Record 0 (genesis)        Record 1                 Record 2
┌────────────────────┐    ┌────────────────────┐    ┌────────────────────┐
│ previousHash: null │    │ previousHash: H(0) │    │ previousHash: H(1) │
│ chainSequence: 0   │    │ chainSequence: 1   │    │ chainSequence: 2   │
│ recordHash: H(0)   │    │ recordHash: H(1)   │    │ recordHash: H(2)   │
└────────────────────┘    └────────────────────┘    └────────────────────┘

​

Chain Verification Rules

1. Genesis validity: The first entry (chainSequence: 0) must have previousHash: null.
2. Sequence contiguity: Each entry’s chainSequence must equal previousEntry.chainSequence + 1.
3. Hash linkage: Each entry’s previousHash must equal the preceding entry’s recordHash.

​

Full Verification

1. Verify chain linkage (structure).
2. For each record, re-compute the hash from source data and compare to the stored recordHash.

​

Merkle Tree

• Pairs of hashes are concatenated and hashed to produce parent nodes.
• If a level has an odd number of nodes, the last node is duplicated.
• The root of the tree is a single hash representing all records in the batch.

​

Layer 3: RFC 3161 Trusted Timestamping

​

Protocol

​

TSA Endpoints

​

TimeStampReq Structure

TimeStampReq ::= SEQUENCE {
  version        INTEGER { v1(1) },
  messageImprint SEQUENCE {
    hashAlgorithm  SEQUENCE {
      algorithm      OID (2.16.840.1.101.3.4.2.2 for SHA-384),
      parameters     NULL
    },
    hashedMessage  OCTET STRING (48 bytes for SHA-384)
  },
  certReq        BOOLEAN TRUE
}

​

Token Structure

Time-Stamp Token (CMS SignedData)
├── TSTInfo
│   ├── version
│   ├── policy (TSA's timestamping policy OID)
│   ├── messageImprint
│   │   ├── hashAlgorithm: SHA-384
│   │   └── hashedMessage: <48-byte hash>
│   ├── serialNumber
│   ├── genTime: <UTC timestamp, millisecond precision>
│   ├── nonce
│   └── tsa: <TSA Distinguished Name>
└── SignerInfo (TSA signature over TSTInfo)

​

Verification

openssl ts -verify \
  -in timestamp.tsr \
  -data record_canonical.json \
  -CAfile tsa_ca_chain.pem

​

Layer 4: OpenTimestamps (Bitcoin Anchoring)

​

Protocol

​

Calendar Servers

​

Digest Requirements

​

Proof Lifecycle

1. Submission: Digest bytes are POSTed to /digest on the calendar server.
2. Pending proof: The calendar returns an incomplete proof file containing the calendar commitment. Stored with status pending.
3. Upgrade: A background process polls the calendar server to upgrade pending proofs once the Bitcoin block is confirmed (typically 10—60 minutes).
4. Complete proof: The upgraded proof contains the full Merkle path from the record hash to the Bitcoin block header. Status becomes confirmed.

​

Verification

pip install opentimestamps-client
ots verify record_canonical.json.ots -f record_canonical.json

​

Layer 5: EVM Smart Contract

​

RecordAnchor V1

contract RecordAnchor {
  struct Anchor {
    bytes32 merkleRoot;
    uint256 timestamp;
    address sender;
  }

  mapping(bytes32 => Anchor) public anchors;

  event Anchored(
    bytes32 indexed merkleRoot,
    address indexed sender,
    uint256 timestamp
  );

  function anchor(bytes32 merkleRoot) external {
    anchors[merkleRoot] = Anchor(merkleRoot, block.timestamp, msg.sender);
    emit Anchored(merkleRoot, msg.sender, block.timestamp);
  }

  function getAnchor(bytes32 merkleRoot)
    external view returns (Anchor memory)
  {
    return anchors[merkleRoot];
  }
}

​

UniversalAnchor V2

• Batch anchoring. Anchor hundreds of Merkle roots in a single transaction, dramatically reducing gas costs for high-volume operators.
• Workspace scoping. Each anchor is associated with a workspace identifier, enabling efficient per-operator querying and audit filtering.
• Record-type classification. Anchors carry a record-type tag (e.g., safety_report, work_order, flight_log), enabling domain-specific verification queries.
• Ownable access control. Only authorized addresses can submit anchors, preventing unauthorized writes.
• Pausable emergency stop. The contract owner can pause anchoring in an emergency without redeploying, then resume when the issue is resolved.

​

Gas Cost Comparison

​

Deployed Addresses

​

Transaction Flow

1. Record hashes are batched into a Merkle tree and the root is computed.
2. For V1: the root (padded to bytes32) is submitted as a single anchor call.
3. For V2: one or more roots are submitted in a batch call with workspace and record-type metadata.
4. The transaction is confirmed with 1 block confirmation (60-second timeout).
5. The transaction hash, block number, and gas used are stored alongside the records.

​

Verification

​

Anchor Orchestrator

​

Strategies

​

Result

• The Merkle root that was anchored.
• The hash algorithm used.
• An array of layer results (one per activated layer), each with success/failure status and layer-specific tokens, proofs, or transaction data.
• The anchoredAt timestamp.
• A flag indicating whether every activated layer succeeded.

​

Proof Lifecycle States

​

State Transitions

              ┌──────────┐
  [Record     │          │
   saved]────►│ Pending  │
              │          │
              └─────┬────┘
                    │ anchor accepted
                    ▼
              ┌──────────┐
              │ Anchored │
              └─────┬────┘
                    │ confirmations received
                    ▼
              ┌──────────┐
              │Confirmed │
              └─────┬────┘
                    │ verification service confirms
                    ▼
              ┌──────────┐         ┌─────────┐
              │ Verified │────────►│ Expired │
              └──────────┘  cert   └─────────┘
                            expiry

​

Cross-Layer Verification

​

Proof Bundle Contents

​

Related