> ## Documentation Index
> Fetch the complete documentation index at: https://astral-6ef288be-docs-policy-evaluation-framing.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Verify

> The verification endpoint — submit a location proof, get a verified location proof

<Note>**Research Preview** — APIs may change. [GitHub](https://github.com/AstralProtocol)</Note>

# Verify

The Verify service accepts a [location proof](/concepts/location-proof-structure) and returns a **verified location proof** — the original proof, a [credibility vector](/concepts/location-proof-evaluation#the-credibility-vector), and a signed result that can be recorded onchain as an EAS attestation. It's a hosted implementation of the [evaluation function](/concepts/location-proof-evaluation). This page describes *how the service works*; the evaluation page describes *what is checked and why*.

## How It Works

When a location proof is submitted to the verify endpoint:

1. **Plugin resolution** — The service identifies which [location proof plugins](/plugins/overview) produced each [location stamp](/concepts/location-stamps) in the proof and loads the appropriate verification logic.

2. **Stamp verification** — Each location stamp is verified independently: signature validation, structural checks, and signal consistency assessment. Verification is plugin-specific — each plugin knows how to check its own evidence.

3. **Cross-correlation** (multi-stamp location proofs) — For location proofs with multiple location stamps from independent proof-of-location systems, the service assesses independence and agreement across sources.

4. **Claim assessment** — The service evaluates how well the evidence from the location stamps supports the [location claim](/concepts/location-claims): spatial overlap, temporal overlap, and overall consistency.

5. **Credibility vector generation** — The per-stamp results, correlation analysis, and claim assessment are combined into a structured credibility vector. It currently spans spatial, temporal, validity, and independence dimensions, though [that structure is an open research question](/concepts/location-proof-evaluation#the-credibility-vector) and will change.

All of this is designed to happen inside the [TEE](/concepts/astral-location-services), so that — under attestation — the evaluation logic is attested and the signing key is protected. See the [trust model](/trust-model/what-you-are-trusting) for current deployment status.

## Two Endpoints

| Endpoint                                        | Input                                | Output                  | Use case                                                            |
| ----------------------------------------------- | ------------------------------------ | ----------------------- | ------------------------------------------------------------------- |
| **[Verify proof](/api-reference/verify/proof)** | Full location proof (claim + stamps) | Verified location proof | Full evaluation — the primary verification path                     |
| **[Verify stamp](/api-reference/verify/stamp)** | Single location stamp                | Stamp validity result   | Quick check of a location stamp's internal validity without a claim |

The stamp endpoint is useful for confirming that a location stamp's signatures are valid and its structure is correct — without the overhead of claim assessment and cross-correlation.

## What Each Endpoint Returns

**Verify proof** returns a verified location proof containing:

* **The original proof** — the location claim and location stamps as submitted
* **Credibility vector** — structured assessment across (currently) spatial, temporal, validity, and independence dimensions, with per-stamp detail; the dimension structure is still evolving
* **Signed result** — the verification result signed by the TEE key, independently verifiable by any downstream consumer and optionally recorded onchain as an EAS attestation

**Verify stamp** returns a validity result: whether signatures, structure, and signals pass their checks.

A verified location proof is valuable on its own. It doesn't need to flow into a [Compute](/concepts/compute) operation — many applications only need to know "how credible is this location claim?" without asking any further spatial questions.

<Card title="Next: Compute" icon="calculator" href="/concepts/compute">
  Geospatial operations inside the TEE
</Card>

***

**See also:**

* [API: Verify proof](/api-reference/verify/proof) — endpoint reference
* [API: Verify stamp](/api-reference/verify/stamp) — stamp verification endpoint
* [SDK: Location proofs](/sdk/location-proofs) — programmatic verification