> For the complete documentation index, see [llms.txt](https://astral-protocol.gitbook.io/astral/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://astral-protocol.gitbook.io/astral/archive/oracles.md). # Spatial Oracles We have done little work on spatial oracles, instead focusing to date on the data storage and spatial contracts layers of the protocol stack. Our early thinking suggests that making a full suite of spatial analytics algorithms (raster and vector) available at the oracle layer would be useful for on-demand processing of geospatial data. For example, one concept protocol we have designed is a parametric insurance system. With this, we trustlessly insure physical assets in space - initially conceived of as static areas or volumes like land parcels or administrative jurisdictions (maritime, terrestrial, airspace etc). Upon purchasing a policy, agents would register their land parcel in an Astral verifiable spatial data registry, possibly represented using a GeoDID identifying a polygon or polyhedron. Additional information like the policy duration, indemnity process and, crucially, insured parameter and data source, would be specified upon policy creation. See this [relatively simple example](https://www.nature.org/en-us/what-we-do/our-insights/perspectives/insuring-nature-to-ensure-a-resilient-future/) deployed by traditional insurers. Asset monitoring could be configured in a few ways. In the example above, periodic checks to the parameterized data feed could be made, and a payout could be triggered automatically if the parameter threshold is exceeded. Alternatively, the insurance contract could be reactive, requiring a policy holder to submit a claim transaction. In this event, the contract would trigger the oracle to fetch both the land parcel information and the relevant parameterized external information. To enable a scalable, fully decentralized system, we suspect the most efficient architecture will require an oracle or some Layer 2 consensus network to apply a spatial analysis algorithm to these inputs to determine if the claim is valid. (This differs to many existing DeFi insurance protocols - these often rely on some entity - a trusted individual or DAO committee - to assess the evidence off chain and submit an attestation to settle a claim or trigger automatic indemnity - see [IBISA](https://ibisa.network/) and certain review strategies employed by Protekt's [Claims Manager](https://docs.protektprotocol.com/#/?id=protekt-contracts). This functionality was also required to detect the amount of time devices spent in policy zones in Hyperaware, and to supply NOx levels to the [sustainability-linked bond dApp](https://github.com/AstralProtocol/sprout) we prototyped during the KERNEL Genesis Block. What is unique about this compared to other oracle systems is that our focus is narrowly on spatial data, that is, information that contains some spatial, or location, dimension. We could argue that *all* data is spatial data, but here specifically we are looking at data representing physical space - geospatial data, and data positioned within other spatial reference systems. Needless to say, much research into these oracle capabilities - including privacy-preserving techniques - for bringing spatial insights on chain in an efficient way is warranted, as it seems this is an unavoidable layer of the Astral stack. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://astral-protocol.gitbook.io/astral/archive/oracles.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.