Skip to main content
Research Preview — Under active development.

​
Verifiable Computation

Astral Location Services run in a Trusted Execution Environment (TEE) via EigenCompute, providing cryptographic guarantees that computations were performed correctly.

​
The Verification Pipeline

Building trustworthy location-based smart contracts requires verification at multiple stages: Astral Location Services solve the middle step — verifiable geospatial computation. Given location inputs, we can provably check spatial relationships and produce signed attestations for onchain use.
What about step 1? Verifying where a user actually is remains an open problem. GPS is spoofable. We’re developing the Location Proof framework to address this. Location proofs will plug into Astral Location Services to complete the pipeline.

​
Why Verification Matters

Without verification, you’re trusting a black box. Anyone could claim “the user is nearby” without proof. With verifiable computation, the signed attestation proves the result came from executing specific code on specific inputs inside a TEE. Smart contracts can verify that the Astral signing key performed the computation correctly, not just that someone claims it did.

​
EigenCompute

EigenCompute is part of the EigenCloud ecosystem. It provides:

TEE Execution

Code runs in a hardware-isolated environment that even the operator can’t tamper with

Attestation

Hardware-generated proof that specific code executed on specific inputs

Determinism

Same inputs always produce same outputs — reproducible and auditable

Future-Proof

Path to additional verifiability (ZK proofs, AVS consensus)

​
The Execution Model

Verify EigenCompute details against the official EigenCompute documentation. Hardware attestation (remote attestation) specifics may vary.

​
Verifiability Properties

PropertyHow It’s Achieved
Input IntegrityAttestation signatures verified at TEE boundary before processing
Execution IntegrityTEE ensures code runs as deployed, can’t be modified
Output AuthenticitySigning key held inside TEE, can’t be extracted
DeterminismStateless model + fixed precision = same inputs → same outputs

​
The Astral Signing Key

The service holds a signing key inside the TEE:
  • Key is generated within the TEE or securely provisioned
  • Cannot be extracted by the operator
  • All Policy Attestations are signed with this key
  • Resolver contracts verify attestation.attester matches the known Astral signer
// In your resolver
require(attestation.attester == ASTRAL_SIGNER, "Not from Astral");

​
Trust Model

​
Current (MVP)

Why can you trust the computation results?
  • Open source code: The compute service code is public and auditable
  • TEE execution: Code runs inside EigenCompute’s trusted execution environment
  • Remote attestation: EigenCompute provides hardware attestation that the expected code is running
  • Deterministic operations: Same inputs always produce same outputs (additional testing in progress)

​
Future Enhancements

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 attestation signing. No single party holds the full key.

​
Why This Matters

Consider a location-gated NFT. The question is: how do we check “is the user within 500m of the Eiffel Tower?” in a way that smart contracts can trust? The computation problem (what Astral Location Services solve): If we have location data for the user and the Eiffel Tower, how do we verifiably check if they’re close enough? The geospatial policy engine runs the computation in a TEE and produces a signed attestation: 
Location A + Location B → TEE (PostGIS) → Signed attestation: "distance = 450m"
The input problem (location proofs, still being developed): Even with verifiable computation, users can lie about their location. GPS is spoofable. The attestation proves the computation was correct, not that the inputs were honest. This is why we’re developing the Location Proof framework — to provide evidence-based location claims that can feed into Astral Location Services for a fully verifiable pipeline.
Be upfront with your users: Until location proof plugins are integrated, location verification relies on trusting the user’s GPS. Astral Location Services provides verifiable computation, not verifiable location.

​
Why Build the Geospatial Layer First?

Location proofs become useful when they can trigger onchain actions through geospatial policies. Astral Location Services apply those policies — checking if a location is inside a boundary, within range of a target, or satisfies other spatial constraints. By building the geospatial policy infrastructure now, we can experiment with use cases and iterate while developing the Location Proof plugins. As proof mechanisms mature, they plug directly into the existing pipeline.

​
Determinism Guarantees

To ensure reproducibility:
  • Precision: Results rounded to centimeter precision before signing
  • Stateless: No persistent state between requests
  • Fixed algorithms: PostGIS version pinned in container
// Same inputs always produce same outputs
const result1 = await astral.compute.distance(uid1, uid2);
const result2 = await astral.compute.distance(uid1, uid2);

result1.result === result2.result  // Always true

Back to: How It Works

See the full architecture