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

Astral Location Services

Astral Location Services is the hosted service that performs location proof verification and geospatial computation. It is designed to run inside a Trusted Execution Environment (TEE) — which, under attestation, is what makes results verifiable rather than merely signed.
Deployment status. Astral has run this service on real TEE hardware in test deployments, but does not currently fund continuous operation on attested hardware. The properties described below hold when the enclave runs under continuous remote attestation; on the hosted staging service today, a valid signature proves a key Astral controls produced the result, not yet that an independently attested enclave did. See What you are trusting. To evaluate against real TEEs, reach out at contact@astral.global.
The TEE makes the computation verifiable — that the attested code ran on the stated inputs. It does not make the location inputs truthful. Whether a location is real depends on the strength of the location proof behind it, not on the TEE.

What the Service Provides

Two endpoints, one TEE:
  • Verify — Submit a location proof, get back a verified location proof: the original proof, a credibility vector, and a signed EAS attestation
  • Compute — Submit location data with geographic features and a specified spatial operation, get a signed result representing the computed relationship between those features
Both endpoints accept requests via the Astral SDK or directly through the API.

Verifiability Properties

Under attestation, the TEE is designed to provide four properties that together make computation verifiable: Together, under attestation: the code is attested, signed inputs are verified, the computation is deterministic, and the output is signed by a key the operator cannot access. An observer can then verify that the result came from the correct code running on the referenced inputs — without re-executing the computation. This is a statement about the computation, not about whether the input locations are truthful.

Privacy Properties

Under attestation, the TEE provides meaningful privacy properties. Inputs and outputs are encrypted in transit and decrypted only inside the enclave, so the infrastructure operator does not see raw location data:
  • Raw input coordinates are processed inside the enclave and not exposed to the operator
  • Exact geometries (polygon boundaries, line paths) exist only during computation and are discarded after signing
  • The operator — whoever runs the Astral service — does not access the plaintext data inside an attested enclave
v0 caveat. Today, signed results may still include input data in plaintext (the full claim, stamps, and credibility vector travel with the result), so anyone who receives a result can read those inputs even though the operator does not. A privacy-preserving output mode is planned. See Privacy for the full picture.
Some information also leaks from the result itself (a contains answer of true tells you the point is inside the polygon), but that is inherent to the computation, not a limitation of the privacy model.

TEE stack

Astral is not tied to a specific TEE provider. The architecture is a self-contained Docker container, so in principle it can run in any TEE that supports containerized workloads — assessing portability across providers is ongoing. The current deployment target is EigenCompute (part of the EigenCloud ecosystem): PostGIS runs inside the TEE container, not as an external service — no external dependencies means the entire execution environment is attested. The GEOS library under PostGIS is the same C++ geometry engine used by QGIS, GDAL, and most professional geospatial software.

The Signing Key

The signing key is generated and provisioned inside the TEE. The design intent is that the operator cannot extract it — a property that holds when the enclave runs under remote attestation (see the deployment-status note above). All signed results are produced by this key, and downstream consumers (smart contracts, applications, agents) can verify that a result was signed by the Astral service by checking the signature against the known public key.
Signing key publication is not yet finalized — key management and rotation are still being worked out for production deployment. This page will be updated with the public key and verification instructions when available.
For key rotation and management details in smart contract integrations, see the SDK: EAS module.

Stateless Model

Each request brings all required inputs. There is no persistent state between requests. This ensures determinism — the same request always produces the same result, regardless of when it’s submitted or what other requests have been processed.

Future Directions

The current TEE-based approach is what makes computation verifiable under attestation. Directions we’re exploring to reduce the trust surface further:
  • AVS consensus — Multiple operators independently verify computations
  • ZK proofs — Cryptographic proof of correct execution without trusted hardware
  • Decentralized signers — Multi-party result signing

Next: Verify

The verification endpoint in detail

See also: