Proof-of-Transit (PoT) Receipts Explained

• Proof-of-Transit (PoT) Receipts are cryptographic frameworks that record sequential transit events using chained hashes and digital signatures to ensure non-repudiation.
• They link events across checkpoints through verified digital signatures and collision-resistant hash functions, guaranteeing forward integrity in V2I and treasury applications.
• Their design supports practical reputation scoring, exposure tracking, and regulatory transparency, balancing performance with resistance to collusive adversaries.

Proof-of-Transit (PoT) Receipts record authenticated evidence that a digital or physical entity has traversed a sequence of checkpoints, domains, or infrastructure nodes. Their principal applications span accountable V2I data validation (Suo et al., 2021) and cryptographically auditable Bitcoin treasuries (Puente et al., 3 Dec 2025). PoT receipts enforce forward integrity by cryptographically chaining event digests, binding each step to all previous ones, with domain-specific unforgeability requirements and game-theoretic resilience against colluding adversaries. They underpin reputation scoring, exposure tracking, and policy-driven transparency for complex multi-party systems.

1. Formal Definitions and Structural Models

A PoT receipt formalizes traceability for the transiting entity. In the V2I context (Suo et al., 2021), a vehicle $v_i$ interacting with roadside infrastructure $rsu_j$ at time $t_k$ receives a location signature: $$ls^{t_k}_{i, j} = [ pk_{rsu_j} \| pk_{v_i} \| t_k \| h_e \| h_{pre} \| \sigma_{rsu_j}(...) ]$$ where $h_e = H(e_i^{t_k})$ and $h_{pre} = H(ls^{t_{k-1}}_{i, j-1})$ cryptographically link current and previous events. Chained receipts constitute a PoT chain: $$PoT_i = \langle ls^{t_1}_{i,1}, ls^{t_2}_{i,2}, \ldots, ls^{t_N}_{i,N}\rangle$$

In Treasury Proof Ledger (TPL) (Puente et al., 3 Dec 2025), a treasury event $e_k = (t_k, d_{src}, d_{dst}, v, evid, m)$ yields: $$h_k = H(evid_k \| v_k \| m_k), \quad R_k = H(R_{k-1} \| h_k \| d_{src} \| d_{dst} \| t_k)$$ with signatures $\sigma^{treas}_k$ and $\sigma^{prov}_k$ producing receipts: $$rec_k = ( t_k, d_{src}, d_{dst}, v_k, evid_k, m_k, h_k, R_k, \sigma^{treas}_k, \sigma^{prov}_k )$$

In both paradigms, chaining links events to prevent equivocation, and digital signatures bind receipt issuance to authenticated agents.

2. Cryptographic Primitives and Receipt Construction

Fundamental primitives include collision-resistant hash functions (e.g., SHA-256 (Suo et al., 2021), domain-separated H (Puente et al., 3 Dec 2025)), digital signatures (ECDSA, RSA, or EUF-CMA-secure schemes), and public-key infrastructures. RSUs or treasury operators hold key-pairs, issuing and verifying signatures for each receipt.

For V2I:

• Vehicles transmit signed requests: $$req_{i\to j}^{t_k} = [ pk_{v_i} \| t_k \| e_i^{t_k} \| pos_i^{t_k} \| h_{pre} \| \sigma_{v_i}(...) ]$$
• RSU verifies request signature, previous hash linkage, and movement plausibility, then issues a signed location signature.

For TPL:

• Each treasury event produces hashed digests and hash-chain commitments, double-signed by the treasury and external provider.
• Chain commitments ($R_k$) anchor full event histories, and periodic ledger snapshots (authenticated via Merkle root) link overall exposure vectors to PoT chains.

Anchoring within TPL employs Bitcoin transactions embedding ledger commitments as OP_RETURN or Taproot script paths, permitting public, timestamped guarantees.

3. Verification Procedures and Integrity Guarantees

PoT receipts are verified by recursively checking:

• Digital signatures (issuer authenticity)
• Chained hash links to prior receipts (forward integrity)
• Temporal and spatial plausibility (strict monotonicity of timestamps, adjacency or physical movement constraints)

TPL imposes PoT Unforgeability (no adversary can generate a valid chain not issued by the protocol), Non-Equivocation (impossibility of divergent anchored event histories for a fixed prefix), and Conservation (total balance invariance across internal domains).

