Diagnostic premise: Today’s append-only trust chains rest on two assumptions that fail at interplanetary scale — that anchoring authorities are reachable in seconds, and that the signatures binding the chain to those authorities resist all foreseeable cryptanalysis. The first breaks during a 14-light-minute Earth-Mars round trip; the second breaks the day a cryptanalytically relevant quantum computer (CRQC) recovers an ECDSA private key from its public key. QTC is the minimal extension of an existing CoC-style chain that survives both failures simultaneously.
QTC specifies a quantum-resistant, delay-tolerant extension to an append-only hash chain protocol of the Chain of Consciousness (CoC) family [1]. It defines:
Existing append-only chain implementations (CoC reference [1], InALign, MAIF [10], Certificate Transparency [11], Sigstore [12]) share three architectural assumptions inherited from terrestrial deployment:
timestamp field is wall-clock UTC, implicitly assuming all writers share an Earth-bound reference frame at sub-second precision.A Mars-resident agent cannot satisfy any of these. One-way light time (OWLT) ranges from 3.03 minutes at perihelic opposition to 22.28 minutes at superior conjunction [14], with a hard 8-23 day blackout every 26 months when the Sun blocks the line of sight [15]. The Mars surface clock runs +477.60 ± 226.80 µs/day faster than Earth surface clock due to gravitational and orbital effects [16]. A chain entry written at T = 2030-04-12 14:00:00 UTC on Mars cannot be anchored on Earth within Bitcoin’s 10-minute settlement window during a conjunction blackout, and the ECDSA signature attesting it will be forgeable once a CRQC arrives — estimated 2030-2035 by NIST [17] and independent expert analysis [18].
QTC is the minimal change to the chain primitive that survives all three constraints without abandoning the public, externally auditable property that makes the chain useful in the first place.
The cryptographic primitives are not novel — ML-DSA, SLH-DSA, HLC, and DTN Bundle Protocol are all pre-existing standards. The DTN store-and-forward model has been operational on the International Space Station since 2016 [19].
The novelty is the integration constraint: prior post-quantum chain proposals (Sigstore PQC [12], BIP-360 [7], MAIF [10]) target terrestrial deployment where the signing-to-anchoring latency is bounded by network round-trip. Prior interplanetary protocol work (NASA’s IETF TIPTOP architecture [20], CCSDS Proximity-1 [21]) targets data delivery, not cryptographic provenance with long-term integrity. QTC integrates them — and surfaces a specific class of failures (split-brain chain extension during multi-week blackout, signature size amplifying bandwidth pressure on already-constrained relay budgets, time-dilation drift accumulating across multi-year missions) that neither line of work alone has addressed.
This document specifies the integration with enough rigor for a reference implementation to be built and a formal model to be checked.
QTC defends against three adversary classes simultaneously, because at interplanetary scale all three are plausibly present in the same operational window.
| Adversary | Capability | Asymmetry leveraged |
|---|---|---|
| A1 — Harvest-Now-Decrypt-Later (HNDL) | Passive interception of all chain entries and anchor transactions broadcast on public networks today; CRQC available 2030-2040 [13][13a] | Stores ciphertext/signatures cheaply ($5.25/TB on LTO-9 [22]); applies Shor’s to ECDSA anchors retroactively |
| A2 — Compromised Relay | Active control of one or more space-segment relay nodes (orbiter, lunar gateway, Mars relay) | Can drop, reorder, duplicate, or selectively delay bundles; cannot forge signatures without keys |
| A3 — Split-Brain Originator | Legitimate writer that loses connectivity during conjunction and continues extending the chain locally | Produces a fork branching at the last pre-blackout entry; benign by intent but indistinguishable from malicious fork without merge protocol |
QTC must satisfy its security properties under any union A1 ∪ A2 ∪ A3 of these adversaries. The split-brain originator is included in the threat model — even though benign — because the chain protocol must reach a deterministic resolution when reconciliation occurs, and an attacker can exploit ambiguity in that resolution to legitimize a malicious fork.
Mosca’s inequality [23] expresses migration urgency as X + Y > Z, where:
For a chain expected to remain verifiable for 25 years that takes 5 years to migrate, with mid-range CRQC estimate Z = 10 years: X + Y = 30 > Z = 10, so migration was already overdue at the moment any ECDSA-anchored entry was created. This is the operational urgency driving Section 8’s roadmap.
CRQC capability projections (consensus range as of April 2026):
| Source | Estimated CRQC arrival | Confidence |
|---|---|---|
| NSA CNSA 2.0 mandate [24] | Quantum-resistant required by 2031 for all NSS | Policy deadline |
| NIST IR 8547 [25] | RSA/ECC deprecated 2030, disallowed 2035 | Standards body |
| Mosca-Piani survey, 37 experts [23] | ~50% probability within 15 years of 2023 | Academic survey |
| Independent expert assessment [18] | 2029 recommended migration deadline | Expert opinion |
| Gidney & Ekerå [26] | 2048-bit RSA in 8 hours with 20M noisy qubits | Lower-bound feasibility |
| Google Quantum AI, March 2026 [27] | ECDSA secp256k1: <500K physical qubits, minutes | Most aggressive recent estimate |
The protocol assumes Z lies somewhere in 2030-2040 and treats the lower bound as the planning deadline.
QTC adopts a quantum extension of the Dolev-Yao symbolic adversary [28], following the Quantum Random Oracle Model formalism used in NIST’s PQC analyses [9][29][29a]. The adversary may:
The adversary is resource-bounded but quantum-capable. Honest parties are classical (resource-bounded probabilistic Turing machines) — QTC does not assume defenders have quantum hardware.
Several adversary capabilities are attenuated by physical distance and limited contact windows; the protocol exploits these attenuations.
| Capability | Earth network | Mars network | Why |
|---|---|---|---|
| Passive interception of all messages | Easy (fiber tap, ISP cooperation) | Very hard | Mars uplink/downlink is point-to-point at DSN/MTN, narrow beam, physical access required |
| Active man-in-the-middle | Easy (BGP hijack, router compromise) | Hard | All Mars relays are state-operated and cryptographically authenticated [21] |
| Storage of harvested data | $5.25/TB on tape [22] | Same costs apply if attacker has Earth presence | HNDL data flows back to Earth |
| Real-time forgery during transmission | Possible | Impossible | OWLT > 3 min means attacker cannot produce and inject alternative signatures within the same contact window without prior compute |
| Sustained partition of victim | Difficult (multi-path Internet) | Already-occurring (conjunction blackouts) | Attacker can exploit existing partition windows but cannot easily extend them |
The implication for protocol design: integrity guarantees against A2 (compromised relay) can lean on the fact that, when multiple independent relay paths are available, even a hostile relay cannot in practice forge an ML-DSA signature within the brief window before honest Earth-side verifiers see the same bundle on a different relay path. When only a single relay path exists (plausible for early Mars missions), this attenuation does not apply; see §7.5 #2.
QTC does not address:
QTC uses a dual hash stack to protect against an unforeseen weakness in either Keccak (SHA-3 family) or Merkle-Damgård (SHA-2 family).
| Layer | Primary | Alternate | Reason |
|---|---|---|---|
Chain link H(prev_entry ‖ payload) | SHA-256 | SHA-3-256 (post-2030) | SHA-256 retains 128-bit Grover-bounded post-quantum security [13b]; alternate offered for Keccak-only deployments |
| Merkle inclusion proofs | SHA-256 | SHA-3-256 | Same as above |
| Bulk content hashing (high-throughput entries) | BLAKE3 | SHA-256 | BLAKE3 is ~10× faster than SHA-256 on commodity CPUs; output truncated to 256 bits matches chain hash size |
| Internal hash within SLH-DSA signatures | Per FIPS 205 parameter set [3] | — | SLH-DSA-SHA2-128s and SLH-DSA-SHAKE-128s both standardized |
Rationale for keeping SHA-256: Grover’s algorithm provides at most 2128 quantum security on SHA-256 preimage. Concrete cost analysis (ArXiv 2202.10982 [31], ArXiv 2512.14759 [32]) places quantum preimage attacks on SHA-256 between 43 days and 2,365 years on hypothetical machines requiring 3.2M+ physical qubits. The chain link primitive is not the urgent vulnerability; the signature primitive binding it to external authority is.
Wire format for hash values: Big-endian byte ordering. SHA-256 outputs are exactly 32 bytes; SHA-3-256 outputs are also 32 bytes; BLAKE3 truncated outputs are 32 bytes. Algorithm identifier is carried in a 1-byte hash_algo_id field within the entry envelope (see §3.5).
| Role | Primary | Backup | Size (sig+pk) | Status |
|---|---|---|---|---|
| Per-entry chain signature | ML-DSA-65 (FIPS 204, Level 3) | SLH-DSA-128s (FIPS 205, Level 1, hash-only) | ML-DSA-65: 5,261 B [2] · SLH-DSA-128s: 7,888 B [3] | Final since Aug 2024 |
| Anchor transaction signature | ML-DSA-65 | SLH-DSA-128s | Same as above | Same |
| Long-horizon checkpoint (every 1,024 entries) | SLH-DSA-128s | — | 7,888 B amortized over 1,024 entries = 7.7 B/entry | Hash-only hedge |
| Compact-signature use (bandwidth critical) | FN-DSA-512 (FIPS 206, draft) [33] | ML-DSA-44 (Level 2 — security downgrade from Level 3; see note) | FN-DSA-512: 1,563 B · ML-DSA-44: 3,732 B | FN-DSA pending finalization |
| Composite hybrid (transition phase only) | ECDSA-secp256k1 + ML-DSA-65 | — | ~73 + 5,261 ≈ 5,334 B | IETF draft-ietf-lamps-pq-composite-sigs [34] |
ML-DSA-44 security level note: ML-DSA-44 provides NIST Security Level 2, while the rest of QTC targets Level 3 (ML-DSA-65). Using ML-DSA-44 as a bandwidth fallback reduces the security level. For bandwidth-constrained outer-solar-system deployments (§6.4), FN-DSA-512 is preferred over ML-DSA-44 because it provides smaller signatures without the security level downgrade.
ML-DSA-65 is selected as primary because: (a) it is the highest-confidence finalized PQC signature standard, (b) its verification time of ~0.12 ms on x86-64 [2] is competitive with classical alternatives, and (c) the Fiat-Shamir with Aborts construction underlying ML-DSA has a mechanized security proof in the ROM (Random Oracle Model) via EasyCrypt [35]. A QROM proof for ML-DSA in EasyCrypt does not currently exist in published literature; the ASIACRYPT 2024 EasyCrypt verification covers SLH-DSA [35a], not ML-DSA. SLH-DSA-128s is selected as backup because its security rests entirely on hash function preimage and collision resistance — the same primitive the chain itself uses — providing a hash-only failsafe if a structural lattice vulnerability is discovered.
Critical sizing note on cross-section consistency: FIPS 204 [2] specifies ML-DSA-65 signature size as 3,309 B and public key 1,952 B (sum 5,261 B). Some earlier informal sources cite 3,293 B for ML-DSA-65 signatures; this discrepancy traces to different counts of an optional ID prefix. QTC normatively uses the FIPS 204 canonical value of 3,309 B [V], confirmed against the Open Quantum Safe liboqs implementation and multiple independent references.
QTC multi-anchors every chain checkpoint to three independent target classes, with weights corresponding to their long-term integrity guarantees.
| Anchor target | Mechanism | PQC migration path | Weight |
|---|---|---|---|
| Bitcoin via OpenTimestamps [36] | SHA-256 commitment in OP_RETURN; settles in ~1-2 hours | BIP-360 P2MR adoption (merged into BIP repo, testnet-implemented [7]) replaces ECDSA spending with hash-based Merkle script paths; mainnet activation uncertain | High |
| Ethereum L2 (PQC-capable) | EIP-7503-class precompile for ML-DSA verification on rollup; settles in seconds-to-minutes | Native ML-DSA support; on-chain verification gas dominated by ML-DSA-44 (cheapest) [37] | Medium |
| PQ RFC 3161 TSA [8] | TSA signs token with ML-DSA-65; settles in seconds | Already PQC if TSA migrated | Medium |
A single chain checkpoint commits its Merkle root to all three anchor classes in parallel. Verification accepts the chain as anchored if at least two of three independent anchor proofs validate. This thresholding tolerates the loss of any single anchor authority without requiring re-anchoring.
Why not single-anchor to PQ-Bitcoin alone? BIP-360 has been merged into the official BIP repository and implemented on testnet (BTQ Technologies, March 2026 [7]), but mainnet activation timeline is uncertain. BIP-361 (the freeze proposal for quantum-vulnerable addresses [38]) is contested. A multi-anchor strategy hedges Bitcoin governance risk.
Chain entries are batched into Merkle trees of size 2k (k ≤ 20, typical k = 10 for batches of 1,024 entries). Tree construction follows RFC 6962/9162 conventions [11][39] with the following modifications:
H(0x00 ‖ entry_canonical_form)H(0x01 ‖ left ‖ right)hash_algo_id (default SHA-256)H(0x00 ‖ "EMPTY") (distinct from real zero-content entries)Selective verification proofs over a subset S of leaves are encoded as a multi-proof per [40], compressing shared internal hashes to ~2.9× over independent inclusion proofs for |S| = 128.
Wire format for canonical entry form: CBOR (RFC 8949) [41] with deterministic encoding (RFC 8949 §4.2.1). All map keys sorted lexicographically by their CBOR-encoded byte string. Integers use shortest encoding. This eliminates ambiguity in the hash input.
QTCEntry := CBOR_canonical({
"v": uint, // QTC protocol version, currently 1
"prev": bstr .size 32, // hash of previous entry's canonical form
"seq": uint, // monotonic sequence number per chain
"did": tstr, // W3C DID of the writing entity [42]
"hlc": bstr .size 8, // packed Hybrid Logical Clock (see §5.2)
"frame": tstr, // time-frame identifier ("UTC", "MTC", "LTC", etc., §5.4)
"hash_algo": uint, // 0=SHA-256, 1=SHA-3-256, 2=BLAKE3-256
"payload": any, // event-type-specific payload (CoC Layer 1/2 [1])
"sigs": [
{"alg": uint, "pk_id": bstr, "sig": bstr}, // ML-DSA-65 mandatory
{"alg": uint, "pk_id": bstr, "sig": bstr}, // ECDSA legacy (transition only)
]
})Algorithm identifiers in sigs[].alg follow IANA COSE registry [43]: ML-DSA-65 = TBD-by-IANA; ECDSA P-256 = -7; SLH-DSA-SHA2-128s = TBD-by-IANA. Until IANA assigns ML-DSA codepoints, QTC uses the values from draft-ietf-cose-dilithium [44] in private-use range.
Every entry MUST carry an ML-DSA-65 signature once the writer’s chain has migrated past Phase 2 (§8). During Phase 2 (composite/dual phase), entries carry both classical and PQC signatures; verification accepts if either is valid initially, and tightens to PQC-required after a per-chain migration timestamp recorded on the chain itself.
A conventional CoC chain assumes synchronous reachability of anchor authorities. QTC relaxes this to a two-mode operation per writer.
| Mode | Trigger | Operations permitted | Trust tier |
|---|---|---|---|
| Connected | OWLT < 10 min and no scheduled blackout in next ~contact window | All standard CoC operations including immediate anchoring | Tier A — full external verification |
| Connected-Degraded | OWLT 10–30 min; relay path available but elevated latency affects anchor settlement and verification round-trips | All Connected operations permitted; anchor settlement latency extends to 20–62 min; sparse verification preferred over full replay to conserve bandwidth budget | Tier A-minus — full external verification with elevated latency |
| Local-Only | OWLT > 30 min, conjunction blackout in progress, or relay path unavailable | Append entries, sign with on-board keys, queue anchor commitments for later transmission | Tier B — local integrity, deferred external verification |
The transition between modes is governed by an explicit MODE_TRANSITION event written into the chain itself (CoC Layer 1 Event Type extension), so a verifier reading the chain post-hoc can identify exactly which entries were written under which guarantees. Transitions between Connected and Connected-Degraded are triggered by measured OWLT crossing the 10-minute threshold; transitions to Local-Only are triggered by OWLT exceeding 30 minutes or relay path loss.
QTC entries traverse the network as DTN Bundle Protocol v7 bundles (RFC 9171 [4]) with the following profile:
A bundle carries one or more chain entries plus their Merkle inclusion proofs against a Merkle root that the originator commits to anchor when next connected.
During a Local-Only mode interval, the chain extends with entries that lack external anchoring. The writer’s own ML-DSA-65 signature and the SHA-256 chain link still provide:
The chain does NOT prove during this interval:
Each Local-Only entry contributes a leaf hash to a Merkle tree maintained locally. When the writer next establishes a relay contact, it transmits:
ANCHOR_COMMIT(Merkle_root, sequence_range, hlc_range, target_set) signed with ML-DSA-65, where target_set lists the three anchor authorities (Bitcoin, L2, TSA).Merkle_root and return inclusion proofs.The anchor commitment is itself an entry in the chain (CoC event type ANCHOR_COMMIT), so once the chain reaches Earth-side verifiers they can detect any anchor that was committed-but-not-fulfilled and flag the corresponding sequence range as “claim-only.”
Bitcoin anchor settlement latency under Mars relay constraints: 13–30+ minutes minimum (3 hops × 250 bytes per OpenTimestamps commitment, mixed Mars-relay rates [47]) plus Bitcoin’s ~10-minute block time, totaling roughly 25–40 minutes from Mars uplink to first-confirmation.
Two writers (or one writer across two relay paths) may legitimately produce divergent chain extensions during a blackout. QTC treats each chain as a state-based grow-only set CRDT (G-Set) [48] over (entry_hash, prev_hash) edges, forming a directed acyclic graph (DAG) — specifically a Merkle-CRDT [49] with HLC for causal ordering.
Merge function: Given two chain DAGs G₁ and G₂ with common ancestor at sequence seq_fork, the merged chain is G₁ ∪ G₂ with all edges retained and a MERGE event appended pointing to both heads. The merge is commutative, associative, and idempotent by construction (G-Set property).
Choosing a canonical linear order on merged DAG: This is the operationally hard part. QTC defines a deterministic linearization rule:
did lexicographic order.prev), it is treated as a hostile fork and resolved per the existing CoC FORK-event mechanism [1, §3.10.3] — the hostile branch is documented but not considered authoritative.The Byzantine-tolerant CRDT extension of Kleppmann (2022) [50] is incorporated by reference: the Blocklace equivocation detection [51] is applied to detect a writer that has signed two contradictory entries at the same sequence number on different forks. Detection produces evidence that is itself a chain entry (CoC event type EQUIVOCATION_DETECTED), removing trust in the equivocating writer’s future entries.
For verifiers operating under deep-space bandwidth budgets (e.g., a Mars-resident agent verifying an Earth-resident agent’s chain over a 6 Mbit/day MRO-relay budget), full chain replay is infeasible — at ML-DSA-65 entry size of ~5 KB and chain length of 10⁶ entries, full replay requires 5 GB of bandwidth.
QTC provides three verification levels:
| Level | Bandwidth cost | Guarantee | Use case |
|---|---|---|---|
| Full replay | O(N × entry_size) | Verifies every entry | High-stakes audits during low-latency window |
| Anchor-only | O(K) for K anchors, ~2 KB each | Verifies chain integrity at K commitment points | Ongoing trust maintenance |
| Sparse-sample selective | O(M × log N) for M sampled entries with Merkle paths | Probabilistic — detects forgery with probability ≥ 1 − (1 − f)M for forgery rate f | Routine health-check |
The sparse-sample mode is the inter-planetary default. The verifier requests M random leaf indices via DTN bundle, the prover responds with the M leaves plus Merkle inclusion paths plus the corresponding ML-DSA-65 signatures over each leaf’s canonical form. The forgery-detection bound follows directly from random sampling without replacement: the verifier can name the forgery rate it tolerates and compute M to achieve a given confidence.
This is the practical engineering equivalent of a Nyquist-style sampling argument applied to trust verification. The current spec uses straightforward random sampling rather than full bandlimited-signal reconstruction; more sophisticated trust-bandwidth models — adapting the Nyquist-Shannon sampling theorem to formally bounded adversary models — remain an open research question (§9.3).
A chain entry needs to express three distinct time concepts:
Lamport clocks address #1 alone; wall-clock UTC addresses #2 and #3 jointly under the implicit assumption that all writers share a frame. QTC separates them.
QTC adopts the Kulkarni-Demirbas Hybrid Logical Clock [6] for causal ordering, packed into 8 bytes per entry:
| Bits | Field | Range |
|---|---|---|
| 48 (high) | l — physical time approximation, ms since epoch (UTC) | ~8,900 years from 1970 |
| 16 (low) | c — logical counter | 0–65,535 |
The HLC algorithm proceeds as in [6]:
On local event at node j:
l_prev = l.j
l.j = max(l.j, pt.j)
if l.j == l_prev: c.j += 1 else: c.j = 0
On receive of (l.m, c.m) at node j:
l_prev = l.j
l.j = max(l.j, l.m, pt.j)
if l.j == l_prev == l.m: c.j = max(c.j, c.m) + 1
elif l.j == l_prev: c.j += 1
elif l.j == l.m: c.j = c.m + 1
else: c.j = 0HLC under interplanetary delay: The algorithm’s correctness (causal ordering preserved) is independent of message latency [6]. What degrades is the tightness of the l - pt ≤ ε bound. On Earth-Mars at conjunction, ε grows to tens of seconds at minimum (since the receiver cannot have observed events from the sender’s last 22 minutes). At ε = 60 seconds, the 16-bit counter accommodates roughly 1,000 nodes × 60 events/sec sustained — adequate for typical operational deployments but a constraint to monitor.
Adaptation for interplanetary use: QTC uses the standard 48/16 split for terrestrial deployments. For deep-space deployments where ε exceeds ~10 seconds, implementations MAY use a 52/12 split (52 bits for l allowing microsecond resolution, 12 bits for c accommodating up to 4,096 collisions per microsecond). The choice is recorded in a chain bootstrap event so downstream verifiers can decode correctly.
A Mars-resident writer cannot use GPS [52]. Acceptable physical clock sources, in order of preference:
| Source | Stability | Holdover | Comment |
|---|---|---|---|
| Deep Space Atomic Clock (DSAC) [53] | <4 ns/20 days | ~250 days projected | Demonstrated on Earth-orbit testbed; flight-proven candidate |
| Chip-Scale Atomic Clock (CSAC) | 10−11 @ 1 day | ~1 month at acceptable accuracy | Commercial off-the-shelf, ~35 g, ~115 mW |
| Oven-controlled crystal oscillator (OCXO/USO) | 2×10−13 @ 1 s | ~1 hour to 1 µs drift | Lowest-end acceptable for short missions |
| X-ray pulsar navigation (XNAV) [54] | ~7 km position accuracy over 2 days | Indefinite | Independent of any spacecraft clock; available everywhere |
The protocol does not mandate a specific clock; it mandates that the writer record (a) the clock source identifier as a bootstrap event, (b) the last GPS/DSN sync time and offset, and (c) the holdover model parameters. A verifier can then compute the writer’s plausible time uncertainty at any given chain position.
The frame field in the entry envelope (§3.5) names the writer’s time reference frame. Standardized values:
| Frame ID | Meaning | Drift vs Earth surface UTC |
|---|---|---|
UTC | Earth surface UTC | 0 (definitional) |
TAI | International Atomic Time | leap-second offset only (~37 s as of 2026) |
LTC | Coordinated Lunar Time per White House April 2024 directive [55] | +56.02 µs/day [16] |
MTC | Mars Coordinated Time (proposed, no formal standard yet) | +477.60 ± 226.80 µs/day [16] |
TDB | Barycentric Dynamical Time | reference for solar-system-wide timing |
The frame value affects neither HLC computation nor Merkle hashing — it is metadata for downstream interpretation. A verifier reconciling a Mars-frame entry against an Earth-frame entry applies the relativistic correction from [16] to bring both into a common frame for human-readable output, but the cryptographic chain itself is frame-agnostic.
For deployments where the primary anchor authorities are temporarily unreachable, QTC allows entries to include environmental witness fields — observable values that should correlate across all writers operating in overlapping time windows.
Candidate witness fields:
Two chains with overlapping witness windows can be cross-dated against each other: if both record the same Bitcoin block hash at HLC values within their respective ε-bounds, this provides supplementary evidence of temporal overlap independent of any authority. The technique adapts dendrochronological cross-dating methods [56] to operational logs; statistical strength scales with the number and entropy of independent witness signals.
This is a supplementary mechanism, not a primary one. It does not replace anchor authorities — it supplements them in regimes where anchor latency exceeds operational tolerance, and provides a tamper-evidence layer that is hard to forge without simultaneously controlling all the witness signals an attacker would need to fake.
Formal status: Cross-dating is informational and is not guaranteed by QTC’s formal security properties P1–P8. It provides supplementary evidence in low-anchor regimes but does not carry cryptographic assurance. Future revisions may formalize this as a property (see §9.6 Q14).
This section walks through how QTC behaves in four representative deployment regimes, with concrete numbers for each.
Profile: Lunar surface or orbital writer; Lunar Pathfinder [57] (Nov 2026) or ESA Moonlight constellation [58] (2028 maiden) provides relay; OWLT 1.28 s; LunaNet [59] dual-stack DTN+IP.
Operating mode: Always Connected. OWLT is below the 30 min threshold; even a five-hop DTN traversal completes in under a minute.
Anchor settlement: Standard. Bitcoin OpenTimestamps anchor settles in ~1-2 hours (essentially limited by Bitcoin block time, not Earth-Moon delay).
Time frame: LTC per [55]. Drift correction +56.02 µs/day vs UTC applied at human-readable layer.
Key constraint: None protocol-level. This regime is essentially a long-RTT terrestrial deployment. It functions as the stepping-stone deployment to validate QTC before extending to Mars distances.
Profile: Mars surface writer; relay via Mars Reconnaissance Orbiter (MRO), MAVEN, TGO, or 2028 Mars Telecommunications Network orbiter [60]; OWLT 3.03–22.28 min; daily downlink budget aggregated across constellation ~3.08 Gbit/day [47].
Operating modes: Connected during ~4-5 months of each 26-month synodic cycle (OWLT < 10 min); Connected-Degraded during the other ~17-21 months (OWLT 10-22 min, varies by orbital geometry); Local-Only during 8-23 day conjunction blackouts every 26 months.
Anchor settlement:
Bandwidth budget for chain replication: A chain growing at 100 entries/day with ML-DSA-65 signatures consumes 100 × 5,261 B ≈ 526 KB/day, or ~4.21 Mbit/day — about 0.14% of Mars constellation aggregate downlink. Full chain replication is bandwidth-feasible at typical chain rates.
Bandwidth budget for sparse verification: Earth-side verifier requesting M = 100 random leaf samples with Merkle proofs over a 10⁶-entry chain consumes ~100 × (5,261 + 32 × log₂(10⁶)) ≈ 590 KB per audit cycle, well within deep-space budgets.
Key constraint: Conjunction blackout. The protocol must reach Local-Only mode gracefully and reconcile via §4.5 merge protocol post-blackout. This is the deployment regime where QTC’s novelty matters most.
Profile: Constellation of LEO satellites (Starlink-class) acting as both writers and relays; intra-constellation latency 2-20 ms via inter-satellite laser links; ground-link latency 20-100 ms with handoffs every ~5 min as satellites pass over ground stations.
Operating mode: Always Connected. Latency is terrestrial-comparable; handoffs are frequent but covered by DTN’s Convergence Layer Adapter abstraction.
Anchor settlement: Standard. Hub-and-spoke or full-mesh routing both work.
Key constraint: Different from Mars — here the issue is frequency of contact-window changes (every minute or two) rather than duration of partition. The Contact Graph Routing [61] algorithm pre-computes routes through the time-varying topology so each bundle knows its forwarding plan in advance.
This regime is the secondary validation case — proves the protocol scales DOWN to high-velocity terrestrial-adjacent deployment, not just UP to deep space.
Profile: Outer-solar-system probe; OWLT 33-52 min (Jupiter), 68-84 min (Saturn), 24+ hours (Voyager 1 in 2026 [62]); contact via DSN 70-meter dishes only; bit rates 0.1-1 kbps for Voyager class.
Operating mode: Predominantly Connected at the hours-to-days timescale, but never fast. Conjunction analogues exist but are less periodic.
Anchor settlement: Hours to days. The protocol is functional but the latency dominates user experience to such a degree that human operators treat each chain commitment as essentially asynchronous batch processing.
Bandwidth budget: At 1 kbps, a single ML-DSA-65 signature transmission takes ~26.5 seconds (3,309 B sig at 125 B/s); the full sig+pk envelope is ~42 seconds. Chain growth must be limited to a few entries per day, and even sparse verification is expensive (each leaf-with-proof takes minutes).
Key constraint: FN-DSA-512 [33] (when finalized as FIPS 206) reduces signature size to ~666 B, cutting per-signature transmission time by ~5× (3,309 / 666 ≈ 5.0). QTC recommends FN-DSA-512 over ML-DSA-65 for outer-solar-system deployments once FIPS 206 is finalized.
This regime is the stress test — establishes that the protocol does not break entirely under extreme delay, even if usability degrades.
| Scenario | OWLT | Operating mode | Daily bandwidth budget | Anchor settlement | Recommended primary signature |
|---|---|---|---|---|---|
| Earth-Moon | 1.3 s | Connected | 100+ Mbps available | 1-2 hr (Bitcoin block) | ML-DSA-65 |
| Earth-Mars (opposition) | 3-10 min | Connected / Connected-Degraded | ~3 Gbit/day | 13-32 min | ML-DSA-65 |
| Earth-Mars (conjunction) | partition | Local-Only → reconcile | 0 during blackout | Deferred 8-23 days | ML-DSA-65 |
| LEO mesh | 2-100 ms | Connected | unlimited per local link | seconds-to-minutes | ML-DSA-65 |
| Outer planets | 33+ min | Connected (slow) | <1 kbps | hours-to-days | FN-DSA-512 (post-FIPS 206) |
QTC must satisfy eight invariants. Each is stated informally, then formalized in standard security-game notation appropriate to the property.
P1 — Chain Integrity (Append-Only Hash Chain).
Informal: No party can modify any past chain entry without breaking the hash chain.
Formal: For chain C = (e₀, e₁, …, eₙ), ∀i < n : H(canonical(eᵢ)) = eᵢ₊₁.prev. An attacker producing a chain C' differing from C at any position i must produce a hash collision in the chain link primitive. Reduction: any successful attack yields a SHA-256 (or chain-link hash function) collision.
P2 — Append-Only.
Informal: Once an entry is reachable from a published anchor, it cannot be removed from the chain.
Formal: If eᵢ appears as a leaf in a Merkle tree whose root has been anchored at any of the three target authorities (§3.3), and at least two of those anchor proofs validate, then any verifier observing those anchors will see eᵢ in the chain.
Note: This property applies post-anchoring. During Local-Only mode (§4.1), entries are append-only locally (P1) but lack external tamper-evidence until anchored. See P6.
P3 — Attestation Unforgeability.
Informal: No party except the legitimate writer can produce a chain entry that validates under the writer’s DID.
Formal: For a writer with ML-DSA-65 keypair (sk, pk), an adversary without sk succeeds at producing a valid entry e* with signature verifying under pk only with probability negligible in the security parameter, under the SUF-CMA security of ML-DSA-65 in the QROM [29a][35].
P4 — Relay Integrity.
Informal: A compromised relay cannot cause Earth-side verifiers to accept a forged entry.
Formal: A relay R that does not possess writer keys cannot produce a bundle whose contained chain entries pass §3.5 verification at the destination. Relay actions limited to: drop (denial of service, not safety violation), reorder (HLC catches), duplicate (idempotent; duplicate detection trivial), delay.
P5 — Temporal Ordering.
Informal: For any two chain events e_a → e_b (causally), HLC values satisfy hlc(e_a) < hlc(e_b).
Formal: Direct from HLC clock condition [6, Theorem 1]. Holds independently of physical clock synchronization.
P6 — Partition Tolerance.
Informal: If the network partitions during a blackout window, no honest writer is forced to violate any other property to make progress.
Formal: A writer in Local-Only mode (§4.1) can extend the chain locally satisfying P1, P3, P5 without communication. P2 is deferred until reconciliation; the writer marks affected entries as “claim-only” (§4.4) so verifiers know which entries lack external anchoring.
P7 — Forward Security.
Informal: Compromise of a writer’s signing key after time T does not retroactively forge entries written before T.
Formal: Each chain entry is linked by SHA-256 to its predecessor. Even with full key extraction, an attacker cannot produce an alternative e'ᵢ for past i without producing both a SHA-256 collision (for the chain link) and a valid signature under the post-compromise key (which the entry’s anchored Merkle root no longer permits). Anchored Merkle roots commit the entire prior chain to the anchor authority’s tamper-evidence guarantees.
Caveat: Forward security applies to entries whose Merkle roots have been committed to at least two anchor authorities (§3.3). Entries in Local-Only mode (§4.1) that have not yet been anchored do not have this property; they are protected only by the writer’s custody of key material. See §4.3 and §4.4.
P8 — Long-Term Integrity.
Informal: Chains created today must remain verifiable in 2050+ even under CRQC arrival, signature scheme deprecation, and authority migration.
Formal: Achieved by the multi-anchor strategy (§3.3) and the hybrid signature envelope (§3.2). SLH-DSA-128s checkpoints sign the Merkle root covering the preceding 1,024 entries, so every entry in the batch inherits hash-only integrity through its Merkle inclusion proof, even if ML-DSA is later broken. The chain’s Bitcoin anchors retain SHA-256 commitment integrity independently. Ratification by at least two surviving anchor authorities + at least one valid signature scheme suffices.
QTC’s properties are amenable to formal verification using existing tools.
| Tool | Use | Expected effort |
|---|---|---|
| ProVerif [63] | Symbolic verification of P3, P4 (signature/relay properties) | ~2 sessions for protocol formalization in applied-pi calculus, ~1 session for property scripts |
| Tamarin [64] | Symbolic verification of P5 (HLC properties) including equivalence with handcrafted lemmas | ~3 sessions |
| EasyCrypt [65] | Computational proof of P3 in QROM, extending existing ROM proof [35] to quantum setting | ~6 sessions for trained EasyCrypt user; significantly more if proof team is bootstrapping |
| Isabelle/HOL [66] | CRDT merge correctness from §4.5; build on Kleppmann’s existing formalizations [50] | ~4 sessions |
| Jasmin [67] | Constant-time signing implementation correctness | Out of QTC spec scope; defer to FIPS 204/205 implementations |
These are estimates for an adequately resourced verification team familiar with the tools; an introductory team should expect 2-3× longer due to environment setup and tool-language onboarding.
QTC, like every formal trust system, faces a structural limitation: the chain cannot prove its own trustworthiness from within. The chain proves linkage (H(e_{i-1}) = e_i.prev), signature validity, and anchor inclusion. It does not prove that the events recorded in payload actually occurred — only that the writer claimed they occurred and signed the claim.
This is a direct analogue of Gödel’s second incompleteness theorem [68]: a sufficiently powerful self-referential formal system cannot prove its own consistency. A trust protocol can verify everything it can mechanically check; what it cannot verify is its own correspondence to external reality.
The mitigation is not to escape the limit (which is impossible) but to anchor to systems with different and independent assumption bases. Bitcoin’s consensus rests on proof-of-work / energy-expenditure assumptions; a PQ TSA’s authority rests on operational and audit-process assumptions; an Ethereum L2’s validity rests on optimistic/zk-rollup security assumptions. By multi-anchoring (§3.3), QTC borrows consistency from three independent foundations, making compromise of the chain’s integrity require simultaneous compromise across cryptographic, infrastructural, and governance domains. The chain itself is not the trustworthiness; the chain plus its public, externally checkable anchor proofs is.
QTC, like all cryptographic protocols, rests on the conjecture that P ≠ NP, more specifically on the believed hardness of Module-LWE/Module-SIS [29a] and SHA-256 / SHA-3 preimage and collision resistance. None of these have unconditional proofs of hardness; they are the best-supported conjectures the community has, supported by decades of cryptanalytic effort that has not broken them.
If P = NP were proven, QTC and every other practical cryptographic protocol would lose its security foundation. The CRQC threat is narrower and more targeted: Shor’s algorithm breaks specific assumptions (factoring, discrete log) without breaking the broader P ≠ NP conjecture. QTC’s choice of lattice-based and hash-based primitives is a hedge against the known quantum threat, not against an unknown collapse of complexity-theoretic asymmetry.
This is acknowledged here, not concealed. The protocol does not claim provable security; it claims security under standard assumptions that are believed but not proven.
Three known weaknesses in this draft’s threat model:
These are explicitly flagged in §9 as open questions.
QTC rolls out in four phases. Effort estimates are in implementation sessions (one focused implementation cycle); calendar mapping depends on team availability and concurrent work, but at typical development velocity each phase is days-to-weeks of wall-clock time, not months.
| Phase | Goal | Effort | Dependencies | Capability gap |
|---|---|---|---|---|
| 0 — Spec | This document, reviewed and ratified | ~2-3 sessions for review pass | None | Cryptographer review external |
| 1 — PQC Hash Migration | Add ML-DSA-65 signing path alongside existing classical signing | ~3 sessions | Phase 0 ratified; FIPS 204 library available (e.g., liboqs [69], pq-crystals [70]) | None — well-trodden territory |
| 2 — Hybrid Anchoring | Multi-anchor across Bitcoin OpenTimestamps + PQ TSA + L2; composite signatures during transition | ~4-6 sessions | Phase 1 deployed; PQ TSA service operational; L2 PQ verification precompile | |
| 3 — DTN Integration | Bundle Protocol v7 transport with BPSec; CRDT merge for split-brain | ~6-8 sessions | Phase 2 stable; ION [71] or equivalent DTN library integration; CRDT formal verification using Isabelle/HOL [50] | |
| 4 — Full Interplanetary | Field deployment to Earth-Moon stepping-stone; Mars deployment when relay constellation ready | ~10-15 sessions plus mission-window operations | Phases 1-3 operational; partner mission opportunity (Lunar Pathfinder, Moonlight, MTN); flight-grade constant-time implementation |
Each phase exits when its acceptance tests pass.
Phase 1 — PQC Hash Migration acceptance:
Phase 2 — Hybrid Anchoring acceptance:
Phase 3 — DTN Integration acceptance:
Phase 4 — Full Interplanetary acceptance:
Phase 1 risks:
Phase 2 risks:
Phase 3 risks:
FORK_HOSTILE events for human review.Phase 4 risks:
Before Phase 1 starts, the existing reference chain implementation needs a crypto-agility envelope so signing/hashing primitives can be swapped without changing entry semantics. The envelope (§3.5) already supports multiple signatures and a hash algorithm identifier; the remaining work is the verifier-side dispatcher that selects the validation routine by alg value.
This is roughly 1-2 sessions of additive refactor on the existing chain code and is not gated by any external dependency.
This section catalogues unresolved questions, ranked by priority for resolution. Each is a place where the spec is currently under-determined or where active research is needed before a future revision (v2).
MTC as a placeholder; a future revision needs to either reference a standardized MTC or define one.INCONSISTENT_ANCHORS and defers to manual review; an automatic resolution would be valuable.
[1] Chain of Consciousness whitepaper (CoC Layer 1/Layer 2 specification, Section 3 architecture, Section 6 governance, Section 3.10.3 FORK event mechanism). Public CoC reference implementation: chain_of_consciousness.py. https://vibeagentmaking.com/whitepaper
[2] NIST FIPS 204, “Module-Lattice-Based Digital Signature Standard,” August 2024.
[3] NIST FIPS 205, “Stateless Hash-Based Digital Signature Standard,” August 2024.
[4] IETF RFC 9171, “Bundle Protocol Version 7,” January 2022.
[5] IETF RFC 9172, “Bundle Protocol Security (BPSec),” January 2022.
[6] Kulkarni, Demirbas et al., “Logical Physical Clocks and Consistent Snapshots in Globally Distributed Databases,” 2014.
[7] BIP-360, “Pay-to-Merkle-Root (P2MR),” 2026. https://bip360.org
[8] IETF RFC 3161, “Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP),” August 2001.
[9] Boneh et al., “Random Oracles in a Quantum World,” ASIACRYPT 2011 (Quantum Random Oracle Model).
[10] arXiv:2511.15097, “Multimodal Artifact File Format (MAIF),” 2025.
[11] IETF RFC 9162, “Certificate Transparency Version 2.0,” December 2021.
[12] Sigstore project documentation; PQC migration approaches (Hybrid Rekor, Hybrid X.509, Merkle Tree Certificates).
[13] Federal Reserve Board, “Harvest Now Decrypt Later: Examining Post-Quantum Cryptography and the Data Privacy Risks for Distributed Ledger Networks,” FEDS 2025-093, 2025.
[13a] Shor, P., “Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer,” SIAM J. Comput. 26(5), 1997.
[13b] Bernstein, D.J. and Lange, T., “Post-quantum cryptography,” Nature 549, 2017.
[14] ESA Mars Express Blog, “Time delay between Mars and Earth,” 2012-08-05.
[15] NASA, “Communications with Mars During Periods of Solar Conjunction: Initial Study Results.”
[16] Mars clock-rate computation (+477.60 ± 226.80 µs/day vs Earth surface) derived from the Schwarzschild metric dτ/dt = √(1 − 2GM/rc² − v²/c²) using Mars solar potential, surface gravity, and orbital velocity (e = 0.0934). Methodology cross-referenced against Ashby-Patla framework (December 2025) and NASA technical literature on planetary timekeeping. Moon +56.02 µs/day computed identically; aligned with the White House LTC directive baseline [55].
[17] NIST IR 8547, “Transition to Post-Quantum Cryptography Standards,” initial public draft, November 2024.
[18] Filippo Valsorda, “A Cryptography Engineer’s Perspective on Quantum Computing Timelines,” April 2026.
[19] NASA, “Delay/Disruption Tolerant Networking” (operational status on ISS since 2016).
[20] IETF draft, “An Architecture for IP in Deep Space,” draft-ietf-tiptop-ip-architecture, working group adopted.
[21] CCSDS Proximity-1 Space Link Protocol (390-450 MHz UHF).
[22] arXiv:2603.01091, “On the Practical Feasibility of Harvest-Now, Decrypt-Later Attacks,” 2026.
[23] Mosca, M. and Piani, M., “Quantum Threat Timeline Report”; Mosca’s inequality framing.
[24] NSA/CSS, “Commercial National Security Algorithm Suite 2.0 FAQ,” September 2022.
[25] NIST IR 8547 (same as [17]); deprecation 2030, disallowance 2035.
[26] Gidney, C. and Ekerå, M., “How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qubits,” Quantum 5:433, 2021.
[27] Google Quantum AI, “Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities,” March 2026.
[28] Dolev, D. and Yao, A. C., “On the security of public key protocols,” IEEE Trans. Information Theory, 1983.
[29] NIST FIPS 204 security analysis, “Module-Lattice-Based Digital Signature Standard,” August 2024 (ML-DSA security reductions).
[29a] NIST FIPS 204/205 combined security analysis: Module-LWE/Module-SIS hardness assumptions and SUF-CMA security of ML-DSA-65 in the QROM.
[30] NIST FIPS 203, “Module-Lattice-Based Key-Encapsulation Mechanism Standard,” August 2024.
[31] arXiv:1603.09383 / 2202.10982, “Applying Grover’s Algorithm to Hash Functions: A Software Perspective,” 2022.
[32] arXiv:2512.14759, “Quantum Resource Analysis of Low-Round Keccak/SHA-3 Preimage Attack,” 2025.
[33] NIST CSRC, “FIPS 206: FN-DSA (Falcon)” presentation, R. Perlner, 2025; expected finalization late 2026 / early 2027.
[34] IETF draft-ietf-lamps-pq-composite-sigs (composite hybrid signature standardization).
[35] Barbosa, M., Dupressoir, F., et al., “Fixing and Mechanizing the Security Proof of Fiat-Shamir with Aborts and Dilithium,” CRYPTO 2023 (ROM proof for ML-DSA/Dilithium in EasyCrypt).
[35a] Hülsing, A., Meijers, D., Strub, P.-Y., et al., “Machine-checked security proofs for SLH-DSA,” ASIACRYPT 2024 (SLH-DSA/SPHINCS+ tight security proofs in EasyCrypt).
[35b] Bos, J. et al., “ML-KEM IND-CCA security in EasyCrypt,” CRYPTO 2024.
[36] OpenTimestamps protocol specification (SHA-256 Merkle aggregation to Bitcoin).
[37] Author estimate of Ethereum L2 ML-DSA verification gas costs, derived from FIPS 204 parameter sizes [2] and EVM opcode gas schedules (ECADD: 150 gas, ECMUL: 6,000 gas; ML-DSA verification modeled as lattice arithmetic over Zq with NTT). Not independently published; treat as engineering estimate.
[38] BanklessTimes, “Bitcoin Developers Propose Freezing $74B in Quantum-Vulnerable BTC,” April 2026 (BIP-361).
[39] IETF RFC 6962, “Certificate Transparency,” June 2013.
[40] EIP-1186 / multi-proof Merkle compression methodologies.
[41] IETF RFC 8949, “Concise Binary Object Representation (CBOR),” December 2020.
[42] W3C, “Decentralized Identifiers (DIDs) v1.0,” W3C Recommendation.
[43] IETF RFC 9052, “CBOR Object Signing and Encryption (COSE): Structures and Process,” August 2022; IANA COSE registry.
[44] IETF draft-ietf-cose-dilithium (ML-DSA in COSE).
[45] IETF RFC 5326, “Licklider Transmission Protocol — Specification,” September 2008 (LTPCL convergence layer).
[46] IETF RFC 9000, “QUIC: A UDP-Based Multiplexed and Secure Transport,” May 2021.
[47] Synthesis of NASA Mars Relay Network specifications: Mars Reconnaissance Orbiter, MAVEN, TGO operational data.
[48] Shapiro et al., “Conflict-free Replicated Data Types,” INRIA Tech Report, 2011.
[49] Sanjuán, H. et al., “Merkle-CRDTs: Merkle-DAGs meet CRDTs,” 2020.
[50] Kleppmann, M., “Making CRDTs Byzantine fault-tolerant,” 2022.
[51] Keidar, I. et al., “Cordial Miners: Fast and Efficient Consensus for Every Eventuality,” 2022 (Blocklace equivocation-detection construction for Byzantine-tolerant CRDT extension).
[52] LuGRE experiment, NASA, March 3, 2025: GPS/Galileo signals successfully acquired on lunar surface; this does not extend to Mars distances.
[53] NASA, “Deep Space Atomic Clock (DSAC) — One-year on-orbit performance results.”
[54] NASA, “Station Explorer for X-ray Timing and Navigation Technology (SEXTANT) / NICER — XNAV pulsar navigation.”
[55] White House Office of Science and Technology Policy, “Coordinated Lunar Time (LTC) Directive,” April 2024.
[56] Holmes, R. L., “Computer-Assisted Quality Control in Tree-Ring Dating and Measurement,” Tree-Ring Bulletin, 1983 (COFECHA program).
[57] ESA, “Lunar Pathfinder mission specifications,” scheduled launch November 2026.
[58] ESA Moonlight constellation: 1 communications satellite + 4 navigation satellites, maiden launch 2028.
[59] NASA / ESA, “LunaNet Interoperability Specification” (DTN + IP dual-stack lunar communications framework).
[60] One Big Beautiful Bill Act 2025, $700M Mars Telecommunications Network appropriation; 2028 launch target.
[61] NASA, “Contact Graph Routing for DTN” — predictive routing through scheduled communication contacts.
[62] NASA/JPL, “Voyager 1 — Mission Status” (distance data updated daily at voyager.jpl.nasa.gov). As of April 2026, Voyager 1 is approximately 164.5 AU from the Sun, approaching the one-light-day milestone (~173 AU).
[63] Blanchet, B., “ProVerif: Cryptographic Protocol Verifier in the Formal Model” (symbolic verification tool).
[64] Tamarin Prover, “Symbolic Verification of Cryptographic Protocols with Algebraic Properties.”
[65] Barthe, G. et al., “EasyCrypt: A Tutorial” (computational proof assistant for cryptographic security).
[66] Nipkow, T. et al., “Isabelle/HOL — A Proof Assistant for Higher-Order Logic.”
[67] Almeida, J. B. et al., “Jasmin: High-Assurance and High-Speed Cryptography.”
[68] Gödel, K., “Über formal unentscheidbare Sätze der Principia Mathematica und verwandter Systeme I,” 1931 (incompleteness theorems).
[69] Open Quantum Safe project, “liboqs” (open-source PQC library).
[70] PQ-Crystals reference implementation of ML-KEM and ML-DSA.
[71] NASA, “Interplanetary Overlay Network (ION)” — DTN reference implementation.
[72] IETF RFC 5053, “Raptor Forward Error Correction Scheme.”
[73] arXiv:2603.19340, “Benchmarking NIST-Standardised ML-KEM and ML-DSA on ARM Cortex-M0+,” 2026.
[74] Conduition, “Making SLH-DSA 10x-100x Faster,” 2025.
[75] IACR ePrint 2024/367, “Accelerating SLH-DSA by Two Orders of Magnitude with a Single Hash Unit.”
[76] Lamport, L., “Time, Clocks, and the Ordering of Events in a Distributed System,” CACM 21(7), 1978.
This draft was reviewed against the following criteria before submission. Marked ✓ where verified.
H(x) : The chain link hash function applied to bytes x. Default SHA-256 unless hash_algo_id says otherwise.Sign(sk, m) : Signature of message m under secret key sk; algorithm determined by entry’s sigs[].alg.Verify(pk, m, σ) : Boolean signature verification.e_i.field : Field field of chain entry at sequence i.‖ : Byte concatenation.→ : Causal happens-before relation (Lamport [76]).∥ : Concurrent (causally unrelated).The chain primitive QTC extends is live today.
QTC is a forward-looking extension of the CoC append-only hash chain — the reference implementation cited as [1] throughout this specification. While QTC targets post-quantum, interplanetary deployment, the foundation it builds on — entry signing, hash-chain verification, and external anchoring — is available now as an open-source library and hosted service.
pip install chain-of-consciousness · npm install chain-of-consciousness