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

​
What you are trusting

We’re transparent about what’s verified and what’s assumed because trust is the product. This page gives an honest accounting of the current trust assumptions and where they’re headed.

​
Current trust assumptions

AssumptionStatusNotes
TEE executes code correctlyVerified under attestationEigenCompute provides hardware attestation; continuous attested deployment is target-state (see below)
Service runs under continuous attestationNot yetDemonstrated in test deployments; not continuously funded today
Astral operates service honestlyRequiredSingle operator in the Research Preview
Signing key held securely in TEEVerified under attestationIntended to be non-extractable when the enclave is attested
Input locations are truthfulDepends on the inputRaw coordinates are trust-based; a location proof backs the input with evaluable evidence — available today (ProofMode end to end; other plugins experimental)
The Research Preview uses a centralized trust model: a single service with a known signer, designed to run inside a TEE. The TEE provides execution attestation, and deterministic operations ensure reproducibility. But you are trusting Astral to operate the service honestly.
Deployment status. Astral has run the service on real TEE hardware in test deployments, but does not currently fund continuous operation on attested hardware. On the hosted staging service today, a valid signature proves that a key Astral controls produced the result — not yet that an independently attested enclave did. This is the gap between “signed by a key” and “signed by an attested enclave,” and we’d rather state it plainly. If you want to evaluate Astral against real TEEs, reach out at contact@astral.global.

​
Raw location inputs are trust-based — location proofs change that

If you pass raw coordinates to Astral, you are trusting they’re honest. GPS is spoofable; a user can claim to be anywhere. A signed result over raw coordinates proves that if the user was at location A, then they were within 500m of location B — not that they were actually at A. This is exactly what location proofs address, and they exist today. Instead of bare coordinates, you submit a claim backed by evidence — stamps from one or more proof-of-location systems. Astral evaluates that evidence and returns a credibility vector. It can’t make weak evidence strong, but it turns “trust the input” into “weigh the evidence and the evaluation.” ProofMode works end to end now; other plugins are experimental, with interfaces defined (we’re keen to develop more with partners — get in touch). Be direct with your users: if you rely on raw coordinates rather than location proofs, the location data is trust-based — say so.

​
What verification buys you today

Even with these assumptions, verifiable computation is meaningful:
  • The computation is correct. You know the spatial relationship was evaluated faithfully, not fabricated.
  • The inputs are recorded. inputRefs let you audit which data went into the computation.
  • The result is tamper-evident. The signature proves the output was produced by Astral’s key and hasn’t been altered since. Under attestation, it further proves the output came from the attested environment.
This is substantially better than trusting an opaque API that returns true or false with no proof.

​
The path forward

1

AVS Consensus

Multiple independent operators run the computation. Results must match to be accepted. No single operator can lie.
2

ZK Proofs

Cryptographic proof that the computation was correct. Verifiable by anyone without trusting the prover.
3

Decentralized Signers

Multi-party computation for result signing. No single party holds the full key.
4

Location Proof Integration

Evidence-based location claims replace raw GPS. Multiple corroborating stamps make spoofing harder.
Each enhancement reduces the trust surface. AVS consensus removes the single-operator assumption. ZK proofs make verification independent of hardware trust. Decentralized signers eliminate the single key. Location proofs address the input honesty gap.

Next: Security considerations

Threat model, known limitations, and responsible disclosure