In order to realize our vision of an ecosystem of location-based and spatial decentralized applications providing a more just and resilient means for human and machine coordination on Earth, we are designing the Astral Protocol **** and building a corresponding stack of software tools. Our aim is to create a simple and delightful experience for the location-based dapp developer, enabling the community to drive innovation and build this ecosystem.

The Astral Protocol provides the bindings between the spatial data domain and the Web3 universe. We intend to make no assumptions about the needs or use cases of developers building on Astral; instead, our effort is directed at creating a simple, versatile way of connecting both raster data and vector geometries, and relevant metadata, to smart contract and dApp front end interfaces. We believe that these spatial data primitives, along with the means to integrate them into smart contracts, will provide the soil from which the Web3 spatial ecosystem will sprout.

At a high level, there are three layers to the Astral stack, stitched together to enable this new spatial dApp ecosystem:

• Data

  • Capture - from a range of edge devices like satellites, IoT devices and mobile phones.

  • Storage - ideally on distributed and verifiable systems like IPFS / Filecoin. Geographic decentralized identifiers wrap spatial data assets in DIDs so they can be controlled by the user in a standardized way

• Oracle - to reliably bring the spatial data into smart contracts

  • Analysis may occur in the oracle, or upstream - but often spatial data needs to be processed before it can be used in expensive smart contracts.

• Spatial contracts - smart contracts developed to use location and spatial data in contract logic.

Astral is working on connecting these components using open, versatile tools. We are actively working on each of the layers of the stack, so if you're interested in contributing, get in touch - we're on Twitter or available via email at contact@astral.global.

What is a DID?

Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identities. A DID identifies any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) that the controller of the DID decides that it identifies. DIDs are URIs that associate a DID subject with a DID document allowing trustable interactions associated with that subject.

Each DID document can express cryptographic material, verification methods, or , which provide a set of mechanisms enabling a to prove control of the .

To learn more about DIDs and why they're useful:

Constructor

Creates a new AstralClient Instance to utilize the following functions.

new AstralClient(_ethAddress, _endpoint?);

Methods

CreateGenesisGeoDID

Creates a GenesisGeoDID Document. This creates a new root node for the linked data structure.

async createGenesisGeoDID(_typeOfGeoDID: string): Promise<IDocumentInfo>{}

CreateChildGeoDID

Creates a Child GeoDIDDocument. This creates a child node for an existing linked data structure.

async createChildGeoDID(_typeOfGeoDID: string, _parentID: string, _path: string): Promise<IDocumentInfo>{}

PinDocument

Pins the Document to IPFS or FFS via Powergate.

async pinDocument(_documentInfo: IDocumentInfo, _token?: string): Promise<IPinInfo>{}

LoadDocument

Loads the Document by the DocID and the Powergate Auth token associated with it.

async loadDocument(_docId: string, _token: string): Promise<ILoadInfo>{}

Welcome to Astral!

Our vision is to build a protocol and community dedicated to creating an ecosystem of location-based Web3 applications and spatial contracts. We believe that the Web3 vision is incomplete without location services, and are working to develop technologies that will make it easy for devs to build user-controlled dApps leveraging location data.

We're taking a modular approach, architecting our tools so each component useful on its own, but all designed to work together.

For an up-to-date summary of what we are working on now, read our litepaper:

Astral

For the past few years we’ve been investigating what we see as a new galaxy in the Web3 universe, at the intersection of spatial data and consensus technologies. We’ve explored the boundaries of the design space researching, prototyping and building community. This is culminating in our work to build what we now see as the key primitives to underpin a new category of Web3 applications using spatial and location data. Our work at Astral is focused on promoting the evolution of an open, human-centered and composable location-based decentralized web.

The opportunity space is pretty vast. We believe that the vision for the user-controlled internet is incomplete without peer-to-peer alternatives to services like Uber, Google Maps, Airbnb, Tinder, Craigslist, Amazon and others. Even more exciting is the opportunity to replicate the functionality required for systems of local taxation, voting, and physical security. Perhaps the most exciting of all is the notion that our systems of value exchange can be configured to promote the preservation of life and ecological health — the nascent “regenerative finance”, or ReFi, movement, leveraging natural capital currencies and other tokenized natural assets. We’ve been finding that all of this is possible if we can reliably tie information about physical reality — where someone or something is, or measures of environmental conditions — to smart contracts, especially contracts capable of computational geometry.

Rather than working at the application layer, at Astral we are designing open source tools, public goods intended to underpin this category to A: make building location-based dapps easier, B: create spatial data storage systems fit for web3 (i.e. verifiable, uncensorable, permissionless, etc). We believe that if the ecosystem can converge on using these tools and design patterns, the location-based decentralized web will exhibit similar emergent composability that we’re witnessing in DeFi.

So what does this specifically mean?

• We’re developing verifiable spatial data registries, smart-contract based registries of vector or raster spatial data assets. Initially this was to store polygons representing geographic jurisdictions on chain, though we see use cases for points, lines, polyhedra and raster datasets as well.

• We’ve also been designing a verifiable location claim, or a “universal location check-in”, a verifiable claim that serves as an attestation that someone / something was at a particular place at a particular time. This VC can be held privately by its creator, and submitted to any compatible location-based dapp or service. We are uncovering dimensions of trust, security and privacy, and that different applications will demand different procedures for creating these VCs.

What Astral enables

As we see it, these primitives enable two key pieces of functionality:

Responding to ecological state changes

One is tying smart contract behavior to ecological state changes.

This is powerful technology, which makes it very dangerous. We are approaching the design and development of natural capital currencies with great humility. Initial thinking suggests that if we can look at a natural ecosystem from three perspectives. First, and most importantly by a large margin, from the people who live in, near and with the ecosystem, especially indigenous people. Supporting the human assessments of ecosystem state / health, we believe that data collected from proximate connected sensors deployed in the environment, along with remote sensing data captured from drones or satellites, can be analyzed to reach a reasonably accurate understanding of ecological conditions.

This is exciting because it means on-chain systems (DeFi, digital governance etc) can adapt to changes in ecosystem health, for example by rebasing a currency or tapping a community treasury to deploy capital when conditions approach threshold parameters. We are especially excited at the idea of detecting leading indicators of ecosystem degradation so we can support more targeted and less extreme interventions to preserve health.

Local contracts

The second: local contracts, smart contracts that can use location as a condition in its control flow, i.e. require(pointInZone(coordinates, zoneGeometry)), with the coordinates from a verifiable location claim and the zoneGeometry polygon stored in the verifiable spatial data registries. This binds smart contract behavior to spatial extents.

We believe with this functionality we can recreate tools of territorial governance that are the standard in the legacy system. We are working on , a suite of geometric and topological functions in Solidity. We’ve also designed and prototyped a spatial governance protocol for connected devices, which could serve as a global (or, really, universal, within any spatial reference system) territorial governance system for self-sovereign jurisdiction administrators. Applications include e-mobility and intelligent transport, supply chain and logistics, autonomous vehicle governance and so on.

Serving the universe and the metaverse

Astral is intended to underpin any dapps using spatial or location data. This includes the metaverse. In fact, we feel quite strongly that doing early experimentation and prototyping in the metaverse is the best way to understand and develop the technology.

This summary has focused on the technology, but we are placing a greater emphasis on people: on building the community of people who will be building with the public goods Astral is creating.

Where we are heading

We've received funding as members of the , and we’re engaging with thought leaders and prospective users to triangulate as versatile a design for these primitives as possible.

So — what do you think? What are we missing? Do you know of anyone working on related things? What should we be thinking about? Who might be interested — can you connect us?

Reach out on or join our !

A Spatial Data Registry is a way of organizing and storing spatial data to run geospatial queries. This registry could be used across a variety of Web3 use cases: spatial governance systems, sustainability-linked bonds, parametric insurance policies, and location-based Web3 games. For MRV (measurement, reporting, and verification) applications, it's an essential tool for querying and identifying all data relevant to an asset, making it difficult, for example, to overstate carbon offsetting by concealing greenhouse gas emissions.

