Token reporting engine

Abstract

A computer-implemented method and system for reporting information contained in a digital token on a geolocation indexed ledger of a public blockchain, the token comprises metadata (figures 1, 2) rela

Description

Field of Disclosure This disclosure relates to reporting information from a digital token stored on a public blockchain. In particular, this disclosure relates to searching for metadata related to a carbon reduction asset contained on one or more digital tokens and reporting such information to a user. Background The present disclosure relates generally to digital tokens, which can be created and recorded in a distributed ledger on a public chain such as blockchain. Blockchain is a time-based series of data since it maintains a chronological record of transactions or data entries. This feature, combined with decentralisation and immutability, provides a reliable and transparent way to track the history of transactions or data entries. Blockchain is well known for its use in the area of non-fungible tokens, where digital tokens are used to represent and transfer real-world assets via the blockchain. The digital token serves as an identifier that allows the real-world asset to be referenced. The asset can then be securely stored and transferred using the blockchain. One area in which the use of blockchain has enhanced security and transparency of the asset is in land ownership transactions. As mentioned above, blockchain is inherently a timebased series of data, therefore storing data on the blockchain using the location information of the asset can be problematic. In fact, it is well-recognised that geospatial data is difficult to index. One area of current interest is the use of digital tokens to represent carbon reduction assets, such as voluntary carbon credits. It is well-known that solutions are desired for the reduction of the green-house gas carbon dioxide (CO2) from the environment. One possible solution to this problem is for persons, companies or governments to trade voluntary carbon credits, where these carbon credits represent assets (i.e. carbon reduction assets) which are designed to reduce or avoid CO2. These carbon credits are traded in carbon markets, which allow their buying and selling. Therefore, the information related to the carbon reduction assets can be represented in the form of a digital token, i.e. a voluntary carbon credit. There are a number of challenges in creating, storing, transferring and reporting of voluntary carbon credits on the blockchain which must be overcome if they are to be seen to be a commercially viable and useful tool in the offsetting of CO2 and / or other greenhouse gas emissions. One problem that exists with current methods and systems related to carbon reduction assets is that the information related to the carbon reduction project or the carbon avoidance project is not centrally accessible. Currently, information is stored in several de-centralised platforms which do not communicate with each other. Therefore, a user looking for information in relation to a voluntary carbon credit will have to search one database for an owner, one database for location, another database for financial value, and another database for carbon reduction rating. Further, the current way of storing this different information securely, apart from being on several databases, is to use standard blockchain protocols, i.e. storing as a time series on a distributed ledger. However, this method is cumbersome when looking to store and report information associated with location based assets such as carbon reduction projects. In particular, it is time consuming and can lead to inaccurate retrieval of information when searching on the general public blockchain, as the project may have evolved over time. Thus, an extended amount of time is taken to locate the digital token related to the current state of the project. Using the location data to search for the digital token results in a faster retrieval of the metadata as throughout the evolution of the project, the location remains a constant. The present disclosure seeks to overcome at least some of the disadvantages discussed above. Summary In an aspect of the disclosure, there is provided a computer-implemented method for reporting information contained in one or more digital tokens on a geolocation indexed ledger of a public blockchain. The one or more digital tokens comprise metadata related to an asset. The method comprising selecting a metadata category of the digital token, and then searching the geolocation indexed public blockchain, using the metadata category, for a digital token comprising metadata related to the metadata category. The method includes retrieving one or more digital tokens comprising metadata related to the metadata category and reporting the asset information from the retrieved metadata to a user. It will be appreciated that any features described herein as being suitable for incorporation into one or more aspects or embodiments of the present disclosure are intended to be generalisable across any and all aspects and embodiments of the present disclosure. Other aspects of the present disclosure can be understood by those skilled in the art in light of the description, the claims, and the drawings of the present disclosure. The foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the claims. Brief Description of Drawings Embodiments of the present disclosure will now be described with reference to the accompanying drawings, where: Fig. 1 is a diagram of a digital token containing data related to a carbon reduction asset; Fig. 2 is a diagram of a digital token containing data related to a geospatially identified voluntary carbon credit (GI-VCC); Fig. 3 illustrates a single platform system with a single public blockchain accessible to multiple users; Fig. 4 is a flow diagram of a method for reporting information from a digital token stored on a public blockchain; and Fig. 5 is a flow diagram of a method of reporting information from a digital token containing geospatially identified voluntary carbon credit (GI-VCC) data to a third party user, in this instance a regulatory body. Detailed Description In an aspect of the disclosure, there is provided a computer-implemented method for reporting information contained in one or more digital tokens on a geolocation indexed ledger of a public blockchain, wherein the one or more digital tokens each comprise metadata related to an asset; the method comprising: selecting a metadata category of the digital token; searching the geolocation indexed public blockchain, using the metadata category, for a digital token comprising metadata related to the metadata category; retrieving one or more digital tokens comprising metadata related to the metadata category; and reporting the asset information from the retrieved metadata to a user. This computer-implemented method allows for accurate and efficient searching and reporting of information related to one or more location based assets. Further, storing the location based asset information on a geolocation indexed public blockchain allows multiple parties to access some parts of the data while restricting access to more sensitive or private information, resulting in a highly secure system. In an embodiment, the method may further comprise inputting at least one cryptographic key or authorisation code to access at least some of the metadata. Providing various access levels allows multiple parties to access relevant information while providing a high degree of security.ln an embodiment, the digital token may be an NFT-type token. This allows the asset to have different financial values depending on the various properties associated with the asset as well as allowing for fluctuations in the financial market. In an embodiment, the method may be executed on a single platform. The use of a single platform allows users a single access point for retrieving information related to a particular asset, for example retrieving an aggregation of information related to a carbon reduction project. In an embodiment, the platform may be a multi-party environment. The multi-party environment provides multi-level access to various third party users on the single platform. For example, a regulatory body can have deeper access to particular information stored on the public blockchain compared to a standards agency or a market actor. In an embodiment, users of the platform may be selected from the list of: project owner, regulatory body, standards agency; and / or market actors. This list is not exhaustive. It will be realised that any third party with an interest in the stored data may be warranted access to particular aspects of the information stored on the public blockchain. For example, it may be that the public can access low level information by performing a basic search, such as what carbon reduction assets are available for purchase / investment without providing any specific of a particular carbon reduction asset. In an embodiment, the digital token may be previously generated and recorded on the geolocation indexed public blockchain. In order for a user to retrieve a report on the information stored on one or more digital tokens, the one or more digital tokens must have already been created with such information. It is important that all the necessary information related to the asset is stored on the digital token to allow for adequate and accurate searching. Once the digital tokens are created they are indexed by location in a ledger on the public blockchain. In an embodiment, the information on the blockchain may be accessible via a single application programming interface (API). The single API allows multi-party users ease of access to the platform and data stored thereon. In an embodiment, the geolocation indexed ledger of the public blockchain may be a single public pseudo-anonymous ledger indexed using location data. Having a single ledger that is indexed by location rather than time allows for more efficient searching for location based assets. For example, the location of a location-based asset (such as carbon reduction project) cannot change whereas other factors of the asset may change over time such as ownership, lifetime of project and / or carbon reduction rating. In an embodiment the metadata may be encrypted and access may be obtained using at least one cryptographic key. Encrypting the data and using cryptographic keys to access such data provides a high level security and only allows certain users access to certain parts of the metadata, i.e. providing varying restriction levels. In an embodiment, the metadata may be pseudo-anonymous and access may obtained using at least one authorisation code. Pseudo-anonymising the metadata and using authorisation codes to access such data provides quick access to nonsensitive or restricted data, but still provides a degree of security. In an embodiment, the digital token may indicate a location of the asset associated with the digital token. The location of the asset allows for regulatory bodies and standards agencies to check that a project associated with the asset exists at that particular location or on such a site. In an embodiment, the digital token may indicate a type of asset associated with the digital token. The type of asset can include a property asset, assets of a smart city, bonds, mining of precious metals such as fractional gold, oil, or any other location based asset. In an embodiment, the digital token may be a geospatially identified voluntary carbon credit (GI-VCC) digital token. Advantageously, voluntary carbon credits allow for the trading of carbon offset projects, thus reducing or avoiding the emission of CO2 from the environment. Further, the GI-VCC can be monitored and regulated via the single platform and provide capabilities for the authentication of the location based asset, such as a carbon reduction project, by using the geospatial information stored with the GI-VCC. In an embodiment, the metadata data may be stored in an enrichment layer of the digital token. The enrichment layer allows the storing of the metadata associated with the project. In an embodiment, the asset may be a carbon reduction asset. In an embodiment, the carbon reduction asset may be a mechanical asset and / or a biological asset. This information can be stored on the digital token to aid in searching for particular carbon reduction assets. For example, if a market actor wishes to invest in a biological asset or buy VCCs associated with a biological asset rather than a mechanical asset, the market actor is able to differentiate between such assets when searching the public blockchain (depending on access requirements). In an embodiment, the metadata category may relate to a property of the asset. By defining categories of the metadata it aids in searching the public blockchain for particular information that may be accessible to a particular user, thereby improving the searching and reporting efficiency. In an embodiment, the metadata category may be one of: location, project owner, carbon reduction rating, lifecycle of project, financial value of project, or hash function. In an embodiment, the searching may be performed by a blockchain crawler, crypto crawler, or blockchain explorer. The crawler or explorer has the capability to crawl, i.e. search, the information stored on the geolocation indexed public blockchain using location data, thereby improving the efficiency of searching and reporting locationbased assets such as carbon reduction projects. In an embodiment, the reporting of the asset information may be an aggregation of the metadata retrieved by use of the cryptographic key or authorisation code. Having the information reported as an aggregation reduces searching time for both the system and user as all (accessible) information is reported in a single report, rather than having to search for multiple entries stored on multiple digital tokens individually. Therefore, all information accessible to a particular user is reported after a performing a single search, thus improving the efficiency of the reporting. In an embodiment, the amount of accessible metadata and the type of accessible metadata may be determined based on the user’s cryptographic key or authorisation code. Each user will have a unique cryptographic key or authorisation code to allow retrieval of the metadata associated with the cryptographic key or authorisation code. The amount and type of metadata that can be retrieved depends on the user. For example, a project owner will have access to different types of data and / or different amounts of data stored on the digital token compared to a regulatory body. Thus, the single platform system provides a secure environment for storing high level information while making it accessible to several third party users. In an aspect of the disclosure, there is provided a system for reporting information contained in a digital token on a geolocation indexed public blockchain, wherein the digital token comprises encrypted metadata related to an asset and wherein the system comprises: a computing platform; an application programming interface (API); and one or more processors, wherein the one or more processors are configured to execute the aforementioned method. Fig. 1 is a diagram of a digital token 100 containing data related to a carbon reduction asset. The digital token represents real-world entities which are stored and transferred via the blockchain, in this case a carbon reduction asset which can be created, stored, reported and transferred via a geolocation indexed public blockchain. The carbon reduction asset may be a carbon capture project or a carbon avoidance project with a particular physical location. Other location based assets which could be created, stored, reported and transferred as a tokenised entity in the same manner as the carbon reduction asset discussed in this disclosure are a property asset, assets of a smart city, bonds, mining of precious metals such as fractional gold, or oil. It will be understood that this list is not exhaustive and other location based assets can be realised. As shown in Fig. 1, the digital token 100 contains a number of data layers for storing information related to the carbon reduction asset, including an enrichment layer 110, an asset layer 120, a volumetric unit layer 130, a digital addressing layer 140 and a base layer 150. The enrichment layer contains encrypted metadata related to the carbon reduction asset and may be used to aid the retrieval of data during a search on the public blockchain. The asset layer 120 contains data related to the carbon reduction asset, such as information on the type of project, i.e. a carbon capture project or a carbon avoidance project. The volumetric unit layer contains data related to the amount of carbon removed, i.e. the amount of carbon the project captures and / or avoids putting into the atmosphere. The volumetric unit can be in units of tonnes of carbon dioxide removed / captured per cubic area. The digital addressing layer contains details of the unique digital token address. The unique digital token address is a combination of the IPv6 address and the bitcoin address and serves as a virtual location of the digital token on the blockchain. The final layer of the digital token is the base layer, which includes details of the location of the carbon reduction asset as well as the owner of such asset. The location data may be stored as global positioning system GPS coordinates, a What3Words address, an OS coordinate, street address, postcode or the like. The location data is used to index the digital token on the geolocation indexed public blockchain as the location of the carbon reduction asset will not change over time, unlike the owner of the project or the lifetime of the project. By indexing the digital token by location a new digital token will be created upon changes of the lifetime or owner or some other factor associated with the carbon reduction asset, whereas the location will not change. This allows for more efficient searching of the carbon reduction asset on the blockchain. The owner data may be the original owner of the carbon reduction asset or may a subsequent owner, i.e. after a transfer of ownership of the asset has been made. As mentioned above, in such a case where a transfer of ownership has been made a new digital token will be created for the asset. In a preferred embodiment in Fig. 2, a diagram of a digital token 200 containing data related to a geospatially identified voluntary carbon credit (GI-VCC) is shown. This digital token 200 is similar to the digital token 100 of Fig. 1 but with more specific details in relation to the preferred embodiment. The digital token 200 still comprises an enrichment layer 110, an asset layer 120, a volumetric unit layer 130, a digital addressing layer 140 and a base layer 150. The enrichment layer 210 contains encrypted metadata related to a project associated with a GI-VCC and may be used to aid the retrieval of data when searching for a particular GI-VCC on the geolocation indexed public blockchain. The asset layer 220 contains data related to the asset represented by the GI-VCC, i.e. the type of project related to carbon removal from the atmosphere. The asset layer 220 includes information as to whether the project is a biological asset or a mechanical asset or both, and whether each of the assets relate to a carbon capture project or a carbon avoidance project. Examples of biological assets of carbon reduction include peat bog protection, forestry or coastal wetlands and examples of mechanical assets of carbon reduction include wind farms, mechanical tree farms, or solar power farms. The volumetric unit layer 230 contains data related to the amount of carbon removed, i.e. the amount of carbon the project captures and / or avoids. In this preferred embodiment the volumetric unit 230 is tonnes of carbon dioxide per cubic area or per 3m x 3m area (the 3m x 3m area aligns with what3words area resolution). The digital addressing layer 240 contains details of the unique digital token address. The unique digital token address is a combination of the IPv6 address and the unique bitcoin address and serves as a virtual location of the digital token on the blockchain. The base layer 250 includes details of the location of the carbon reduction asset as well as the owner of such asset. In this preferred embodiment, the location data stored is a what3words address, i.e. a unique combination of three words representative of a 3m square of anywhere in the world. The owner details are also stored in the base layer 250, which in this embodiment is determined by a Global Legal Entity Identifier (GLEI). The GLEI identifies the legal owner of the GI-VCC through the ISO standard global financial system and provides a unique global identifier for legal entities participating in financial transactions, such as GI-VCCs. Fig. 3 illustrates a single platform system 300 with a single public blockchain 350 accessible to multiple users 310. The multi-party environment allows different third party users 310 to access the platform 340 via the application programming interface (API) 320. Depending on access requirements, the users 310 can access different information stored as digital tokens 360 on the public blockchain 350, wherein the digital tokens 360 have been previously generated and recorded on public blockchain 350. In this embodiment, the public blockchain 350 is a geolocation indexed public blockchain 350, wherein the geolocation indexed public blockchain is a single public pseudo-anonymous ledger indexed using location data, and the one or more digital tokens 360 contain data related to one or more assets, for example geospatially identified voluntary carbon credits (GI-VCC). As discussed in relation to Fig. 2, the digital token indicates a location of the asset and the type of asset associated with the digital token. The users of the platform 340 can include anyone with an interest in the stored one or more assets, i.e. the GI-VCCs. The users 310 include the project owner of the asset or VCC (for example forestry commission), a regulatory body, one or more standards agencies and / or market actors, wherein the market actors can include buyers, investors, banks, insurance companies or the like. Each user 310 will have a specific cryptographic key (or authorisation code) to allow retrieval of the relevant information stored on the geolocation indexed public blockchain 350, the cryptographic key being a public or private key depending on access constraints. For example, an owner of the carbon reduction project and the GI-VCC will have access to different information than a regulatory body. Each user 310 will access the relevant information via the API 320 by using their cryptographic key or authorisation code, where the accessible information will be retrieved from the blockchain 350. Using the cryptographic key, the metadata is decrypted via the encryption / decryption means 330. In both scenarios, the authorised information and the decrypted information are reported to the user 310 via the API 320. Further, a user 310 may not require a cryptographic key or authorisation code to access publically available information stored on the blockchain 350. The user 310 can use the platform 340 to search and retrieve relevant data that contains no sensitive information and the platform 340 will report the data to the user 310 via the API 320. Fig. 4 is a flow diagram of a method 400 for reporting information from a digital token 360 stored on a public blockchain 350. When a user 310 accesses the API 320 the method 400 comprises selecting a metadata category 410 linked to one or more digital tokens 360. The metadata category is selected 410 from one of location, project owner, carbon reduction rating, lifecycle of project, financial value of project, or hash function. For example, a project owner may select project owner as the metadata category and input their details such as to allow searching for information in relation to their one or more assets stored on one or more digital tokens 360. Regardless of the metadata category selected the searching will be location based, given the blockchain 350 is indexed by location. The next step is searching the geolocation indexed public blockchain 420 using the metadata category to aid in the search. The searching may be performed by a blockchain crawler, crypto crawler, blockchain explorer, or the like. The platform searches the blockchain 350 to gather all information related to the metadata category and retrieves the one or more digital tokens 430 that contain such metadata. The user’s 310 cryptographic key is then input into the system 440 and the platform 340 assesses whether the cryptographic key matches with the metadata key 450 of the one or more digital tokens 360. Similarly, a user 310 can input an authorisation code into the system 300 and the platform 340 assesses whether the authorisation code matches the pseudo-anonymisation access requirements to allow access to nonsensitive parts of the data. If the user’s 310 cryptographic key matches that of the one or more metadata keys the platform 340 will decrypt the metadata 460 via the encryption / decryption means 330 and report the information from the retrieved metadata 470 to the user 310. If a plurality of digital tokens 360 are retrieved, the accessible parts of the information related to the asset orGI-VCC will be reported as an aggregation of the metadata retrieved. The reporting is preferably executed via the API 320 of the platform 340. All information accessible to the particular user 310 is reported after a performing a single search 400, thus improving the efficiency of the reporting. This is achieved by having all data on a single public pseudo-anonymous ledger and using a single platform 340 to access such data. If the user’s 310 cryptographic key does not match any of the metadata keys, the system 300 will not allow reporting of the information to the user 310 and the user 310 will be prompted to select a different metadata category 410. Similarly, if the user’s 310 authorisation code does not match the pseudo-anonymisation access requirements, the system 300 will not allow access to the platform 340 or to the reporting of non-sensitive information to the user 310. In this case, the user 310 will be prompted to input a different authorisation code. If no metadata category and / or authorisation code can be established, the user will not have access to the platform 340 or any information stored on the blockchain 350. Therefore, the system 300 has a high level of security. Fig. 5 is a flow diagram of a method 500 of reporting information from a digital token 360, stored on a geolocation indexed public blockchain, containing geospatially identified voluntary carbon credit (GI-VCC) data to a third party user 310, in this instance a regulatory body. It will be understood that the method 500 can be executed where the user and metadata category may be interchangeable with other third party user’s and metadata categories without detracting from the steps of the method 500. The initial step 510 is accessing the platform 340 as a third party user 310 via the API 320. In this embodiment the third party user 310 is a regulatory body. As in the method 400 of Fig. 4, the regulatory body (user 310) selects a metadata category 520. As a specific example, the metadata category is selected to be the location of the asset in the description of this method 500. The next step 530 is for the platform 340 to search the geolocation indexed public blockchain 350 using the category input, i.e. the location. As in the method 400 of Fig. 4, the searching is performed using a blockchain crawler, crypto crawler, blockchain explorer, or the like. Again, the platform searches the geolocation indexed public blockchain 350 to gather all information related to the location metadata category and retrieves the one or more GI-VCC digital tokens 540 that contain such location information in the metadata. The cryptographic key of the regulatory body (third party user 310) is then input into the system 550 to assess whether the regulatory body 310 can receive the retrieved information. The platform 340 assesses whether the regulatory body’s 310 cryptographic key matches with the metadata key 560 of the one or more GI-VCC digital tokens 360. If the regulatory body’s 310 cryptographic key matches that of the one or more metadata keys the platform 340 will decrypt the metadata 570 via the encryption / decryption means 330 and report the information from the retrieved metadata 580 to the regulatory body 310. If a plurality of GI-VCC digital tokens 360 are retrieved, the accessible parts of the information related to the GI-VCC, and thus the carbon reduction asset, will be reported as an aggregation of the metadata retrieved 580. The reporting is preferably executed via the API 320 of the platform 340. Again, all information accessible to the regulatory body 310 is reported after a performing a single search 500 using the disclosed system. Thus, the regulatory body only needs access to a single platform to retrieve all the information related to the Gl-VCC (that they have access to). Therefore, the disclosed system 300 improves the efficiency of the reporting of carbon reduction asset or GI-VCC based information to an accessible user 310. This is achieved by having all data on a single public pseudo-anonymous ledger and using a single platform 340 to access such data. If the regulatory body’s 310 cryptographic key does not match any of the metadata keys of the retrieved metadata, the system 300 will not allow reporting of the information to the regulatory body 310 and access to such information will be denied 590. The regulatory body 310 will be then prompted to select a different metadata category 520, for example lifecycle of the carbon reduction or carbon avoidance project. If no metadata category can be established, the regulatory body will not have access to the platform 340 or any information stored on the geolocation indexed public blockchain 350. This provides an additional layer of security to the system 300 as the searching (and reporting) can only take place of specific metadata matches that which is stored on GI-VCC digital tokens. It should be noted that the above-mentioned aspects and embodiments illustrate rather than limit the disclosure, and that those skilled in the art will be capable of designing many alternative embodiments without departing from the scope of the disclosure as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed as limiting the claims. The word "comprising" and "comprises", and the like, does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In the present specification, “comprises” means “includes or consists of’ and “comprising” means “including or consisting of”. The singular reference of an element does not exclude the plural reference of such elements and vice-versa. The disclosure may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

