Internet-Draft Heime Jorgen Intended status: Experimental Kenosian Expires: September 15, 2026 March 15, 2026 The TLS TimeToken Secure Protocol (tttps://) draft-helmprotocol-tttps-00 Abstract This document specifies the TLS TimeToken Secure Protocol (tttps://), an application-layer protocol extension that augments TLS 1.3 [RFC8446] with cryptographically verifiable temporal ordering. Where TLS authenticates identity ("who"), tttps:// authenticates temporal origin ("when") in a manner resistant to Byzantine manipulation. The protocol introduces Proof of Time (PoT): a multi-source NTP- synthesized, cryptographically authenticated timestamp bound to a distributed ledger anchor. PoT enables honest participants to achieve preferential execution, while Byzantine nodes are economically evicted through an adaptive state machine (the AdaptiveSwitch mechanism). Primary use cases include MEV-resistant decentralized exchange (DEX) transaction ordering, AI agent-to-agent payment sequencing, IoT mission-critical command ordering, and satellite inter-link communication timestamping. This document has Experimental status to allow deployment experience to accumulate prior to consideration for the Standards Track. The GRG Integrity Pipeline specification will be made available for independent implementation upon conclusion of pending patent proceedings (see Section 10). 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 September 15, 2026. This document is being discussed in the context of a proposed Birds of a Feather (BoF) session to explore the formation of a new working group on temporal ordering for distributed systems. Interested parties are invited to review the draft and participate. Comments are welcome on the dispatch@ietf.org mailing list. 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction 1.1. Motivation 1.2. Scope 1.3. Terminology 2. Problem Statement: Temporal Indeterminacy 2.1. The Byzantine Time Problem 2.2. Existing Mitigations and Their Limitations 3. Proof of Time (PoT) Specification 3.1. PoT Data Structure 3.2. PoT Generation Algorithm 3.3. On-Chain Hash (Deterministic ABI Encoding) 3.4. PoT Verification 4. GRG Integrity Pipeline (Abstract Specification) 4.1. Pipeline Overview 4.2. Stage Descriptions 4.3. Verification Interface 5. AdaptiveSwitch: Byzantine Node Eviction Mechanism 5.1. State Machine 5.2. Transition Conditions and Hysteresis 5.3. Penalty and Exponential Backoff 5.4. Nash Equilibrium Analysis 6. tttps:// Protocol Integration 6.1. TLS Extension Definition 6.2. Handshake Augmentation 6.3. Backward Compatibility 7. Tier Structure 8. IANA Considerations 9. Security Considerations 9.1. NTP MITM Attacks 9.2. Replay Attacks 9.3. Sybil Time Sources 9.4. Side-Channel Considerations 9.5. Byzantine Node Economic Attacks 10. Intellectual Property Rights 11. References 11.1. Normative References 11.2. Informative References Acknowledgments Author's Address 1. Introduction 1.1. Motivation The Internet operates under two implicit trust axioms: o Identity trust (solved by TLS/PKI): "Who am I communicating with?" o Temporal trust (currently unsolved at the protocol level): "When did this message originate, in a manner that cannot be falsified by any single party?" Emerging application domains -- decentralized exchanges, autonomous AI agent networks, industrial IoT systems, and inter-satellite communication links -- share a common requirement: verifiable temporal ordering of events across mutually untrusted parties. These environments were not addressed by existing time synchronization or trust infrastructure, which were designed primarily for single-domain or human-supervised contexts. This document describes an experimental protocol for a temporal trust layer leveraging distributed ledgers. The proposed mechanism provides a transparent and verifiable framework for time-ordered event sequencing in multi-party, adversarial environments. It is designed to operate alongside existing trust infrastructure, not as a replacement for it. Block builder timestamp manipulation enables MEV sandwich attacks [FLASHBOTS] costing an estimated $60 million annually in DEX user losses as of 2025. GPS spoofing enables coordinate falsification in autonomous systems. NTP MITM attacks allow timestamp manipulation in financial systems. This specification addresses temporal Byzantine faults: network participants that report plausible but fabricated timestamps to gain economic advantage or disrupt system operation. 1.2. Scope This document specifies: o The Proof of Time (PoT) data structure and generation algorithm o The GRG Integrity Pipeline abstract interface (implementation details are outside the scope of this document) o The AdaptiveSwitch Byzantine eviction mechanism o The tttps:// TLS extension for embedding PoT in TLS 1.3 handshakes This document does NOT specify: o Concrete implementation of the GRG pipeline cryptographic operations (covered by pending patent applications; see Section 10) o Specific NTP server selection policies o Smart contract implementations for on-chain anchoring o Pricing or fee schedules (implementation-defined; see Section 7) 1.3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174]. Proof of Time (PoT): A cryptographically authenticated record of a synthesized timestamp derived from multiple independent NTP sources, bound to a context identifier and protected against replay. GRG Pipeline: A multi-stage integrity pipeline that encodes and authenticates PoT payloads. "GRG" denotes the three pipeline stages: G(olomb-Rice encoding), R(eed-Solomon erasure coding), and G(olay forward error correction), with keyed integrity authentication applied at each stage. The abstract interface is specified in Section 4; concrete implementation details are proprietary and covered by pending patents (Section 10). AdaptiveSwitch: A state machine that classifies network participants as TURBO (honest, preferential execution) or FULL (potentially Byzantine, standard execution) based on observed PoT conformance. Byzantine Time Attack: An adversarial action in which a network participant reports a fabricated or manipulated timestamp to gain ordering advantage. Temporal Ordering: The verifiable sequence in which transactions or messages were initiated, independent of network propagation delays. PoT Issuer: An entity authorized to generate and sign Proofs of Time for consumption by verifying parties. Analogous in function to a Certificate Authority in the TLS PKI model, but operating over time attestations rather than identity certificates. 2. Problem Statement: Temporal Indeterminacy 2.1. The Byzantine Time Problem In current decentralized systems, "time" is approximated. Block timestamps in Ethereum are provided by block builders with second- level granularity and no cryptographic commitment to external time sources. This creates a "dark window" within which transactions may be reordered, front-run, or censored. Formally, let T_actual be the actual transaction submission time and T_block be the block timestamp assigned by the builder. Current systems provide no mechanism to verify that: |T_block - T_actual| < epsilon for any meaningful epsilon. A malicious builder may set T_block arbitrarily within consensus tolerance, enabling sandwich attacks [EIGENPHI], front-running, and other temporal manipulation. The same vulnerability exists in: o AI agent multi-step transactions where ordering determines economic outcome o Industrial IoT command sequences where ordering determines physical safety o Inter-satellite communication where propagation delay variance is exploited 2.2. Existing Mitigations and Their Limitations Private mempools (e.g., Flashbots Protect [FLASHBOTS-PROTECT]) reduce front-running exposure but do not eliminate it. As documented in [SANDWICH-STUDY], private sandwich attacks affecting 3,126 transactions produced $409,236 in losses during November- December 2024, with 50.1% of Ethereum transactions using private routing by February 2025. Private routing does not provide temporal authentication; it only obscures order flow. Network Time Security (NTS) [RFC8915] addresses NTP authentication within a single network domain but does not provide: o Cross-domain Byzantine fault tolerance o Economic incentive alignment for honest participation o Integration with distributed ledger anchoring IEEE 1588 Precision Time Protocol (PTP) provides sub-microsecond synchronization within local networks but is not Byzantine fault tolerant and does not operate across administrative domains. 3. Proof of Time (PoT) Specification 3.1. PoT Data Structure A Proof of Time is defined as the following JSON-serializable structure. Implementations MUST preserve all fields for verification purposes. struct ProofOfTime { uint64 timestamp_ns; // Synthesized Unix timestamp in nanoseconds. // Derived from multi-source NTP median synthesis // per the algorithm in Section 3.2. uint64 expires_at_ms; // Validity window expiry in Unix milliseconds. // Default: timestamp_ns / 1,000,000 + 60,000. // Implementations MUST reject PoTs where // current_time_ms > expires_at_ms. uint8 sources; // Number of independent NTP sources contributing // to synthesis. MUST be >= 2 for TURBO eligibility. // A PoT with sources == 1 is valid but carries // degraded confidence and is ineligible for TURBO. uint8 stratum; // Minimum NTP stratum across contributing sources. // Lower values indicate proximity to atomic clocks. // MUST be <= 15 (RFC 5905 Section 7.3). uint32 confidence_ppm; // Source availability confidence scaled by 10^6. // Value = (responding_sources / configured_sources) // * 1,000,000. // MUST be >= 500,000 (0.5 confidence) for // TURBO eligibility. bytes32 nonce_hash; // keccak256(random_nonce_bytes). // Provides replay protection. The underlying // nonce MUST be generated using a cryptographically // secure random number generator. bytes32 grg_hash; // Output of the GRG Integrity Pipeline applied to // the PoT payload. See Section 4.3. bytes issuer_signature; // Optional Ed25519 signature over on_chain_hash // by the PoT issuer. Enables non-repudiation. SourceReading[] source_readings; // Per-source evidence supporting timestamp_ns. } struct SourceReading { string source_name; // Identifier of the time source uint64 timestamp_ns; // Per-source timestamp float32 uncertainty_ms; // Per-source uncertainty (ms) uint8 stratum; // Per-source NTP stratum } 3.2. PoT Generation Algorithm A PoT is generated as follows: (1) Query N configured time sources in parallel. Sources MAY include NTPv4 [RFC5905] servers and HTTPS-authenticated endpoints. Implementations SHOULD use a minimum of 3 sources. (2) Discard responses where: - stratum == 0 or stratum > 15 - Round-trip delay exceeds implementation-defined threshold - Response timestamp is prior to 1970-01-01 (Unix epoch) (3) For each valid response i, compute: theta_i = ((T2_i - T1_i) + (T3_i - T4_i)) / 2 where T1 is local originate time, T2 is server receive time, T3 is server transmit time, and T4 is local receive time, all in nanoseconds. timestamp_i = T4_i + theta_i (4) Sort valid timestamps: t_1 <= t_2 <= ... <= t_k. (5) Select synthesized timestamp: - If k == 1: T_synth = t_1 (with degraded confidence warning) - If k == 2: T_synth = (t_1 + t_2) / 2 - If k >= 3: T_synth = t_{floor(k/2)} (median) (6) Verify all source readings are within tolerance of T_synth: |t_i - T_synth| <= TOLERANCE(stratum) where TOLERANCE is defined in Section 5.2. (7) Construct PoT with T_synth, a fresh cryptographic nonce, and expiry window. Apply GRG pipeline (Section 4) to produce grg_hash. 3.3. On-Chain Hash (Deterministic ABI Encoding) The on-chain representation of a PoT MUST use the following deterministic encoding to enable independent third-party verification: on_chain_hash = keccak256( ABI.encode( uint64(timestamp_ns), uint64(expires_at_ms), uint8(sources), uint8(stratum), uint32(confidence_ppm), bytes32(keccak256(nonce_bytes)) ) ) This encoding is field-order-fixed and independent of serialization library implementation, enabling any conforming implementation to reproduce the hash given the same PoT fields. NOTE: JSON serialization MUST NOT be used for on_chain_hash computation, as key ordering varies across implementations. 3.4. PoT Verification A verifying party MUST reject a PoT if any of the following conditions hold: (a) current_time_ms > expires_at_ms (b) confidence_ppm < 500,000 (c) sources < 1 (a PoT with zero sources is invalid by definition; sources == 1 is valid but TURBO-ineligible per Section 3.1) (d) stratum > 15 (e) The nonce has been previously observed (replay protection) (f) grg_hash fails GRG pipeline verification (Section 4.3) (g) Any source_reading deviates from timestamp_ns by more than TOLERANCE(stratum) nanoseconds, where TOLERANCE is: - stratum <= 1: 10,000,000 ns (10 ms) - stratum == 2: 25,000,000 ns (25 ms) - stratum >= 3: 50,000,000 ns (50 ms) A PoT with sources < 2 or confidence_ppm < 750,000 MUST NOT be admitted to TURBO mode regardless of other fields. Optionally, verifying parties SHOULD validate issuer_signature against a trusted PoT issuer public key registry. 4. GRG Integrity Pipeline (Abstract Specification) 4.1. Pipeline Overview The GRG Integrity Pipeline is a multi-stage encoding and authentication mechanism applied to PoT payloads. It provides: o Structured encoding for error correction (Stage 1) o Erasure coding with configurable redundancy (Stage 2) o Forward error correction per shard (Stage 3) o Keyed integrity authentication per shard (Stage 4) The pipeline accepts an arbitrary byte sequence and produces a set of authenticated shards. Any conforming subset of shards can reconstruct the original payload and verify its integrity. The specific algorithm parameters, optimization strategies, and implementation techniques are proprietary and covered by pending patent applications (see Section 10). This specification defines only the abstract interface required for interoperability. 4.2. Stage Descriptions Stage 1 -- Structured Encoding (G): The input payload is transformed into a structured bit representation using a Golomb-Rice based encoding optimized for subsequent error correction. Implementations MUST preserve the original byte length as metadata to enable exact reconstruction. Stage 2 -- Erasure Coding (R): The structured payload is divided into K data shards and M parity shards (K + M total), using a systematic Reed-Solomon coding scheme over a finite field. Any K of the K + M shards MUST be sufficient to reconstruct the original payload. Default parameters: K=4, M=2 (total 6 shards; recovers from any 2 shard failures). Stage 3 -- Forward Error Correction (G): Each individual shard is protected with a Golay-based binary block code capable of correcting up to t bit errors per codeword, where t >= 3. Stage 4 -- Keyed Integrity Authentication: Each shard is appended with a truncated keyed hash (minimum 8 bytes) computed with a context-derived key. The key MUST be derived from the deployment context (e.g., chain identifier and pool address) to prevent cross-context replay. The specific key derivation function is implementation-defined; implementations MUST ensure that shards produced for one context cannot be used to satisfy verification for a different context. 4.3. Verification Interface The GRG pipeline MUST expose the following abstract interface: Input: original_data (bytes), shards (list of byte arrays), context_id (opaque identifier) Output: VerifyResult { ok: bool, hmac_failures: int, recovered: bool } A result with ok=true and recovered=true indicates that the payload was successfully reconstructed despite one or more shard integrity failures, using the erasure coding redundancy of Stage 2. Implementations SHOULD log hmac_failures for security monitoring. The grg_hash field in the PoT structure is computed as: grg_hash = keccak256(concatenate(shards)) where shards are the output of Stage 4. 5. AdaptiveSwitch: Byzantine Node Eviction Mechanism 5.1. State Machine The AdaptiveSwitch classifies each network participant as one of two operational states: TURBO: Preferential execution mode. Latency target: 50 ms. Fee discount: 20% (implementation-defined). FULL: Standard execution mode. Latency target: 127 ms. No fee discount. All participants begin in FULL state. Transitions are determined by the observed PoT conformance rate over a sliding window. 5.2. Transition Conditions and Hysteresis Let R_match be the fraction of recent blocks whose observed transaction order and timestamp are consistent with the participant's submitted PoT records, computed over a sliding window W (default W=20 blocks). Tier-specific temporal tolerance: T0_epoch (6.4 min intervals): 2000 ms T1_block (2 s intervals): 200 ms T2_slot (12 s intervals): 500 ms T3_micro (100 ms intervals): 10 ms Transitions: FULL -> TURBO: R_match >= 0.95 over W blocks AND penalty_cooldown == 0 AND GRG integrity verified for all W blocks TURBO -> FULL: R_match < 0.85 OR any GRG integrity failure detected The hysteresis gap (0.95 entry vs. 0.85 maintenance) prevents oscillation and ensures stable TURBO participation requires sustained honest behavior. 5.3. Penalty and Exponential Backoff Upon a GRG integrity failure while in TURBO state, a mandatory cooldown period is applied: cooldown_blocks = 20 * 2^(consecutive_failures - 1) subject to a maximum of 320 blocks, with consecutive_failures capped at 4. This exponential backoff ensures that repeated Byzantine behavior results in extended exclusion from TURBO mode, creating a strong economic disincentive for timestamp manipulation. 5.4. Nash Equilibrium Analysis Let R be the block reward, V_mev be the extractable MEV value, C_turbo and C_full be the per-block costs in TURBO and FULL modes respectively, and L_penalty be the expected penalty cost. U_honest = R - C_turbo U_byzantine = R + V_mev - C_full - L_penalty The protocol parameters are chosen such that: U_honest > U_byzantine Specifically, the fee discount in TURBO mode combined with the exponential backoff penalty ensures that sustained honest participation yields strictly higher utility than occasional MEV extraction, provided V_mev does not exceed the penalty cost. Specific parameter calibration is implementation-defined. 6. tttps:// Protocol Integration 6.1. TLS Extension Definition This document requests the allocation of a new TLS extension type value from IANA: ExtensionType: pot_temporal_attestation (TBD) The extension carries a serialized ProofOfTime structure as defined in Section 3.1. struct { opaque pot_data<1..2^16-1>; } TemporalAttestationExtension; where pot_data is the canonical JSON encoding of a ProofOfTime with BigInt fields represented as decimal strings. 6.2. Handshake Augmentation The tttps:// handshake augments TLS 1.3 as follows: ClientHello: MAY include a pot_temporal_attestation extension carrying the client's current PoT. ServerHello (or EncryptedExtensions): If the server supports tttps://, it MUST include a pot_temporal_attestation extension carrying the server's current PoT. Verification: After the TLS handshake completes, each party MUST verify the counterpart's PoT per Section 3.4. Additionally: |client.timestamp_ns - server.timestamp_ns| <= max(TOLERANCE(client.stratum), TOLERANCE(server.stratum)) If this condition is violated, the connection MAY be terminated with a new alert: temporal_inconsistency(TBD). 6.3. Backward Compatibility If either party does not include the pot_temporal_attestation extension, the connection proceeds as standard TLS 1.3 without temporal attestation. This ensures complete backward compatibility. Applications MAY require tttps:// as a policy matter; this document does not mandate such requirements. 7. Tier Structure tttps:// defines four operational tiers, balancing temporal resolution against verification overhead. The tier determines the temporal tolerance window (Section 5.2) and eligibility for TURBO mode: +----------+----------+------------------+----------------------+ | Tier | Interval | Resolution Class | Primary Use Case | +----------+----------+------------------+----------------------+ | T0_epoch | 6.4 min | low | Batch / standard DEX | | T1_block | 2 s | medium | L2 block ordering | | T2_slot | 12 s | high | L1 slot ordering | | T3_micro | 100 ms | ultra | Institutional / HFT | +----------+----------+------------------+----------------------+ NOTE: Per-tick pricing and fee schedules are implementation-defined and outside the scope of this specification. Reference pricing for the OpenTTT implementation is documented separately [OPENTTT]. Implementations operating at T3_micro SHOULD employ asynchronous GRG processing to meet the 100 ms interval constraint. 8. IANA Considerations This document requests the following IANA actions: 1. Registration of TLS extension type pot_temporal_attestation in the "TLS ExtensionType Values" registry. 2. Registration of TLS alert temporal_inconsistency in the "TLS Alerts" registry. 3. Creation of a new "PoT Source Type" registry with the following initial values: ntp_udp, https_date_header, roughtime. 9. Security Considerations 9.1. NTP MITM Attacks Plain NTPv4 [RFC5905] is transmitted over unauthenticated UDP, making it vulnerable to on-path attackers. Implementations SHOULD use Network Time Security (NTS) [RFC8915] for at least one configured source. Additionally, including HTTPS-authenticated sources provides TLS-protected temporal evidence even at reduced precision (1-second resolution from HTTP Date headers). The multi-source median synthesis algorithm is inherently resistant to single-source compromise: an attacker must compromise a majority of configured sources simultaneously to meaningfully affect the synthesized timestamp. 9.2. Replay Attacks The nonce_hash field MUST be generated fresh for each PoT and MUST NOT be reused. Verifying implementations MUST maintain a bounded nonce cache with TTL >= expires_at_ms to reject replayed PoTs. Recommended cache parameters: capacity 10,000 entries, TTL 300 seconds (5x the default 60-second expiry window). 9.3. Sybil Time Sources A single entity controlling multiple NTP servers could fabricate a consistent false timestamp across "multiple" sources. Implementations SHOULD use sources from distinct administrative domains (e.g., NIST, KRISS, Google, Cloudflare) with verified different operators. 9.4. Side-Channel Considerations The key derivation function for the GRG pipeline MUST be implemented using constant-time operations where applicable to prevent timing side-channel attacks. The specific derivation algorithm is implementation-defined (see Section 10). 9.5. Byzantine Node Economic Attacks Section 5.4 demonstrates that the AdaptiveSwitch mechanism creates a Nash equilibrium favoring honest participation. However, implementations MUST set penalty parameters such that L_penalty exceeds the expected V_mev for the deployed context. Operators SHOULD monitor the TURBO/FULL ratio across participants and investigate sustained FULL operation as a potential indicator of Byzantine behavior. 10. Intellectual Property Rights The contributor represents that to the best of the contributor's knowledge, there are IPR claims under which RAND licensing terms would be available, in the event the IETF takes any action based on the contribution (pursuant to BCP 79 [RFC8179]). Specifically, pending patent applications cover aspects of the technologies described in this document, including: (a) The multi-stage GRG integrity pipeline (Stage 1 through Stage 4 as described in Section 4), including specific algorithm parameter selection, key derivation methodology, and performance optimization techniques; (b) The AdaptiveSwitch Byzantine node eviction mechanism, including the specific hysteresis thresholds, penalty calculation formula, and Nash equilibrium parameterization; (c) The combination of multi-source NTP synthesis with on-chain deterministic hash anchoring as specified in Section 3.3. Patent applications have been filed in multiple jurisdictions. Application numbers are not yet publicly available pending examination. The anticipated licensing framework is: o Open-source non-commercial implementations: royalty-free o Entities operating as PoT Issuers in a commercial capacity (see Section 1.3): tiered royalty schedule to be published upon patent grant o End-user implementations that consume but do not issue PoTs: royalty-free A formal IPR disclosure will be filed on the IETF Datatracker (https://datatracker.ietf.org/ipr/) concurrent with the proposed BoF session. Inquiries may be directed to: peter@kenosian.com 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4", RFC 5905, DOI 10.17487/RFC5905, June 2010, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. Sundblad, "Network Time Security for the Network Time Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, . 11.2. Informative References [EIP-712] Ethereum Foundation, "EIP-712: Typed structured data hashing and signing", Ethereum Improvement Proposal, 2017, . [EIGENPHI] EigenPhi Research, "Exclusive data reveals sandwich attacks on Ethereum have waned", CoinTelegraph, December 2025. [FLASHBOTS] Flashbots, "MEV-Boost and block building on Ethereum", . [FLASHBOTS-PROTECT] Flashbots, "Flashbots Protect", . [OPENTTT] "OpenTTT: Reference implementation of the TTT SDK", March 2026, . [RFC8179] Arkko, J. and A. Farrel, "Intellectual Property Rights in IETF Technology", BCP 79, RFC 8179, DOI 10.17487/RFC8179, May 2017, . [SANDWICH-STUDY] Caradonna, P. et al., "Sandwiched and Silent: Behavioral Adaptation and Private Channel Exploitation in Ethereum MEV", arXiv:2512.17602, December 2024. [UNISWAP-V4] Adams, H. et al., "Uniswap v4: The Flexibility to Build Anything", Uniswap Blog, January 2025. Acknowledgments The authors thank the IETF TSVWG and NTP working groups for their prior work on time synchronization and transport security. The authors also acknowledge the Flashbots research team whose published MEV data provided the empirical foundation for the problem statement in Section 2. Author's Address Heime Jorgen Kenosian Email: heime.jorgen@proton.me URI: https://github.com/Helm-Protocol/OpenTTT