For a truly decentralized geospatial search, we have created the where the geospatial index is stored on-chain.

We've also created a more performant version called the that makes use of MongoDB's spatial capabilities and validates the data by anchoring of hashes on-chain.

A client MRV Provider authenticates and receives a token containing the 'provider' role. With this token applied to an HTTP client header 'x-access-token', they will send (post) data in the form described by this flexible schema example:

Location can be an array of points or polygons. See the measurements interface definition below for currently supported data types and units of measure.

Relevant code:

The fully decentralized spatial data registry stores all data on-chain. Due to technology limitations, we built a lightweight solution to organize and query the geospatial data using the geohash geocode system to build a data structure called a GeoTree.

Geohash

Geohashing is a method that encodes coordinates as a string of characters. In the geohash system, the Earth's surface is divided into 32 rectangles, each one corresponding to a specific character. The characters include all numbers and letters except a, i, l and o. Each top level rectangle is subsequently divided into 32 rectangles, representing a second level of detail. This pattern can be continued for an infinite number of nested rectangles, so that every level corresponds with its identifier character — but the convention defines a maximum level of 12. The more characters we specify, the smaller the rectangle will be. For example, the geohash de2f7 with five characters is five nested rectangles deep.

The short alphanumeric format of a geohash lends itself well to a Solidity implementation that doesn't support floating point numbers. Additionally, it's convenient to remove characters from the end of a hash to query locations that are less and less precise.

Point Locations

Our current implementation of the spatial data registry only indexes a single latitude/longitude point. For polygons, we calculate the centroid off-chain and use that value to register a location.

The registry stores data at level 8, which corresponds to a square of 20x20 meters. Any point inside that square will be resolved to the same geohash.

GeoTree

A GeoTree is a type of data structure that permits indexing of data that exist at different levels. Below is an example of GeoTree indexing two-dimensional data using geohashes. The top nodes of the tree correspond to geohash level 1 — we call them parent nodes. Child nodes are the bottom nodes of this diagram, and they represent level 2. In the GeoTree, nodes only contain one character, as the child nodes automatically inherit their parent’s value. By traversing from the root node to the end node, we can access each geohash character and build the complete geohash.

The tree allows us to query data assets at any resolution by picking any node and traversing through all of its children to find all enclosed assets. For example, the level 5 geohash gbsuv represents a rectangle of approximately 5x5 km. To find all assets inside this area, we would select all child nodes with geohashes beginning with gbsuv. Let’s assume the end nodes of our system are the following:

• gbsuv7dq

• gbsuv7zw

• gbsuv7zy

The GeoTree data structure would look like this:

Note that we’ve created all the intermediate nodes of the tree, including d and z, even though they didn’t contain data. This way, we can query any subtree at any level and get all of its children.

Optimization

The above data structure allows us to query the GeoTree on a time complexity O(n). We made the decision to improve the structure by caching all the enclosed assets at each intermediate node. This means that for every insertion, the asset will be stored on the end node and every parent of that node. The following illustration shows this:

Even though this variant may have some drawbacks, we choose it because it pays off in terms of query efficiency. Time complexity would be as follows:

• Insertion: Process would be executed on every level (k). In a system with a depth of 8, k would be 8, so time complexity is O(1).

• Query: Given that every node contains all its children assets, the querying process would only need one step, making time complexity O(1).

Regarding the storage, this modification will increase its size from n to (k+1)*n. However, the depth of the tree (k) would usually be a low number, making the memory requirement O(n) — the same as the non-cached version.

Solidity Implementation

Nested data structures such as trees are hard to implement in Solidity due to its limited functionality. However, the cached implementation of the GeoTree was achieved with a simple hash map. The key is the full geohash mapped to an array of asset values. Our previous example would be represented as follows:

Ecological Index is an on-chain variable that represents the value of the ecological asset stored in the GeoNFT. Depending on the application's requirements and data collected, it could be a measurement of area, soil health, biodiversity, carbon sequestration, or other calculation.

Area Calculation

Area is a simple way of calculating ecological value using the topological data represented by the GeoJSON. For instance, if a steward of an asset has agreed to follow regenerative practices, the size of that natural space plays a key role in its value. When using fractionalization, token supply would be controlled by this value, so it's important to accurately calculate area using on-chain functionality.

Below is a description of how we calculated the ellipsoidal area of Polygon and MultiPolygon geometries on-chain.

Implementation

The area calculation of a surface can be approached in different ways. A very simple and straightforward one is to display the coordinates on a flat plane. Doing so, the area calculation is similar to any irregular geometric figure. It’s very common to use the planar representation of maps (called “projected” coordinate systems) because they are easier to view and work with. One example is Google Maps, which uses the (or Web Mercator) projection. It was initially conceived as a variant of the Mercator projection (the one used on typical physical maps), and has become the standard for mapping applications.

In our implementation, however, we calculate the ellipsoidal area based on the spherical representation of the Earth instead of on a flat plane. Calculating the area over a sphere is more difficult, but the result is more accurate.

Challenges

Calculating the area on-chain using Solidity has some challenges that are not present in most standard programming languages. There are two aspects that make it difficult:

1. decimal handling and irrational constants (such as pi)

2. trigonometric functions (sine function is needed in the area calculation algorithm).

Decimal Handling

Handling decimals is a well-known topic in the Solidity community: you need to multiply the value by some factor, do the calculations and, finally, divide by that same factor. In the end, the result should be valid (with some error deviation). This is used, for example, on the input coordinates. The range of valid numbers are [-90, 90] for latitude and [-180, 180] for longitude. Operating without decimals in this context is useless because of the lack of precision, so we are applying a factor of to operate with integer values. This is also applied to constant values such as the earth radius, pi, etc.

Trigonometric Functions

Using trigonometric functions in Solidity is not straightforward. Typically, trigonometric functions (sine, cosine, tangent) work with radians, and the result lives bounded in a very specific domain. For example, the range of sine and cosine values is [-1, 1]. Given that, it is impossible to operate without decimals, and there is no built-in sine function in Solidity.

The solution to this was found by Lefteris Karapetsas for his app which was based on the C library named that, in turn, was an implementation of Scott Dattalo's . In all cases, the problem was the same: calculate the sine of an angle using only integer values. In summary, the solution is to pre-calculate all the values and store them in a hash table. This may be done in a programming language that supports standard sine calculation (e.g. Python) and export the hash table in a format compatible with Solidity. That format is a .

But, how is that table built? Excluding decimal values, a circle can be split in 360 parts, each one representing an angle of 1 degree. We could calculate the real sine value for each degree and store it on the hash table. But this doesn’t give us a lot of precision, especially in a geospatial coordinate system context (68.1º and 68.9º will relate to the same value).

A way of improving this is to split the circle into more units, thus increasing precision. Splitting the circle into 16,384 units allows storing the angle parameters as unsigned 16-bit data types (as used in the trigint library). In our case, we needed even more precision in order to accurately calculate the area. We used a 256-bit data type to store the values of up to 1,073,741,824 angle units in a circle. With this method we were able to achieve an error deviation of < 0.1% on very small areas.

Future Plans

Ecological state calculations will be expanded to include other indexes based on data collected for an ecological asset. These values could be determined by machine learning models or other algorithms.

As such, we have separated the area calculation into a separate library from the GeoNFT contract, thus making it easy to replace when adding other ecological calculations.

Overall design diagram shows all moving parts; data flow is from left to right. Detail pages for each process follow.

Functionality is managed and secured with authentication and authorization via HTTP interceptors. Account creation and management runs under the 'super' role:

Relevant code:

A GeoNFT represents geospatial assets by extending the non-fungible token (ERC-721) contract with location information.

Geospatial data is defined as a string defining a FeatureCollection of one or more Features (Polygon or Point):

Additionally, GeoNFTs contain an Ecological Index as a measure of ecological state:

Introduction

The purpose of this MVP was to demonstrate a workflow from an MRV data provider, supplying raw measurement data based on both stationary and mobile sources, to a backend with the following features:

