Skip to main content
Research Preview — APIs may change. GitHub

Verifying location proofs

A location proof is a location claim bundled with evidence — stamps from proof-of-location systems. The proof carries everything needed to assess the claim’s credibility. This guide walks you through creating a claim, collecting stamps, bundling them into a proof, and interpreting the verification result.

What is a location proof?

A location proof has two parts:
  • Claim — an assertion that a subject was at a location during a time window
  • Stamps — evidence from one or more proof-of-location systems that support (or contradict) the claim
The verification process evaluates the stamps against the claim and produces a credibility assessment — not a simple yes/no, but a structured evaluation of how strong the evidence is.

Creating a location claim

A claim follows the Location Protocol format and includes the asserted location, time bounds, and spatial uncertainty:
Key fields:
The radius field is required. Every location claim involves spatial uncertainty. Claiming a smaller radius requires stronger evidence to achieve the same credibility score.

Collecting stamps

Stamps are evidence from proof-of-location plugins. Each plugin collects signals from its PoL system and produces a stamp:
For stronger verification, collect stamps from multiple independent systems — independence is what cross-correlation rewards, so two stamps from the same source add little. Real independence means genuinely different proof-of-location systems (for example the ProofMode app plus a network-based plugin). Those client plugins are still being built; the shape is the same:

Bundling into a proof

Combine the claim and stamps into a location proof:
A single-stamp proof is valid. Multiple stamps from independent systems enable cross-correlation, which increases confidence.

Submitting to the verify API

Submit the proof for verification:
Or via raw HTTP:

Understanding credibility scores

The verification result is a structured credibility assessment, not a simple pass/fail:
The exact structure of the credibility vector is an open research question and will change. The fields below are illustrative of the current shape, not a stable contract.

Credibility dimensions

These dimensions are a preliminary sketch — their exact structure and metrics are an active research area and will change. The credibility vector is a multidimensional assessment grouped into four dimensions — each an object of metrics, not a single score:

No single score

There is no top-level confidence field. Collapsing the vector into one number requires deciding which dimensions matter most — that judgment belongs to your application, not to Astral. The SDK ships an exampleWeighting() helper you can use as a starting point, but you’re expected to define your own.
A credibility score is not a probability. Strong metrics mean the evidence is strong — not “an X% chance the claim is true.” Calibrating these to true probabilities is future work.

Cross-correlation

When a proof includes multiple stamps, the verification engine analyzes their relationship:
  • Independence — are the stamps from truly independent systems? Two stamps from the same underlying data source do not add much.
  • Agreement — do the stamps agree on location and time? Independent stamps that corroborate each other significantly boost confidence.

Multi-factor proofs

Multiple stamps from independent systems increase confidence because an attacker would need to compromise multiple unrelated systems simultaneously:
The improvement comes from source independence. Redundant stamps from the same system do not meaningfully strengthen the assessment, but they do not weaken it either.

Choosing the right level of evidence

The level of evidence you need depends on the value of the transaction the proof underpins:
  • Low-stakes (check-in rewards, social proof) — a single stamp from a device attestation plugin may be sufficient.
  • Medium-stakes (delivery verification, access control) — two independent stamps provide meaningful forgery resistance.
  • High-stakes (insurance payouts, land records) — multiple independent stamps with high forgery resistance, plus onchain submission for an immutable audit trail.

Using verified proofs as compute inputs

Verified location proofs can serve as trusted inputs to geocomputation operations. This connects the verification pipeline to the spatial reasoning pipeline:

Next steps

Location proofs concept

Deeper dive into claims, stamps, and the verification model

Building plugins

Connect a new proof-of-location system to Astral