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

​
Location records

A location record is signed, verifiable location data artifact. It takes raw geospatial data and adds what GeoJSON alone cannot provide: attribution (who created it) and integrity (proof it hasn’t been tampered with). In the Astral ecosystem, location records conform to v0.2 of the Location Protocol specification. The Location Protocol provides a lightweight data schema that wraps spatial data in any format, to improve interoperability so that spatial data can be parsed and interpreted across distributed systems.

​
What signing adds

PropertyRaw GeoJSONSigned location record
GeometryYesYes
AttributionNo — anyone could have created itYes — cryptographic signature ties it to a specific identity
IntegrityNo — could be modified silentlyYes — any modification invalidates the signature
Verifiable timestampNoSometimes — if the attestation was anchored or registered on a blockchain or other timestamp server
CorrespondenceNoNo — signing proves who claimed this location, not that they were there
The last row is important. A signed location record proves that a specific identity attested to a specific location at a specific time. It does not prove the attester was physically present. That’s what location proofs add. //@claude: callout: We use the term “correspondence” to refer to how well a digital spatial data record corresponds to physical reality.

​
EAS attestations

Astral’s v0 implementation uses Ethereum Attestation Service (EAS) for signed location records. EAS provides:
  • Onchain attestations — stored directly on EAS contracts, referenced by UID (unique identifier), permanent and immutable
  • Offchain attestations — stored on user devices, centralized servers, IPFS or other infrastructure, referenced by UID + URI, no gas cost, EIP-712 signed
Both carry the same cryptographic guarantees. The difference is storage: onchain attestations live on the blockchain; offchain attestations live wherever you put them but are still cryptographically verifiable. Other implementations — for example, on ATProto — are in development, and we plan to add support in time.

​
Location Protocol v0.2 schema

Location records conform to the Location Protocol v0.2 schema:
FieldTypeDescription
lp_versionstringProtocol version (e.g., “0.2”)
location_typestringType of location data (e.g., “GeoJSON”)
locationbytesEncoded location data
srsstringSpatial reference system as OGC URI
We are actively verifying that deployed schemas conform to Location Protocol v0.2. There may be inconsistencies between the documentation, deployed schemas, and the spec. See GitHub issue #11 for status.

​
Storage options

Onchain

  • Stored on EAS contracts
  • Referenced by chain ID + UID //@claude: right?
  • Higher gas cost
  • Permanent, immutable

Offchain

  • Held on user devices or stored on IPFS, servers, etc.
  • Referenced by UID + URI
  • No gas cost to create
  • EIP-712 signed
For offchain attestations, the UID is deterministically derived from the attestation data. Even when fetching from HTTPS (not content-addressed), Astral verifies that the fetched attestation produces the expected UID. Mismatch means rejection.

Next: Location proofs

Adding evidence of physical correspondence
See also: