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

​
What is verified

When Astral produces a signed result, that signature makes specific claims. This page spells out exactly what is covered — and what that coverage depends on.
Deployment status. The guarantees below hold when the service runs inside an enclave under continuous remote attestation. Astral has done this on real TEE hardware in test deployments, but does not currently fund continuous operation on attested hardware. On the hosted staging service today, a valid signature proves a key Astral controls produced the result — binding that key to an independently attested enclave is target-state. To evaluate Astral against real TEEs, reach out at contact@astral.global.

​
Verifiability properties

PropertyHow it’s achieved
Input integrityInput signatures verified at the TEE boundary before processing
Execution integrityUnder attestation, the TEE ensures code runs as deployed and can’t be modified
Output authenticitySigning key held inside the TEE; under attestation, can’t be extracted
DeterminismStateless model + fixed precision = same inputs produce same outputs
The integrity and authenticity properties depend on the enclave running under continuous remote attestation — see the deployment-status note above for what holds on the hosted service today.
Privacy is a near-term design direction. Today, signed results can still expose their inputs (see Privacy). The same TEE design makes stronger privacy feasible — encrypted input coordinates, shielded outputs (a policy decision carrying no identifying detail), and outputs encrypted so only a specified counterparty can read them. We’re designing these now; if that would be useful to you, reach out at contact@astral.global.

​
What the signature covers

Under attestation (see deployment status above), a signed result from Astral is intended to prove three things:
  1. The computation ran inside the TEE. EigenCompute is designed to provide hardware attestation that the expected code is executing in the attested environment.
  2. The inputs were hashed and recorded. Every signed result includes inputRefs — hashes of the inputs used. You can verify which inputs went into the computation. This holds today regardless of attestation status.
  3. The output was produced by that computation. The signing key is held inside the TEE. When the enclave is attested, a valid signature means the output came from the attested code running on the referenced inputs. Without live attestation, a valid signature proves only that Astral’s key signed the result.

​
What the signature does not establish: location correspondence

The signature proves the computation (or, for verification, the evaluation) ran correctly on the stated inputs. It does not, on its own, establish that a location claim corresponds to physical reality. That correspondence comes from two things outside the signature:
  • the evidence bundled into the location proof — stamps from one or more proof-of-location systems, and
  • the evaluation function applied to that evidence, which produces the credibility vector.
Astral runs that evaluation and reports it honestly; it does not pronounce a claim “true.” It is up to the verifier to decide whether a given evidence set and evaluation function are convincing enough for their context — a 10check−inanda10 check-in and a 10M asset transfer warrant very different thresholds.

​
Input references (inputRefs)

Every signed result includes an array of inputRefs — deterministic references to the inputs used in the computation. These let downstream consumers verify which inputs were used:
  • For geographic features referenced by UID, the inputRef is the UID itself
  • For raw GeoJSON inputs, the inputRef is a hash of the geometry
This means you can check not just that a computation was performed, but what data it operated on.

​
Computation reproducibility

Determinism is what makes signed results meaningful. If someone else runs the same computation on the same inputs, they should get the same answer. Astral achieves this through:
  • Centimeter precision rounding before signing — eliminates floating-point variance
  • Pinned PostGIS version in the container — no algorithm changes between builds
  • Stateless execution — no accumulated state that could affect results

​
The signing key

The service holds a signing key inside the TEE:
  • Key is generated within the TEE or securely provisioned
  • Intended to be non-extractable by the operator when the enclave is attested
  • All results are signed with this key
  • Downstream consumers verify that results came from the known Astral signer
Verifying that the attester matches Astral’s signer proves the result came from a key Astral controls. Binding that key to an independently attested enclave — so a matching signature also proves where and how it was produced — is the target-state property described in the deployment-status note above.
// In a resolver contract
require(attestation.attester == ASTRAL_SIGNER, "Not from Astral");

Next: What you are trusting

Honest accounting of current assumptions