Security

Security considerations and trust model

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): 0x590fdb53ed3f0B52694876d42367192a5336700F

Resolver contracts must verify that attestation.attester equals this address. See Staging for the full configuration.

Trust Model

Current (Research Preview)

Trust Assumption	Status
TEE executes code correctly	✓ Verified under attestation
Service runs under continuous attestation	✗ Test deployments only (not yet funded)
Astral operates service honestly	✓ Required
Signing key held securely in TEE	✓ Verified under attestation
Input locations verified	✗ Future work

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

Phase	Enhancement	Benefit
2	AVS Consensus	Multiple operators must agree
3	ZK Proofs	Cryptographic computation proof
4	Decentralized Signing	No single point of failure

---

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):

contract SecureResolver is SchemaResolver {
    mapping(bytes32 => bool) public usedAttestations;

    function onAttest(Attestation calldata attestation, uint256)
        internal override returns (bool)
    {
        // 1. Check not already used
        bytes32 attHash = keccak256(abi.encode(attestation.uid));
        require(!usedAttestations[attHash], "Already used");
        usedAttestations[attHash] = true;

        // 2. Check timestamp freshness
        (, , uint64 timestamp, ) = abi.decode(...);
        require(timestamp > block.timestamp - 1 hours, "Too old");

        // 3. Verify expected inputs
        (, bytes32[] memory inputRefs, , ) = abi.decode(...);
        require(inputRefs[1] == EXPECTED_LOCATION, "Wrong location");

        // ... business logic
    }
}

---

Input Trust

Status: Raw GeoJSON not verified

Raw GeoJSON inputs are accepted for flexibility, but are not verified for authenticity:

// This works but geometry source is unverified
const result = await astral.compute.contains(
  { type: 'Polygon', coordinates: [...] },  // Raw, unverified
  userLocationUID
);

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 [e-mail].

---

Best Practices

For Resolver Authors

Always verify attester

require(attestation.attester == astralSigner, "Not from Astral");

Check timestamp freshness

require(timestamp > block.timestamp - MAX_AGE, "Attestation too old");

Verify input references

require(inputRefs[1] == EXPECTED_LANDMARK, "Wrong location checked");

Track used attestations

require(!usedAttestations[uid], "Already used");
usedAttestations[uid] = true;

Support key rotation

function updateSigner(address newSigner) external onlyOwner {
    astralSigner = newSigner;
}

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:

address public astralSigner;

event SignerUpdated(address oldSigner, address newSigner);

function updateAstralSigner(address newSigner) external onlyOwner {
    emit SignerUpdated(astralSigner, newSigner);
    astralSigner = newSigner;
}

For the Research Preview, a simple owner-controlled update is sufficient. For production, consider making the owner a multisig.

---

Audit Status

Component	Status
Compute Service	Pending
SDK	Pending
Example Contracts	Pending

Full security audit will be conducted before mainnet deployment.

Next: Roadmap

See what’s coming