Skip to main content

Building a custom plugin

Any proof-of-location system can integrate with the Astral SDK by implementing the LocationProofPlugin interface. This guide walks through the interface contract, which methods to implement, and how to test your plugin.

The interface

All four methods are optional. Implement what makes sense for your system.

Step 1: Implement the interface


Step 2: Register with the SDK

The registry validates that the current runtime is in the plugin’s runtimes array. If not, register() throws.

Step 3: Use through the SDK

Once registered, your plugin works with the standard stamps and proofs pipeline:

Which methods to implement

MethodImplement when…
collect()Your system can actively gather evidence (API calls, sensor reads)
create()You need to parse raw data into Location Protocol v0.2 format
sign()Your system has its own signing mechanism (most plugins skip this — the SDK handles signing)
verify()You can validate stamps from your system (signature checks, signal consistency)
Common patterns:
  • API-based service (like WitnessChain): implement collect(), create(), verify()
  • Mobile app export (like ProofMode): implement create(), verify() (collection happens on-device)
  • Full control: implement all four methods

Runtime compatibility

Declare which environments your plugin supports:
The SDK detects the current runtime automatically and rejects plugins that don’t support it.

Location Protocol v0.2 compliance

Stamps must conform to LP v0.2. Key requirements for UnsignedLocationStamp:
FieldTypeDescription
lpVersionstringMust be '0.2'
locationTypestringe.g., 'geojson-point', 'h3-index'
locationLocationDataGeoJSON geometry or string
srsstringSpatial reference system, typically 'EPSG:4326'
temporalFootprint{ start: number; end: number }Unix seconds
pluginstringYour plugin name
pluginVersionstringSemver
signalsRecord<string, unknown>Plugin-specific data

Testing with MockPlugin

Use the MockPlugin as a reference implementation and for testing alongside your plugin: