Network Working Group H. Jorgen Internet-Draft Kenosian Intended status: Experimental 19 September 2026 Expires: 21 February 2027 The TLS TimeToken Secure Protocol (tttps://) draft-helmprotocol-tttps-10 Abstract This document specifies the TLS TimeToken Secure Protocol (tttps://), a protocol extension that augments TLS 1.3 with cryptographically verifiable temporal ordering. TTTPS introduces Proof-of-Time (PoT): a multi-source synthesised timestamp bound to a holder identity and to a live TLS session through an explicit holder-proof construction, verified in constant time independent of network size. Internet infrastructure conventionally assumes ordering-neutral channels. NTP servers, BGP routing authorities, DNS resolvers, and transaction sequencers all have an operational incentive to misrepresent event ordering; this document formalises that condition as the Strategic Channel Controller Problem (SCCP). PoT detects Byzantine time-source manipulation with probability at least 1 minus 2 to the negative 61st power, and an AdaptiveSwitch mechanism makes sustained ordering manipulation economically self-defeating; the equilibrium threshold is derived in closed form and empirically calibrated from deployed auction data. This document has Experimental status. A reference deployment has produced over 70,000 verified records, 55 percent of which were generated by autonomous AI agents. The mandatory-to-implement integrity mode (SHA-256) is completely and publicly specified in Appendix B; the optional GRG integrity mode is specified only through an abstract interface and is not required for conformance. Discussion Note This note is to be removed before publishing as an RFC. This document is being discussed on the dispatch@ietf.org mailing list. Comments and participation are welcome. Changes from -09: * draft-10 integrates the Confidence and Deep-space companion profiles as optional, informative extensions without changing the PoT wire record or core integrity boundary. * Added the seven-layer verification pipeline: PKI admission, physical deduplication, D-chain freshness, unique effective quorum, Byzantine aggregation, optional VN correlation, and read-only Epi-Entropy shadow. * Added admissible density-bundle semantics, epistemic entropy interval, certified purity lower bound, identity ambiguity diameter, AHE bounded holdover, and explicit HOLD/CONSTRAINT_INCONSISTENCY outcomes. * Added conservative claims and evidence boundaries: Epi-Entropy is a read-only shadow analysis; sparse peers do not create a quorum; simulated or offline evidence is not flight validation; universal Sybil prevention is not claimed. Jorgen Expires 21 February 2027 [Page 1] Internet-Draft TTTPS September 2026 * Header: revision -06 -> -07; submissionType corrected from "IETF" to "independent" (this document is an Independent Submission, not an IETF Working Group product); dates updated. * Section 2 / Section 6.1 (the former binding_key construction): the -06 construction let any participant in the TLS session -- including an attacker in its own session with the Issuer -- recompute binding_key and pass verification without proving possession of any holder key material, because binding_key was derived solely from public TLS Exporter output and the public PoT bytes. This is replaced with a PoT Record v2 (180 octets) carrying an explicit holder_auth_type (Ed25519 public key, MTI, or a pre-shared secret, OPTIONAL) and a binding_proof computed by the holder over the TLS Exporter output at binding time. Verification now performs integrity-tag interpretation first, in a single fixed-cost pass with a three-way intact/resolved/unresolvable verdict; in -06 the equivalent check was ordered after five other checks. The full 8-step order is specified in Section 2.5. * Appendix B: removed the "(Placeholder)" designation. Appendix B now specifies a public Integrity Algorithm Registry: alg_id 0x0001 (SHA-256, detection-only) is the Mandatory-to-Implement algorithm and is completely and publicly specified. Optional profile algorithms are maintained outside the core; this revision does not assign or define GRG. * IANA Considerations, HTTP/3 Stream Types: renamed from "HTTP/3 and QUIC Stream Types". The "QUIC Stream Types" registry entry is removed; no such IANA registry exists, and QUIC stream identification for TTTPS is carried entirely by the HTTP/3-layer frame registration. * Abstract: shortened from six paragraphs to three; removed inline document citations (an abstract is conventionally self-contained and does not carry bracketed references). * Scope reduced to the core protocol: satellite communication, SS7 legacy infrastructure, 5G/6G core network ordering, and deep- space/SAGIN deployment material are removed from this revision as out of scope; see 3GPP and CCSDS/TIPTOP for domain-specific profiles. The former Appendix E (a regulated therapeutic-design motivating scenario) is removed as non-normative and out of scope for a protocol specification. Jorgen Expires 21 February 2027 [Page 2] Internet-Draft TTTPS September 2026 * Sections 1 through 4 of -06 (Introduction, Use Cases, Requirements Language, Problem Statement) are consolidated into a single Section 1, removing a duplicated BCP 14 paragraph and shortening the document. * The former Section 4.3 (Shannon Gap / SCCP) and Section 7.4 (V* equilibrium) are shortened; the full economic and information- theoretic derivations remain in the companion paper [POT2026], which this document now points to rather than reproduces. * IANA Time Source Type Registry: named operators (NIST, Google, Cloudflare, Apple) are replaced with source classes (national metrology laboratory, GNSS-disciplined, Roughtime-authenticated, NTS-authenticated, PTP grandmaster); the same replacement is applied to the worked examples in Sections 1.3, 2.2, and 7.1. This document does not depend on, or endorse, any specific named operator. * References [NTS], [RFC5705], and [RFC8126] are unchanged from -06. Changes from -02 through -05 (compressed; see prior revisions of this draft for the full itemised changelog): -03 added Use Cases, the SS7/ SCCP instance analysis, path manipulation scenarios, the trust model, and the Implementation Status section (RFC 7942). -04 added the Formal Verification Artifacts subsection and the former Appendix E. -05 is not separately archived. -06 added Oracle Confidence Gating (the G-Score), corrected IPR licensing language per ISE guidance, and recorded the provisional "tttps" URI scheme registration. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 21 February 2027. Jorgen Expires 21 February 2027 [Page 3] Internet-Draft TTTPS September 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Why This Protocol, Why Now . . . . . . . . . . . . . . . 7 1.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 7 1.3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 8 1.4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9 1.6. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 11 1.6.1. Financial Infrastructure Timestamping . . . . . . . . 11 1.6.2. AI Agent Networks . . . . . . . . . . . . . . . . . . 11 1.6.3. Operational Requirements Summary . . . . . . . . . . 11 1.7. Problem Statement . . . . . . . . . . . . . . . . . . . . 12 1.7.1. Documented Temporal Ordering Failures . . . . . . . . 12 1.7.2. The Shannon Gap: SCCP . . . . . . . . . . . . . . . . 13 1.7.3. Existing Mitigations and Their Limitations . . . . . 14 2. Proof-of-Time Structure . . . . . . . . . . . . . . . . . . . 14 2.1. PoT Record v2 Wire Format . . . . . . . . . . . . . . . . 14 2.2. Field Definitions . . . . . . . . . . . . . . . . . . . . 15 2.3. Holder Authentication Types . . . . . . . . . . . . . . . 17 2.4. Generation Algorithm . . . . . . . . . . . . . . . . . . 17 2.5. Verification Procedure . . . . . . . . . . . . . . . . . 18 2.6. JOSE and COSE Data Representations . . . . . . . . . . . 19 2.6.1. COSE / CBOR Data Model (CWT Mapping) . . . . . . . . 19 2.6.2. JOSE / JSON Data Model (JWS Mapping) . . . . . . . . 19 3. Gap Analysis vs Existing Timestamping Standards . . . . . . . 20 4. Integrity Algorithm Registry . . . . . . . . . . . . . . . . 21 4.1. Abstract Interface . . . . . . . . . . . . . . . . . . . 21 4.2. Optional Integrity Profiles . . . . . . . . . . . . . . . 22 4.3. Confidence GRG Profile Integration . . . . . . . . . . . 22 5. AdaptiveSwitch . . . . . . . . . . . . . . . . . . . . . . . 22 5.1. State Machine . . . . . . . . . . . . . . . . . . . . . . 22 5.2. Transition Conditions and Hysteresis . . . . . . . . . . 22 5.3. Penalty and Exponential Backoff . . . . . . . . . . . . . 23 5.4. Equilibrium Analysis (V* Threshold) . . . . . . . . . . . 23 5.5. Oracle Confidence Gating (G-Score) . . . . . . . . . . . 24 6. Transport Binding . . . . . . . . . . . . . . . . . . . . . . 24 6.1. TLS 1.3 Binding . . . . . . . . . . . . . . . . . . . . . 24 Jorgen Expires 21 February 2027 [Page 4] Internet-Draft TTTPS September 2026 6.2. QUIC Integration . . . . . . . . . . . . . . . . . . . . 25 6.3. HTTP/3 Frame Type . . . . . . . . . . . . . . . . . . . . 26 6.4. Backward Compatibility . . . . . . . . . . . . . . . . . 26 7. Asynchronous PHC Substrate . . . . . . . . . . . . . . . . . 27 7.1. Time Interval Specification . . . . . . . . . . . . . . . 27 7.2. d_T Dynamic Accumulation Formula . . . . . . . . . . . . 28 7.3. Rust Lock-Free Atomic Reference . . . . . . . . . . . . . 28 8. Tier Structure . . . . . . . . . . . . . . . . . . . . . . . 29 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 9.1. Compromised Time Sources and Path Attacks . . . . . . . . 30 9.2. Replay Prevention . . . . . . . . . . . . . . . . . . . . 31 9.3. Sybil Time Sources and Unique Quorum . . . . . . . . . . 31 9.4. Side-Channel Considerations . . . . . . . . . . . . . . . 31 9.5. Byzantine Economic Attacks . . . . . . . . . . . . . . . 32 9.6. Delay-Based Temporal Attacks . . . . . . . . . . . . . . 32 9.7. Integrity Algorithm Security . . . . . . . . . . . . . . 32 9.8. Path Manipulation . . . . . . . . . . . . . . . . . . . . 33 9.9. Trust Model and Key Compromise Resilience . . . . . . . . 33 9.9.1. Trust Hierarchy . . . . . . . . . . . . . . . . . . . 33 9.9.2. Issuer Key Compromise Response . . . . . . . . . . . 34 9.9.3. Untrusted Substrate Guarantee . . . . . . . . . . . . 34 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 34 10.1. Unlinkability . . . . . . . . . . . . . . . . . . . . . 34 10.2. Minimal Disclosure . . . . . . . . . . . . . . . . . . . 34 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 11.1. TLS Exporter Labels Registry . . . . . . . . . . . . . . 35 11.2. ALPN Protocol ID Registration . . . . . . . . . . . . . 35 11.3. TTTPS Tier Registry . . . . . . . . . . . . . . . . . . 35 11.4. Time Source Type Registry . . . . . . . . . . . . . . . 35 11.5. Integrity Algorithm ID Registry . . . . . . . . . . . . 36 11.6. Holder Authentication Type Registry . . . . . . . . . . 36 11.7. HTTP/3 Stream Types . . . . . . . . . . . . . . . . . . 36 11.8. URI Scheme Registration . . . . . . . . . . . . . . . . 37 12. Intellectual Property . . . . . . . . . . . . . . . . . . . . 37 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 37 13.1. Reference Implementation . . . . . . . . . . . . . . . . 37 13.2. Deployment Evidence . . . . . . . . . . . . . . . . . . 38 13.3. Formal Verification Artifacts . . . . . . . . . . . . . 38 13.4. Interested Parties . . . . . . . . . . . . . . . . . . . 39 14. Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 15.1. Normative References . . . . . . . . . . . . . . . . . . 39 15.2. Informative References . . . . . . . . . . . . . . . . . 40 Appendix A. AdaptiveSwitch TLA+ Specification . . . . . . . . . 43 Appendix B. Integrity Algorithm Registry Specification . . . . . 46 B.1. alg_id 0x0001 -- SHA-256 (Mandatory-to-Implement) . . . . 46 B.2. Optional GRG Profile . . . . . . . . . . . . . . . . . . . 47 B.3. Registering New Algorithms . . . . . . . . . . . . . . . 47 Jorgen Expires 21 February 2027 [Page 5] Internet-Draft TTTPS September 2026 Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 48 Appendix D. FILO+Integrity Delay Rejection Flow . . . . . . . . 48 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 50 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 50 1. Introduction Every major class of internet ordering attack -- BGP hijacking that disrupts routing priority, NTP amplification attacks that bias financial settlement windows, legacy signaling-gateway compromise that enables silent path manipulation -- shares one root cause: the network layer cannot prove WHEN an event occurred. TLS proves WHO sent a message. DNSSEC proves WHAT the content is. No standard protocol proves WHEN -- in a manner cryptographically verifiable by any party without trusting any single intermediary. This document closes that gap. The gap is not theoretical. Legacy telephony signaling infrastructure (SS7), designed in 1975 with no sender authentication, permits an operator controlling a gateway to silently reroute traffic and modify inter-operator timestamps without detection at the application layer [SS7-VULN]. TTTPS is designed to operate above such an untrusted substrate: its Proof-of-Time (PoT) is path- independent, meaning no network-layer manipulation can produce a valid PoT without access to the Issuer's Ed25519 private key. A full treatment of SS7, satellite, 5G/6G core network, and deep-space deployment profiles is out of scope for this document; see 3GPP and CCSDS/TIPTOP for domain-specific profiles. The urgency of this gap has increased along two independent dimensions. First, autonomous AI agents executing financial transactions at machine speed have eliminated the latency buffer that historically made human-scale ordering fraud detectable; the broader trajectory toward increasingly autonomous, self-improving agents [Zhang2026] sharpens this exposure. Second, 70,612 PoT records generated over six months of experimental deployment reveal that 55% originate from AI agents -- an unanticipated finding that confirms ordering manipulation is already an operational problem, not a future risk. TTTPS introduces Proof-of-Time (PoT): a multi-source synthesised timestamp protected by an algorithm-selectable integrity tag, bound to a cryptographic context identifier and to a live TLS session through an explicit holder proof, and verifiable at O(1) cost independent of network size. TTTPS does not require trust in any single time source or any network path. Jorgen Expires 21 February 2027 [Page 6] Internet-Draft TTTPS September 2026 1.1. Why This Protocol, Why Now Three converging developments make this the appropriate moment for standardisation: (a) Infrastructure exposure. Documented signaling-layer vulnerabilities [SS7-VULN] enable timestamp manipulation without application-layer detection. No existing protocol -- NTS [NTS], PTP [IEEE1588], or Roughtime [I-D.ietf-ntp-roughtime] -- provides a path-independent temporal proof at the application layer. (b) Agent proliferation. As autonomous AI agents [Zhang2026] execute transactions at machine speed, the window for human detection of temporal manipulation collapses. Protocol-layer enforcement becomes necessary. (c) Running code. A reference implementation [OPENTTT] is deployed and has generated 70,612 verified PoT records. The experimental data (Section 13.2) demonstrates both the technical viability and the demand for the protocol. 1.2. Objectives The objectives of TTTPS are as follows: * Temporal origin authentication: prove "when" a message originated, complementing TLS's proof of "who". * Byzantine time source elimination: transform detection probability from P(detect) < 1 (Shannon model) to P(detect) >= 1 - 2^{-61} via context-bound integrity tagging. * Delay attack prevention: enforce that PoT submissions outside the tier freshness window are rejected pre-ingestion, as defined for delay attacks in [NTS] Section 8.6. * Economic eviction of dishonest nodes: via AdaptiveSwitch equilibrium threshold V*, below which ordering manipulation is self-defeating. * Transport-layer agnosticism: operate over TLS 1.3, QUIC [RFC9000], and HTTP/3 [RFC9114] without modification to those protocols. * Backward compatibility: deployable alongside existing TLS 1.3 without requiring server-side changes. * Experimental deployment: accumulate implementation experience prior to consideration for the Standards Track. Jorgen Expires 21 February 2027 [Page 7] Internet-Draft TTTPS September 2026 * Privacy-preserving temporal attestation: PoT binds to context without revealing transaction content or participant identity. Primary use cases include MEV-resistant decentralised exchange (DEX) transaction ordering, AI agent-to-agent payment sequencing, IoT mission-critical command ordering, and financial settlement timestamping. 1.3. Protocol Overview TTTPS does NOT modify the TLS handshake. No new TLS Extension Type is required. This approach follows the Network Time Security model [NTS], Section 5.1. TTTPS operates in two phases: Phase 1 -- PoT Generation: Holder PoT Issuer | | |--- Time synthesis request ---------->| | | Query k>=3 independent | | time sources (national | | metrology lab, GNSS- | | disciplined, NTS- | | authenticated, ...) | | ts = median(T_1..T_k) | | |<-- PoT Record v2 (180B, signed) -----| | [ts | ctx_id | nonce | | | integrity_tag | issuer_sig] | Phase 2 -- TLS Binding: Holder Verifier |--- TLS ClientHello -------------->| |<-- TLS ServerHello + ... ---------| |<-- TLS Finished -----------------| | | | Holder computes binding_proof | | over TLS-Exporter output | | (Section 6.1) and attaches it | | to the PoT Record | | | |--- 1-RTT[binding_proof|PoT] ----->| |<-- 1-RTT[PoT-Ack] --------------| Jorgen Expires 21 February 2027 [Page 8] Internet-Draft TTTPS September 2026 Byzantine nodes that submit manipulated ordering are identified with probability >= 1 - 2^{-61} and economically penalised via AdaptiveSwitch FULL mode. 1.4. Scope This document specifies: * The PoT Record v2 data structure and wire format (Section 2) * The Integrity Algorithm abstract interface (Section 4) * The AdaptiveSwitch Byzantine eviction mechanism (Section 5) * The TTTPS transport binding (Section 6) This document does NOT specify: * Optional profile algorithms such as GRG. The GRG interface and external properties are specified in the Confidence track [CONFIDENCE]; this core draft does not make them a core conformance requirement. * Specific time source selection policies * External audit-log or anchoring substrate implementations * Pricing or fee schedules (implementation-defined; Section 8) * Satellite, 5G/6G, and deep-space deployment specifics (out of scope for this document; see 3GPP and CCSDS/TIPTOP) 1.5. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. SCCP (Strategic Channel Controller Problem): A system satisfies SCCP if (i) a controller C has authority over message ordering; (ii) U(C) is strictly monotone in that ordering; (iii) no external party can verify original ordering without C's cooperation. Instances include NTP timestamp bias, BGP hijacking, DNS poisoning, and transaction sequencer MEV. Proof-of-Time (PoT): A cryptographically authenticated record of a synthesised timestamp, bound to a context identifier and to a holder, and protected against replay and delay. Jorgen Expires 21 February 2027 [Page 9] Internet-Draft TTTPS September 2026 Holder: The entity that generated the PoT Record and that proves possession of holder key material -- an Ed25519 private key (holder_auth_type 0x01, MTI) or a pre-shared secret (holder_auth_type 0x02, OPTIONAL) -- via binding_proof at TLS binding time (Section 6.1). Integrity Tag: A 256-bit value, selected by alg_id, that protects the PoT Record payload against modification. alg_id 0x0001 (SHA-256) is Mandatory-to-Implement and detection-only. Optional profile algorithms are referenced by profile documents and are not required by this core. AdaptiveSwitch: A state machine classifying nodes as TURBO (ordering- compliant, ~50 ms verification, 20% fee discount) or FULL (potentially Byzantine, ~127 ms, exponential backoff). Byzantine Time Attack: An adversarial action in which a network participant reports a fabricated or manipulated timestamp to gain ordering advantage. V* (Equilibrium threshold): V* = c_0 + lambda * Delta_tau. For MEV opportunity value V < V*, ordering manipulation is eliminated in the unique symmetric Nash equilibrium. Empirically calibrated from 151,423 Timeboost auctions: V* in [$8.67, $87.13]. FILO+Integrity: The processing discipline in which PoT submissions are subject to two sequential gates (integrity-tag gate, then AdaptiveSwitch freshness gate) before entering the processing queue; within the queue, the most recently generated qualifying PoT is processed first. PoT Issuer: An entity authorised to generate and sign PoT records. Analogous in function to a Certificate Authority, but attesting time rather than identity. Tier: An ordered set of time resolution levels (T0_epoch through T3_micro) controlling the tier freshness window for PoT submission recency. See Section 8. Jorgen Expires 21 February 2027 [Page 10] Internet-Draft TTTPS September 2026 1.6. Use Cases This section describes deployment scenarios in which existing protocols (NTS, PTP, Roughtime) are insufficient and TTTPS provides the necessary path-independent temporal proof. Satellite and 5G/6G core network use cases are out of scope for this revision; see 3GPP and CCSDS/TIPTOP for domain-specific profiles. 1.6.1. Financial Infrastructure Timestamping MiFID II (EU) and CAT (US) require submillisecond-accurate timestamps for regulated financial transactions. GPS-based timing, the current industry standard, is vulnerable to spoofing attacks that can shift reported timestamps by seconds [GPS-SPOOF]. TTTPS provides a multi-source temporal proof that detects GPS spoofing: if the GPS-derived timestamp diverges from the median- derived timestamp by more than stratum_tolerance, PoT generation ABORTS (Section 2.4, step 4). This transforms GPS spoofing from an undetectable manipulation into a verifiable abort condition. Operational requirement: a regulatorily auditable timestamp that survives GPS spoofing and does not depend on any single time infrastructure provider. 1.6.2. AI Agent Networks Autonomous AI agents executing financial or coordination transactions at machine speed generate ordering-sensitive messages at rates that eliminate human-scale audit cycles. The experimental deployment (Section 13.2) found that 55% of all PoT records were generated by AI agents -- consistent with the broader trajectory toward autonomous agent operation [Zhang2026]. As agent reaction times converge toward network propagation delay, ordering advantage can no longer be earned through superior reaction time. The remaining mechanism for ordering advantage is timestamp manipulation -- precisely the attack class TTTPS addresses. Operational requirement: O(1) temporal verification that scales to agent transaction rates without BFT overhead. 1.6.3. Operational Requirements Summary The use cases above share four requirements that existing protocols do not jointly satisfy: Jorgen Expires 21 February 2027 [Page 11] Internet-Draft TTTPS September 2026 R1. Path independence: temporal proof must be valid regardless of which network path the PoT traverses after generation. R2. Cross-domain verification: proof must be verifiable by parties without access to the generation environment. R3. Pre-ingestion enforcement: invalid ordering must be detectable before the record enters system state, not after (unlike Roughtime's audit-only model). R4. O(1) scalability: verification cost must be independent of network size and number of participants. Table R: Protocol Coverage of Operational Requirements. | R1 Path | R2 Cross | R3 Pre- | R4 O(1) | Indep. | Domain | Ingest. | Scale ------------|----------|----------|----------|-------- NTS [NTS] | No | No | No | Yes PTP [IEEE1588] | No | No | No | Yes Roughtime | Partial | Partial | No | O(log n) TTTPS | Yes | Yes | Yes | Yes Requirement R3, pre-ingestion enforcement, is unique to TTTPS: NTS, PTP, and Roughtime all enforce ordering only after a record is admitted (session rejection or retrospective audit signal), whereas TTTPS rejects non-conforming ordering before the record enters system state. 1.7. Problem Statement 1.7.1. Documented Temporal Ordering Failures The following documented attack classes motivate TTTPS. Each represents a deployed instance of the Strategic Channel Controller Problem (SCCP, Section 1.5) in which an ordering authority has both capability and incentive to misrepresent temporal ordering. (a) Signaling-layer timestamp manipulation. Legacy telephony signaling protocols transmit location and timing information without sender authentication; a gateway operator can shift perceived timestamps by seconds without detection [SS7-VULN][GSMA-SS7]. This is not theoretical: such attacks have been demonstrated against live networks in multiple countries. A full treatment of this class as an SCCP instance is out of scope for this revision. Jorgen Expires 21 February 2027 [Page 12] Internet-Draft TTTPS September 2026 (b) BGP route hijacking. An AS operator controlling routing can reroute traffic to create artificial ordering delays. The 2010 China Telecom BGP incident diverted US military traffic for 18 minutes. Application-layer timestamps recorded during such diversions cannot be verified. (c) NTP amplification and bias. An NTP server operator can bias returned timestamps by amounts below stratum-check thresholds, shifting financial settlement windows by sub-second amounts sufficient to capture MEV ($0.11-$1.13/ms, calibrated from 151,423 Timeboost auctions [Messias2025]). (d) GPS spoofing. Civilian GPS signals are unencrypted. Spoofing hardware costing under $500 can shift GPS-derived timestamps by seconds within a local area [GPS-SPOOF]. MiFID II-compliant systems relying solely on GPS timestamps are vulnerable. The common thread: in each case, a single infrastructure operator can manipulate temporal ordering without producing any detectable artefact at the application layer. TTTPS closes this gap by requiring that temporal ordering be cryptographically provable independent of any single infrastructure operator. 1.7.2. The Shannon Gap: SCCP Shannon (1948) modelled a channel as Y = X + N_rand, where noise N is random and the channel operator is passive. All subsequent coding theory, information theory, and cryptographic channel models assume NOT-SCCP -- an assumption structurally violated by modern internet infrastructure, as summarised in Table 1. The full formal treatment, including the derivation of lambda per domain, is given in the companion paper [POT2026]. Table 1: SCCP instances in deployed infrastructure. Domain | SCCP mechanism | lambda --------------|-------------------------------|------------------ NTP server | Timestamp bias shifts | Low | settlement windows | BGP router | Traffic rerouting disrupts | Medium | ordering | DNS resolver | Forged response wins | Low | temporal race | Tx sequencer | Reordering extracts MEV | $0.11--1.13/ms AI agent | Agent ordering captures | High (scaling) coordinator | surplus | Jorgen Expires 21 February 2027 [Page 13] Internet-Draft TTTPS September 2026 Shannon's noise model has no mechanism for strategic N. PoT changes this: Byzantine manipulation becomes cryptographically self- identifying and economically self-penalising. 1.7.3. Existing Mitigations and Their Limitations Table 2: Comparison with existing temporal protocols. | Roughtime | NTS/PTP | PoT --------------|-----------|-----------|------------------ Timing | Retro. | Session | Pre-ingestion Enforcement | Signal | Reject | Economic penalty Cross-domain | No | No | Yes SCCP | No | No | Yes Complexity | O(log n) | O(1) | O(1) per record BFT overhead | N/A | N/A | O(1) vs O(n^2) Classical BFT protocols (PBFT [Castro1999], Tendermint) tolerate f < n/3 Byzantine nodes with O(n^2) message complexity. PoT ELIMINATES Byzantine ordering manipulation at O(1) per record: the manipulation is not outvoted but cryptographically identified and economically penalised. As network size grows from n to 10n, classical BFT message overhead grows up to 100x; PoT overhead is unchanged. The urgency of this gap has increased as AI systems acquire autonomous capability to identify and exploit protocol-layer vulnerabilities without human direction [GLASSWING]. 2. Proof-of-Time Structure This section specifies PoT Record v2, which replaces the v1 (143-octet) record of earlier revisions of this document. The v2 record separates two concerns that v1 conflated: the Issuer's attestation of a synthesised time (Section 2.4), and the Holder's proof of possession bound to a live TLS session (Section 6.1). This separation is the structural fix for the -06 binding weakness described in the Discussion Note. 2.1. PoT Record v2 Wire Format A PoT Record is encoded as a fixed 180-octet binary sequence. All multi-octet integer fields are in network byte order (big-endian). Jorgen Expires 21 February 2027 [Page 14] Internet-Draft TTTPS September 2026 Offset Length Field ------ ------ ----------------------------------------------- 0 1 version (0x02 for this document) 1 1 holder_auth_type (0x01 Ed25519 pk MTI, 0x02 shared secret OPTIONAL) 2 2 alg_id (integrity algorithm, Section 4) 4 8 ts (TAI microseconds since epoch) 12 4 dispersion (microseconds, uncertainty bound) 16 16 ctx_id (opaque context identifier) 32 16 nonce (cryptographically random) 48 32 holder_auth_data (holder public key, or PSK digest) 80 32 integrity_tag (Section 4, algorithm per alg_id) 112 4 issuer_key_id (Issuer signing-key identifier) 116 64 issuer_sig (Ed25519 over octets 0-115) ------ ------ Total: 180 octets The binding_proof carried alongside the PoT Record at TLS binding time (Section 6.1) is a separate value, not part of these 180 octets: it is computed by the Holder from live TLS session material and cannot be produced at PoT generation time, which is the point of the separation. 2.2. Field Definitions version (8 bits): Protocol version. This document defines version 2 (0x02). Implementations MUST reject PoT records with unknown versions. holder_auth_type (8 bits): Identifies how the Holder proves possession. See Section 2.3. Implementations MUST reject unknown values. alg_id (16 bits): Identifies the integrity algorithm protecting this record (Section 4). Implementations MUST reject unsupported values. ts (64 bits): Synthesised timestamp: ts = median(T_1, ..., T_k), k >= 3 sources from independent administrative domains. TAI microseconds since the TAI epoch. TAI, rather than UTC, is used to avoid leap-second ambiguity in the freshness comparison of Section 2.5. Synthesis MUST use at least three independent sources from distinct administrative domains (e.g., a national metrology laboratory, a GNSS-disciplined source, and an NTS-authenticated source). Jorgen Expires 21 February 2027 [Page 15] Internet-Draft TTTPS September 2026 dispersion (32 bits): Synthesis uncertainty bound in microseconds: dispersion = max|T_i - ts| across the k sources. Used in the freshness check of Section 2.5. ctx_id (128 bits): An opaque, application-assigned context identifier. Binds the PoT Record to its context; see Section 4.1. A verifier that enables an optional profile MUST resolve ctx_id against an authenticated context manifest before selecting a physical or confidence profile. The manifest MAY select a terrestrial, near-Earth/SAGIN, cislunar, or deep-space profile. A missing, expired, contradictory, or unauthorized mapping MUST result in HOLD or UNVERIFIABLE; the verifier MUST NOT infer deep-space context from packet arrival time or silently apply a terrestrial default. The manifest is out of band and is not part of the fixed 180-octet record. It SHOULD bind the profile identifier, epoch, time scale, coordinate frame, endpoints, OWLT interval, navigation or ephemeris authority, uncertainty budget, peer/provenance digest, and policy revision to ctx_id. This lookup is the automatic profile-dispatch mechanism and does not change the PoT wire length. nonce (128 bits): Cryptographically random value. MUST be generated with a cryptographically secure random number generator. Provides replay prevention in conjunction with Section 9.2. holder_auth_data (256 bits): For holder_auth_type 0x01: the Holder's Ed25519 public key. For holder_auth_type 0x02: SHA-256(k_h), a digest of the pre-shared secret, never the secret itself. integrity_tag (256 bits): Output of the algorithm identified by alg_id (Section 4), computed over octets 0-79 of this record. Detection and correction semantics are defined by the selected algorithm profile; the core SHA-256 path is detection-only. issuer_key_id (32 bits): Identifies the Issuer's signing key, enabling key rotation without requiring verifiers to trial multiple keys. issuer_sig (512 bits): Ed25519 signature [Bernstein2012] by the Issuer's private key over octets 0-115 (all preceding fields), following EUF-CMA security. Issuer Integrity Property: the Issuer cannot forge a timestamp without detection. A forged ts' != ts produces a different integrity_tag', and issuer_sig over the changed record then fails verification against the published Issuer public key. This is a mathematical consequence of EUF-CMA security, not a procedural control. The remaining trust assumption is that the Issuer's private key is not compromised; this is the same trust model as PKI (Certificate Authority), applied to time rather than identity. Issuer misbehaviour is auditable via an append-only commitment log of published PoT records. Jorgen Expires 21 February 2027 [Page 16] Internet-Draft TTTPS September 2026 2.3. Holder Authentication Types 0x01 -- Ed25519 public key (Mandatory-to-Implement): holder_auth_data = holder_pk (32 octets). binding_proof (64 octets) = Ed25519.Sign(holder_sk, binding_input), verifiable by any party holding holder_pk (Section 6.1). 0x02 -- Shared secret (OPTIONAL): holder_auth_data = SHA-256(k_h) (32 octets). binding_proof (32 octets) = HMAC-SHA256(k_h, binding_input). This type requires out-of-band distribution of k_h between Holder and verifier and MUST NOT be used where verification by an external party that does not already possess k_h is required. 2.4. Generation Algorithm 1. Query k >= 3 time sources from independent administrative domains. 2. Compute ts = median(T_1, ..., T_k), in TAI microseconds. 3. Compute dispersion = max|T_i - ts|. 4. If dispersion > stratum_tolerance: ABORT. 5. Generate a 128-bit cryptographically random nonce. 6. Assemble octets 0-79: version, holder_auth_type, alg_id, ts, dispersion, ctx_id, nonce, holder_auth_data. 7. Compute integrity_tag over octets 0-79 using the algorithm identified by alg_id (Section 4). 8. Assign issuer_key_id identifying the signing Issuer key. 9. Compute issuer_sig = Ed25519.Sign(issuer_sk, octets 0-115). 10. Output the 180-octet PoT Record v2. binding_proof is deliberately not computed at generation time: it requires TLS session material that does not yet exist when the Issuer generates the record, and is instead computed by the Holder at TLS binding time (Section 6.1). Jorgen Expires 21 February 2027 [Page 17] Internet-Draft TTTPS September 2026 2.5. Verification Procedure Implementations MUST verify a received (binding_proof, PoT Record) pair in the following order. Reordering this sequence, in particular performing step 3 later, reintroduces the -06 binding weakness described in the Discussion Note. 1. Frame length check: the received frame MUST equal len(binding_proof) + 180 octets, where len(binding_proof) is 64 (holder_auth_type 0x01) or 32 (holder_auth_type 0x02); otherwise REJECT. 2. Support check: version, alg_id, and holder_auth_type MUST all be values the verifier supports; otherwise REJECT. 3. Integrity-tag interpretation (single fixed-cost pass): apply the algorithm profile identified by alg_id to octets 0-79 and compare against integrity_tag. The result is *intact*, *resolved* only when the selected profile defines bounded correction and confirms recovery, or *unresolvable* (REJECT immediately, do not proceed to any later step). This check MUST be performed before steps 4-7. 4. Freshness: if |now - ts| > tier_window + dispersion: REJECT. Trigger FULL mode per Section 5.3. 5. Anti-replay: if the (ctx_id, nonce) pair has been seen before within the freshness window: REJECT. 6. issuer_sig verification: verify the Ed25519 signature over octets 0-115 against the Issuer public key identified by issuer_key_id; otherwise REJECT. 7. binding_proof verification: recompute the expected binding_input from the live TLS-Exporter output (Section 6.1) and verify binding_proof against holder_auth_data per holder_auth_type; otherwise REJECT. 8. Accept. NOTE: performing integrity-tag interpretation first (step 3) gives early, fixed-cost rejection of corrupted or foreign-context submissions before the more expensive signature and binding-proof checks are attempted. Jorgen Expires 21 February 2027 [Page 18] Internet-Draft TTTPS September 2026 2.6. JOSE and COSE Data Representations To facilitate seamless integration with modern identity, attestation, and cryptographic token frameworks (e.g., JWTs, CWTs, RATS Conceptual Message Wrappers [I-D.ietf-rats-msg-wrap]), a PoT Record v2 MAY be represented as either a COSE (CBOR Object Signing and Encryption) map or a JOSE (JSON Object Signing and Encryption) claim set. 2.6.1. COSE / CBOR Data Model (CWT Mapping) In CBOR Web Token (CWT) contexts, the PoT Record v2 is represented as a CBOR Map containing the following integer-keyed claims: +-------+-------------------+-------------------------------------+ | Claim | Key Name | CBOR Type & Value | +-------+-------------------+-------------------------------------+ | 1 | ver | unsigned integer (0x02) | | 2 | auth_type | unsigned integer (0x01 / 0x02) | | 3 | alg_id | unsigned integer (core/profile-defined) | | 4 | ts | unsigned integer (microsecond TAI) | | 5 | dispersion | unsigned integer (microseconds) | | 6 | ctx_id | byte string (16 octets) | | 7 | nonce | byte string (16 octets) | | 8 | holder_auth_data | byte string (32 octets) | | 9 | integrity_tag | byte string (32 octets) | | 10 | issuer_key_id | unsigned integer (32 bits) | | 11 | issuer_sig | byte string (64 octets) | +-------+-------------------+-------------------------------------+ When encapsulated within a COSE_Sign1 structure, the 180-octet raw PoT record forms the COSE payload, and the binding_proof is carried in an unprotected COSE header attribute (Label: TBD_COSE_HEADER_TTTPS). 2.6.2. JOSE / JSON Data Model (JWS Mapping) In JSON Web Signature (JWS) and JWT contexts, the PoT Record v2 is represented as a JSON Object with deterministic Base64URL string encodings for byte arrays: Jorgen Expires 21 February 2027 [Page 19] Internet-Draft TTTPS September 2026 { "ver": 2, "auth_type": 1, "alg_id": 1, "ts": 1787184000000000, "dispersion": 5, "ctx_id": "Base64URL(16B)", "nonce": "Base64URL(16B)", "holder_auth_data": "Base64URL(32B)", "integrity_tag": "Base64URL(32B)", "issuer_key_id": 1001, "issuer_sig": "Base64URL(64B)" } When transmitted over HTTP APIs, a detached JWS header carries the binding_proof as a JOSE header parameter ("pot_bp"). 3. Gap Analysis vs Existing Timestamping Standards Existing secure timestamping ecosystems (RFC 3161 Time-Stamp Protocol, eIDAS Qualified Preservation Services with Qualified Trust Service Providers) rely on out-of-band, high-latency Time-Stamping Authorities (TSAs) using ASN.1/DER structures transported over HTTP. While suitable for static document signing, this architecture cannot serve modern cloud-native, wire-speed environments because of three structural bottlenecks. _In-Band Wire-Speed vs Out-of-Band Latency._ RFC 3161 requires an HTTP round-trip to a central TSA and one asymmetric signature per token (typical latency 10 ms to 100 ms). TTTPS operates in-band at the packet or wire level (sub-microsecond execution via a no_std C-ABI reference core in Rust), binding hardware PTP clock readings directly to payload digests before the record enters database or storage memory. _Hardware-Bound Immutability without Central TSA Dependencies._ Traditional TSAs rely on trust in an external signing authority's private key. TTTPS constructs an unkeyed, mathematically verifiable commitment (O(1) state bound) tied to a hardware Precision Time Protocol (PTP) clock, establishing an immutable Hardware Root of Trust without requiring a third-party TSA server round-trip per micro-event. Jorgen Expires 21 February 2027 [Page 20] Internet-Draft TTTPS September 2026 _High-Throughput Scalability._ Modern AI training pipelines, 5G telemetry, and high-frequency financial ledgers process millions of events per second. Applying RFC 3161 to such streams causes catastrophic throughput collapse. TTTPS provides a lightweight, composable record format designed for streaming high-throughput verification. TTTPS does not replace RFC 3161 for the static document signing case where an out-of-band TSA is appropriate; it complements it for the wire-speed streaming case. The two can co-exist: TTTPS records MAY be countersigned by an RFC 3161 TSA as a downstream reinforcement. 4. Integrity Algorithm Registry 4.1. Abstract Interface Each alg_id value selects an algorithm that computes integrity_tag over the 80-octet payload described in Section 2.1, and that a verifier uses to interpret integrity_tag against three possible outcomes: intact, resolved, or unresolvable (Section 2.5, step 3). This document defines SHA-256 as the core algorithm. Optional integrity profiles, including GRG, are defined outside the core and are identified here only through their profile documents. alg_id 0x0001 -- SHA-256 (Mandatory-to-Implement): Detection-only. Fully and publicly specified in Appendix B.1, All conformant implementations MUST support this algorithm. Optional GRG profile: A verifier MAY select a GRG integrity profile only when the profile document is available and the deployment has separately evaluated interoperability and IPR applicability. The core does not assign a GRG algorithm definition or require its implementation. See [CONFIDENCE]. When the Confidence GRG profile is selected, its intact/resolved/ unresolvable integrity verdict is evaluated before freshness, replay, signature, confidence, or physical-context gates. A later gate MUST NOT convert unresolvable input into a valid PoT. Implementations of any registered algorithm MUST satisfy, at minimum: * Detection: a registered algorithm MUST state its detection and, if applicable, correction properties in its profile specification. * Context binding: the computation MUST incorporate ctx_id (via its presence in the protected octets), so that a record generated under one ctx_id cannot be revalidated as if generated under another. Jorgen Expires 21 February 2027 [Page 21] Internet-Draft TTTPS September 2026 New alg_id values are registered under Specification Required (Section 11.5). 4.2. Optional Integrity Profiles The core does not reproduce the internal construction, stage ordering, parameter choices, or correction claims of optional integrity profiles. The Confidence track [CONFIDENCE] is the independent profile reference for the optional GRG interface. A deployment MUST NOT infer that a profile is implemented, interoperable, or free of IPR constraints merely because the core accepts an algorithm identifier. 4.3. Confidence GRG Profile Integration The independent Confidence track [CONFIDENCE] is the authoritative profile source for the optional GRG integrity pipeline. This subsection records how the core consumes that profile without redefining it. For a protected payload P and context identifier ctx_id, the profile exposes the ordered external stages G1 -> R -> G2 -> H: G1: Golomb-Rice symbol preparation; R: Reed-Solomon erasure processing; G2: Golay(23,12,7) bounded correction; H: HMAC-SHA256 authentication and context binding. The profile's external contract includes lossless recovery for intact or resolved results, declared k/n erasure parameters (reference profile k=4, n=6), a declared bounded correction capacity (reference t=3 bit errors per 23-bit block), and ctx_id separation. A result is exactly one of intact, resolved, or unresolvable under the selected profile. The core MUST treat unresolvable as an integrity failure and MUST NOT allow a later freshness, quorum, G-Score, VN, Epi-Entropy, or Deep-space decision to promote it to valid. When GRG is selected, integrity interpretation occurs at the integrity gate before freshness, replay, issuer signature, holder binding, or any confidence/profile qualification. The profile remains OPTIONAL; SHA-256 remains the core MTI path. A verifier MUST NOT infer GRG implementation, interoperability, or IPR status from an alg_id alone. The core does not reproduce GRG's internal parameter selection or claim ownership of its implementation. The independent Confidence document owns the profile contract; any IPR disclosure is handled under BCP 79 [RFC8179]. 5. AdaptiveSwitch 5.1. State Machine AdaptiveSwitch maintains per-node state in {TURBO, FULL}. +-------------------+ +----| TURBO |<---+ | | ~50 ms | | | | -20% fee | | match_rate >= 0.85 | | integrity check: | | (sustained) | | ~0.3 ms/record | | | +-------------------+ | | | | | match_rate < 0.85 match_rate >= 0.95 | OR integrity fail over 20 blocks | | | | +-------------------+ | +--->| FULL |----+ | ~127 ms | | standard fee | | backoff applied | +-------------------+ 5.2. Transition Conditions and Hysteresis TURBO entry: match_rate >= 0.95 sustained over >= 20 blocks. All PoT submissions within tier freshness window. No integrity-tag failures. Jorgen Expires 21 February 2027 [Page 22] Internet-Draft TTTPS September 2026 TURBO maintenance: match_rate >= 0.85 (relaxed threshold prevents flapping). TURBO -> FULL: match_rate < 0.85 over any 20-block window, OR any integrity-tag failure, OR any submission outside the tier freshness window (delay attack). The hysteresis asymmetry is deliberate: trust is earned slowly and lost quickly (hard to earn, easy to lose). 5.3. Penalty and Exponential Backoff On integrity failure in TURBO mode: Backoff penalty = 20 * 2^{f-1} blocks, maximum 320 blocks. (f = consecutive failure count) On submission outside the tier freshness window: immediate FULL mode transition. Backoff applies to TURBO re-entry. 5.4. Equilibrium Analysis (V* Threshold) Let lambda = operator opportunity cost per millisecond, c_0 = baseline ordering cost, and Delta_tau = 77 ms (TURBO vs FULL latency difference): V* = c_0 + lambda * Delta_tau For V < V*: ordering spam is eliminated (E[S] = 0) in the unique symmetric Nash equilibrium. For V >= V*: spam is reduced by a c_PoT / c_0 factor. The full derivation and its information-theoretic framing are given in the companion paper [POT2026]; this section records only the calibrated result. Empirical calibration from 151,423 Timeboost auctions (Arbitrum, April-July 2025): Phase | lambda ($/ms) | V* | Result ----------------|---------------|----------|------------------ Stable (May+) | 0.11 - 0.23 | $8.67 | Spam eliminated Central est. | 0.16 | $12.82 | Spam eliminated Competitive | 1.13 | $87.13 | Spam eliminated ETH L1 sandwich | -- | ($131) | Spam reduced The Ethereum L1 average sandwich MEV ($131) lies above V*_max, consistent with "reduced but not eliminated" for highest-value attacks. For V < $8.67, PoT eliminates ordering manipulation entirely. Jorgen Expires 21 February 2027 [Page 23] Internet-Draft TTTPS September 2026 5.5. Oracle Confidence Gating (G-Score) The G-Score specified in this subsection is a layer separate from the Integrity Algorithm Registry of Section 4: it gates AdaptiveSwitch's confidence in oracle-source agreement, and it does not process, encode, or verify PoT Record octets. The match_rate that drives the state transitions above is an oracle- agreement signal reflecting the degree to which the independent sources observed by a node agree. Raw agreement is not sufficient on its own: agreement from a small number of confident sources and agreement from a diffuse, uncertain set of sources carry different weight. For an agreement distribution p over n sources, the G-Score is the normalised Shannon entropy G(p) = H(p) / log n, where H(p) = sum_i -p_i log p_i with 0 <= G(p) <= 1: G(p) = 0 for a point mass (full certainty) and G(p) = 1 for the uniform distribution (maximal uncertainty). When G(p) exceeds a configured threshold, the node signals InsufficientKnowledge (Section 13.3) rather than asserting agreement it cannot justify. The Shannon G-Score is a marginal measure and cannot, by construction, detect correlation between colluding sources. TTTPS therefore specifies an OPTIONAL von Neumann (density-matrix) extension, S(rho) = -Tr(rho log rho), which reduces to the Shannon form on independent (diagonal) sources but is strictly lower when off-diagonal correlation is present -- a detector for collusion the marginal entropy misses. It is gated to the low-source-count regime, where collusion leverage is highest and the O(n^3) eigendecomposition cost is bounded; high-source-count deployments use the linear-cost Shannon form. This subsection specifies an abstract confidence- gating mechanism only; the mapping from observed sources to p and rho, source weighting, and threshold calibration are implementation- defined. The companion specification is [CONFIDENCE]. The research background is [CONFIDENCEPAPER]. 5.6. Epi-Entropy Admissible Density Bundle An implementation that enables the Epi-Entropy shadow MAY represent observed coupled constraints C = {(A_k, b_k)} as the admissible bundle B(C) = { R in C^(n x n) | R = R^dagger, R >= 0, Tr(R) = 1, Tr(R A_k) <= b_k for every k in C }. The epistemic entropy interval is EpiEnt(B) = [ inf_(R in B) S_VN(R), sup_(R in B) S_VN(R) ], S_VN(R) = -Tr(R log_2 R). The identity ambiguity diameter is Delta_id(B) = sup_(R,R' in B) 1/2 ||R - R'||_1. The exact lower endpoint is distinct from a certified lower bound. To avoid treating concave minimization as a real-time exact operation, an implementation MAY use the purity bound inf_(R in B) S_VN(R) >= -log_2(sup_(R in B) Tr(R^2)). The bound MUST be labelled as a bound, not as the exact endpoint. An empty B is not assigned an entropy value: the verifier MUST return CONSTRAINT_INCONSISTENCY or DEGRADED_HOLD, and MUST NOT emit PASS solely because an endpoint could not be computed. 5.7. Seven-Layer Verification Pipeline When the profile is enabled, processing occurs in the following order: 1. PKI Peer Admission: verify stable_node_id, Ed25519 key, and challenge signature. Failure yields UNAUTHORIZED_VOTE and zero voting authority. 2. Physical Deduplication: map stable_node_id to an authority-bound PhysicalEntity. Duplicate entity votes count zero. 3. D-Chain Freshness: verify nonce echo, RTT evidence, and round-hash continuity. A replay violation invalidates the observation. 4. Unique Quorum Check: compute N_eff and require the configured quorum. If N_eff is insufficient, fail closed to HOLD_AHE. 5. Byzantine Median: apply only when the declared bound f < N_eff/2 holds; otherwise do not fabricate an aggregate. 6. VN Correlation: optionally evaluate aligned residual history. A failed policy signal lowers confidence and enters HOLD, not cryptographic REJECT. 7. Epi-Entropy Shadow: asynchronously evaluate Delta_id and bundle status. This layer is read-only with respect to integrity and binds its result to the evidence record. The order is normative for the enabled profile. Later confidence or shadow results MUST NOT repair an earlier admission, freshness, or quorum failure. 5.8. Effective Quorum and AHE Holdover Effective quorum is based on authority-bound physical entities: N_eff = | union over i in Roster PhysicalEntity(stable_node_id_i) |. A verifier MUST use N_eff, not raw labels or key count, for quorum and Byzantine aggregation. A fresh valid key MUST NOT increase N_eff without a new authoritative physical-identity binding. For N_eff < 3, an implementation MAY enter AHE mode with bounded holdover: T_bound(t) = E_sync + sigma_clock sqrt(t - tau_sync) + 1/2 gamma_drift (t - tau_sync)^2. AHE is not a quorum and MUST NOT be reported as independent consensus. Its bound, synchronization age, drift parameters, and reason code MUST be kept in the evidence receipt. Recovery requires fresh authority-backed evidence. 5.9. Deep-Space and Delay-Tolerant Profile The optional Deep-space profile [DEEPSPACE] preserves the PoT wire record and carries OWLT, epoch, coordinate frame, uncertainty, authority, and applicability context out of band. Arrival time MUST NOT substitute for OWLT. Missing, stale, or unauthoritative ephemeris or TCB context yields HOLD or UNVERIFIABLE, not a zero correction or a terrestrial default. After core authentication, a verifier MUST resolve the protected ctx_id to an authenticated context manifest and select the declared terrestrial, near-Earth/SAGIN, or propagation-aware Deep-space processing path. The dispatch result, manifest digest, and policy revision MUST be retained in the evidence receipt. Profile selection MUST NOT be inferred from the timestamp, source count, or network address alone. The common profile order is: verify fixed-record integrity and replay; authenticate the ctx_id manifest; validate epoch, frame, time scale, OWLT, precision, and authority; project observations and collapse physical or provenance duplicates; compute N_eff and apply the declared robust aggregate; then run optional G-Score, VN, and Epi-Entropy qualification before a new promotion or commit. A missing or contradictory manifest yields HOLD or UNVERIFIABLE. No Deep-space field is appended to the 180-octet record. A future in-band negotiation extension, if required, MUST be separately versioned and carried as a sidecar or extension record while preserving the fixed-record parser and signature domain. Large nanosecond epochs SHOULD remain in integer representation. A floating-point relativistic or propagation factor MAY be used for the correction term only; the correction MUST be rounded under a declared rule before it is added to the integer timestamp. Direct conversion of an absolute nanosecond epoch to binary floating point is not lossless. Sparse peers do not create quorum. After physical deduplication, if N_eff is below the configured fault-bound requirement, the verifier enters HOLD_AHE or UNVERIFIABLE according to policy. A Byzantine median MUST NOT be used outside its declared bound. Epi-Entropy is a read-only shadow analysis. A nonzero identity ambiguity, an empty admissible bundle, or missing physical context MAY request more evidence or enter HOLD, but MUST NOT alone cause REJECT or establish physical truth. Epi-Entropy does not constitute flight validation. The research background is [DEEPSPACEPAPER]. 5.10. GRG Physical Framing Boundary The optional GRG integrity profile and a link-layer GRG framing profile are distinct contracts. The fixed PoT record is not automatically a Golay codeword stream merely because its length is divisible by three. A deployment MUST declare, before packet reception, whether GRG framing is active, which code is used, the interleaver dimensions, the Rice parameter, and the protected byte domain. This document's fixed records remain 143 octets for v1 and 180 octets for v2. The v2 record's ctx_id is 16 octets. No one-octet profile header is inserted into v1 by this document; adding 1 octet to make a 144-octet PHY frame requires a separately versioned link profile and MUST NOT be presented as the existing v1 wire format. The profile MUST identify the exact FEC code. A Golay (23,12,7) block and a binary extended Golay [24,12,8] code are not interchangeable. A deployment selecting one MUST NOT decode the other by length inference. Likewise, a 180-octet record MAY be transported in a 60-codeword frame only when the selected PHY profile explicitly defines that mapping and protected domain; the arithmetic divisibility alone is not a protocol guarantee. The current checked GRG reference path associated with this document uses Golay (23,12,7). An independent implementation of extended Golay [24,12,8] is not the current TTTPS/GRG reference path and MUST NOT be substituted without a separately identified profile, framing contract, and interoperability vectors. The octet length alone does not select either code. GRG parameter selection is session- and context-bound. The authenticated manifest MAY bind the FEC code, Rice parameter, interleaver dimensions, block ordering, padding rule, and decoder limits. The receiver MUST configure these before decoding the frame and MUST fail closed on profile mismatch, syndrome failure, malformed Rice stream, or manifest mismatch. The result is UNVERIFIABLE or HOLD according to the selected profile; FEC correction MUST NOT convert a failed cryptographic integrity result into PASS. GRG framing is below the PoT semantic verifier. After successful deinterleaving, FEC, and stream validation, the recovered fixed record is passed to the normal v1/v2 parser. Epi-Entropy and G-Score operate only after that boundary and do not control FEC decoding. 6. Transport Binding 6.1. TLS 1.3 Binding TTTPS uses the TLS Exporter mechanism [RFC5705] to derive binding material from an established TLS 1.3 session, following the model of [NTS] Section 5.1. This requires NO new TLS Extension Type codepoint and is fully backward-compatible with existing TLS 1.3 implementations. Jorgen Expires 21 February 2027 [Page 24] Internet-Draft TTTPS September 2026 Binding computation (normative), performed by both Holder and verifier: record_hash = SHA-256(pot_record) [all 180 octets] exporter_output = TLS-Exporter("EXPORTER-tttps-pot-binding", record_hash, 32) binding_input = "tttps-binding-v2" || 0x00 || exporter_output binding_proof is then computed by the Holder according to holder_auth_type (Section 2.3): 0x01: binding_proof = Ed25519.Sign(holder_sk, binding_input) (64 octets) 0x02: binding_proof = HMAC-SHA256(k_h, binding_input) (32 octets) exporter_output MUST NOT be transmitted; only binding_proof and the PoT Record are sent. Because exporter_output is derived from the TLS session's master secret [RFC5705] Section 4, a PoT captured from session A cannot be replayed into session B: recomputing binding_input in session B yields a different value, and binding_proof over session A's binding_input fails verification. Because binding_proof additionally requires holder key material the session alone does not provide, a party present in the session but not in possession of holder_sk or k_h cannot produce a valid binding_proof even for its own session -- the defect this revision corrects (Discussion Note). PoT Frame format: holder_auth_type 0x01: binding_proof(64) || pot_record(180) = 244B holder_auth_type 0x02: binding_proof(32) || pot_record(180) = 212B The verifier's procedure is given in Section 2.5. 6.2. QUIC Integration TTTPS operates over QUIC [RFC9000] post-handshake. The TLS Exporter is available after QUIC handshake completion. Jorgen Expires 21 February 2027 [Page 25] Internet-Draft TTTPS September 2026 Holder Verifier |--Initial[CRYPTO]-------------->| (TLS ClientHello) |<-Initial[CRYPTO]--------------| (TLS ServerHello) |<-Handshake[CRYPTO]------------| (TLS EncryptedExtensions) |--Handshake[CRYPTO]----------->| (TLS Finished) | | | Holder computes binding_proof| | per Section 6.1 | | | |--1-RTT[STREAM:PoT frame]----->| |<-1-RTT[STREAM:PoT-Ack]--------| PoT frames MUST be sent in a dedicated QUIC stream, identified via the HTTP/3 frame registration of Section 6.3 (Section 11.7). 6.3. HTTP/3 Frame Type Over HTTP/3 [RFC9114], PoT records are conveyed in a dedicated HTTP/3 frame type. Frame Type: 0x4C4F5400 (ASCII "LOT\0", IANA assigned, see Section 11.7) Frame Length: variable (244 octets with a type-0x01 binding_proof, 212 octets with type-0x02) Frame Body: binding_proof || PoT Record (Section 2.1) PoT frames MAY appear in any HTTP/3 request or response stream. Servers MUST NOT reject requests solely on the basis of absent PoT frames (backward compatibility). 6.4. Backward Compatibility Servers that do not implement TTTPS MUST be able to process TLS 1.3, QUIC, and HTTP/3 connections that include TTTPS binding material. TTTPS MUST NOT modify the TLS handshake in a way that causes negotiation failure with non-TTTPS peers. Implementations SHOULD use ALPN [RFC7301] extension identifier "tttps/1" (IANA registration, Section 11.2) to negotiate TTTPS capability between peers. The ALPN identifier negotiates TTTPS capability at the transport layer; it is not tied to the PoT Record version, which is negotiated separately via the version field (Section 2.2). Jorgen Expires 21 February 2027 [Page 26] Internet-Draft TTTPS September 2026 7. Asynchronous PHC Substrate TTTPS binds to any Linux PTP Hardware Clock (PHC) device conforming to IEEE 1588. The reference implementation and interoperability testing use AWS EC2 Nitro-family instances with the ENA driver, which exposes the Nitro PHC as /dev/ptp_ena; this is one specific instantiation and MUST NOT be interpreted as a normative dependency. Other supported substrates include: * Standard Linux PHC (/dev/ptp0) on any host with a synchronized hardware clock. * Google Cloud Platform Precision Time (via the Compute Engine PTP device). * Microsoft Azure Precision Time Protocol via VMBus. * On-premise Time-Sensitive Networking (TSN) NIC vendors including Intel i210/i225, Broadcom BCM577xx, and Marvell Prestera. * White-box switches implementing PTP boundary/transparent-clock roles. The reference clock read path uses the Linux dynamic clock ID convention FD_TO_CLOCKID(fd) = ((~fd) << 3) | CLOCKFD where CLOCKFD = 3, as documented in the Linux kernel's Documentation/driver-api/ ptp.rst. Implementations parameterize the device path; no code change is required to switch substrates. 7.1. Time Interval Specification The reference implementation separates responsibilities across three periodic schedules: _Hot-path event sealing (O(1), event-triggered)._ On every observed event, the application thread reads a shared-memory triple (t_ref, d_T_base, tsc_ref) that was published by the background PHC poller, then computes the sealed timestamp using the CPU TSC (Time Stamp Counter) offset. This path is non-blocking and completes in sub- microsecond wall time on contemporary x86_64 hardware; it MUST NOT invoke a kernel syscall on every event. _Background PHC polling (100 Hz to 1 kHz)._ A dedicated daemon thread reads the PHC hardware register every 1 to 10 ms via clock_gettime() on the dynamic clock ID above, retrieves the PTP lock status and driver-reported drift tolerance, and atomically publishes them into shared state using Release-ordered stores (see Section 7.3). Jorgen Expires 21 February 2027 [Page 27] Internet-Draft TTTPS September 2026 _Drift accumulation (continuous, computed on read)._ The drift bound d_T grows linearly with time since the last background poll: d_T(t_event) = d_T_base + alpha * (t_event - t_ref), where alpha is the oscillator drift rate (typically 1 ppm for Nitro NICs, higher for consumer-grade oscillators; declared per-substrate in a driver manifest). At the 10 ms polling cadence, the added drift is bounded by approximately 0.01 microseconds per interval. _Asynchronous flush (100 ms to 1 s, or 1 MB batch)._ Sealed records are buffered in a lock-free ring buffer and flushed asynchronously to durable storage (S3 Object Lock, Timestream DB, or equivalent WORM store). Flush does not block the hot path. 7.2. d_T Dynamic Accumulation Formula For a hot-path event observed at CPU-time t_event, where t_ref and d_T_base were captured at the most recent successful background PHC poll: d_T(t_event) = d_T_base + alpha * (t_event - t_ref) valid_time_interval = [ t_hw(t_event) - d_T(t_event), t_hw(t_event) + d_T(t_event) ] Two records A and B admit strict temporal ordering (A precedes B) with O(1) verification when: t_hw(B) - t_hw(A) > d_T(A) + d_T(B) Records whose intervals overlap are not strictly ordered by this construction; applications requiring a total order in that regime MUST layer an additional ordering mechanism (e.g., a sequence number in the payload) atop TTTPS. 7.3. Rust Lock-Free Atomic Reference The reference no_std core exposes the following interface: Jorgen Expires 21 February 2027 [Page 28] Internet-Draft TTTPS September 2026 use core::sync::atomic::{AtomicU64, AtomicU32, Ordering}; pub struct PhcSharedState { pub t_ref_nanos: AtomicU64, // t_ref of last poll pub tsc_ref: AtomicU64, // CPU TSC at t_ref pub d_t_base_nanos: AtomicU32, // driver-reported bound pub drift_ppm: AtomicU32, // oscillator alpha pub clock_status: AtomicU32, // 0x01 locked, 0x02 holdover } impl PhcSharedState { /// Background thread: 100 Hz to 1 kHz. pub fn publish(&self, t_hw: u64, tsc: u64, d_t: u32, status: u32) { self.t_ref_nanos.store(t_hw, Ordering::Release); self.tsc_ref.store(tsc, Ordering::Release); self.d_t_base_nanos.store(d_t, Ordering::Release); self.clock_status.store(status, Ordering::Release); } /// Hot path: sub-microsecond, no syscall. pub fn read(&self, tsc_now: u64) -> (u64, u32, u32) { let t_ref = self.t_ref_nanos.load(Ordering::Acquire); let tsc_r = self.tsc_ref.load(Ordering::Acquire); let d0 = self.d_t_base_nanos.load(Ordering::Acquire); let stat = self.clock_status.load(Ordering::Acquire); let elapsed_ns = tsc_now.saturating_sub(tsc_r); let t_hw = t_ref.wrapping_add(elapsed_ns); let d_t = d0 + (elapsed_ns / 1_000_000) as u32; (t_hw, d_t, stat) } } Full source (with Cargo manifest, benchmarks, and CI harness) is available in the reference implementation repository; see Section 13.1. 8. Tier Structure TTTPS defines four terrestrial time resolution tiers. Deep-space and Space-Air-Ground Integrated Network (SAGIN) deployment profiles, which require a propagation-delay-adaptive tolerance, are out of scope for this document; see CCSDS/TIPTOP for domain-specific profiles. Jorgen Expires 21 February 2027 [Page 29] Internet-Draft TTTPS September 2026 Tier | ID | Interval | Window | Use Case ------------|------|-----------|------------|------------------ T0_epoch | 0x0 | 6.4 min | 60 s | Epoch ordering T1_block | 0x1 | 2 sec | 2 s | Fast settlement T2_slot | 0x2 | 12 sec | 12 s | Slot ordering T3_micro | 0x3 | 100 ms | 100 ms | High-frequency 0x4-0xF | -- | -- | -- | Reserved The tier freshness window (Section 2.5, step 4) defines the maximum acceptable |now - ts| deviation, inclusive of dispersion. Submissions outside the window trigger FULL mode per Section 5.3. Fee discounts in TURBO mode are implementation-defined; reference implementation: 20% discount [OPENTTT]. 9. Security Considerations 9.1. Compromised Time Sources and Path Attacks This section addresses two threat models: compromised time sources and compromised network paths between the PoT Issuer and its sources (the standard IETF network adversary model). Compromised source: a single compromised time source biases the synthesised timestamp by at most 1/k of the manipulation, where k >= 3 is the source count. For k=4 independent sources, single-source bias impact <= 0.25 of manipulation magnitude. Compromised network path: an attacker controlling the path between the Issuer and one source can inject delayed or replayed responses. Two mitigations apply: (a) multi-source median (ts = median(T_1, ..., T_k), k >= 3, distinct administrative domains) -- a path-level attacker must simultaneously compromise paths to a majority of sources to bias the median; (b) the stratum tolerance check (Section 2.4, step 4) -- a single-path delay injection that pushes one source beyond tolerance is detected and rejected. NTS [NTS] on the path between Issuer and sources provides an additional layer of path authentication; implementations SHOULD use NTS-authenticated sources where available. Implementations MUST use sources from distinct administrative domains (e.g., a national metrology laboratory, a GNSS-disciplined source, and an NTS- authenticated source) to maximise independence. Sources from a single autonomous system MUST NOT be counted as independent. Jorgen Expires 21 February 2027 [Page 30] Internet-Draft TTTPS September 2026 9.2. Replay Prevention Each PoT Record includes a 128-bit cryptographically random nonce (Section 2.2). Verifiers MUST maintain a nonce cache, keyed on (ctx_id, nonce), for the duration of the tier freshness window. Duplicate pairs MUST be rejected. issuer_sig seals the nonce against Issuer-side forgery. Cross- session replay is additionally prevented by the TLS binding of Section 6.1. _Implementations MUST perform the nonce-cache duplicate-check and the nonce-cache insertion as a single atomic operation._ Split-phase implementations (check-then-insert without atomicity) are subject to a Time-of-Check to Time-of-Use (TOCTOU) race under concurrent request load, permitting an attacker to replay a captured record N times by issuing N concurrent verifications faster than the cache-insert phase completes. The reference implementation uses Redis with SET pot:{event_id} NX EX , which is atomic on the Redis server; equivalent atomic primitives include PostgreSQL INSERT ... ON CONFLICT DO NOTHING RETURNING, DynamoDB ConditionalPutItem, and in-process std::collections::HashSet guarded by a std::sync::Mutex. Empirical validation: a split-phase implementation deployed with 20 concurrent identical requests observed 20/20 duplicate acceptances (100 percent TOCTOU exploitation success). After conversion to atomic SET-NX, the same load produced 1 acceptance and 19 rejections, matching the correct behaviour. 9.3. Sybil Time Sources and Unique Quorum A valid signature or a fresh key does not establish a new independent physical source. Before constructing the agreement distribution, density operator, or robust aggregate, the verifier MUST validate D-chain freshness and map each stable_node_id to an authority-bound PhysicalEntity and provenance group. Duplicate labels for one physical entity count zero after the first admitted vote. The effective quorum is N_eff = | union over i in Roster PhysicalEntity(stable_node_id_i) |. Quorum and Byzantine aggregation MUST use N_eff rather than raw label or key count. The f < N_eff/2 condition MUST be checked before applying a Byzantine median. If the condition fails, the verifier MUST enter HOLD_AHE or InsufficientKnowledge and MUST NOT fabricate a quorum. This defense is bounded by the declared identity and provenance authority. It provides no universal guarantee against an attacker that can forge or compromise that authority. 9.4. Side-Channel Considerations Integrity-tag verification and Ed25519 verification MUST be implemented in constant time. Variable-time implementations risk timing side-channel attacks against secret key material. The nonce MUST be generated with a constant-time CSPRNG. Jorgen Expires 21 February 2027 [Page 31] Internet-Draft TTTPS September 2026 9.5. Byzantine Economic Attacks An attacker may attempt to manipulate ordering for economic gain (MEV). The AdaptiveSwitch V* threshold (Section 5.4) ensures that for V < V*_min = $8.67, ordering spam is eliminated in the unique Nash equilibrium. Attackers with V >= V*_max = $87.13 may find manipulation economically rational at the margin; PoT reduces expected spam for such cases by a factor of c_PoT / c_0 (Section 5.4). 9.6. Delay-Based Temporal Attacks [NTS] Section 8.6 identifies delay attacks as a primary threat to time synchronisation security. TTTPS addresses this through two complementary gates, applied in sequence (Section 2.5): (1) Integrity-tag gate: a PoT generated under context ctx_id cannot be presented in a different context ctx_id' without the integrity check failing, because ctx_id is part of the protected octets (Section 4.1). This is analogous to the cookie freshness mechanism of [NTS] Section 5.4. (2) AdaptiveSwitch freshness gate (Section 5.3): a PoT submitted outside the tier freshness window is rejected regardless of cryptographic validity, and FULL mode is triggered immediately. FILO+Integrity processing discipline: among PoT records that pass both gates, the most recently generated qualifying submission is processed first, creating an adverse incentive for delay attackers -- a delayed-but-valid PoT that bypasses the integrity gate is rejected at the freshness gate, and a PoT that passes both gates competes at a recency disadvantage against honest peers. Together: a delayed PoT fails the freshness gate and triggers FULL mode; repeated FULL mode triggers exponential backoff; backoff cost exceeds MEV opportunity for V < V*. The full flow is diagrammed in Appendix D. 9.7. Integrity Algorithm Security The core SHA-256 algorithm has no correction capability and its security depends on its standard cryptographic assumptions. Optional GRG security and correction properties are profile-specific and MUST NOT be inferred by a core verifier. The Confidence profile [CONFIDENCE] is the source for any GRG interface claims; this core makes no independent GRG security claim. Jorgen Expires 21 February 2027 [Page 32] Internet-Draft TTTPS September 2026 Implementations MUST NOT expose internal algorithm state, shard values, or intermediate pipeline results through public APIs or error messages. 9.8. Path Manipulation An adversary controlling only network paths (not the Issuer's Ed25519 private key, nor holder key material) cannot produce a PoT that passes verification: context binding (Section 4.1) rejects cross- context replay, the freshness gate (Section 2.5, step 4) rejects path-induced delay beyond the tier window, and the TLS binding (Section 6.1) rejects cross-session replay because binding_proof requires holder key material the path attacker does not possess. This holds independent of the network-layer substrate the PoT traverses, including legacy signaling gateways; a detailed per- substrate scenario walkthrough is out of scope for this revision. 9.9. Trust Model and Key Compromise Resilience 9.9.1. Trust Hierarchy TTTPS defines a two-level trust hierarchy: Level 0 (L0) Certificate Authority: An L0 CA issues certificates to PoT Issuers. Verifiers trust L0 CA public keys, published in a transparency log (analogous to Certificate Transparency [RFC6962]). Level 1 (L1) PoT Issuer: An L1 Issuer holds an Ed25519 key pair certified by an L0 CA, identified on the wire by issuer_key_id (Section 2.2). The Issuer generates PoT Records (Section 2.4) and signs them with its private key. Verifier: Any party that receives a (binding_proof, PoT Record) pair and verifies it per Section 2.5. This model is analogous to TLS PKI: L0 CAs are root CAs, L1 Issuers are intermediate CAs, and verifiers are TLS clients. Jorgen Expires 21 February 2027 [Page 33] Internet-Draft TTTPS September 2026 9.9.2. Issuer Key Compromise Response If an L1 Issuer's Ed25519 private key is compromised: (1) Key rotation -- the L0 CA revokes the compromised certificate and issues a new one under a new issuer_key_id (Section 2.2), which verifiers use to select the correct public key without ambiguity. (2) Transparency audit -- all PoTs generated by the compromised key are logged with their timestamps; third parties can determine which PoTs were generated before versus after the compromise window. (3) Source independence -- the multi-source median (Section 2.4) provides an independent check on Issuer-reported timestamps; even after key compromise, the attacker cannot generate PoTs with timestamps outside the source consensus window without also compromising k/2 sources. 9.9.3. Untrusted Substrate Guarantee TTTPS provides the following formal guarantee: for any adversary A controlling at most k/2 - 1 time sources, at most one L0 CA, and any subset of network paths, and not in possession of any Holder's private key material, A cannot (a) generate a PoT with ts' != ts that passes verification with probability > 2^{-61}; or (b) replay a valid (binding_proof, PoT) pair into a different TLS session; or (c) cause the freshness gate to accept a PoT submitted outside the tier window; or (d) link PoT records from different sessions to the same Holder. This guarantee holds under the assumption that Ed25519 satisfies EUF- CMA with 128-bit security and that HMAC-SHA256 is a PRF; neither assumption requires trust in the underlying network layer. 10. Privacy Considerations 10.1. Unlinkability PoT Records include a 128-bit random nonce (Section 2.2) that MUST be freshly generated for each record. This prevents linkage of PoT Records from the same Issuer across sessions. The TLS binding of Section 6.1 ensures PoT Records are bound to specific TLS sessions and cannot be used to correlate activity across sessions. Issuers SHOULD NOT include in PoT Records any information beyond the fields defined in Section 2.2 that could enable participant identification. 10.2. Minimal Disclosure The PoT Record wire format (Section 2.1) does not include participant identity or address, transaction content, or economic parameters or bid values beyond holder_auth_data, which identifies only the Holder's public key or a shared-secret digest, not a real-world identity. ctx_id is an opaque, application-assigned context identifier and a public, non-sensitive value; because it is an opaque Jorgen Expires 21 February 2027 [Page 34] Internet-Draft TTTPS September 2026 string to the protocol, its semantics can be extended by application convention without any change to the wire format (Section 2) or the integrity binding (Section 4). 11. IANA Considerations 11.1. TLS Exporter Labels Registry IANA is requested to add the following entry to the "TLS Exporter Labels" registry [RFC5705]: Label: EXPORTER-tttps-pot-binding DTLS-OK: Y Recommended: Y Reference: [this document] Section 6.1 11.2. ALPN Protocol ID Registration IANA is requested to add the following entry to the "TLS Application- Layer Protocol Negotiation (ALPN) Protocol IDs" registry [RFC7301]: Protocol: TTTPS over TLS 1.3 Identification Sequence: 0x74 0x74 0x74 0x70 0x73 0x2F 0x31 ("tttps/1") Reference: [this document] Section 6.4 11.3. TTTPS Tier Registry IANA is requested to create a new registry "TTTPS Tier Identifiers" with the following initial values: Value | Name | Interval | Reference ------|-------------|-----------|------------------ 0x0 | T0_epoch | 6.4 min | [this document] 0x1 | T1_block | 2 sec | [this document] 0x2 | T2_slot | 12 sec | [this document] 0x3 | T3_micro | 100 ms | [this document] 0x4-F | Reserved | -- | [this document] Registration procedure: Specification Required. 11.4. Time Source Type Registry IANA is requested to create a new registry "TTTPS Time Source Types" with the following initial values. Entries identify source classes rather than named operators, so that neither this document nor deployments depend on or endorse any specific organisation: Jorgen Expires 21 February 2027 [Page 35] Internet-Draft TTTPS September 2026 Value | Name | Reference ------|--------------------------|------------------ 0x01 | national-metrology-lab | [this document] 0x02 | gnss-disciplined | [this document] 0x03 | roughtime-authenticated | [this document] 0x04 | ntp-authenticated-nts | [this document] 0x05 | ptp-grandmaster | [this document] 0x06-FE | Unassigned | Specification Required 0xFF | Private Use | [this document] 11.5. Integrity Algorithm ID Registry IANA is requested to create a new registry "TTTPS Integrity Algorithm IDs" with the following initial values: Value | Name | Status | Reference -------------|--------|----------|------------------- 0x0000 | Reserved | -- | [this document] 0x0001 | SHA-256 | MTI | [this document] App. B.1 0x0002-FFFF | Unassigned | -- | Specification Required This core document does not assign a GRG codepoint. A future profile registration MUST identify its profile document and satisfy the applicable IETF review and IPR-disclosure requirements. 11.6. Holder Authentication Type Registry IANA is requested to create a new registry "TTTPS Holder Authentication Types" with the following initial values: Value | Name | Status | Reference -------|----------------|----------|------------------ 0x01 | Ed25519 pubkey | MTI | [this document] 0x02 | Shared secret | OPTIONAL | [this document] 0x03-FE| Unassigned | -- | Specification Required 0xFF | Private Use | -- | [this document] 11.7. HTTP/3 Stream Types IANA is requested to add the following entry to the HTTP/3 Frame Types registry: Type: TBD (to be assigned by IANA; 0x4C4F5400 proposed) Name: TTTPS_POT_FRAME Reference: [this document] Section 6.3 Note: Implementations MUST use the IANA-assigned value. Jorgen Expires 21 February 2027 [Page 36] Internet-Draft TTTPS September 2026 11.8. URI Scheme Registration IANA has provisionally registered the URI scheme "tttps" in the "Uniform Resource Identifier (URI) Schemes" registry [RFC7595]: Scheme: tttps Status: Provisional Reference: [this document] URI: https://www.iana.org/assignments/uri-schemes/prov/tttps Per [RFC7595] Section 3.3, this provisional registration does not imply endorsement by the IETF. Permanent registration will be requested upon publication of this document as an RFC. 12. Intellectual Property The core SHA-256 integrity mode is completely specified in Appendix B.1, and the optional GRG profile is not required for conformance. GRG is maintained independently in the Confidence track [CONFIDENCE]. IPR matters are handled only through the IETF disclosure process specified by BCP 79 [RFC8179]; this document makes no determination about the validity or scope of any IPR claim. 13. Implementation Status This section records the status of known implementations of TTTPS at the time of posting, per [RFC7942]. 13.1. Reference Implementation Name: OpenTTT URL: https://github.com/Helm-Protocol/OpenTTT Level: Partial (verifier SDK, QUIC transport) Coverage recorded at the time of the v1 wire format (143-octet PoT record): PoT wire format, 12/12 tests; integrity pipeline external interface, 4/4 integration tests; AdaptiveSwitch, TLA+-verified, 9/9 tests; QUIC transport / TLS binding, implemented with quinn 0.11, ALPN tttps/1, measured RTT ~494 us on loopback; source-median synthesis, 8/8 tests; no_std verifier, IoT/ARM compatible, 10/10. Jorgen Expires 21 February 2027 [Page 37] Internet-Draft TTTPS September 2026 Total: 99 tests passing, 0 failing (April 2026). The v2 record format (Section 2) is specified in this revision; implementation coverage of v2 will be recorded in a subsequent revision. Private Issuer implementation: Name: Helm grg-core (reported profile implementation) Level: Not a core-conformance claim Note: Any GRG implementation status belongs to the independent Confidence profile and is not evidence of core TTTPS conformance. 13.2. Deployment Evidence A PoT Issuer compliant with an earlier revision of this document has been operated experimentally. The following data were collected: Total PoT records generated: 70,612 Collection period: October 2025 -- April 2026 AI agent-originated records: 55% (38,837 records) Human-originated records: 45% (31,775 records) Mean generation latency: 47 ms (TURBO mode) Mean generation latency: 127 ms (FULL mode) TURBO / FULL split: 62% / 38% Zero cryptographic failures in 70,612 records. The 55% AI agent fraction was unanticipated and constitutes empirical evidence that the ordering problem is already operational in agent economies, not merely theoretical. 13.3. Formal Verification Artifacts This subsection records publicly available formal-verification artifacts relevant to the TTTPS confidence and InsufficientKnowledge primitives. These artifacts are informational; they are not required for protocol conformance. * kenoslean (Python Package Index, version 0.1.0): a publicly published package of machine-verified computational contracts, with the underlying properties formalised in Lean 4 / Mathlib [KENOSLEAN]. The library is sorry-free for the contracts it exposes. * G-Score / InsufficientKnowledge primitive: formalised in Lean 4 as the normalised Shannon entropy G(p) = H(p) / log n. The formalisation is sorry-free and machine-checked, and proves 0 <= G(p) <= 1, G(uniform) = 1, and G(point mass) = 0. Jorgen Expires 21 February 2027 [Page 38] Internet-Draft TTTPS September 2026 * von Neumann extension: the OPTIONAL density-matrix confidence form S(rho) = -Tr(rho log rho) (Section 5.5) is specified and unit- tested, with a sorry-free Lean 4 formalisation proving it equals the Shannon G-Score on independent sources and is strictly lower under correlation. Live AdaptiveSwitch integration of this gate is pending source time-value distribution instrumentation. Scope note: "machine-verified" here means the stated Lean 4 properties are checked by the Lean kernel against Mathlib; it does not assert verification of the integrity algorithm implementations, which are addressed separately in Appendix B. 13.4. Interested Parties This subsection records organisations that have expressed interest in the deployment scenarios described in Section 1.6. Inclusion here does not constitute endorsement of any specific version of this draft. At the time of this revision, no interested-party statements have been received. Authors request that organisations wishing to be listed contact the authors directly; a non-binding expression of interest in the stated use cases is sufficient for inclusion. 14. Roadmap The following companion profiles are published in parallel with this revision and are cited informatively: * draft-helmprotocol-deepspace-00: propagation-aware OWLT, physical context, integer-preserving correction, sparse-peer handling, and conservative Epi-Entropy shadow qualification. * draft-helmprotocol-confidence-00: G-Score, correlation-aware von Neumann confidence, Epi-Entropy, AdaptiveSwitch, and InsufficientKnowledge semantics. * GRG-specific integrity mode extensions are maintained in the independent Confidence profile; the core remains vendor-neutral. This revision integrates the profile control rules in Sections 5.6-5.9 and cites the companion drafts and papers in Section 15.2. Profile processing is optional; the core wire record and cryptographic integrity boundary remain unchanged. 15. References 15.1. Normative References Jorgen Expires 21 February 2027 [Page 39] Internet-Draft TTTPS September 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, March 2010, . [RFC7301] Friedl, S., "Transport Layer Security (TLS) Application- Layer Protocol Negotiation Extension", RFC 7301, July 2014, . [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", RFC 7595, BCP 35, June 2015, . [RFC8179] Bradner, S. and J. Contreras, "Intellectual Property Rights in IETF Technology", BCP 79, RFC 8179, May 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8126] Cotton, M., "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, June 2017, . [NTS] Franke, D., "Network Time Security for the Network Time Protocol", RFC 8915, September 2020, . [RFC9000] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, May 2021, . [RFC9114] Bishop, M., "HTTP/3", RFC 9114, June 2022, . 15.2. Informative References Jorgen Expires 21 February 2027 [Page 40] Internet-Draft TTTPS September 2026 [Bernstein2012] Bernstein, D.J., "High-speed high-security signatures", J. Cryptogr. Eng. 2, 77-89, 2012. [Castro1999] Castro, M. and B. Liskov, "Practical Byzantine Fault Tolerance", OSDI, 173-186, 1999. [Messias2025] Messias, J. and C.F. Torres, "The express lane to spam and centralization: an empirical analysis of Arbitrum's Timeboost", arXiv:2509.22143, 2025, . [OPENTTT] Helm Protocol, "OpenTTT SDK", npm install openttt, 2026, . [POT2026] Jorgen, H., "Proof-of-Time: Byzantine-Resilient Temporal Ordering in Untrusted Networks", Work in Progress, draft-helmprotocol-tttps-00, March 2026. [CONFIDENCE] Jorgen, H., "Oracle Confidence Gating: G-Score, Correlation-Aware von Neumann Confidence, and AdaptiveSwitch," Work in Progress, draft-helmprotocol-confidence-00, September 2026, . [DEEPSPACE] Jorgen, H., "TTTPS Deep-space Profile: Propagation-Aware Time Attestation," Work in Progress, draft-helmprotocol-deepspace-00, September 2026, . [CONFIDENCEPAPER] Jorgen, H., "Oracle Confidence Gating for TTTPS: G-Score, Correlation-Aware von Neumann Confidence, and AdaptiveSwitch," SSRN abstract 7487098, 2026, CC BY, . [DEEPSPACEPAPER] Jorgen, H., "Interplanetary Time Attestation Under Light-Time Delay," SSRN abstract 7487038, 2026. Jorgen Expires 21 February 2027 [Page 41] Internet-Draft TTTPS September 2026 [GLASSWING] Anthropic, "Project Glasswing: Securing Critical Software for the AI Era", April 2026, . [Zhang2026] Zhang, J., "Hyperagents", arXiv:2603.19461, 2026, . [SS7-VULN] Positive Technologies, "SS7 Vulnerabilities and Attack Exposure Report", 2020, . [GSMA-SS7] GSMA, "SS7 and SIGTRAN Network Security", GSMA document FS.11, November 2015, . [GPS-SPOOF] Humphreys, T., "Statement on the Vulnerability of Civil Unmanned Aerial Vehicles and Other Systems to Civil GPS Spoofing", University of Texas Radionavigation Laboratory, 2012. [RFC6962] Laurie, B., "Certificate Transparency", RFC 6962, June 2013, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, July 2016, . [I-D.ietf-ntp-roughtime] Ladd, W. and M. Dansarie, "Roughtime", Work in Progress (draft-19). RFC Editor Queue; intended status Experimental (status verified on the IETF Datatracker, June 2026), Work in Progress, Internet-Draft, draft-ietf-ntp-roughtime-19, 2026, . Jorgen Expires 21 February 2027 [Page 42] Internet-Draft TTTPS September 2026 [I-D.ietf-rats-msg-wrap] Birkholz, H., "RATS Conceptual Messages Wrapper (CMW)", Work in Progress. RFC Editor Queue (status verified on the IETF Datatracker, June 2026), Work in Progress, Internet- Draft, draft-ietf-rats-msg-wrap-23, 2026, . [KENOSLEAN] Kenosian, "kenoslean: machine-verified computational contracts, Lean 4 / Mathlib", Python Package Index, version 0.1.0, 2026, . [IEEE1588] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Std 1588-2019. Appendix A. AdaptiveSwitch TLA+ Specification The following TLA+ module formally specifies the AdaptiveSwitch state machine. The module is verified by the TLC model checker with parameters MaxNodes=3, MaxBlocks=10, TierToleranceMs=100, TurboEntry=95, TurboMaintain=85. The module specifies: * TypeInvariant: all five state variables are well-typed. * S1 (NoForcedTurbo): TURBO requires match_rate >= 85 AND fail_count = 0 -- conjunction, not disjunction. * S2 (DelayRejectionTriggersFull): submission outside tier tolerance is incompatible with TURBO. * S3 (FailureExcludesTurbo): any integrity failure forces FULL. * L1 (EventualTurbo): a node with sustained good behaviour eventually reaches TURBO (liveness under weak fairness). EnvStep models the environment updating match_rate, fail_count, and submission_delay nondeterministically, ensuring the invariants hold under all adversarial input sequences. Jorgen Expires 21 February 2027 [Page 43] Internet-Draft TTTPS September 2026 ---- MODULE AdaptiveSwitch ---- EXTENDS Naturals, FiniteSets CONSTANTS MaxNodes, MaxBlocks, TurboEntry, TurboMaintain, TierToleranceMs ASSUME /\ TurboEntry = 95 \* 95% match_rate required for TURBO /\ TurboMaintain = 85 \* 85% minimum to stay in TURBO /\ TierToleranceMs > 0 \* positive tier tolerance (ms) NodeId == 1..MaxNodes \* finite set of node identifiers Modes == { "TURBO", "FULL" } VARIABLES node_mode, \* [NodeId -> Modes] per-node state match_rate, \* [NodeId -> 0..100] ordering-match percentage fail_count, \* [NodeId -> Nat] consecutive failures block_count, \* Nat current block number submission_delay \* [NodeId -> Nat] ms since last PoT gen vars == <> \* -- Helpers ------------------------------------------------------ SubmittedOutsideTolerance(n) == submission_delay[n] > TierToleranceMs \* -- Type correctness --------------------------------------------- TypeInvariant == /\ node_mode \in [NodeId -> Modes] /\ match_rate \in [NodeId -> 0..100] /\ fail_count \in [NodeId -> Nat] /\ block_count \in Nat /\ submission_delay \in [NodeId -> Nat] \* -- Initial state (all nodes start in FULL, zero counters) ------- Init == /\ node_mode = [n \in NodeId |-> "FULL"] /\ match_rate = [n \in NodeId |-> 0] /\ fail_count = [n \in NodeId |-> 0] /\ block_count = 0 /\ submission_delay = [n \in NodeId |-> 0] \* -- Actions ------------------------------------------------------ \* Promote n from FULL to TURBO when match_rate sufficient \* and no pending failures. PromoteToTurbo(n) == Jorgen Expires 21 February 2027 [Page 44] Internet-Draft TTTPS September 2026 /\ node_mode[n] = "FULL" /\ match_rate[n] >= TurboEntry /\ fail_count[n] = 0 /\ ~SubmittedOutsideTolerance(n) /\ node_mode' = [node_mode EXCEPT ![n] = "TURBO"] /\ UNCHANGED <> \* Demote n from TURBO to FULL on poor match_rate, integrity \* failure, or submission outside tier tolerance. DemoteToFull(n) == /\ node_mode[n] = "TURBO" /\ \/ match_rate[n] < TurboMaintain \/ fail_count[n] > 0 \/ SubmittedOutsideTolerance(n) /\ node_mode' = [node_mode EXCEPT ![n] = "FULL"] /\ UNCHANGED <> \* Environment step: update match_rate / fail_count / delay \* (models external inputs; unconstrained for model checking) EnvStep(n, mr, fc, sd) == /\ match_rate' = [match_rate EXCEPT ![n] = mr] /\ fail_count' = [fail_count EXCEPT ![n] = fc] /\ submission_delay' = [submission_delay EXCEPT ![n] = sd] /\ block_count' = block_count + 1 /\ UNCHANGED node_mode Next == \E n \in NodeId : \/ PromoteToTurbo(n) \/ DemoteToFull(n) \/ \E mr \in 0..100, fc \in 0..5, sd \in 0..(TierToleranceMs+50) : EnvStep(n, mr, fc, sd) Spec == Init /\ [] (Next \/ UNCHANGED vars) /\ WF_vars(Next) \* -- Safety invariants -------------------------------------------- \* S1: TURBO requires healthy match_rate AND no integrity failures. NoForcedTurbo == \A n \in NodeId : node_mode[n] = "TURBO" => /\ match_rate[n] >= TurboMaintain /\ fail_count[n] = 0 \* S2: Delay outside tier tolerance must not coexist with TURBO. Jorgen Expires 21 February 2027 [Page 45] Internet-Draft TTTPS September 2026 DelayRejectionTriggersFull == \A n \in NodeId : SubmittedOutsideTolerance(n) => node_mode[n] = "FULL" \* S3: fail_count > 0 must not coexist with TURBO. FailureExcludesTurbo == \A n \in NodeId : fail_count[n] > 0 => node_mode[n] = "FULL" \* -- Liveness ----------------------------------------------------- \* L1: A node with sustained good behaviour eventually reaches TURBO. EventualTurbo == \A n \in NodeId : (match_rate[n] >= TurboEntry /\ fail_count[n] = 0 /\ ~SubmittedOutsideTolerance(n)) ~> node_mode[n] = "TURBO" \* -- TLC model values (for model checking) ------------------------ \* MaxNodes = 3, MaxBlocks = 10, TierToleranceMs = 100 \* TurboEntry = 95, TurboMaintain = 85 ==== The invariant NoForcedTurbo corresponds to Safety Property S4 of the Helm Autonomy Layer Yellow Paper v2.0 (AS score external immutability). Appendix B. Integrity Algorithm Registry Specification This appendix specifies the core SHA-256 integrity algorithm. Optional profile algorithms are not defined by this appendix; the GRG profile is maintained in the independent Confidence track [CONFIDENCE]. B.1. alg_id 0x0001 -- SHA-256 (Mandatory-to-Implement) This algorithm is completely and publicly specified and MUST be implemented by all conformant implementations. integrity_tag = SHA-256(pot_record[0:80]) where pot_record[0:80] denotes octets 0 through 79 of the PoT Record (version through holder_auth_data, Section 2.1). Because the integrity_tag field is exactly 32 octets, the full SHA-256 output is used with no truncation. Verification: the verifier recomputes SHA-256(pot_record[0:80]) and compares it against integrity_tag. A match yields the *intact* verdict; a mismatch yields *unresolvable* (this algorithm has no Jorgen Expires 21 February 2027 [Page 46] Internet-Draft TTTPS September 2026 correction capability, so the *resolved* verdict of Section 2.5 never applies to it). Detection bound: P(undetected single-bit modification) <= 2^{-256} under the random-oracle idealisation of SHA-256. B.2. Optional GRG Profile The optional GRG integrity profile is specified in the independent Confidence track [CONFIDENCE]. The core document intentionally does not reproduce its stage construction, parameters, correction claims, or implementation requirements. A core implementation remains conformant without GRG. B.3. Registering New Algorithms New alg_id values are registered under Specification Required (Section 11.5). A registration MUST specify: the computation of integrity_tag from the protected octets; the detection (and, if applicable, correction) guarantee, stated as a probability bound; and whether the algorithm is Mandatory-to-Implement, RECOMMENDED, or OPTIONAL. Jorgen Expires 21 February 2027 [Page 47] Internet-Draft TTTPS September 2026 Appendix C. Test Vectors Test vectors for the core PoT generation and verification are provided as property-based tests. Optional profile test vectors belong to their respective profile documents. Required properties (all MUST pass): C.1 Core integrity verification: Verify(Generate(P, ctx), ctx) = intact for the SHA-256 profile. C.2 Nonce uniqueness: Two calls to Generate() MUST NOT produce equal nonces. C.3 Context separation: integrity_tag(P, ctx_A) != integrity_tag(P, ctx_B) for ctx_A != ctx_B (negligible probability of collision). C.4 Verification correctness: Verify(Generate(P, ctx), ctx) = intact. C.5 Forgery resistance: Verify(tampered_record, ctx) = unresolvable for any single-bit modification exceeding the algorithm's correction capacity. C.6 Delay rejection: A PoT submitted at ts + tier_window + dispersion + 1 microsecond MUST trigger FULL mode. C.7 Integrity-first ordering: Integrity-tag verification (Section 2.5, step 3) MUST complete, and MUST yield unresolvable on failure, before issuer_sig or binding_proof are attempted (measurable via timing). Reference test suite: 365 tests, 31 suites, 100% pass rate [OPENTTT] (recorded against the v1 wire format; v2 coverage will be recorded in a subsequent revision). The test suite uses property-based testing only (no deterministic byte vectors). Appendix D. FILO+Integrity Delay Rejection Flow This appendix provides a normative ASCII diagram of the FILO+Integrity delay rejection mechanism described in Section 9.6. Jorgen Expires 21 February 2027 [Page 48] Internet-Draft TTTPS September 2026 TIME AXIS: |----ts-----|---(ts+window)---|---------(ts+Delta)-------> PoT gen tier freshness delayed submission time window end zone VALID SUBMISSION WINDOW: [ts, ts + tier_window + dispersion] DELAYED ZONE: (ts + tier_window + dispersion, infinity) GATE 1: Integrity-tag verification (fixed cost, alg_id-dependent) -------------------------------------------------- Input: PoT Record If integrity_tag verdict is unresolvable: -> REJECT immediately -> DO NOT invoke issuer_sig or binding_proof verification Covers: wrong context, tampered payload GATE 2: AdaptiveSwitch freshness check -------------------------------------------------- Input: PoT Record + current time S If (S - ts) > tier_window + dispersion: -> REJECT -> Trigger FULL mode -> Apply exponential backoff Covers: valid PoT submitted outside freshness window FILO QUEUE (Gate 1 AND Gate 2 passed) -------------------------------------------------- Queue discipline: most recently generated PoT first. If multiple PoTs qualify: Select max(PoT.ts) for processing. Earlier PoTs remain in queue. Effect on delay attackers: o Cannot pass Gate 2 (freshness check rejects) o Even if somehow past Gate 2, lose priority to fresher PoTs o Repeated failures -> exponential backoff -> self-defeating COMPLEXITY NOTE: Gate 1 (integrity tag): O(1) per record, fixed cost Gate 2 (freshness): O(1) per record Queue ordering: O(log q) for q queued records (priority queue) Total per-record: O(1) -- independent of network size n Compare with BFT consensus protocols: PBFT/Tendermint/HotStuff: O(n^2) network-wide message Jorgen Expires 21 February 2027 [Page 49] Internet-Draft TTTPS September 2026 exchanges to reach Byzantine TOLERANCE (tolerate f < n/3 Byzantine nodes) for n total nodes. TTTPS achieves Byzantine ELIMINATION at O(1) per record. Attacker economic cost increases as the V* threshold makes manipulation irrational (E[profit] < 0 for V < $8.67). Attacker backoff cost: O(2^f) blocks for f failures. Network scaling: 100 nodes -> 1,000,000 nodes: BFT cost grows 10^8x; TTTPS per-record cost unchanged. Acknowledgements The authors thank the IETF dispatch list reviewers for feedback on earlier TTTPS drafts. Optional integrity profiles are maintained in the independent Confidence track. Author's Address Heime Jorgen Kenosian Email: heime.jorgen@proton.me Jorgen Expires 21 February 2027 [Page 50]