• an ingestion process including:

The validation process, running under the 'validator' role, retrieves a requested number of unvalidated anchors, and for each one, retrieves the associated data points, recalculates the summary hash.

The current counts and hash results are then compared to both the Celo contract and database counts and hash results established by the anchor process and any discrepancies are reported.

Relevant code:

A spatial data asset is any data asset that contains spatial or location information. This term is intentionally broad, and GeoDIDs are deliberately flexible enough to identify current and legacy spatial data types, as well as ones that haven't been developed yet.

Generally, spatial data assets to fall into two categories: raster and vector.

This MVP demonstrates the power of geospatial queries and the analytics potential of raw timeseries data which is anchored and validated on-chain.

Possible next steps include a full analytics layer with composable endpoints and integration with active inference workflows.

Thank you to for funding this MVP.

The anchor process, running under the 'super' role, retrieves a requested number of unanchored raw data points which have been hashed at ingestion. It then creates a "summary hash" by hashing the individual data point hashes.

The created anchor instance id and summary hash are then stored in both the database and on the Celo contract, with the Celo transaction hash also applied back to the anchor instance on the database. The anchor instance id is then applied to each of the raw data points that comprise the transaction.

Relevant code:

15 Jun 2022

• Finalized Spatial Data Registry Data Structure (Kolektivo)

• MongoDB v6 evaluation of timeseries, indexing, and analytics (MRV Collective)

8 Jun 2022

• Mocked up GeoNFT and Spatial Data Registry Contracts with hardhat testing (Kolektivo)

• Currently building out provider/role/user security infrastructure (MRV Collective)

1 Jun 2022

• Ingestion layer first look (MRV Collective)

• Added backend service for circuit and contract generation (zkMaps)

23 May 2022

• Began development of MVP for decentralized MRV registry (MRV Collective)

20 May 2022

• Completed Astral (dClimate)

18 May 2022

• Met about use cases for GeoNFT minting, approval, metadata, and ecological data (Kolektivo)

• Met about ArcGIS and weather station data (Kolektivo)

27 Apr 2022

• Supported the Oika project at the Planet Positive NFT Hackathon

• Met with Regen Network on Data Module v4

• Met with dMeter

20 Apr 2022

• Presented Astral GeoNFT specs (Kolektivo)

13 Apr 2022

• Completed data registry requirements document (Kolektivo)

6 Apr 2022

• Reviewed ArcGIS food forest survey app (Kolektivo)

• Completed Ocean Protocol v4 test dataset and paper (Kolektivo)

• Completed lo-fi map of Curacao and food forests (Kolektivo)

23 Mar 2022

• First meeting of the "Survelliance Squad" now known as "dMeter"

• 3rd and final meeting of KERNEL Regen Guild, discussed locus of control

16 Mar 2022

• Reviewed use cases related to badges, weather stations, and monetization with Ocean Protocol (Kolektivo)

• Second KERNEL Regen Guild meeting, discussed Donella Meadows leverage points and ran an ecosystem mapping exercise with Ale Borda

9 Feb 2022

• Hardhat/React dApp for GeoNFT (Kolektivo)

2 Feb 2022

• Draft GeoNFT Contract (Kolektivo)

12 Jan 2022

• PoC decentralized data storage using Ceramic on Alfajores (Kolektivo)

5 Jan 2022

• Defined initial bounds for computation and tree data storage limits (Kolektivo)

27 April 2021

• Call with Ryan John King, CEO of FOAM space, a pioneer in the geospatial decentralized web. FOAM recently launched their , and is working on trustless "".

• Reviewed the draft whitepaper for the Kolektivo Framework, a crypto-institutional framework that seeks to promote socio-ecological sustainability through cryptoeconomic mechanisms. Watch this space ...

• Exploring ways to keep pushing forward with the Web3-native geospatial vision, which we first explored with a Filecoin development grant. More soon ...

13 April 2021

• Met with jabyl from , where they're building a DAO for DAOs and a universal "skills wallet" enabling you to port your reputation with you in the mutual credit network .

• Spencer and the team joined the Astral Discord - really exciting work designing an app to help people hold themselves accountable. Set goals and stake money - by exercising claim your crypto back.

• On Discord we're discussing verifiable impact claims - a common problem that many teams are solving. One take: Impact NFTs.

6 April 2021

• Submitted the GeoDID Explorer client application to Filecoin, completing our Development Grant. You can explore the Astral Studio - live on Ropsten - . Working on docs.

• Lots of community building this week:

  • Max from Earthify is building a data DAO that is crowdsourcing, standardizing, and publishing public / government records, with a focus on real estate data. We are advising Max and got to listen in to his design sprint with @RaidGuild.

31 March 2021

• Completed initial implementation of IPLD-encoded GeoTIFFs in Typescript for our Filecoin Development Grant - .

• Finishing the GeoDID Explorer client interface.

• Spoke on Web3 Spatial at the Open Geospatial Consortium Blockchain Domain Working Group - recording forthcoming.

23 March 2021

• Work week.

16 March 2021

• Coming into the final weeks of our Filecoin development grant - developing IPLD-encoded GeoTIFFs, which will complement the GeoDID spec we designed. The idea is to use DIDs to create permanent, resolvable identities for satellite images. More soon.

• We started outlining - a brief summary below.

  We want to build DIDs that support spatial querying and raster clipping, so a DID can represent a subset of a larger spatial dataset.

11 March 2021

• Still building for our Filecoin Development Grant - working on IPLD-encoded GeoTIFFs and a front end GeoDID browser for Web3-native satellite imagery ...

• Working with a new community member building to collect land parcel data - watch this space

• Initial security reviews of Spatial.sol - much more to come.

4 March 2021

• Initial tests for Spatial.sol. Point in Polygon is *mostly* working.

• Submitted initial implementation of the @astralprotocol Typescript modules for the Filecoin Development Grant. GeoDID client libraries and solidity contracts are functional.

• Release of the vision and roadmap for community review.

23 February 2021

• Our Discord is gathering steam. We've seen new members this week from startup projects, the GIS world, economics graduate schools and more. Join if you want to learn more:

• Discord member Econometrie raised some great points about how systems built on Astral could solve an interesting problem: how do we know where we can park rental e-bikes and e-scooters? We are working out how to adapt Hyperaware to help solve this.

• A new member - Kiran - joined and shared a draft post he's writing about applying principles of token engineering to manage road network usage.

16 February 2021

• Commits on modules for working with GeoDIDs, plus a check-in call with @filecoin on development grant progress.

• Call with @blairvee and Jonny, talking about GIS, Grassroots Economics and truly local currencies.

• Core community call. We talked through the road up to this point, and where it should lead.

9 February 2021

• Broke ground on a research report on the intersection of spatial data and Web3.

• Progress on the GeoDID Browser interface development and Astral modules for working with GeoDIDs - part of our work on a Filecoin Development Grant.

• Spoke with an American entrepreneur working to onboard land parcel data onto Ethereum.

2 February 2021

• Submitted the for feedback - if you're interested, read it here, and give feedback by creating an issue on the .

• Fixed a bug in our prototype implementation of the Hyperaware Protocol - a spatial governance protocol for connected devices.

• KERNEL Fairlaunch seminar with Brian Flynn from Rabbit Hole - got us thinking about the value of community.

26 January 2021

• Completed the draft GeoDID Method Specification - now we're architecting software modules for working with GeoDIDs

• Spoke with @KERNEL0x Fellow @mattgcondon - the grandfather of NFTs - about trusted location proofs and using location in smart contracts.

• Kicking ideas around with @naz about NFT markets and the NFT community.

19 January 2021

• Refinements of the draft GeoDID Method Specification.

• Chat with a VC about the past, present and future of the spatial Web3.

• Chatting about trusted location proofs with a security-minded developer in KERNEL.

12 January 2021

• Joined KERNEL 2 - Fairlaunch track!

• Published our with Astral documentation.

