The TLS TimeToken Secure Protocol (tttps://)
draft-helmprotocol-tttps-09
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | 장동호 | ||
| Last updated | 2026-08-20 | ||
| RFC stream | Independent Submission | ||
| Intended RFC status | Experimental | ||
| Formats | |||
| Stream | ISE state | In ISE Review | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-helmprotocol-tttps-09
Network Working Group H. Jorgen
Internet-Draft Kenosian
Intended status: Experimental 20 August 2026
Expires: 21 February 2027
The TLS TimeToken Secure Protocol (tttps://)
draft-helmprotocol-tttps-09
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 high-assurance integrity mode (GRG) remains
subject to pending patent proceedings and is specified only at the
abstract-interface level pending their conclusion.
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 -06:
Jorgen Expires 21 February 2027 [Page 1]
Internet-Draft TTTPS August 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, free of any licensing
condition. alg_id 0x0100 (GRG, detection-and-correction) remains
OPTIONAL and interface-only pending conclusion of the patent
proceedings referenced in Section 12.
* 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 August 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 [RFC8915], [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 August 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. GRG Stage Ordering Rationale . . . . . . . . . . . . . . 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 August 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 . . . . . . . . . . . . . . . . . . . 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. alg_id 0x0100 -- GRG (OPTIONAL) . . . . . . . . . . . . . 47
B.3. Registering New Algorithms . . . . . . . . . . . . . . . 47
Jorgen Expires 21 February 2027 [Page 5]
Internet-Draft TTTPS August 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 August 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 [RFC8915],
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 [RFC8915] 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 August 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 RFC 8915 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 August 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:
* Concrete implementation of the OPTIONAL GRG integrity algorithm
(covered by pending patent; see Section 12)
* 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 August 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. alg_id 0x0100 (GRG:
Golomb-Rice -> Reed-Solomon -> Golay(23,12,7) -> HMAC) is OPTIONAL
and additionally corrects bounded bit errors. See Section 4 and
Appendix B.
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 August 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 August 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 [8915] | No | No | No | Yes
PTP [1588] | 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 August 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 August 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 August 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 August 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.
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. Detects, and for alg_id 0x0100
additionally corrects, modification of the preceding fields.
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 August 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 August 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 identified by alg_id to octets 0-79 and compare against
integrity_tag. The result is one of three verdicts: *intact*
(payload unmodified), *resolved* (alg_id 0x0100 only: bounded bit
errors corrected, recovered payload confirmed), 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 August 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 (0x0001 / 0x0100) |
| 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 August 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 August 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).
Two algorithms are defined in this document:
alg_id 0x0001 -- SHA-256 (Mandatory-to-Implement):
Detection-only. Fully and publicly specified in Appendix B.1,
with no licensing condition. All conformant implementations MUST
support this algorithm.
alg_id 0x0100 -- GRG (OPTIONAL):
Detection-and-correction, via the Golomb-Rice -> Reed-Solomon ->
Golay(23,12,7) -> HMAC pipeline. RECOMMENDED for deployments
where retransmission is costly or impossible (e.g., store-and-
forward links). The abstract interface and external properties
are specified in Appendix B.2; the internal stage implementation
remains unpublished pending conclusion of the patent proceedings
referenced in Section 12.
Implementations of any registered algorithm MUST satisfy, at minimum:
* Detection: a single-bit modification to the protected octets is
detected with probability >= 1 - 2^{-61} (0x0001: exactly; 0x0100:
via the context-binding bound of Appendix B.2).
* 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 August 2026
New alg_id values are registered under Specification Required
(Section 11.5).
4.2. GRG Stage Ordering Rationale
For alg_id 0x0100, the internal stage ordering Golomb-Rice (G_1) ->
Reed-Solomon (R) -> Golay(23,12,7) (G_2) -> HMAC (H) is
mathematically necessary: G_1 before R yields byte-aligned, GF(2^8)-
optimal symbol boundaries; R before G_2 supplies the fixed-size
shards Golay requires with zero waste; G_2 before H means HMAC seals
the error-corrected shards. Any permutation degrades a provably
tight property. The full proofs (Theorems 1-3) and the deep-space
engineering heritage motivating the code choices (Golomb-Rice: JPL
compression; Reed-Solomon: Cassini and Mars rovers; Golay(23,12,7):
the perfect-code core of the Voyager Saturn transmissions) are given
in the companion paper [POT2026] and are not reproduced here.
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 August 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 August 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.
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
[RFC8915] 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 August 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) [64B]
0x02: binding_proof = HMAC-SHA256(k_h, binding_input) [32B]
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 August 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 August 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 August 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 August 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 August 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 [RFC8915] 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 August 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
<ttl>, 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
An attacker controlling multiple time sources may attempt a Sybil
attack on the synthesis median. The median is resistant to Sybil
attacks when fewer than k/2 sources are compromised, for k >= 3.
Implementations using k=4 are resistant to any single-source
compromise.
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 August 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
[RFC8915] 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 [RFC8915] 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
For alg_id 0x0100 (GRG): P(detect Byzantine manipulation) >= 1 -
2^{-61}, following from P(forge_i) = 2^{-64} per shard (PRF security
of HMAC [Bellare1996]) and a union bound over 6 shards: P(forge all)
<= 6 * 2^{-64} < 2^{-61}. For alg_id 0x0001 (SHA-256): detection
relies on second-preimage resistance, P(undetected modification) <=
2^{-256} in the random-oracle idealisation, with no correction
capability. Both transform SCCP from P(detect) < 1 (Shannon model)
to a cryptographically bounded detection probability.
Jorgen Expires 21 February 2027 [Page 32]
Internet-Draft TTTPS August 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 August 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 August 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 August 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-00FF | Unassigned | -- | Specification Required
0x0100 | GRG | OPTIONAL | [this document] App. B.2
0x0101-FFFF | Unassigned | -- | Specification Required
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 August 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 Mandatory-to-Implement (MTI) integrity mode (alg_id 0x0001, SHA-
256) is completely and publicly specified in Appendix B.1, with zero
licensing conditions, royalty obligations, or encumbrances.
Complete, interoperable implementations of TTTPS can be deployed
solely using the MTI specification and the open reference code
[OPENTTT].
The OPTIONAL GRG integrity algorithm (alg_id 0x0100) is specified at
the abstract-interface level in Section 4.1 and Appendix B.2.
Certain internal stage optimizations of GRG are subject to pending
patent applications. Full internal stage disclosures will be
submitted upon conclusion of patent proceedings (targeted Q3 2026).
All IPR disclosures relating to this specification are filed in
accordance with BCP 79.
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 August 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
Level: Complete (Issuer with GRG pipeline, Ed25519 signing)
Tests: 72 tests passing, 0 failing
Note: GRG pipeline internal implementation not published pending
patent proceedings (Section 12). Abstract interface (Section
4.1) is sufficient for independent implementation.
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 August 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 material is developed on the companion Independent
Submission draft series, published in parallel with -09:
* draft-helmprotocol-tttps-deepspace: TTTPS extensions for high-
latency, high-drift environments (space-relay, terrestrial- relay,
bounded-connectivity edge deployment).
* draft-helmprotocol-tttps-confidence: formal treatment of the
oracle-confidence signal alluded to in Section 5.5, including
derivation of the cross-round correlation metric.
* GRG-specific integrity mode extensions: normative parameters and
interoperability profiles for GRG-suite deployments; kept in the
companion series to preserve the vendor-neutral profile of the
main draft.
draft-10 will fold review feedback on -09, publish reference-
implementation benchmark artifacts substantiating Section 13.2, and
integrate the companion drafts either by reference or by merging as
appendices depending on Independent Submission Editor guidance.
15. References
15.1. Normative References
Jorgen Expires 21 February 2027 [Page 39]
Internet-Draft TTTPS August 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, March 2010,
<https://www.rfc-editor.org/info/rfc5705>.
[RFC7301] Friedl, S., "Transport Layer Security (TLS) Application-
Layer Protocol Negotiation Extension", RFC 7301, July
2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
and Registration Procedures for URI Schemes", RFC 7595,
BCP 35, June 2015,
<https://www.rfc-editor.org/info/rfc7595>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8126] Cotton, M., "Guidelines for Writing an IANA Considerations
Section in RFCs", BCP 26, RFC 8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 8447, August 2018,
<https://www.rfc-editor.org/info/rfc8447>.
[RFC8915] Franke, D., "Network Time Security for the Network Time
Protocol", RFC 8915, September 2020,
<https://www.rfc-editor.org/info/rfc8915>.
[RFC9000] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", RFC 9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9114] Bishop, M., "HTTP/3", RFC 9114, June 2022,
<https://www.rfc-editor.org/info/rfc9114>.
15.2. Informative References
Jorgen Expires 21 February 2027 [Page 40]
Internet-Draft TTTPS August 2026
[Bellare1996]
Bellare, M., Canetti, R., and H. Krawczyk, "Keying Hash
Functions for Message Authentication", CRYPTO 1996, LNCS
1109, 1996.
[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.
[EIGENPHI] EigenPhi Research, "MEV sandwich attacks: annual loss
estimates", 2025.
[FLASHBOTS]
Flashbots, "MEV explore", 2025,
<https://explore.flashbots.net>.
[Golomb1966]
Golomb, S.W., "Run-length encodings", IEEE Trans. Inf.
Theory 12, 399-401, 1966.
[Mazorra2026]
Mazorra, B., Schlegel, C., and A. Mamageishvili, "Timing
games: probabilistic backrunning and spam",
arXiv:2602.22032, 2026,
<https://arxiv.org/abs/2602.22032>.
[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,
<https://arxiv.org/abs/2509.22143>.
[OPENTTT] Helm Protocol, "OpenTTT SDK", npm install openttt, 2026,
<https://github.com/Helm-Protocol/OpenTTT>.
[POT2026] Jorgen, H., "Proof-of-Time: Byzantine-Resilient Temporal
Ordering in Untrusted Networks", IETF draft-helmprotocol-
tttps-00, March 2026.
[Reed1960] Reed, I.S. and G. Solomon, "Polynomial codes over certain
finite fields", SIAM J. Appl. Math. 8, 300-304, 1960.
Jorgen Expires 21 February 2027 [Page 41]
Internet-Draft TTTPS August 2026
[Tietavainen1973]
Tietavainen, A., "On the nonexistence of perfect codes
over finite fields", SIAM J. Appl. Math. 24, 88-96, 1973.
[GLASSWING]
Anthropic, "Project Glasswing: Securing Critical Software
for the AI Era", April 2026,
<https://www.anthropic.com/project/glasswing>.
[MAZORRA2026note]
Jorgen, H., "Proof-of-Time: Completing the Timing Game",
The Flashbots Collective, March 2026,
<https://collective.flashbots.net/t/proof-of-time-
completing-the-timing-game/5633>.
[Zhang2026]
Zhang, J., "Hyperagents", arXiv:2603.19461, 2026,
<https://arxiv.org/abs/2603.19461>.
[SS7-VULN] Positive Technologies, "SS7 Vulnerabilities and Attack
Exposure Report", 2020, <https://www.ptsecurity.com/ww-
en/analytics/ss7-vulnerability-2020/>.
[GSMA-SS7] GSMA, "SS7 and SIGTRAN Network Security", GSMA document
FS.11, November 2015,
<https://www.gsma.com/security/fs-11/>.
[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, <https://www.rfc-editor.org/info/rfc6962>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[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, <https://datatracker.ietf.org/doc/html/draft-ietf-
ntp-roughtime-19>.
Jorgen Expires 21 February 2027 [Page 42]
Internet-Draft TTTPS August 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,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
msg-wrap-23>.
[KENOSLEAN]
Kenosian, "kenoslean: machine-verified computational
contracts, Lean 4 / Mathlib", Python Package Index,
version 0.1.0, 2026,
<https://pypi.org/project/kenoslean/>.
[IEEE1588] IEEE, "IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems",
IEEE Std 1588-2019.
[WSS2000] Weinberger, M.J., Seroussi, G., and G. Sapiro, "The LOCO-I
lossless image compression algorithm: principles and
standardization into JPEG-LS", IEEE Trans. Image Process.
9(8), 1309-1324, 2000.
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 August 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 == <<node_mode, match_rate, fail_count,
block_count, submission_delay>>
\* -- 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 August 2026
/\ node_mode[n] = "FULL"
/\ match_rate[n] >= TurboEntry
/\ fail_count[n] = 0
/\ ~SubmittedOutsideTolerance(n)
/\ node_mode' = [node_mode EXCEPT ![n] = "TURBO"]
/\ UNCHANGED <<match_rate, fail_count,
block_count, submission_delay>>
\* 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 <<match_rate, fail_count,
block_count, submission_delay>>
\* 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]_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 August 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 two integrity algorithms registered by
this document (Section 11.5) and referenced from Section 4.
B.1. alg_id 0x0001 -- SHA-256 (Mandatory-to-Implement)
This algorithm is completely and publicly specified, is free of any
licensing condition, 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 August 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. alg_id 0x0100 -- GRG (OPTIONAL)
GRG processes the protected octets through four stages: Golomb-Rice
(G_1), Reed-Solomon (R), Golay(23,12,7) (G_2), and HMAC-SHA256 (H);
the stage ordering is mathematically necessary (Section 4.2).
Implementations of this interface MUST satisfy:
* Lossless round-trip: GRG_Inverse(GRG(P)) = P
* Erasure tolerance: any k of n shards reconstruct P (k and n are
implementation-defined; minimum k=4, n=6)
* Bit-error correction: up to t=3 bit errors per 23-bit block are
corrected
* Context binding: GRG(P, ctx_id_A) != GRG(P, ctx_id_B) for ctx_id_A
!= ctx_id_B, with probability >= 1 - 2^{-61}
Verification against this interface yields *intact* (no errors
detected), *resolved* (up to t=3 bit errors per 23-bit block
corrected and the recovered payload confirmed against the HMAC tag),
or *unresolvable* (error count exceeds correction capacity).
Full specification of the internal stage implementation -- parameter
selection, the Reed-Solomon generator beyond the public primitive
polynomial x^8 + x^4 + x^3 + x^2 + 1, and the Golay generator matrix
construction -- will be published upon conclusion of pending patent
proceedings (targeted Q3 2026; Section 12). Reference
implementation: [OPENTTT].
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 August 2026
Appendix C. Test Vectors
Test vectors for PoT generation and verification are provided as
property-based tests rather than deterministic byte vectors, to avoid
encouraging reverse-engineering of the OPTIONAL GRG algorithm's
internal parameters from expected byte sequences.
Required properties (all MUST pass):
C.1 Lossless round-trip:
GRG_Inverse(GRG(P, ctx)) = P for all P, ctx (alg_id 0x0100).
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 August 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 August 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 (Worley, Jim, Tim)
for feedback on draft-helmprotocol-tttps-00. The GRG pipeline
selection rationale builds on deep-space engineering heritage: JPL
Golomb-Rice compression, RS codes from Cassini and the Mars rovers,
and Golay(23,12,7) from the Voyager Saturn transmissions (1.0e9 km,
1980).
Author's Address
Heime Jorgen
Kenosian
Email: heime.jorgen@proton.me
Jorgen Expires 21 February 2027 [Page 50]