astralDAO

AstralDAO the primitive that will stitch together various decentralized components to bring advanced spatial data technologies into the Web3 fold, which will enable an ecosystem of location-based dApps to support our transition to a just, sustainable and resilient world.

Demo Video Live Demo Source Code

Prizes

Protocol Labs, 3rd place

Technologies

Ethereum

Filecoin

IPFS

Solidity

The Graph API

Description

astralDAO aims to bring advanced spatial data technologies into the Web3 fold, which would enable an ecosystem of location-based dApps to support our transition to a just, sustainable and resilient world. We’ve been studying and experimenting how Web3 and spatial data technologies intersect for a while and we have identified the components we’ll need to develop to connect spatial data to smart contracts.We’re beginning to design astralDAO, to fairly govern the tools we’ll need to orchestrate the connection between these components. The components include - Data capture from a range of edge devices like satellites and IoT devices. - Data storage on traditional and distributed systems. - Data analytics, including privacy-preserving techniques like compute-to-data and enclave computing. - Oracles - Smart contracts, and dApps built on top of them. astralDAO is working on connecting these components using open, versatile tools. It is the primitive that will stitch together these various components and enable a spatial dApps ecosystem like: - Congestion zones and spatial governance systems built on smart contracts, which we prototyped as Hyperaware - https://hyperaware.io/. - Sustainable DeFi applications like green bonds and parametric insurance, which we prototyped as a sustainability-linked smart green bond built on Ethereum and IPFS. - Verified carbon permits, enabling a global emissions trading market. - Privacy-preserving location tracking, enabling location-weighted voting and taxation, contact tracing etc. - A sustainability-linked universal basic income and other regenerative incentive mechanisms.

How It's Made

Our application allows a user to create and register a GeoDID, representing a spatial asset such as a raster satellite image, along with all the associated file metadata. The GeoDID, which builds upon the DID and the STAC specs, is intended to be the primitive that enables us to build sophisticated decentralized applications that rely on raster and vector spatial data - location-based dApps ranging from spatial finance applications to mobility to supply chain management and so on. The GeoDID is then pinned to the filecoin network along with any spatial data assets linked to it.These assets, as well as ownership information, can then be visualized in an interactive map in our application. The GeoDID will contain several service endpoints, which will be valid STAC Items, each containing a reference to a spatial asset file. These files are typically GeoTIFF, (Geo)JSON, XML, shapefiles, and other files one might typically find in a STAC Specification. These files are usually referenced by some sort of href url in the STAC Spec, but instead of using a location based identifier, we aim to represent them as CIDs on FFS. As of right now we are going to be using Powergate to pin the "assets" in the STAC Item, so we can use them as service endpoints. We will also use Powergate to pin our GeoDID Documents. We are working on setting up a Hosted Powergate Node on the Lotus Testnet, but we want to test our application locally first. We are also looking into building Chainlink adapters for consumption of the GeoDIDs (which might include aggregated metrics about the spatial data asset), and into extending GeoDIDs to also identify spatial datasets representing vector geometries. We are using The Graph to maintain a subgraph of all the registered geoDIDs. Once a user wants to load and view a geoDID, a DID resolver is called, resolving to the CID for the GeoDID document, stored on filecoin. This retrieves the GeoDID document object, including relevant metadata and links to raw assets, into our UI. As of right now, the requesting party has to get verification from the GeoDID controller in order to view and/or query the GeoDID, the verification will happen on chain for now (ex. signed transaction). The GeoDIDs + their respective "assets" will be stored in cold storage on FFS. The requesting party will only need to retrieve the data once, in order to utilize the service endpoints within the GeoDID Document. In the future we hope to add transactional proofs for our GeoDIDs, so that the GeoDID controller can give access to certain service endpoints, and not reveal all the service endpoints within the whole GeoDID Document. We also want to utilize IPLD to manage the GeoDID versions and the parent/child relationships between the STAC Collections, Catalogs, and Items. If a new version of the GeoDID Document is appended to the DAG, then the requesting party will have to seek verification from the DID Controller again to gain access to the new document. This is only the tip of the iceberg, as we still have many more ideas that we want to test.

Team

João Martins John IV Jared Childers
← click here to see all projects