1. A computer-implemented method for reporting information contained in one or more digital tokens on a geolocation indexed ledger of a public blockchain, wherein the one or more digital tokens each comprisemetadata related to an asset;the method comprising:selecting a metadata category of the digital token;searching the geolocation indexed public blockchain, using the metadata category, for a digital token comprising metadata related to the metadata category;retrieving one or more digital tokens comprising metadata related to the metadata category; andreporting the asset information from the retrieved metadata to a user.

2. The method of claim 1, further comprising inputting at least one cryptographic key or authorisation code to access at least some of the metadata.

3. The method of claim 1 or 2, wherein the digital token is an NFT-type token.

4. The method of claim 1,2 or 3, wherein the method is executed on a single platform.

5. The method of claim 4, wherein the platform is a multi-party environment.

6. The method of claim 4, wherein users of the platform are selected fromthe list of: project owner, regulatory body, standards agency; and / or market actors.

7. The method of any of the preceding claims, wherein the digital token ispreviously generated and recorded on the geolocation indexed public blockchain.

8. The method of any of the preceding claims, wherein the information on the blockchain is accessible via a single application programming interface (API).

9. The method of any of the preceding claims, wherein the geolocation indexed ledger of the public blockchain is a single public pseudo-anonymous ledger indexed using location data.

