Skip to main content
Research Preview — Security audit pending.

Security Considerations

This page documents the security model, known considerations, and best practices for building with Astral Location Services.

Astral Signer Address

Current Astral Signer (Base Sepolia): 0x590fdb53ed3f0B52694876d42367192a5336700FResolver contracts must verify that attestation.attester equals this address. See Staging for the full configuration.

Trust Model

Current (Research Preview)

The Research Preview uses a centralized trust model:
  • Single service with known signer
  • TEE (EigenCompute) provides execution attestation when running under continuous remote attestation — see TEE attestation deployment
  • Deterministic operations ensure reproducibility

Future Enhancements


Known Considerations

Replay Attacks

Status: Documented, resolver responsibility Signed results (once submitted onchain as attestations) could potentially be reused:
  • Temporal replay: Old result used for current benefit
  • Cross-context replay: Result for one resolver used at another
Mitigations (your responsibility):

Input Trust

Status: Raw GeoJSON not verified Raw GeoJSON inputs are accepted for flexibility, but are not verified for authenticity:
The signed result proves:
  • “Astral computed the relationship between A and B”
It does NOT prove:
  • “Geometry A came from a trusted source”
  • “User was actually at location B”
Best practice: For high-security applications, require attested inputs (UIDs) rather than raw GeoJSON.

GPS Spoofing

Status: Partially addressed by location proofs; an active research area Astral verifies that a computation was correct, not that the input location is where the device actually was. Raw GPS can be spoofed. Location proofs raise the cost: ProofMode, for example, includes on-device protections that resist some software spoofing (such as detecting rooted or tampered devices), but offers little against hardware/physical attacks like attenuating or replaying the RF signal. The goal is to raise the cost of forgery above the value of the action a proof supports, not to achieve certainty. Future: Combining multiple independent, corroborating stamps raises the bar further, and we’re researching harder proof-of-location systems — including authenticated GNSS signals such as Galileo OSNMA.

TEE Attestation Deployment

Status: Test deployments only; continuous attested operation not yet funded A valid signature proves a result was produced by a key Astral controls. Binding that key to an independently attested enclave — so the signature also proves which code ran and where — requires continuous remote attestation. Astral has demonstrated this on real TEE hardware in test deployments but does not currently fund continuous attested operation. Until then, treat a valid Astral signature as “signed by Astral’s key,” not as a hardware-attestation guarantee. To evaluate Astral against real TEEs, reach out at contact@astral.global.

Best Practices

For Resolver Authors

For Application Developers

  • Prefer attestation UIDs over raw GeoJSON for sensitive operations
  • Set appropriate timeouts — don’t accept stale attestations
  • Validate recipient — ensure attestation is for the right user
  • Handle signature expiry — delegated attestation signatures have deadlines

Key Management

Service Signing Key

  • Key generated/provisioned within the TEE
  • Intended to be non-extractable by operators when the enclave runs under attestation (see TEE Attestation Deployment)
  • Used to sign all results

Key Rotation

Resolver contracts should support key rotation:
For the Research Preview, a simple owner-controlled update is sufficient. For production, consider making the owner a multisig.

Audit Status

Full security audit will be conducted before mainnet deployment.

Next: Roadmap

See what’s coming