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.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
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
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.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:
- API Reference — full endpoint documentation