• Drafting GeoDID Method Specification, working on scaling problems with IPLD-encoded GeoTIFFs for the Filecoin Development Grant.

5 January 2021

• Astral received a to develop a few key pieces of the Astral Protocol: a GeoDID Method Specification (more soon!) and IPLD-encoded GeoTIFFs, for Web3-native geospatial imagery. .

• The Astral team won the Ceramic Bounty for the SkyDB hackathon for building a version of Geolocker, a verifiable spatial data registry.

• Launched our new website, . (Thanks for the awesome template, !)

With geodata-anchor (Junø/CosmWasm contract) and geodata-rest (HTTP REST Server) we address the feasibility of providing performant and scalable access to geospatial data in geojson format, leveraging MongoDB’s geospatial data and queries. When a data item is ingested into the database, a hash of the relevant data is generated and stored on a CosmWasm contract which implements a cw-storage-plus indexed datastore. Validation results are stored on both the database and the contract. Validators would each run a MongoDB Atlas replica instance, with an independent compute instance performing the same hashing algorithm.

Current PoC implementation:

• Fully written in , using and .

• Role-based access to rest endpoints: admin role creates data items, validator role validates, and user role can query.

• Polymorphic (polygon, point, line, etc.) geospatial data within a single index.

• Validation compute currently occurs via a REST endpoint based on userid/role and is not yet tied to a validator’s specific replica instance.

• Integration tests for both geodata-anchor and geodata-rest run against a local instance of via Docker; we have not yet deployed to a testnet.

Possibilities:

• Evolve hashing strategies via .

• Larger datasets could leverage MongoDB features.

• Reverse anchor hash from contract to database.

Tokenomics:

• Mostly beyond the scope of this PoC, but with and the on Cosmos, many possibilities exist for .

Thank you to for funding this PoC and providing valuable technical direction.

Location is one of the fundamental properties of any physical object. Where something is, and where it is in relation to other objects, is an intrinsic attribute of its identity and determines many of its capabilities and responsibilities. What’s more - information about physical objects is carried on signals in the form of light, sounds, electrical currents, and so on. If some entity - organic or synthetic - receives these messages, they can perceive this information and learn about its origin.

Based on these phenomena, humanity has created an incredible network of connected sensors for communication and observation. Air and water quality monitors, thermometers, seismographic instruments, microphones, remote sensors - on, within or orbiting the planet - measure electromagnetic radiation, and others - these all capture empirical observations of the Earth every instant, forming a global surveillance system witnessing our shared, physical reality. This is happening constantly, in real time, and in a format that can be analyzed and interpreted by machines.

As these monitoring networks are developing, so is a parallel phenomenon. Consensus networks are creating a durable shared reality in the informational domain, controlled by no one and governed by a strict, transparent set of rules. Over a decade since Satoshi’s seed first sprouted, the Web3 universe is beginning to blossom. We believe that the fruit that will ripen will complement - and eventually, in some ways outcompete - our legacy systems and come to underpin the functioning of our global society.\

A vital part of the Astral protocol is the integration of an Oracle system that can trustlessly fetch spatial data from multiple sources into smart contracts.

Spatial data from a range of sources - satellites, IoT devices, vehicles, mobile phones, and more - can be very useful, but is prone to failure and subject to cheating. Due to the potential spatial economies that can be built with our protocol, it is paramount to have trust in the spatial data submitted to the blockchain. We're researching ways to ensure this trust at the Data and Oracle layers of the Astral stack.

Taking the example of the GPS data, it is widely known how spoofable the system is. The usage of a protocol such as FOAM in combination with GPS data can provide a more reliable and trustless measure of the position of an object or a person in the real world. Combined with other methods of validating one's position, such as biometrics, it is possible to reduce to a great extent the possibility to cheat the system.

In addition to the different data sources, the usage of multiple Oracle networks, such as Chainlink or API3, as the gateway to the Astral Protocol will further reduce the possibility of mutability of the data and the potential of failure of any of the aforementioned networks.

With trustworthy spatial data assets stored on distributed, fault-tolerant systems controlled by the user, we are positioned to pull that information into smart contracts and use them in contract logic. We are intending to apply principles of composability to these contracts, enabling an ecosystem of interoperable Web3 location services much as the "money legos" are accelerating the pace of innovation in DeFi.

Working with spatial data in smart contracts has its social, technical and economic challenges. We are actively researching and experimenting to understand how these spatial contracts could be used to replace brittle and inefficient Web 2.0 systems, and what innovative new capabilities they might create.

Spatial data contains information relevant to locations in the physical world. Different locations have different rules - depending on where you are you have to abide to a different regulatory framework.

To create decentralized applications that leverage spatial data and location information, we need to be able to store and access spatial data in ways that ensure it is simple and reliable for Web3 developers to work with.

All in all, geospatial data matters, but there are issues with the way it is being used:

• Lack of transparency between spatial data providers and end users. How do we know if spatial data can be trusted?

• No Web3 app has truly been able to connect smart contracts to the “real world”

• Supported by spatial data, new capabilities are possible in diverse fields like finance, mobility and identity - as long as there is a proven way to ensure the validity of geospatial data.

In sum, we need a better way to access and archive satellite and sensor data - fit for a resilient, user-controlled web.

We believe that bringing advanced spatial data technologies into the Web3 fold will enable an ecosystem of spatial dApps to support our transition to a just, sustainable and resilient world.

The sample queries take a polygon, date range, and provider id and return the average temperature, and the raw data points, respectively. The query endpoints are public so no access token is required to run:

The data query is more appropriate for the Ocean marketplace than the previous average temperature query, which is more an example of a composable intermediate endpoint for an inference toolchain.

Data from the second query was listed on the Ocean Görli test network:

• Sample query test listing

• on Opensea Görli Testnet

Note that you need Görli ETH and Görli OCEAN tokens to purchase.

Relevant code:

Astral is developing the standards and tools developers need to create location-based dApps and spatial contracts. We're thinking big - we aim to enable an ecosystem of applications by creating flexible and developer-friendly technologies that are native to Web3.

The past 15 years have seen the smartphone revolution - in 2021, it's hard to imagine life without location-based applications. Maps, dating, social networking, mobility, peer-to-peer goods markets - the usefulness of so many of the apps we use every day relies on some location element.

Concurrently, the past decades have seen a revolution in Earth observation technologies - a greater number of more sophisticated remote sensing satellites are orbiting our planet every year. These sensors - combined with advancements in techniques for analyzing spatial data - are enabling us to glean new insights about our world at a profound level of detail. Insights like wildlife movements and illegal fishing, greenhouse gas emissions, deforestation, consumer behavior and so on are becoming an increasingly important factor in the decision-making of businesses and governments.

Astral

Astral is creating tools and standards to work with geospatial and location data in the Web3 universe. To be truly Web3 native, we need to create technologies that are trustless, independently verifiable, next to impossible to take down and that empower the user. To do this, we are delving into the bleeding edges of some of the most exciting technologies on the web - blockchains, smart contracts, decentralized identifiers, verifiable claims, cryptography, token engineering and more.

Enabling an ecosystem

The applications enabled by the spatial data layer of the decentralized web are wide-ranging and revolutionary - and we have barely touched the surface. We are learning by building - some examples:

• We prototyped - a library of geometric and topological functions in Solidity.

• We prototyped , a verifiable spatial data registry on 3Box and Ethereum, with a team at ETHLondon 2020.

• We designed the Hyperaware Protocol - a spatial governance protocol for connected devices - and built - a congestion zone system running on IoT + smart contracts.

All of these projects point towards our goal, which is to develop the capability to work with spatial data on the decentralized web. We've realized that we need to develop the specifications and tools needed to work with this type of data in the web3 space, without having to opt for a web2 alternative.

Once we develop this, we open a brand new world of possibilities within the web3 space, that will allow: developers to leverage geospatial data within their applications; data providers to store and distribute their data efficiently and effectively; data scientists to manipulate, analyze, and share their findings in a more user friendly way.

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, Regen Network, Grassroots Economics, IoTeX, 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:

