Skip to main content
Research Preview — This project is under active development.

​
Frequently Asked Questions

​
General

Astral Location Services is verifiable location infrastructure. It does two things: it verifies location proofs (via the /verify endpoint — evaluating evidence about where something was), and it runs geospatial computation (distance, containment, intersection) inside a trusted execution environment. Both produce signed results that any downstream system can verify independently — an agent, a backend, a compliance report, or a smart contract.
A normal geospatial API returns an answer you have to take on faith. Astral signs the result inside a TEE, so anyone can check that the computation was performed correctly on the stated inputs — without re-running it or trusting the server. (This is a hardware-backed attestation, not a zero-knowledge proof — and it depends on the service running under attestation; see the trust model for current deployment status.)
Most uses are entirely offchain:
  • Delivery and field-service verification
  • Compliance and audit trails (e.g. an asset stayed within an approved area)
  • Spatial decisions for autonomous agents, with a verifiable record
  • Parametric triggers based on verified proximity
The same signed results are also natively compatible with Ethereum smart contracts, for onchain use cases (proof-of-visit, geofenced access, and so on). See Use Cases for detailed examples.
No. Astral Location Services is under active development. APIs may change. We’re building in public and welcome feedback!

​
Technical

Supported operations:
  • distance - Distance between two geometries (meters)
  • contains - Is geometry B inside geometry A?
  • within - Is point within radius of target?
  • intersects - Do geometries overlap?
  • area - Area of a polygon (square meters)
  • length - Length of a line (meters)
Future operations:
  • buffer, centroid, union, intersection, disjoint
v0 targets Base Sepolia (chain ID 84532). Additional chains (Base Mainnet, Ethereum Sepolia/Mainnet) are planned.
  1. Operations run in EigenCompute’s TEE (Trusted Execution Environment)
  2. Under remote attestation, the TEE attests that specific code executed on specific inputs
  3. Results are signed with a key held inside the TEE
  4. Smart contracts verify attestation.attester == astralSigner
Note: continuous attested operation is not yet funded — today a valid signature proves Astral’s key produced the result. See the trust model.
Today: A centralized service with TEE execution attestation. You are trusting Astral (the operator) and the TEE — and, to some extent, the TEE manufacturer.Future: AVS consensus (multiple operators), ZK proofs, decentralized signing.
Yes. GPS is spoofable. Astral verifies that computations are correct, not that inputs are authentic. If a user provides a fake GPS coordinate, we’ll compute on that fake coordinate.We’ve developed a framework for multifactor location proofs, which compose evidence from multiple corroborating proof-of-location systems to support a location claim. The aim is to raise the cost of spoofing, not to make it impossible. ProofMode is working today; experimental stamp-verification logic for several other systems (witnesschain, gpsd, geoclue, wifi-mls, ip-geolocation) also exists, with interfaces defined. We’re keen to develop new proof-of-location plugins with partners. As these mature, they plug into Astral for stronger verification.

​
Integration

No. Astral operates the service. You use the SDK (or call the API directly) to get signed results; if you want them onchain, you submit them to your contracts yourself.
You do. The delegated attestation pattern means:
  • Astral signs the attestation offchain
  • You submit with Astral’s signature (paying gas)
  • EAS records Astral as the attester
This lets you control costs and timing.
No — and most uses don’t. Signed results are produced offchain and used directly in your application; that’s the primary path. A blockchain is only involved if you choose to submit a result onchain.
Yes — signed results are natively compatible with Ethereum smart contracts. Use an EAS resolver:
function onAttest(Attestation calldata attestation, uint256)
    internal override returns (bool)
{
    require(attestation.attester == astralSigner, "Not from Astral");
    (bool result, , , ) = abi.decode(attestation.data, (bool, bytes32[], uint64, string));
    require(result, "Location check failed");
    // ... your logic
}
Complementary!
  • Turf.js: Client-side, instant, free, unverified
  • Astral: Server-side, verified, signed result
Use Turf for UX (showing distance in real-time), and Astral when you need a result you can verify (and, if you want, submit onchain).

​
Data

GeoJSON standard: [longitude, latitude] in WGS84 (EPSG:4326).
// San Francisco
const sf = { type: 'Point', coordinates: [-122.4194, 37.7749] };
Metric only:
  • Distance/length: meters
  • Area: square meters
  • Radius (in within): meters
No unit conversion options. Convert client-side if needed.
Both work! You can pass:
  • Attestation UIDs (verified, traceable)
  • Raw GeoJSON (unverified, for reference data or prototyping)
For security-sensitive operations, prefer attestation UIDs.
  • Location records: On EAS (onchain) or IPFS/your storage (offchain)
  • Signed results: Returned to you; optionally submitted to EAS as attestations
  • Compute service: Stateless, no persistent storage

​
Getting Help

We’re building in public:
  • Open issues with feedback
  • Share your use cases
  • Submit PRs for improvements

Back: Introduction

Return to the introduction