How Proof of Travel turns operational signals into verified events.

Design principles

Neutrality, determinism, minimalism

Proof of Travel is intentionally narrow. The protocol does not store passenger data, it does not interfere with commercial workflows, and it does not require trust in any single operator. Instead, it provides a thin, deterministic layer that turns multi-source operational agreement into independently verifiable references.

Neutrality

No participant — airline, GDS, agency, consolidator, settlement framework, or operator — is privileged in the verification logic. A proof is valid only if independent signals agree.

Determinism

Given the same set of input signals, the protocol produces the same proof. There is no probabilistic logic, no machine-learned scoring, and no off-protocol arbitration. Auditors can re-derive a proof and confirm it matches the public anchor.

Data minimisation

The on-chain artefact contains only a hash and a small set of structural metadata. No PNRs, ticket numbers, names, dates of birth, or itineraries appear on the public ledger. The protocol is GDPR-aligned by design.

Conservatism

If signals disagree, no proof is generated. Silence is preferred to a false positive. This is what makes PoT defensible in audit, insurance, and compliance contexts.

What a proof contains

A PoT proof is a small, structured record consisting of:

• A type identifying the lifecycle event (issuance, departure, arrival, reconciliation, refund, etc.).
• A commitment hash derived deterministically from the verified signal set.
• A schema version so older proofs remain re-derivable as the protocol evolves.
• A public anchor — a transaction hash and block reference on the underlying chain.

What it is not

PoT is not a booking system, a settlement system, an identity system, or a replacement for IATA/ARC reconciliation. It is an independent audit layer that sits alongside existing infrastructure.