# Proposed Workplan: the Astral Protocol

At Astral we are creating the tools developers will need to build an ecosystem of location-based dApps and composable spatial contracts. We see a vast opportunity space here, with exciting early initiatives from [FOAM](https://foam.space/), [Regen Network](https://www.regen.network/), [Grassroots Economics](https://www.grassrootseconomics.org/), [IoTeX](https://iotex.io/), [IBISA Network](https://ibisa.network/) and others.

Our vision at Astral is to build tools and help establish standards that will enable a composable location-based decentralized web. We're quite early in our journey, and have an orienting question prompting these investigations - what if we could use an entity's physical location as a condition in a smart contract? And relatedly, how can we connect verifiable insights about physical reality with smart contract logic?

Our investigations into this question has hardened our understanding of the tools and components needed. Our goal here is to share these ideas openly - gather some feedback, and see if you or anyone you know would be interested in supporting one or more of these initiatives with expertise and / or capital. Our strategy is to design a modular architecture of Web3 spatial primitives - each useful in their own right, but designed to function best together.

We have built a few Astral dApp prototypes, and have architected a few more. This work has helped us identify versatile tools that would have accelerated development, regardless of the application. Based on these insights we are conceptualizing the design space as a three layer stack.
- **Spatial Contracts** - smart contracts that use location or spatial data in some way
- **Data** - capture, storage and perhaps processing
- **Oracles** - to connect the two

Our goal is to produce a suite of tools, libraries and SDKs that would let developers efficiently build location-based dapps without having to deal with the complexities of managing spatial data in the Web3 paradigm. A second order effect is that if the community adopts standards, applications become composable.

To achieve this goal, we are currently working on a few initiatives:
- Spatial.sol
- Verifiable spatial data registries
- GeoDIDs
- IPLD-encoded raster and vector spatial datasets
- Universal location proofs

## Spatial.sol: a Solidity library of topological and geometric functions

Many of the applications we envision will require us to perform spatial operations in smart contracts. To this end, a few years ago (at ETHParis) we outlined and experimented with a Solidity library for performing these operations - measuring the length of a linestring, testing to see if lines intersect, checking to see if a point is inside a polygon, etc.

We prototyped a location-aware wallet (early experiments that may lead to truly [**local** currencies](https://ethresear.ch/t/how-to-implement-digital-community-currencies-with-ethereum/8801)). At the time we were discouraged due to computational complexity leading to high gas costs, but Layer 2 solutions like Polygon and xDai, alternative lower cost EVM-compatible blockchains like IoTeX or Avalanche and, of course, Eth2 does mean that these kinds of operations will be increasingly viable in smart contracts.

We are developing the first version of the `Spatial.sol` library and plan to release it under an open source license. Developing the library entails tackling several technical challenges, and to build a production-quality library will be quite involved.

First, `Spatial.sol` has a dependency: `Trigonometry.sol`, developed and open sourced by Sikorka ([docs](https://github.com/Sikorkaio/sikorka#trigonometry), [code](https://github.com/Sikorkaio/sikorka/blob/master/contracts/trigonometry.sol)). This library appears to have been abandoned a few years ago, and lacks a `tangent` method, which is useful in some operations like the [bearing](https://github.com/Turfjs/turf/blob/41a123a0e151be6a7e312dfecb91b69c4ff3f3f2/packages/turf-bearing/index.ts#L53) between two points. `Spatial.sol` will require an audited `Trigonometry.sol` to be secure.

`Spatial.sol` is required for many Astral dapps and contracts, including the verifiable spatial data registries described below. We have not decided on the functions the library will include, and will look to [Turf.js]() for inspiration. We anticipate that we'll want to develop a corresponding client library `eth-spatial.js`, to abstract some of the complexities of supplying spatial data to contracts using Spatial.sol.

| | |
| --- | --- |
| Solidity engineers | 3 months (?) |
| Typescript engineer | 1-2 months |
| Audit | ? |
| Target deliverable | `Spatial.sol v0.0`, `Trigonometry.sol v0.0` |

## Verifiable spatial data registries

Leveraging Spatial.sol, we are early in the process of developing a standard contract to represent spatial data registries. There is a wide breadth of opportinities in this design space as well.

Specifically, we are building on work we've done to let self sovereign users register geographic zones on Ethereum. This capability is required for a number of use cases - a congestion zone system like Hyperaware, sustainability-linked bonds and other spatial DeFi applications, parametric insurance policies like those IBISA provides, location-based Web3 games including AR and [Pebble Go](https://twitter.com/go_pebble?lang=en) and so on.

We believe that a smart contract standard would make developer's lives easier, and contribute to composability of these zone registries. Our plan is to extend the ERC721 contracts, and represent geographic zones as NFTs, meaning they can interoperate with ERC721-compatible dapps, be owned and transferred, etc. We'll extend the contract, though, to include geospatial operations - for example, we plan to include a method that checks if a point supplied is contained within the boundaries of a specific zone: `zoneContains(zoneID, coordinates) returns (bool)`.

### Challenges

Land registry contracts exist, for both virtual and real-world land parcels - [Decentraland](https://decentraland.org/), [Etherland](https://etherland.world/marketplace/), [Superworld](https://www.superworldapp.com/), [Geo Web](https://www.geoweb.network/), [Cryptovoxels](https://www.cryptovoxels.com/) and others. However, these almost always restrict users to owning grid cells, due to the complexity of representing irregular polygons in a smart contract. A land registry where two users could own the same piece of land would not be realistic - detecting these topological intersections is difficult.

It is our belief that for spatial data registries to be useful in real world contexts, they must support irregular polygons. This means that we need to be able to detect zone intersections, which could result in a piece of land being double-insured, or a vehicle being in two congestion zones at once.

The spatial data registries standard we are designing aims to achieve the representation of this _physical scarcity_ applied to physical territory within a spatial reference system. These are "non-intersecting" boundaries, defined as Type 1 jurisdictions by [Hooghe and Marks (2003)](https://www.researchgate.net/publication/248233581_Unraveling_the_Central_State_but_How_Types_of_Multilevel_Governance).

We intend to achieve this by performing zone intersection checks using `Spatial.sol`. The library will have functions that allow us to check if zones intersect, and adapt contract control flow accordingly.

We have been experimenting ([geolocker](https://devpost.com/software/geolocker), [hyperaware jurisdiction registry](https://hyperaware.io/demo/jurisdiction-registration)) with smart contracts that would enable a spatial data registry of polygons representing zones on the Earth's surface (or areas / volumes within any spatial reference system ...).

We would like to design this protocol to make polygons composable building blocks to use across the smart contract landscape. Our understanding of the potential of this is quite nascent, but we anticipate these registries will have myriad uses in spatial finance, mobility, gaming and governance.

We're researching how to efficiently design a system that would enable this kind of a spatial data registry, along with requirements. We're trying to work out exactly what the needs might be and anticipate that this will emerge as a contract standard. We can imagine many variations of this type of contract deployed, each storing its own registry of polygons - for mobility apps, administrative jurisdictions, maritime governance zones, restricted airspace and so on. The spatial reference system is configurable - so it could define zones in relation to the sun, another planet, a vehicle, and so on. Such a standard would contribute to composability of these spatial dApps. We expect a Typescript client library will be useful to work with verifiable zone registry contracts.

| | |
| --- | --- |
| Protocol engineer | 3 months |
| Solidity engineer | 3 months |
| Typescript developer | 1 month |
| Audit | ? |
| Dependencies | |
| Target deliverable | EIP? White paper? ERCx standard contract. ERCx.js package. |

## Data

### Origin

All data has some origin, a point of capture or creation. Very often spatial data originates at a device that detects some variation in the physical environment contacting its empirical sensor, converts this analogue signal into some digital representation, and stores, processes or transmits that binary information.

We see this as the ultimate oracle problem - how can we trust that information is true? We understand that while advancements in positioning, navigation and timing like FOAM's dynamic [Proof of Location](https://foam.space/location) and IoTeX's [Pebble trackers](https://iotex.io/pebble), are developing apace, it is still not possible to completely trust an edge reading, especially a position. This represents a significant attack vector for the systems we are building, and we would like to conduct and support further research into trusted measurements from the edge of the network.

### GeoDIDs: Web3-native spatial data

Once these measurements are captured digitally, the information is formatted to be processed by some software. Spatial data comes in many different formats - GeoJSON, KML, shapefiles, GeoTIFFs, cryptospatial coordinates etc etc.

Astral endeavors to design an open and agnostic protocol that will gracefully develop and evolve with the state of computing. We also demand full trustlessness, self sovereignty and independent verifiability of all protocols we design. This requires a versatile, Web3-native spatial data identification, encoding and storage scheme.

To achieve this, with support from the Filecoin Foundation and London Blockchain Labs, we have drafted a [GeoDID Method Specification](https://docs.astral.global/geodids/geodid-core-specification) and [prototype modules and smart contracts](https://github.com/AstralProtocol/astralprotocol) to create, read, update and deactivate these geographic decentralized identifiers and the data assets they reference.

GeoDIDs will identify these files by wrapping the spatial data assets in DID documents, thereby providing a standard schema to grant the user verifiable control and enable trustless interoperability. Different spatial data formats will be supported through GeoDID Extensions - meaning GeoDIDs can support any current or future digital spatial data format. Required member variables will include relevant metadata to enable comprehensive indexing and use of the spatial data a GeoDID identifies.

We have designed the initial draft of the spec and would be curious for feedback from you or anyone interested when we release the spec to the community for review. Additionally, we invite anyone interested in using or contributing to the GeoDID project to reach out to us via Twitter @AstralProtocol or on our Discord [here](https://discord.gg/kBu3zSva).

GeoDIDs are agnostic to the spatial data assets being identified. However, we are designing the alpha implementation of the GeoDID modules to rely on IPFS by default, so we can cryptographically verify the integrity of the data assets referenced.

More on the Web3-native geospatial vision can be found [here](https://hackmd.io/@astral/rkQh4HbEO), and initial prototypes of IPLD-encoded GeoTIFFs [here](https://docs.astral.global/develop/ipld-and-geotiffs).

## Oracles

We have done little work on spatial oracles, instead focusing to date on the data storage and spatial contracts layers of the protocol stack. Our early thinking suggests that making a full suite of spatial analytics algorithms (raster and vector) available at the oracle layer would be useful for on-demand processing of geospatial data.

For example, one concept protocol we have designed is a parametric insurance system. With this, we trustlessly insure physical assets in space - initially conceived of as static areas or volumes like land parcels or administrative jurisdictions (maritime, terrestrial, airspace etc). Upon purchasing a policy, agents would register their land parcel in an Astral verifiable spatial data registry, possibly represented using a GeoDID identifying a polygon or polyhedron. Additional information like the policy duration, indemnity process and, crucially, insured parameter and data source, would be specified upon policy creation. See this [relatively simple example](https://www.nature.org/en-us/what-we-do/our-insights/perspectives/insuring-nature-to-ensure-a-resilient-future/) deployed by traditional insurers.

Asset monitoring could be configured in a few ways. In the example above, periodic checks to the parameterized data feed could be made, and a payout could be triggered automatically if the parameter threshold is exceeded. Alternatively, the insurance contract could be reactive, requiring a policy holder to submit a claim transaction. In this event, the contract would trigger the oracle to fetch both the land parcel information and the relevant parameterized external information. To enable a scalable, fully decentralized system, we suspect the most efficient architecture will require an oracle or some Layer 2 consensus network to apply a spatial analysis algorithm to these inputs to determine if the claim is valid. (This differs to many existing DeFi insurance protocols - these often rely on some entity - a trusted individual or DAO committee - to assess the evidence off chain and submit an attestation to settle a claim or trigger automatic indemnity - see [IBISA](https://ibisa.network/) and certain review strategies employed by Protekt's [Claims Manager](https://docs.protektprotocol.com/#/?id=protekt-contracts).

This functionality was also required to detect the amount of time devices spent in policy zones in Hyperaware, and to supply NOx levels to the [sustainability-linked bond dApp](https://github.com/AstralProtocol/sprout) we prototyped during the KERNEL Genesis Block.

What is unique about this compared to other oracle systems is that our focus is narrowly on spatial data, that is, information that contains some spatial, or location, dimension. We could argue that _all_ data is spatial data, but here specifically we are looking at data representing physical space - geospatial data, and data positioned within other spatial reference systems.

Needless to say, much research into these oracle capabilities - including privacy-preserving techniques - for bringing spatial insights on chain in an efficient way is warranted, as it seems this is an unavoidable layer of the Astral stack.

| | |
| --- | --- |
| Product researcher | 3 months |
| Technical researcher | 3 months |
| Target deliverable | Research note on spatial data oracles |

## Universal Location Proofs

Technically it is extremely difficult (if not impossible) to create a definitive proof that some information was created at a specific physical location.

There are technical ways to improve trust in the position - signing position captured by the sensor triangulating with the GPS or FOAM network in a secure enclave, for example. It would require a special app or - eventually - a plugin for mobile crypto wallets that allows users to generate the “universal location check-ins” (credit @jabyl from Distributed Town for his help thinking this through).

Additional layers of trust could be built on a location by incorporating other sensor readings (like from a camera or microphone), as could requiring users to scan a cycling QR code only available at the location, form social check-ins in which they verify that the others were present, etc.

We’ve been doing some early thinking about zero-knowledge location proofs as well, which prove that a point is inside a polygon without revealing the user’s position. This could then be verified on chain, enabling location-based smart contracts that preserve the user's privacy. Applications include local currencies, intelligent mobility systems, dynamic game preserves, detecting illegal and unregulated fishing in Maritime Protected Areas, location-anchored games and a lot more.

We have not looked into what work on this has been done in any meaningful sense - Tux at NuCypher was interested but we're not sure if they’ve looked at it any further. We don’t have any cryptographers working with us so right now.

Phase 1:
| | |
| --- | --- |
| Cryptographer | 3 months |
| Researcher | 3 months |
| Target deliverable | Academic paper. Blog posts. Feasibility study. |

---

That's the state of our thinking right now - building tools to make it easy for developers to build location-based dApps. If any of this interests you please reach out.