A plausible implication is that such chaining assures non-repudiation of event histories and prevents adversarial modification or deletion of transit evidence, critical for both V2I trust management and treasury accountability.

4. Reputation, Exposure Metrics, and Policy-Driven Views

PoT receipts in V2I systems quantify “Verified Vehicle Miles Traveled” (VVMT), supporting both linear and logistic reputation metrics (Suo et al., 2021): $$vvmt^{V}_i = \sum_{j=1}^{N} \gamma d(ls^{j-1}, ls^j)$$ resilient variants accommodate missing proofs via parameterized aggregation. Vehicles surpassing a minimum VVMT threshold join whitelists for voting/reporting.

In treasuries, recurrences of PoT receipts populate exposure vectors: $$B_d(t_k^+) = B_d(t_k^-) - v \text{ if } d=d_{src};\quad B_d(t_k^+) = B_d(t_k^-) + v \text{ if } d=d_{dst}$$ Snapshot molecules summarize multi-domain positions for stakeholder views, filtered and aggregated per policy requirements (public investor, regulator, auditor), with View-Correctness ensuring disclosed PoT receipts and ledger commitments reconstruct the unique valid exposure view.

A plausible implication is that PoT chains naturally support hierarchical visibility, affording privacy and granularity matched to institutional, regulatory, or audit standards.

5. Game-Theoretic and Security Analysis

V2I PoT whitelisting induces robust voting games, where eligible vehicles face a reward-penalty matrix for their voting actions (Suo et al., 2021). The inclusion of “Super-Integrity Drivers” (SID, $V_i > R-c$) in sufficient proportion breaks collusive cheating (all-cheat is not a Nash equilibrium if $p_{SID} > (|I| - N_{thld}) / |I|$), and raising VVMT thresholds amplifies resilience.

TPL formalizes PoT receipt unforgeability and non-equivocation via reductions to hash resistance and signature security. Restricted Exposure Soundness (Theorem) ensures that no adversary can inflate exposures in a closed set of domains while passing all PoT, PoR, and anchoring checks, given standard cryptographic assumptions and minimal non-collusion.

This suggests that PoT-based accountability frameworks are provably resistant to Sybil-style and colluding manipulations, subject to cryptographic primitives and stakeholder population properties.

6. Performance, Implementation, and Practical Results

V2I PoT receipts incur low overhead: $\sim$160 bytes per receipt, with $\sim$12KB total for 75 RSUs over 400 miles; RSU processing time is $\lesssim$1ms per signature verify and hash. In simulation, voting security under PoT whitelisting tolerates up to 50% malicious vehicles, with invalid-event rates a full 20–30 points lower than non-PoT baselines. Trade-offs exist: raising voting thresholds (e.g., $N_{thld}$) improves security at the expense of latencies (median decision time from 3s for $N_{thld}=5$ to 60s for $N_{thld}=12$). (Suo et al., 2021)

For treasuries, hash-chain commitments and PoT receipts anchor event histories with minimal leakage of internal ledger structure; subset views support materiality thresholds and time delays. Ledger updates and anchoring remain compatible with Bitcoin’s confirmation and state protocols, while privacy is preserved for view policies employing witness-indistinguishable proofs.

7. Application Across Domains and Supply Consistency

PoT receipts generalize from physical-spatial event tracking (vehicles in V2I) to multi-domain asset movement (Bitcoin treasuries). Corporate-treasury workflows employ PoT receipts to resemble a conserved state machine; events, receipts, snapshots, and anchors enable regulated reporting and cross-institution reconciliation. Periodic supply consistency checks across TPL instances ensure that the aggregate reported supply does not violate Bitcoin’s cap, with any shortfall reducible to a primitive break or collusion/coverage assumption. (Puente et al., 3 Dec 2025)

The table below outlines structural differences in PoT receipt applications:

System	Transit Object	Receipt Structure
V2I PoT	Vehicle movement	$\langle$location signature, hash chain$\rangle$
Treasury PoT	Domain value transfer	$$(t,d_{src},d_{dst},v,evid,m,h,R,\sigma^{treas},\sigma^{prov})$$

A plausible implication is that PoT methodologies provide a unified approach to provenance, accountability, and origin tracking in cryptographically governed environments.