Astral’s Geospatial Role in the Kolektivo Framework
This blog post provides a technical overview of the tools that the Astral Protocol is developing for the Kolektivo Framework. It is recommended to read the framework’s Bluepaper summary prior to this post.
Astral builds location-based Web3 applications and spatial smart contracts to serve applications that interact with the real-world, such as MRV tools (measurement, reporting, and verification), spatial governance systems, sustainability-linked bonds, parametric insurance mechanisms, or location-based Web3 games. As one of the core builder teams of the Kolektivo Network, Astral is working on key technologies for the Kolektivo Framework’s Minimum Viable Product (MVP), including:
This post will describe each in turn, helping provide key insights into how these tools will create value for the Kolektivo Network or the Web3 regenerative finance (ReFi) sector as a whole.
A GeoNFT is an NFT that represents some physical feature, including its location. In the Kolektivo Framework, GeoNFTs represent ecological assets — e.g. regenerative agricultural projects — or data-producing devices — e.g. weather stations. In the future, GeoNFTs are planned to include merchants and other place-based commercial operators in order to incentivize local trade.
The GeoNFT is implemented as an extended version of a non-fungible token (ERC-721) that includes geospatial location and an ecological index — a type of calculated indicator or score that provides a quick assessment of a territory. GeoNFTs can generally be seen as the digital twin of an ecological asset, such as an area of land, carrying relevant data about what is going on in the real-world in relation to that asset. As tokens, ecological assets fulfill innovative functions, such as backing local Reserves that issue community currency.
A GeoNFT’s physical location is stored as a GeoJSON string. The Polygon geometry representing the boundary of the GeoNFT is verified by a trusted member of the community using Kolektivo’s Badge governance system — a collection of modules primarily forked from the Gnosis Zodiac suite. By doing so, it ensures that no asset is double-counted or over-valued. Each polygon is represented as a latitude and longitude coordinate specified in decimal degrees using the World Geodetic System 1984 (WGS 84) datum.
As mentioned, the ecological state of a GeoNFT is specified by an on-chain attribute called the Ecological Index: a condensed score or value providing relevant information about the GeoNFT, typically calculated using an algorithm or machine learning model.
GeoNFTs play an important role backing the Kolektivo Network Treasury and constituent local Reserves. For a GeoNFT to back either, it must be liquid, and therefore fractionalized — i.e. split into a certain number of fungible ERC20 tokens, which we call shards. To determine the number of shards, we take its area, its Ecological Index, or some value derived from both. Generally, the higher the Ecological Index — an attestation to the good health of the ecosystem represented — the higher the number of shards that should be produced through this process.
For the MVP, we are only calculating produced shards using the ellipsoidal area of the GeoNFT. Put simply, it means that the bigger the area, the higher the number of Ecological Tokens. Consequently, if an area shrinks, the token supply does as well, similar to an elastic-supply token. While we won’t go in-depth into the math behind this, to calculate this on-chain in Solidity, the decimal latitude and longitude numbers were converted to integers, and a sine trigonometric function was built to calculate the area of the polygon.
As more data is collected for a GeoNFT that produces a certain type of fungible Ecological Token — e.g. a regenerative food forest token — we hope to expand the range of index-producing methodologies that ultimately calculate the ecological index. For an agricultural GeoNFT, two examples include Biodiversity and Soil Health. Overall, it is important not only to calculate use area to determine how many Ecological Tokens should be sharded for some GeoNFT, but the quality of that area as well. Transparent, data-driven methodologies that accurately measure ecological health are necessary for any tokenization that is meant to reflect the underlying material reality.
As methodologies are introduced, they are integrated into a GeoNFT’s ecological index calculations through local Reserve governance. Members of a community economy with relevant expertise — such as project stewards or bioregional experts — are assigned a Kolektivo governance badge granting functional permission to do so. In our MVP, we call them Ecology Data Delegates. Our intention is for the GeoNFT design pattern — NFT + geospatial information + index — to underpin a wide range of location-based protocols. The Kolektivo Framework provides the first use case and enables us to build our reference implementation.
For more detailed information, please see the documentation for Ecological State.
A Spatial Data Registry is a way of organizing and storing spatial data to facilitate geospatial querying — i.e. looking up a previously inserted value based on a key. It’s an essential tool for identifying all data relevant to a GeoNFT and its produced Ecological Tokens. It helps prevent efforts to game the production of ecological assets; for example, overstating carbon offsetting by concealing greenhouse gas emissions. In Kolektivo, the Spatial Data Registry is governed by delegates that we know as Topology Data Delegates, using the same Badge system mentioned prior. They are designated persons able to adjust the geographic boundaries of a GeoNFT, and determine which GeoNFTs are displayed on the Impact Map.
The registry serves two purposes in Kolektivo’s MVP:
For the MVP, Astral has built a fully decentralized registry on-chain. Geospatial data is organized and queried using a lightweight geohash geocode system.
Geohashing is a method to encode geographic coordinates as a string of characters. Geohash has the advantage of using only alphanumeric characters, which works well to overcome Solidity’s lack of floating point number support. 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. The more characters specified, the smaller the rectangle will be. For example, the geohash de2f7 with five characters is five nested rectangles deep.
A convenient way to hold a collection of geohashes is a GeoTree, 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 GeoNFTs at different levels of precision by picking any node and traversing through all of its children to find all enclosed GeoNFTs. For example, the level 5 geohash gbsuv represents a rectangle of approximately 5x5 km. To find all GeoNFTs 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:
The GeoTree data structure would look like this:
It takes a certain amount of time to find information along a GeoTree. In computer science, we talk about time complexity — i.e. the number of steps calculated before arriving at a result. Assume that the previous 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 GeoNFTs at each intermediate node. This means that for every insertion, the GeoNFT will be stored on the end node and every parent of that node, as displayed in the following illustration:
Even though this variant may have some drawbacks, we chose it because it pays off in terms of query efficiency. Its time complexity is as follows:
Regarding the storage, the caching-version will increase its size from n to (k+1)*n. However, the depth of the tree (k) will usually be a low number, making the memory requirement O(n) — just the same as the non-cached version.
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 — i.e. a key/value datastore. The key is the full geohash mapped to an array of GeoNFT ids. Our previous example would be represented as follows:
{ "gbsuv" => {1, 2, 3} "gbsuv7" => {1, 2, 3} "gbsuv7d" => {1} "gbsuv7dg" => {1} "gbsuv7z" => {2, 3} "gbsuv7zw" => {2} "gbsuv7zy" => {3}}
A regenerative agricultural steward has activated a parametric insurance policy for an extreme wind event on GeoNFT’s land. Wind data is collected on a 10 minute interval across the region. Using the Spatial Data Registry, weather stations are queried near the insured GeoNFT’s location by specifying a latitude/longitude and a precision that corresponds with the corresponding geohash depth level. The maximum velocity of wind is then calculated from the resulting weather stations. The parametric insurance policy is triggered as the calculated velocity is greater than its threshold, meaning money is transferred to the stewards affected by the extreme weather event.
For more detailed information, please see the documentation for On-Chain Spatial Data Registry.
In Kolektivo, Ecological Tokens are proposed to be data access tokens to a GeoNFT’s specific data store. For example, an Ecological Token representing a coral reef may grant access to a dataset about water temperature and biodiversity for the reef for a specific timeframe. The following section details how data relating to a GeoNFT is collected in the context of the MVP, as well as the limits within which data is shared.
For the Kolektivo MVP, a rule book detailing regenerative principles will be used to determine which GeoNFTs can be added to Kolektivo’s Spatial Data Registry. Following this rulebook, stewards of agricultural projects must verify that they are following regenerative practices in their usage of water, nutrients, or chemicals. When a regenerative agricultural project is approved, baseline and benchmark data on inputs and yields is collected using Survey123 — a tool by ArcGIS. As part of the rulebook, each steward is provided with a how-to manual on working with waste, nutrients, and water on their land.
A trained data collector, working on a monthly basis, will collect more detailed data in a dependable, reproducible way for each listed regenerative agricultural project — the aforementioned Ecology Data Delegate. For regenerative agricultural projects in the MVP, Ecology Data Delegates will collect the following values:
Ecological data is exported from ArcGIS on a regular basis and uploaded to a decentralized storage by the Ecological Data Delegate. This data will be available for purchase on a platform such as the Ocean Marketplace for a fixed fee as determined by the owners of the data — the projects themselves.
In addition to agricultural data, weather data is also used to produce ecological data in Kolektivo’s MVP. Five personal weather stations were deployed across Curaçao by the local team. To facilitate data collection, Astral polls data from the weather stations every 10 minutes and sends the data to a message broker — i.e. a middleware layer allowing multiple incoming data streams each to be routed to multiple subscribers. The message broker forwards the data to a centralized MongoDB database, exposing data for querying and analysis. The summary data can be queried and uploaded on a regular basis to decentralized storage by the Ecological Data Delegate.
In the future, data will be hashed, anchored and validated regularly to the blockchain using Astral’s Anchored Spatial Data Registry.
Kolektivo’s Impact Map is the convergent interface of the geospatial tools described throughout this post, acting as a gateway that bridges the physical and digital world. It visualizes ecological assets and different impact initiatives — including local merchants, community driven initiatives, and events. On the Map, we would like it to be eventually possible to:
In the long term, the Impact Map is envisioned as an augmented browser for coordinating all types of ReFi initiatives across a bioregion. This means that ultimately, the Map should not be perceived as a Kolektivo-specific platform, but rather as a generalized means of facilitating ReFi initiatives’ incubation, inter-organizational trade, and collaboration between embedded communities.
As we increase the number of local regenerative economies supported by Kolektivo, we will be collecting valuable data about the earth’s state. As these datasets grow, we will need to query these repositories. Searching by location will enable bioregions to share their local practices globally.
When Kolektivo asked us to build the location support for the Curaçao MVP, we were excited by the opportunity to expand the tools and design patterns that we had been building. We have already shared these open source tools and these components are available to be reused by other regenerative projects.
Holly Grimm | Daniel Serrano | Tsondru | Louise Borreani | Pat | JohnX
Take action now and explore potential synergies with the Kolektivo Network.
%201%20(1).png)
.png)