• , a Solidity library of topological and geometric functions

Spatial data comes in many different formats, from myriad sources, containing different information. As Astral wants to make as few assumptions as possible about the use cases that the protocol will be used for, we are leaving room for devs to work with any spatial data formats - including ones that haven't been developed yet.

To achieve this, and to make sure that spatial data used in Astral is reliable and controlled by the user, we are designing a DID Method specifically for identifying spatial data assets.

The GeoDID Method Specification will act as the default Web3 specification for working with geo-spatial data sets. Each DID Document will reference one or many spatial data assets endpoints and its respective metadata. The core spec is very lightweight - support for different formats are built in as Extensions.

GeoDIDs are designed to work with any spatial data assets, leaving the user to decide if they trust the data identified. We are designing best practices and advanced extensions that will help data consumers trust that satellite imagery is not tampered with, that locations are trustworthy and so on.

GeoDIDs

, or GeoDIDs, are DIDs designed to identify spatial data assets and to be compatible with any distributed ledger or network. In creating a GeoDID, data controllers permissionlessly create irrevocable, cryptographically-verifiable identities for spatial data assets that can be useful in decentralized applications - a Web3-native way to identify spatial data.

The work on geographic decentralized identifiers is being progressed by the team at , supported by a development grant from the . The team recently released an alpha version of a GeoDID Method Specification, which defines an approach in creating, reading, updating and deleting identifiers for these assets using DIDs. However, through this work the team has learned that it may not be appropriate to use its own DID Method Specification for identifying these data assets, but to instead publish a metaspecification: a standard data format that any DID could incorporate. This would mean that any decentralized identifier could identify a spatial data asset, unlocking a large amount of flexibility in how GeoDID technology could be developed.

A GeoDID effectively wraps a reference to an existing spatial data asset in a DID Document. The endpoint or content identifier (CID) where the spatial data asset can be retrieved from is included in the DID Document's service array. The core specification is intentionally very lightweight, designed to support legacy and future spatial data formats. These data formats will be supported by a list of GeoDID Extensions, which standardize how GeoDIDs identifying assets of that format are structured - meaning code can be written to work with those standard formats by uncoordinated developers or, more likely, software packages can be written to work with data compliant with the standard. GeoDIDs can be public or peerwise.

A Rationale for GeoDIDs

The GeoDID is intended to imbue identifiers for spatial data assets with the standards that Web3 applications demand. "Don't trust - verify". To enable location-based decentralized applications and smart contracts that are trustless and immutable for self-sovereign users, the data used in the system must be reliably there.

This might sound like an overengineered solution. Why store a reference to a spatial dataset on a blockchain? Why store the spatial dataset itself on a decentralized, permanent substrate like Arweave? Aren't HTTPS URLs and Amazon S3 buckets much easier?

We anticipate that in the coming century, spatial / sensor data technologies will come to underpin significant portions of the world economy. The emerging field of - "the application of geospatial data technologies to financial theory and financial practice" (Caldecott) - shows great promise to undermine a timeless problem and realign financial incentives with our moral imperative to preserve the health of our Earth. If spatial finance continues to grow and traditional finance is consumed by decentralized finance - and we expect that it will be to a great extent, given the profound efficiency improvements DeFi enables - then a wide range of spatial DeFi applications will emerge in the ecosystem. Imagine a £100M sovereign bond linked to sustainability metrics derived from satellite imagery: the importance of Web3-native geospatial technologies for trustworthy verification of the bond become clearer.

Furthermore, GeoDIDs are intended to be useful in smart contracts. Blockchains are expensive places to store data - it is unlikely that most spatial datasets will be stored on-chain in full. However, if a GeoDID is written to a smart contract, the contract has an immutable reference, a persistent identifier to a spatial data asset that is controlled by the registrant. This technology is nascent, and its designers do not comprehend what its implications may be - but the opportunity space is vast.

GeoDIDs under the hood

The GeoDID is inspired by the SpatioTemporal Asset Catalog (STAC) specification and utilizes a similar linked data structure. The structure alleviates a handful of problems associated with traversing large datasets, and allows for ease of use for the end user. Spatial data assets are identified in the service endpoints of the GeoDID document. These service endpoints can be classed as either Collections or Items. Each "Collection" contains a number of child Collections or Items; and each "Item" will contain several service endpoints that resolve to geospatial data assets. This hierarchy of encapsulating linked data within the GeoDIDs will allow for user's to find or create the data/datasets that they need easily.

The alpha implementation of the GeoDID specification is under development at . For the initial version, only public GeoDIDs are supported. A mapping of GeoDID => GeoDID Document URLs is stored in a smart contract, granting DID Controllers sovereignty over their DIDs and ensuring that permissionless, permanent resolution is possible. Testing is ongoing on Ethereum's Ropsten testnet, but the team expects to deploy the first version of production GeoDID contracts to an Ethereum sidechain, likely Polygon (formerly Matic). This will ensure that the cost of registering a GeoDID is low.

It is important to note: GeoDIDs are blockchain agnostic. A blockchain is not required. This is an intentional design decision, intended to accommodate users who, for whatever reason, may not be able to rely on public blockchains in their data architectures. We believe that public blockchains offer significant advantages that should not be overlooked - but we also recognize that organizations must operate within technical and regulatory constraints that may require them to avoid their usage until the technology is more mature. GeoDIDs and GeoDID Documents can be easily configured to resolve on private distributed ledger instances or centralized databases. It should be stressed that this might undermine some important qualities of the DID. See Decentralized Identifiers for further explanation.

Future Work

Plans to develop an IPLD encoding for vector datasets are being developed, but many technical challenges are foreseen. Content identifiers present interest opportunities for identifying geographic extents - hierarchical topologies naturally adhere to a parent-child-like tree structure. A national border could be represented as a CID; child nodes would identify subsidiary jurisdictions like states or regions, counties, cities, land parcels, and individual buildings. Early ideas around developing capabilities to compare the topologies of CID-encoded vector geometries are being discussed by the team.

Wales, Welsh Electoral Divisions and Welsh Parish Regions, from .

Additionally, the next phase of research and development will be for GeoDIDs that support spatial querying and clipping. DIDs support selectors, paths, query parameters and fragments. These additional details that can be included in a GeoDID offer a powerful way to efficiently represent and store large spatial datasets in a much more resource-constrained manner that is still persistent, cryptographically verifiable and optionally private.

For example, consider GeoDID representing a collection of satellite imagery. We should be able to specify a a spatial and temporal subquery in the GeoDID itself. That way, a user could store a single GeoDID that specifies a single image, clipped to a particular area, extracted from the GeoDID Collection. The user would not need to store that clipped image, but only the GeoDID with query parameters - they would still have the confidence that the GeoDID would resolve to the same clipped image permanently. The same principles apply to vector datasets. A Web Feature Service request contains selection parameters in the URL query string's xml filter, and resolves to a user-defined subset of the dataset served by the WFS. A GeoDID containing a query would likewise resolve to such a subset, but with the persistence, user control and cryptographic verifiability DIDs afford.

This functionality seems to be crucial for an efficient geospatial Web3. One use case: auditing spatial finance applications. A satellite image might prove that a particular green infrastructure project was completed by a certain date, or that some insured natural capital warranted a payout. A GeoDID selecting a vector polygon - the project site - could be stored on chain, as could a series of GeoDIDs representing a sequence of satellite images clipped to that area, before, during and after construction. Investors could audit their green bonds with such a system, confident that audit records will be available for decades to come.

The Web3-native geospatial web is nascent, but ripe with potential to serve as a core component of a more resilient Internet. Much work within the Web3 ecosystem is focusing on how programmable money can be applied to solve intractable problems that have always plagued humanity. Integrating geospatial insights into this mechanism design could be a limited - but potent - tool in the toolkit.

Context: Cloud-Native Geospatial

