Proof-of-Transit Timestamping (PoTT)

• Proof-of-Transit Timestamping (PoTT) is a cryptographic primitive that creates tamper-evident custody and timing trails through chained, hop-authenticated receipts.
• It leverages a transitive prefix authentication graph (TPAG) to efficiently unify log-auditing techniques, producing sublinear certificate sizes and streamlined verification.
• Designed for high-latency environments such as interplanetary communications, PoTT enables verifiable event ordering without modifying underlying consensus protocols.

Proof-of-Transit Timestamping (PoTT) is a cryptographic primitive for constructing tamper-evident, hop-authenticated custody and timing trails of data as it traverses untrusted networks or relays. PoTT is essential when accurate, out-of-band, protocol-independent ordering and auditability of events (particularly in delay-prone and high-latency settings such as interplanetary communication) must be cryptographically verifiable without altering underlying consensus or ledger semantics.

1. Conceptual Foundations and System Definition

PoTT is formally defined as a transport-layer receipt primitive that “cryptographically chains hop-timed custody attestations to Bitcoin payload hashes” (Puente et al., 28 Aug 2025). The central object is a chain of signed receipts, each produced by relays on a message transmission path. Each receipt contains:

• a cryptographic hash of the payload $h = H(P)$
• a per-message nonce $\nu$ (typically 128 bits)
• node identifier $\mathrm{NodeID}_i$
• ingress and egress timestamps ($t_{\mathrm{in}}^{(i)}, t_{\mathrm{out}}^{(i)}$), encoded in International Atomic Time (TAI)
• a “prev” pointer $$\mathrm{prev}_i = H(R_{i-1}\; \backslash \;s_{i-1})$$, binding to the prior hop’s receipt (with its signature removed prior to hashing)
• a Schnorr signature $s_i$ over the structured message

This receipt structure ensures a tamper-evident, append-only log bounding each hop’s custody over the data, including strict sequencing and time monotonicity. Any alteration (removal, modification, or reordering) of the receipts invalidates the hash chain, ensuring cryptographic detectability of forgery.

2. Formal Construction and TPAG Unification

The cryptographic structure underlying PoTT can be realized as a transitive prefix authentication graph (TPAG), as introduced in "SoK: Authenticated Prefix Relations" (Meyer, 2023). A TPAG is an acyclic directed graph $G = (V, E)$ whose vertices map to committed prefixes of the event log. Essential functions in the TPAG framework include:

• $\gcommit: \mathbb{N} \to V$ : assigns a “commitment” vertex for each log prefix
• $\dock: \mathbb{N} \to \mathcal{P}(V)$ : specifies vertices determining digest labels for prefixes
• $\gcertify: \mathbb{N} \times \mathbb{N} \to \mathcal{P}(V)$ : yields paths (or subgraphs) linking a later event to an earlier prefix

Hash-based labeling of vertices is recursively defined as

$\lbl(v) = \begin{cases} \lfun(v) & \text{if } v \text{ is a sink} \ h\left(\seq(\mathrm{outs}_G(v))\right) & \text{otherwise} \end{cases}$

with $\seq$ imposing canonical ordering on out-neighbors.

A PoTT certificate $\certify(s, t)$ for “$s \preceq t$” is then a collection of labels forming a subgraph proof that the commitment for prefix $s$ is included in that for $t$. Verification reconstructs $\lbl(\gcommit(len_s))$ from the certificate and compares it to the stored digest.

This unifies existing log-auditing and hash-chain timestamping techniques—ranging from simple chains and skip lists to Merkle forests—under a general, graph-based abstraction.

3. Architectural Deployment in Interplanetary Networks

PoTT is specifically designed for environments such as interplanetary monetary systems, where the physical and protocol constraints of delay and disruption-tolerant networking (DTN) complicate classical transaction ordering (Puente et al., 28 Aug 2025). The architecture features:

• DTN Backbones & Optical LEO Mesh: Interplanetary data (e.g., Bitcoin blocks or Lightning network updates) traverses a backbone spanning DTN (using Bundle Protocol v7 and BPSec) and optical low-Earth-orbit mesh constellations.
• Header-First Replication: Gateways prioritize block header propagation to maintain global chain awareness and local Median Time Past (MTP) anchors. Transactional payloads are subsequently transferred with custody proofs.
• PoTT Receipt Chain: Each relay appends a receipt with TAI-monotonic timestamps. The chain encodes ingress/egress times, node identity, and is hash-linked to its predecessor.

Practical instantiation involves strong cryptographic primitives:

Field	Role	Remarks
$h$	Hash of payload	SHA-256 / BLAKE3
$\nu$	Per-instance nonce	128-bit
$t_{in}, t_{out}$	Ingress/egress TAI timestamps	Synchronized to independent time-beacons
$\mathrm{prev}$	Hash-pointer to previous receipt	Excludes prior signature (anti-splice)
$s$	Schnorr signature (BIP-340)	Covers entire encoded receipt

The overall design is protocol-agnostic: PoTT receipts are sent and stored strictly out-of-band, separate from L1 consensus protocols (such as Bitcoin). As such, L1 consensus and monetary base remain unchanged even as PoTT is layered on top.

4. Security Properties and Attested Auditability

PoTT’s security model comprises several cryptographically enforced invariants:

• Hash Chaining: Ensures that any removal, replay, or splicing of hop records results in hash chain failure.
• Digital Signatures: BIP-340 Schnorr signatures guarantee per-hop authenticity.
• Timestamp Monotonicity: Enforced by requiring $t_{out}^{(i-1)} < t_{in}^{(i)}$, providing unambiguous, monotonic sequencing.
• Non-repudiability: Because receipts are signed and hash-linked, a relay cannot later deny possession of the payload or reorder its receipt in the chain.

Receipts are cross-checked against external time-beacons (e.g., GNSS on Earth, optical time transfer in deep space). This assures both the sequence and timing aspects of event custody can be externally verified, even in the presence of adversarial network actors.

PoTT enables decentralized dispute resolution: For example, Lightning Network watchtowers can audit timely arrival of updates by referencing PoTT receipts and checking them against Bitcoin’s MTP.

5. Complexity, Efficiency, and TPAG Trade-offs

Integrating TPAGs with PoTT optimizes both the efficiency and auditability of proof generation and verification (Meyer, 2023):

• Certificate Size: The number of nodes/edges traversed in producing a subgraph proof (e.g., using antimonotone or skip-list-based TPAGs) can be polylogarithmic in the log size $n$. For practical instantiations, positional certificate sizes of $O((\log n)^2 \cdot k)$ or $2 \lceil \log_2 n \rceil \cdot k$ (for hash size $k$) are typical.
• Verification Time: Recovery of a stored commitment/digest from a certificate scales with the induced subgraph size—commonly logarithmic or low-degree polynomial. This makes PoTT suitable for deployment on resource-constrained (spaceborne or embedded) platforms.
• Storage Overhead: Digest and certificate pools can be maintained at $O(\log n)$ scalings, minimizing the cost of future proof updates.
• Append Complexity: Amortized per-event append cost is linear in efficient TPAGs, with “sparse commit” optimizations further constraining update work.

The encapsulating TPAG model enables system designers to balance proof compactness, update efficiency, and verification complexity by choice of concrete TPAG construction.

6. Deployment Modes, Settlement Layers, and Limitations

Deployment strategies differ based on the desired security model and operational constraints:

• Strong Federations: Near-term, a federation of trusted operators on each planetary domain manages local settlement and acts as relay witnesses. PoTT receipts serve as settlement and audit evidence on peg-in/peg-out operations.
• Blind-Merge-Mined (BMM) Commit Chains: To approach greater decentralization, sidechains pegged 1:1 to Bitcoin (BMM commit chains) provide asynchronous, tamper-evident settlement across domains. PoTT is mandatory for attesting timely cross-domain relay.
• Lightning Extensions: For Lightning Network, PoTT is fundamental for enforcing long-horizon HTLC constraints over OWLT-dominated paths. Cross-domain watchtowers use PoTT to prove transaction arrival timestamps with respect to MTP.

The impact on Bitcoin L1 consensus and monetary base is strictly null: all PoTT mechanisms are purely additive and opt-in at infrastructural and protocol layers above consensus.

Limitation: Trust in timestamp accuracy is reliant on independent, TAI-traceable time-beacons. Simultaneous compromise of all involved time-beacon regimes (e.g., both Earth and Mars) degrades PoTT's evidence to mere administrative assertions. Custody attestation remains verifiable, but cryptographic time-anchoring loses its external trust.

Other Challenges:

• PoTT does not guarantee liveness or delivery—only (non-repudiable, ordered) custody.
• Metadata overhead per payload increases linearly with hop count (e.g., 200 B/receipt).
• Attested paths must exhibit sufficient administrative and time-source diversity to prevent targeted collusion.

7. Example: Interplanetary Lightning HTLC Safety Margins

A key operational formula from (Puente et al., 28 Aug 2025) demonstrates how PoTT receipts inform Lightning timelock extensions across planetary links: $$\Delta^{(\mathrm{extra}\_\mathrm{CLTV})} = \left\lceil \frac{\mathrm{RTT} + J}{b_{\mathrm{target}}} \right\rceil$$ where

• RTT = 2 × OWLT (one-way light time)
• $J$ = jitter and processing delay allowance
• $b_{target}$ = base block interval (10 minutes for Bitcoin)

For Earth–Mars maximal delay (OWLT = 22 min, thus RTT = 44 min), $J = 60$ min, and $b_{target} = 10$: $$\Delta^{(\mathrm{extra}\_\mathrm{CLTV})} = \lceil (44+60)/10 \rceil = 11$$ Final timelock = base (e.g., 144) + ops margin (e.g., 2) + 11 = 157 blocks.

PoTT-captured receipt chains provide certified basis for “arrived-before-expiry” disputes.

---

PoTT is a cryptographic protocol and distributed systems primitive that transforms physical delay and connectivity limitations into verifiable, append-only, custody and timing audit trails. By incorporating TPAG-based log structures, PoTT achieves sublinear certificate size and efficient verification, enabling large-scale, transparent, and high-integrity event ordering in both terrestrial and interplanetary settings (Meyer, 2023, Puente et al., 28 Aug 2025). The practical security and scalability of PoTT depend on the composition of system design, relay diversity, and independent publicly verifiable time-beacons. When implemented under these conditions, PoTT provides foundational support for cross-domain monetary systems, settlement protocols, and accountability infrastructure over high-latency, unreliable links.