The TLS TimeToken Secure Protocol (tttps://)
draft-helmprotocol-tttps-00
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.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | 장동호 | ||
| Last updated | 2026-03-14 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-helmprotocol-tttps-00
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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4", RFC 5905,
DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174,
DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS)
Protocol Version 1.3", RFC 8446,
DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[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,
<https://www.rfc-editor.org/info/rfc8915>.
11.2. Informative References
[EIP-712] Ethereum Foundation, "EIP-712: Typed structured data
hashing and signing", Ethereum Improvement Proposal,
2017, <https://eips.ethereum.org/EIPS/eip-712>.
[EIGENPHI] EigenPhi Research, "Exclusive data reveals sandwich
attacks on Ethereum have waned", CoinTelegraph,
December 2025.
[FLASHBOTS] Flashbots, "MEV-Boost and block building on Ethereum",
<https://docs.flashbots.net>.
[FLASHBOTS-PROTECT] Flashbots, "Flashbots Protect",
<https://protect.flashbots.net>.
[OPENTTT] "OpenTTT: Reference implementation of
the TTT SDK", March 2026,
<https://github.com/Helm-Protocol/OpenTTT>.
[RFC8179] Arkko, J. and A. Farrel, "Intellectual Property Rights
in IETF Technology", BCP 79, RFC 8179,
DOI 10.17487/RFC8179, May 2017,
<https://www.rfc-editor.org/info/rfc8179>.
[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