Satellite images are big. One 8-band Landsat 7 scene we examined (LE71660522010289ASN00) is nearly 850MB. These datasets are rich with information about the state of the Earth's surface at the moment of capture, immensely valuable snapshots of the state of our world that can be studied for decades - centuries to come. However, traditional client-server data architectures make it infeasible for non-specialists to work with these large raster datasets. Download times slow workflows, and consumer-grade hardware is incapable of visualizing and analyzing these datasets.

From

Web3-Native Geospatial

Cloud-native geospatial technologies are key to scaling the geospatial data sector, and for the efficient discovery and computation of relevant data. However, they are built in a centralized computing paradigm, with roots still in the client-server model. Data networks designed in this way are brittle - links can break, file content can be changed unbeknownst to users, and data must be held by trusted custodians who may abuse their role as maintainers of server systems holding geospatial data.

A more secure, resilient and user-centric vision for the Internet is evolving with Web3. Decentralized identifiers, peer-to-peer storage and transfer, and content identifiers resolve the most critical fragilities that exist in the incumbent web.

The geospatial data sector is not immune to these problems - in fact, the ecosystem is rife with inefficiencies. Many organizations hold multiple versions of the same reference spatial datasets on various internally-operated servers. Each of these servers requires computing resources and skilled workers to maintain. It seems unlikely that each of these datasets is kept up to date based on update release cycles, meaning the reference data upon which the organizational data is overlaid is not current. Deep architectural wastefulness pervades geospatial data storage systems in the public, private and third sectors worldwide.

The Web3-native geospatial vision seeks to integrate the learnings of the incumbent geospatial data practitioners with the principles underpinning the design of the decentralized web.

• Data must persist — we cannot try to resolve a mission-critical dataset a few years after its creation only to receive a 404 error. This is especially true for spatial finance applications where decisions dealing with large monetary values are made based on insights derived from geospatial data.

• Datasets must be verifiable — all parties can have cryptographic confidence when accessing a dataset around the world and into the future that they are looking at the same information as others.

• Data networks must be resilient

These are challenging problems to solve, and the community is early in the process of developing the standards, tools and protocols that will unlock the potential of the decentralized, location-based web.

In this talk, the core team from the Astral Protocol will outline their vision for a Web3-native geospatial data architecture, including data storage and computation systems that are decentralized and fault tolerant, and in which all participants are cryptoeconomically-aligned. The Astral team will touch on data storage systems they are designing based on IPFS, Filecoin, Arweave and Ceramic, and will share insights into decentralized geospatial data processing and discovery systems including dClimate, Ocean Protocol and Algovera AI. They will also touch on their early research into privacy-preserving geospatial technologies.

These technologies are designed to interoperate with distributed ledgers, smart contracts and digital currencies, with an eye towards underpinning the emerging regenerative finance ecosystem being built on public blockchains.

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). 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.

Spatial.sol

Spatial.sol is required for many of the location-based dapps and spatial contracts we envision, including the verifiable spatial data registries described . We are researching which functions the library should include, and will look to for inspiration. Some functions we expect to include are:

• Boolean verification algorithms like isPolygon, isLine and so on

• sqrt

These functions will serve as a basis for the first cohort of applications built on Astral. Note that these are primarily vector operations - we anticipate that raster analysis techniques may be useful (recreating some of the functionality of , for example), but will leave that for a future version of Spatial.sol. We still need to research the feasibility of supporting multifeature data structures like multipoints, multilines and multipolygons, as well as more complex shapes like polygons with holes. Version 1 will not support 3-dimensional volumes (polyhedra), but we anticipate that many use cases will require implementation of this functionality in future - for example, to test if an aircraft has entered some airspace.

Spatial Reference Systems

We anticipate that one of the most difficult aspects of building smart contracts designed to work with spatial data is accommodating the diversity of . The Earth is not a perfect sphere - it is a geoid - and many different systems are used to represent positions relative to the planet. matters, and implementing systems that accommodate different spatial reference systems, converting between them etc will be a complex technical challenge.

For v1 of Spatial.sol we will minimize accuracy and complexity in favor of developing simplified on-chain geospatial computing capabilities. For example, we will likely implement a function, but not a function.

Trigonometry.sol

Spatial.sol has a dependency: Trigonometry.sol, developed and open sourced by Sikorka (, ). This library appears to have been abandoned a few years ago, and lacks a tangent method, which is useful in some operations like the between two points. Spatial.sol will require an audited Trigonometry.sol to be secure.

eth-spatial.js

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. Our goal is to ease the developer experience - we expect that many developers will be working with GeoJSON in the client.

eth-spatial.js will be designed to seamlessly accept common data formats used on the web (starting with GeoJSON) and prepare the spatial data for use in contracts that use the Spatial.sol library. One example process here will be converting decimal degrees to integers to be used in the contract, possibly nanoradians.

Likewise, our aim is for eth-spatial.js to easily convert from on-chain spatial data to web-ready GeoJSON. We may look into developing a subgraph to index on-chain geospatial data - the final step to fetching this data will be presenting it in a format that interoperates with common spatial data libraries like Leaflet, Mapbox GL JS etc. An eth-spatial.py library would also probably be helpful, as would implementations in other languages - future work to do.

Future

We anticipate this library will need a thorough audit. We would like to explore how we can ensure ongoing support and development of the library once it is developed and open sourced.

Process of Tiling and Encoding GeoTIFF

Tile Object

Beforehand the GeoTIFF is tiled at different resolutions and sizes, and the binary of the image is then serialized into an IPLD Block. This block contains the serialized binary of the tile, and its respective CID (Content Identifier). This data is then stored into an Object that also contains the tiles respective window and size.

Wrapper Object wrapping Tile Objects

The Wrapper Object wraps the Tile Objects by row, as to act as a "key", when we need the path to pull these tiles. The Wrapper Object should be grouping them by the row *2(tileSize), in order to encapsulate the scaled up version of the tile.

MasterDocument Output

The Master Document is the document that contains all the Rows, Tiles, and their respective Overviews. This is essentially the "IFD", except it is done with IPLD, and is stored as a JSON object.

Response after the GeoTIFF is successfully Tiled and pinned to IPFS

The response after the GeoTIFF is successfully Tiled returns an Object that contains metadata related to the tiling job.

Leveraging , we are early in the process of developing a standard contract for verifiable spatial data registries. There is a wide breadth of opportunities in this design space.

Specifically, we are building on work we've done to let self sovereign users register geographic zones on smart contract platforms, starting with EVM-compatible chains. This capability is required for a number of use cases - a spatial governance system like , sustainability-linked bonds and other spatial DeFi applications, parametric insurance policies like those provides, location-based Web3 games including AR and , and so on.

We believe that a smart contract standard would promote the composability of these spatial data registries. We see value in building on existing work and designing these spatial data registries to interoperate with existing protocols. To this end, our plan is to represent these spatial data assets - vector or raster data objects - as tokens.

We will likely extend the ERC721 contract standard 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:

Spatial data assets identified by GeoDIDs will come in a particular format, likely with information about the spatial reference system, attribution and other metadata. GeoDID extensions will enable the GeoDID Core Spec to expand to support any type of spatial data asset - legacy, current, or future.

Under construction - stay tuned! @AstralProtocol

When sensor 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 spatial computing. We also expect 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 and prototype modules and smart contracts 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.

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.

The GeoDID Method Specification can be found , and writing on the extensions . A repository containing our prototype implementation of a GeoDID system is .

Under construction - stay tuned!

Under construction - stay tuned!

Description

The @astralprotocol/core package is a Typescript NPM package that is responsible for any CRUD operations performed on the DID Documents. This includes the creation of DID Documents, loading the DID Documents, as well as updating them. The package also has utilities that enable the creation of the collision resistant GeoDID IDs, a custom **** did-resolver that enables DID Resolution, as well as pinning features for storing the Documents on IPFS or FFS. This package is meant to be used in conjunction with the @astralprotocol/contracts **** and @astralprotocol/subgraph **** packages. However, the package can also be used independently if the user does not want to rely on the Ethereum network.

To add Astral Protocol Core to your application

To develop or try the Astral Protocol Core locally

