Threat Model Section: Document What Is and Isn't Proven

[johnx25bd]

Priority: Critical

Description

The documentation correctly notes that policy attestations prove "Astral computed the relationship between inputs A and B," but not who signed the raw GeoJSON inputs. However, the implications need to be spelled out more explicitly because this is where systems get exploited.

Concrete risk surfaces not clearly treated:

1. Garbage-in attestation: User attests their own location → policy says "within" → resolver mints NFT → attacker spoofs GPS. GPS spoofability is mentioned once but not carried into threat modeling.

2. Boundary conditions: The docs note ST_Contains boundary behavior and suggest intersects for boundary cases, but don't connect this to resolver implementation to prevent accidental rejection of legitimate edge cases.

3. Replay & freshness: Timestamp checks and usedAttestations are recommended, but the example usedAttestations hashing is inconsistent (sometimes keyed by UID, sometimes by keccak of encoded attestation).

Fix Direction

Add a compact Threat Model section covering:

• What Astral guarantees:

  • Computation integrity
  • Input binding
  • Signer identity

• What Astral does NOT guarantee:

  • Input truth
  • GPS honesty
  • Identity binding

• Recommended plugin/proof path (even if "in development") and interim mitigations

• Consistent guidance on usedAttestations implementation