​

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.

​

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

Running the service inside an attested enclave would keep the host operator from inspecting the running process’s memory — so raw input coordinates, exact geometries, and stamp signals would live only in enclave memory during computation. That is the privacy property a TEE provides, and it’s narrow: it would not encrypt inputs end-to-end, and it would not stop the service from returning inputs in the result. True input and output privacy needs the affordances described in Privacy, not the TEE alone. 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.

​

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

---

See also:

• API Reference — full endpoint documentation