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

​
Security considerations

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

​
Astral signer address

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

​
Known considerations

​
Replay attacks

Status: Documented, resolver responsibility Signed results 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 The signature on a result proves it was produced by a key Astral controls. Binding that key to an independently attested enclave — so a valid signature also proves which code ran and where — requires the service to run under 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. If you want to evaluate Astral against real TEEs, reach out at contact@astral.global.

​
Best practices

​
For resolver authors

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

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

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

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

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

​
For application developers

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

​
Key management

​
Service signing key

  • Key generated or 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

ComponentStatus
Compute ServicePending
SDKPending
Example ContractsPending
Full security audit will be conducted before mainnet deployment.