Set up a local Powergate Client

In order to store the GeoDIDs created by the core package, you will need to start up a local Powergate client or connect to an existing hosted client. Below will be a brief overview on how to setup a local Powergate client on your system. Further information is available at: .

In order to setup the Powergate Client locally on your system you must have , , and installed.

• In your terminal, create a new directory and clone the Powergate repo into it:

git clone https://github.com/textileio/powergate.git

• After you clone the repo, enter the following commands:

cd powergate/docker

make localnet

For moreinformation regarding Powergate's Localnet mode, please refer to their documentation:

Check an implementation of core package:

Run the script

IDocumentInfo

ILoadInfo

IPinInfo

Under construction - stay tuned! @AstralProtocol

Setting up local Powergate Client

In order to store the GeoDIDs created by the core package, you will need to start up a local Powergate client or connect to an existing hosted client. Below will be a brief overview on how to setup a local Powergate client on your system. Further information is available at: https://github.com/textileio/powergate.

In your terminal, create a new directory and clone the Powergate repo into it:

git clone https://github.com/textileio/powergate.git

After you clone the repo, enter the following commands:

cd powergate/docker

make localnet

More information regarding Powergate's Localnet mode, please refer to their documentation:

Install the packages

Configure truffle-config.js

Create a script for interacting with the Astral Client and Contracts

And execute with

Any comments or feedback please reach out @astralprotocol on twitter or via Discord.

Representing geographic vector features

How to represent these features on chain: struct, array or otherwise? We want to balance efficiency, simplicity and developer experience.

Our initial impulse is to mirror GeoJSON as it is the de facto standard for web developers, well documented and a familiar concept. So a struct is a sensible approach, with s.coordinates being the coordinate array [[lon0, lat0], [lon1, lat1], [lon2, lat2], ... ]:

Then we would call length(s), which would compute the length of the linestring represented by s.coordinates.This also would enable efficient type checking and verification when data is onboarded or used in a method:

Coordinate Reference Systems

How do we want to handle different coordinate reference systems? Do we want to plan on supporting various systems? We think it is probably an aspirational goal, but realistically a requirement that we don't think we need to worry about too much for a long time.

For now we think we want to just focus on mirroring the standards adopted by GeoJSON, especially for v0. (Interesting that GeoJSON for alternative coordinate reference systems in 2016 "because of interoperability issues".)

The coordinate reference system for all GeoJSON coordinates is a geographic coordinate reference system, using the World Geodetic System 1984 (WGS 84) [WGS84] datum, with longitude and latitude units of decimal degrees. This is equivalent to the coordinate reference system identified by the Open Geospatial Consortium (OGC) URN urn:ogc:def:crs:OGC::CRS84.

An OPTIONAL third-position element SHALL be the height in meters above or below the WGS 84 reference ellipsoid. In the absence of elevation values, applications sensitive to height or depth SHOULD interpret positions as being at local ground or sea level.

This decision would be based on a few observations:

• We want these contracts to be composable - dapps will be built that permissionlessly call other spatial data registries deployed on a blockchain. Even if we had a contract- or feature-level CRS flag, handling a range of coordinate reference systems would cause complexity to balloon

• Early on especially we don't anticipate precision location based applications to be running on any smart contract platforms. This is partly because positioning systems are neither hyper precise nor trustless. This disclaimer should be included in the code - that precision may vary. It will be a long time before these technologies mature to the point that they can support mission critical location-based applications - for now our bias towards action and the pragmatic, progress-oriented critical path leads us to lean towards just adopting the most commonly used coordinate reference system used on the web.

Consistency

• We need to establish a consistent way of working with these features. i.e. Always passing around the entire struct and not sometimes passing s.coordinates into a function.

Features as contract instances?

• Is there any benefit to taking the and having these geographic features be contract instances in their own right? Then we could have methods - s.length() returns the length of the linestring - but it seems super inefficient and probably unnecessary.

eth-spatial client libraries

Solidity has certain quirks that makes it tricky to work with. Our focus is on developer experience - we want to make it as easy as possible for dapp developers to build spatial and location-based decentralized applications.

So we expect we will need to develop client libraries that effectively serve as a transpiler. We're not exactly certain how this will work, but a few ideas:

• These client libraries - imagine eth-spatial.js and eth-spatial.py to start - are designed to provide a developer friendly interface between vector spatial data represented in JavaScript / Python environments and those represented in the EVM.

• This could mean moving from JS / Python -> EVM and preparing GeoJSON for submission to a contract that uses Spatial.sol. This would happen by, for example, converting decimal degrees coordinates to Solidity-friendly integers.

(or something like that - to give the instance of web3 access to all of the required methods etc to work with spatial contracts)

We are early in developing the GeoDID spec. For now, we are focused on storing geojson vector spatial data structures, and geotiff raster data. The GeoDID specification is designed to be flexible and identify any spatial dataset in any format - even ones that haven't been developed yet.

Abstract

Geographic decentralized identifiers, or GeoDIDs, are DIDs designed to identify spatial data assets and to be compatible with any distributed ledger or network. Spatial data has unique properties that require special treatment - the GeoDID Method Specification defines an approach in creating, reading, updating and deleting identifiers for these assets using DIDs. In creating a GeoDID, data controllers permissionlessly create irrevocable, cryptographically-verifiable identities for spatial data assets that can be useful in decentralized applications

The objective of the GeoDID is to encourage contribution to the DID specification and Linked Data Signatures to identify and ensure trustable spatial data. This will allow rapid development of extensions to these without requiring the usage of trustless infrastructures such as blockchains or other distributed systems.

The GeoDID is inspired by the and utilizes a similar linked data structure. The structure alleviates a handful of problems associated with traversing large datasets, and allows for ease of use for the end user. Spatial data assets are identified in the service endpoints of the GeoDID document. These service endpoints can be classed as either Collections or Items. Each "Collection" contains a number of child Collections or Items; and each "Item" will contain several service endpoints that dereference to geospatial data assets. This hierarchy of encapsulating linked data within the GeoDIDs will allow for user's to find or create the data/datasets that they need easily.

1. GeoDID Method

The namestring that shall identify this DID method is: geo.

A DID that uses this method MUST begin with the following prefix: did:geo. Per the DID specification, this string MUST be in lowercase. The remainder of the DID after the prefix, is specified below.

2. Namespace Specific Identifier:

did:geo:<geo-specific-identifier>

All GeoDIDs are base58 encoded using the Bitcoin / IPFS alphabets of a 16-byte UUID.

geo-did = "did:geo:" + geo-specific-identifier geo-specific-identifier = new CID(0, 'dag-pb', hash, 'base58btc') hash = multihash(byte, sha2-256) byte = new TextEncoder().encode(ethereum address + UNIX Time)

Namestring Generation Method

For the draft version of this specification, <geo-specific-identifier> referenced above is created by computing a sha2-256 multihash on the byte representation of the DID controller's ethereum address + Unix time: multihash(ethAddress + time, sha2-256). Then we create a new CID Block by encoding the multihash with a base58 encoding. This will return a cid that will act as the identifier for the GeoDID.

Identifying the correct GeoDID

The service array in the GeoDID will contain several references to other GeoDIDs and/or assets. The idea is that if the GeoDID is the root DID in the hierarchy, regardless of its type, then it has the base DID identifier. If the GeoDID is a sub-collection or sub-item then it is referenced via path, and if it is an asset within the sub-item's service array, then it is referenced via fragment.

Standalone or Root GeoDIDs using the Base DID Identifier:

did:geo:9H8WRbfd4K3kQ2NTxT6L2wTNyMj1ARCaVVsT5GJ87Jw2

Paths reference other GeoDID sub-Collections or sub-Items:

did:geo:9H8WRbfd4K3kQ2NTxT6L2wTNyMj1ARCaVVsT5GJ87Jw2/sub-collection-A/sub-item-1

Fragments reference assets within the GeoDID sub-Items:

did:geo:9H8WRbfd4K3kQ2NTxT6L2wTNyMj1ARCaVVsT5GJ87Jw2/sub-collection-A/sub-item-1#raster-image-1