10. The method of any of the preceding claims, wherein the metadata is encrypted and access is obtained using at least one cryptographic key.

11. The method of any of the preceding claims, wherein the metadata is pseudo-anonymous and access is obtained using at least one authorisation code.

12. The method of any of the preceding claims, wherein the digital token indicates a location of the asset associated with the digital token.

13. The method of any of the preceding claims, wherein the digital token indicates a type of asset associated with the digital token.

14. The method of any of the preceding claims, wherein the digital token is a geospatially identified voluntary carbon credit (GI-VCC) digital token.

15. The method of any of the preceding claims, wherein the metadata data is stored in an enrichment layer of the digital token.

16. The method of any of the preceding claims, wherein the asset is a carbon reduction asset.

17. The method of claim 16, wherein the carbon reduction asset is a mechanical asset and / or a biological asset.

18. The method of any of the preceding claims, wherein the metadata category relates to a property of the asset.

19. The method of claim 18, wherein the metadata category is one of: location, project owner, carbon reduction rating, lifecycle of project, financial value of project, or hash function.

20. The method of any of the preceding claims, wherein the searching is performed by a blockchain crawler, crypto crawler, or blockchain explorer.

21. The method of any of the preceding claims, wherein the reporting of the asset information is an aggregation of the retrieved metadata.

22. The method of any of the preceding claims, wherein the amount of accessible metadata and the type of accessible metadata is determined based on the user’s cryptographic key or authorisation code.

23. A system for reporting information contained in a digital token on a geolocation indexed public blockchain, wherein the digital token comprises encrypted metadata related to an asset and wherein the system comprises:a computing platform;an application programming interface (API); andone or more processors,wherein the one or more processors are configured to execute the method of any of claims 1-22.

Images