> ## Documentation Index
> Fetch the complete documentation index at: https://astral-6ef288be-docs-policy-evaluation-framing.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Security

> Security considerations and trust model

<Warning>
  **Research Preview** — Security audit pending.
</Warning>

# Security Considerations

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

## Astral Signer Address

<Info>
  **Current Astral Signer (Base Sepolia):** `0x590fdb53ed3f0B52694876d42367192a5336700F`

  Resolver contracts must verify that `attestation.attester` equals this address. See [Staging](/resources/staging) for the full configuration.
</Info>

## 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](#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):**

```solidity theme={null}
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**:

```typescript theme={null}
// 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](https://www.gsc-europa.eu/galileo/services/galileo-open-service-navigation-message-authentication-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](mailto:contact@astral.global).

***

## Best Practices

### For Resolver Authors

<AccordionGroup>
  <Accordion title="Always verify attester" icon="shield-check">
    ```solidity theme={null}
    require(attestation.attester == astralSigner, "Not from Astral");
    ```
  </Accordion>

  <Accordion title="Check timestamp freshness" icon="clock">
    ```solidity theme={null}
    require(timestamp > block.timestamp - MAX_AGE, "Attestation too old");
    ```
  </Accordion>

  <Accordion title="Verify input references" icon="link">
    ```solidity theme={null}
    require(inputRefs[1] == EXPECTED_LANDMARK, "Wrong location checked");
    ```
  </Accordion>

  <Accordion title="Track used attestations" icon="list-check">
    ```solidity theme={null}
    require(!usedAttestations[uid], "Already used");
    usedAttestations[uid] = true;
    ```
  </Accordion>

  <Accordion title="Support key rotation" icon="rotate">
    ```solidity theme={null}
    function updateSigner(address newSigner) external onlyOwner {
        astralSigner = newSigner;
    }
    ```
  </Accordion>
</AccordionGroup>

### 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](#tee-attestation-deployment))
* Used to sign all results

### Key Rotation

Resolver contracts should support key rotation:

```solidity theme={null}
address public astralSigner;

event SignerUpdated(address oldSigner, address newSigner);

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

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

***

## Audit Status

| Component         | Status  |
| ----------------- | ------- |
| Compute Service   | Pending |
| SDK               | Pending |
| Example Contracts | Pending |

<Note>
  Full security audit will be conducted before mainnet deployment.
</Note>

<Card title="Next: Roadmap" icon="road" href="/resources/roadmap">
  See what's coming
</Card>