did:geo:9H8WRbfd4K3kQ2NTxT6L2wTNyMj1ARCaVVsT5GJ87Jw2/sub-collection-A/sub-item-1#thumbnail

3. CRUD Operation Definitions

Create (Register)

In order to create a GeoDID, a method specific identifier must be created, which will be used to build the document. After the method specific identifier is created, the user will need to select the type of Document they would like to create, Collection or Item.

Required Assets

• ECDSA keypair. (for the alpha version of the specification - future versions may be agnostic to which digital signature algorithm is used).

• Spatial data asset(s), or URI(s) resolving to spatial data asset(s), along with relevant metadata / attribution.

• If GeoDID Collection, some information about the relationships between the spatial data assets being identified.

Proof of Concept Process

1. Create Method Specific Identifier described in (2), above.

2. User chooses which type of GeoDID they want to create (Collection or standalone Item).

3. If the user decides to create a standalone Item then they just upload the assets, did-metadata information, and item-metadata they want in the DID. The GeoDID will be built, pinned on IPFS, and anchored on the Ropsten Testnet.

In the near future, we will also create automation features to create trees, by uploading folders with files in it. We hope this will kill two birds with one stone, so the user will only need to prepare the data once, and upload it in bulk.

Read (Resolve)

In the alpha implementation of the specification a GeoDID document can be resolved by invoking the resolve(<GeoDID ID>) method at contract address <0x___TBD___> on Ethereum's Ropsten testnet. This contract method will first verify that the user has access to this GeoDID by checking to make sure that his address registered the GeoDID via the create method. The contract will store a mapping from the user's address to GeoDID IDs.

Once the user has been authenticated, the contract will trigger an event that the astral-protocol-core package will be listening for. From there the geo-did-resolver will handle the rest, and dereference to the proper GeoDID Document.

The GeoDID Document can then be parsed and analyzed by the client, or spatial data assets can be fetched from their respective service endpoints. Do note that sometimes data assets will be identified by CIDs and stored on the IPFS network, while other service endpoints may be HTTP URLs - appropriate resolution methods will be required.

Controller Address

Each identity always has a controller address. To check the read only contract function identityOwner(address identity) on the deployed version of the ERC1056 contract.

The identity controller will always have a publicKey with the id set as the DID with the fragment #key appended.

An entry is also added to the authentication array of the DID document with type Secp256k1SignatureAuthentication2018.

Service Endpoints

Service Endpoints are relevant in both GeoDID Controllers **<Collections?>**¸ and Items. It exists to list relevant relationships to and from itself. <?Each object in the> service array will contain a required link field and several that contain the GeoDID ID, its relationship to the DID ID, and a reference link if the controller needs to dereference it. The purpose of the link field is to enables browsers and crawlers to access the sets of Items, in an organized and straightforward way. These service endpoints can also contain references to assets that are related to a specific item.

The GeoDID Document identified by the CID can the be resolved using a browser with native IPFS support (ipfs://<CID>), or by resolving via a gateway, like ipfs.io/ipfs/<GeoDID Document CID>

Update

The DID Document may be updated by invoking the update(<GeoDID ID>) method at contract address <0x_____> on the Ropsten testnet.

Once the address has been verified as the DID controller, an oracle function will be invoked and will trigger an off chain event to open the GeoDID Document for the user to update. When user is done updating, they can submit the update, which will compute the CID of the GeoDID Document and compare the block to the previous CID version.

If the CIDs differ, the client will append the timestamp of the update within the GeoDID Document, recalculate the finalized CID, and will append a new Record in the astral-core-package. The updated CID will be returned via the oracle, and appends to the end of the array of GeoDID Document CIDs, meaning users can fetchVersionHistory(<GeoDID fragment>) and retrieve all the CIDs of historical GeoDID documents.

Deactivate (Revoke)

A GeoDID Controller can revoke access to a GeoDID by invoking the deactivate(<GeoDID fragment>) method. This simply sets that GeoDID's GeoDIDActive record to false - it does not remove information from the smart contract about the historical versions of the GeoDID. It does, however, mean that future attempts to resolve that GeoDID will not succeed.

Reference Implementations

Once we develop it, we will store code at as a reference implementation of this DID method.\

The GeoDID Collection

As of right now, the Collection extends the default GeoDID Specification without any added fields. It is up to the user to add what they deem necessary,. However, the collection must function as a DID that will reference other DID documents or URL links. The metadata added to it must reflect that.

Example of GeoDID Collection

The GeoDID Item

The Item extends the default GeoDID Specification. It can function as a standalone DID and does not rely on a GeoDID Collection to be referenced.

Example of GeoDID Item

Description

The @astralprotocol/subgraph serves as the indexing engine of the protocol, capturing the registration and modification events of GeoDIDs in the @astralprotocol/contracts. It acts like a decentralized querying database where it is substantially easier to make complex queries to the Spatial Assets registry. It is used to create the tree of GeoDID nodes that represents their relationships and groupings.

The current version of the subgraph (spatialassetsfinalv1) is indexing the Ethereum Roptsten network at the following GraphQL endpoints:

You can connect to these with your GraphQL client of choice or try them at .

To add Astral Protocol Subgraph to your application

To develop or try the Astral Protocol Subgraph locally

Prerequisites

• Clone the astralprotocol repository and go to packages/subgraph

• Run sudo apt-get install libsecret-1-dev

Deployment

1. Ensure you have ganache running with the contracts deployed from packages/contracts

2. Update the SpatialAssets contract address that you got from the previous step in the subgraph.yaml (if needed and ensure the correct file is named according to the network of deployment - for ganache it should read as mainnet: backup the current subgraph.yamlfile and rename it to subgraphRopsten.yaml).

Testing

The following query can be provided to the graphql endpoint to view the GeoDIDs tree (after doing the deployment steps above):

Introduction

One of Astral's main goals was to bring cloud native Geospatial capabilities to the Web3 space. While working with Protocol Labs tech for the past few months, we gained some insight into how, IPLD data structures, libp2p, IPFS, FFS, can enable us to make the aforementioned a reality.

We knew we had to experiment with different pieces of tech, in order to understand what's possible, and what we could do to improve the existing tools. With Raster Imagery being so important to the Geospatial community, we challenged ourselves to figure out how we could bring Cloud Optimized GeoTIFF-esque type functionality to IPFS/FFS. In order to understand what we're trying to accomplish, we need to first understand what is a TIFF and GeoTIFF.

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 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

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.

Description

These contracts serve as the Registry for the Astral Protocol GeoDIDs. It allows binding of a GeoDID to an ethereum address and CID name resolving.

By registering a spatial asset Smart Contract events are triggered, which are picked up by the subgraph indexer to build the tree of relationships for easy querying.

To add Astral Protocol Contracts to your application

To develop or try the Astral Protocol Contracts locally

• Clone the and go to packages/contracts:

• Run ganache yarn ganache

• In a new terminal, deploy contracts with yarn truffle

• Run tests with yarn truffle-test

To deploy your own contracts in the Ropsten testnet

• Create a .env file in /packages/contracts with a MNEMONIC and ROPSTEN_API_KEY

State modifying methods

constructor

Initiates the smart contract with an hardcoded uri type representing the did method (did:geo). Also initiates the msg.sender as the default admin and as a data supplier role.

registerRole

Registers a new user with the ability to register a spatial asset. Contract creator is hardcoded as default admin and data supplier roles.

enableStorage

Registers a new storage that can accept GeoDID document creation.

disableStorage

Disables an existing storage.

registerSpatialAsset

Registers on-chain one Spatial Asset.

addChildrenGeoDIDs

Adds children GeoDIDs to an existing GeoDID. GeoDIDId must correspond to a GeoDID type that can be a parent (Collection or type 0).

addParentGeoDID

Adds a GeoDID as a parent to an already existing GeoDID.

removeChildrenGeoDIDs

Removes children GeoDIDs from a specified GeoDID.