Geo-linked token

Abstract

A computer-implemented method involves accessing land-parcel data defining a plurality of land parcels, creating a digital token for each land parcel, and storing the digital tokens in a repository 107. Each digital token (201, fig 2) has an attribute associated with the corresponding land parcel, e.g. GPS coordinates, geocode system address, postcode. A further method involves obtaining a request from a client to create a digital token for a project 101, identifying a land parcel on which the project is located, and searching a repository to determine if a digital token having an attribute associated with the land parcel already exists. If a digital token already exists, the project is linked to the identified digital token. If a digital token does not exist, a new digital token is created which is linked to the project and the client is assigned as the token’s owner. Preferably, the project is a carbon capture or avoidance project and the digital token represents a voluntary carbon credit.

Description

Field The present disclosure relates to a digital token, and computer-implemented methods and a system for creating the digital token. Background The present disclosure relates generally to a digital token, 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. The most widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. One area of current interest and research is the use of blockchain for the implementation of “smart contracts”. These are computer programs designed to automate the execution of the terms of a contract or agreement. Unlike a traditional contract which would be written in natural language, a smart contract is a machine executable program which comprises rules that process inputs in order to produce results, which can then cause actions to be performed dependent upon those results. Another area of blockchain-related interest is the use of digital tokens to represent and transfer real-world entities via the blockchain. The digital token serves as an identifier that allows the real-world entity to be referenced. For example, digital tokens can be used to represent carbon reduction assets, such as voluntary carbon credits (VCC). A voluntary carbon credit (VCC) is a unit of measurement that represents a reduction or removal of greenhouse gas emissions from the atmosphere. These credits are typically generated through projects that aim to mitigate or offset carbon emissions, such as reforestation, renewable energy projects, and methane capture initiatives. 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. Blockchain technology can also play a role in enhancing the security and transparency of land ownership transactions. However, blockchain does not inherently deal with the concept of physical location, it uses standard blockchain protocols i.e., storing as a time series on a distributed ledger. Furthermore, it is well-recognised that geospatial data is hard to index. The present disclosure seeks to overcome the abovediscussed disadvantage. Summary Throughout this specification the word "comprise", or variations such as “includes”, "comprises", or "comprising", will be understood to imply the inclusion of a stated element, integer, step, or group of elements, integers, or steps, but not the exclusion of any other element, integer, step, or group of elements, integers, or steps. In a first aspect, the present disclosure provides a computer-implemented method, comprising: accessing land-parcel data defining a plurality of land parcels; creating a plurality of digital tokens by creating a digital token for each land parcel among the plurality of land parcels, wherein each digital token comprises an attribute associated with the corresponding land parcel; and storing the plurality of digital tokens in a repository. In a second aspect, the present disclosure provides a computer-implemented method, comprising: obtaining a request from a client to associate a project with a land parcel; identifying a respective digital token in the repository that has an attribute associated with the land parcel; and linking the identified digital token with the project. In a third aspect, the present disclosure provides a computer-implemented method, comprising: obtaining a request from a client to create a digital token for a project; identifying a land parcel on which the project is located; searching a repository to determine if a prior digital token having an attribute associated with the land parcel already exists; and based on a determination that a prior digital token does not exist in the repository, creating a new digital token linked to the project and comprising an attribute associated with the land parcel, and assigning the client as a current owner of the new digital token, and optionally wherein the token is minted on a distributed ledger. In a fourth aspect, the present disclosure provides a digital token, comprising an attribute associated with a land parcel. 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 the Figures Embodiments of the present disclosure will now be described with reference to the accompanying drawings, where: Figure 1 is a diagram of a carbon credit cycle. Figure 2 is a diagram of a digital token containing data related to a carbon reduction asset. Figure 3 is a flowchart illustrating the steps of a computer-implemented for creating a geo-linked token. Figure 4 is a flowchart illustrating the steps of a computer-implemented method for assigning an owner to a created digital token. Figure 5 is a flowchart illustrating the steps of a computer-implemented method for creating a project; and a digital token, having an assigned owner, and representing the project. Figure 6 illustrates a node configured to implement Bitcoin software in order to validate a blockchain transaction. Figure 7 illustrates an example of node software run on the node shown in Figure 6. Figure 8 illustrates the blockchain 612 shown in Figure 6. Detailed Description The aspects of the present disclosure as set out in the summary section solves all of the problems associated with the prior art and in particular the problem of using digital tokens in transactions associated with a physical location by providing a unique digital token, which can be minted on a distributed ledger such as blockchain, whereby the indexing relates to physical location rather than the commonly used time series. The subject matter of the disclosure provides further advantageous properties. In particular, the digital token can be recorded and audited in a distributed ledger on a public chain and becomes the single source of truth to prevent “double spend” of land for a project. Additionally, double counting of projects is also prevented. The computer-implemented methods described herein allow for accurate and efficient searching of information related to location-based digital tokens. Preferably, the computer-implemented method further com prises assigning the client as a current owner of the identified digital token. Preferably, the current owner is an owner of the project Preferably, the identified digital token is minted on a distributed ledger. Accordingly, the digital token represents a digital asset that is tradeable on a blockchain-based platform. This can make it easier to trade the digital asset and can also help to increase transparency and traceability in the market. Preferably, the distributed ledger is immutable. Preferably, the distributed ledger is blockchain based. Preferably, the repository includes a public blockchain. Preferably, based on a determination that a prior digital token exists on the distributed ledger, the computer-implemented method further comprises sending a notification to reject the request from the client. This prevents minting of a token for the new project located on a land parcel if a prior digital token having an attribute associated with that land parcel already exists. Accordingly, double counting of projects is prevented. Preferably, identifying the land parcel on which the project is located comprises performing fuzzy matching of locations. Preferably, the attribute comprises: global positioning system (GPS) coordinates, a geocode system address, a street address, or a postcode. Since the location of a project remains a constant throughout the evolution of a project, using geodata to search for a digital token results in faster retrieval of the metadata. Preferably, the digital token represents: a property asset, a smart device, a bond, fractionalised gold, or oil. Preferably, the digital token represents a voluntary carbon credit. 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 voluntary carbon credit can be monitored and regulated via a single platform and provide capabilities for the authentication of a land parcel-based asset by using the attribute associated with the land parcel. Preferably, the project is a carbon capture or avoidance project. Preferably, the attribute comprises one or more types of metadata relating to the land parcel. Having one or more types of metadata aids in searching the repository or public ledger for specific information that may be accessible to a particular user, thereby improving the searching efficiency. Preferably, the attribute includes a link to a file wherein data identifying the land parcel is provided. Preferably, the attribute comprises a field wherein data identifying the land parcel is provided. Preferably, the client is represented by a unique identifier. Preferably, minting the token further comprises generating a transaction, comprising: a transaction input pertaining to a digital signature associated with the current owner; a transaction output related to a quantity of cryptocurrency associated with the attribute; a data output pertaining to the attribute; and a locking script pertaining to at least one cryptographic key associated with the current owner. Advantageously, storing the location-based digital token on a geolocation indexed public ledger and providing access via cryptographic keys allows multiple parties to access some parts of the data while restricting access to more sensitive or private information. Preferably, a system, comprising: one or more processors; and at least one memory storing instructions that, when executed by at least one processor among the one or more processors, cause the at least one processor to perform the computer implemented. Preferably, the at least one processor is associated with a project management service. Preferably, a computer readable storage medium includes instructions that, when executed by a processor, cause the processor to perform the computer implemented. Figure 1 is an overview of the carbon credit cycle. Carbon capture or sequestration projects are built or developed, each at a particular location on the Earth. Each location can be defined by one or more parcels of land in land parcel data such as a geolocation system. For example, project 101 is located on land parcel 102. Project 101 has an owner 103 that is typically a legal person such as a company or individual. Each project generates an amount of carbon credits 104 that may be purchased using money or other value 105 by a carbon emitter 106. Core principles of a high integrity carbon credit system include transparency of information, accountability, and a searchable public registry of projects. Fraud within a carbon credit system is often referred to as double counting, and includes a project being registered more than once and credits being issued or spent more than once. Therefore, any carbon credit system must be robust enough to prevent double counting of projects, preferably without onerous oversight by humans. Digital tokens, which include information about project 101 and other carbon capture projects, are stored in repository 107. Each digital token in repository 107 comprises an attribute associated with a unique land parcel. In the embodiment described herein, the repository includes a public blockchain, which can be used to create an immutable and searchable repository. However, other suitable repositories could be used. Figure 2 shows a high-level representation of a digital token protocol 200 used to implement a digital token 201 representing project 101. Protocol 200 has a number of conceptual data layers for storing information, including a base layer 210, a digital addressing layer 220, a volumetric unit layer 230, an asset layer 240, and an enrichment layer 250. Base layer 210 is in this embodiment implemented on a public blockchain. In the example described herein, the digital tokens are minted on the Bitcoin blockchain, but the disclosure is not limited to any particular blockchain. Base layer 210 includes a geolocation attribute 211 relating to the land parcel 102 on which project 101 is situated, and an owner identifier 212 relating to the owner 103 of project 101. Thus a digital token comprises an attribute associated with a land parcel and is linked to a project owner, thus creating an association between the project and the land parcel. Digital addressing layer 220 optionally includes an IP address 221 and a digital wallet address 222 to identify the owner of the token. Volumetric unit layer 230 includes an amount 231 of carbon removed by project 101 .This may be stored in the token or may be a link to off-chain storage. Asset layer 240 includes categorisation information 241 about the project, for example as a biological or mechanical carbon capture project. Enrichment layer 250 includes metadata 251 that can be used to store any other information about the project or the digital token. The disclosure described herein is not limited to minting tokens representing voluntary carbon credits but is applicable to any asset that has a geolocation. Examples include a property asset, a bond, fractionalised gold, oil, an insurance asset, and so on. The system could be used to store data for a smart city, which would have a large number of smart devices each having a location. In each case, the disclosure makes it possible to provide an automated, publicly searchable and immutable database of assets having locations. Geolocation attribute 211 may comprise or link to any type of location data capable of digital representation of a parcel of land. In the embodiment described herein, a geocode system is used that divides the surface of the Earth into identically-sized land parcels and attaches an identifier to each parcel. A suitable system is what3words®, which allocates a three-word identifier to every 3-metre-square location on the Earth. Other geolocation information could be used to define the land parcels, such as longitude-latitude coordinates, GPS coordinates, or components of a postal address such as a street address or postcode. Geolocation attribute 211 may comprise the location data, stored for example as metadata, or may be a link to location data stored off-chain. Each digital token must be associated with a unique land parcel, since only one project may be physically located on the land parcel. This avoids double counting, where two projects may be registered for the same location, or the same project may be registered twice. A project may be physically located on more than one land parcel, in which case the project must be associated with all the land parcels to avoid the possibility of double counting. Therefore, a plurality of digital tokens, each having an attribute associated with a different land parcel, may be linked with a single project. In alternative embodiments, attribute 211 may indicate a plurality of land parcels, or may indicate a single land parcel but include a link to information associating it with a plurality of other parcels. Owner identifier 212 is in this embodiment a company registration number or a Legal Entity Identifier (LEI) but could be any type of identifier. In other embodiments, the owner may not be a legal person, depending on the type of asset represented by the token. For example, the owner of a smart device could be a smart city. As an implementation example, digital token 201 is minted as a transaction on the Bitcoin Satoshi Vision (Bitcoin SV) blockchain, which is an Unspent Transaction Output (UTXO) based blockchain. The transaction includes a transaction input pertaining to a digital signature of the current owner, a transaction output related to a quantity of cryptocurrency, a data output including geolocation attribute 211, and a locking script pertaining to at least one cryptographic key associated with the current owner. The transaction output may include an output address or wallet 222. In other embodiments, the tokens may be minted on other blockchains such as: Bitcoin (BTC) or Bitcoin Cash (BCH), which are also UTXO-based blockchains. Alternatively, the tokens may be minted on Ethereum, which is an account based blockchain platform. Minting refers to the creation of new tokens or assets on a blockchain. Digital tokens are minted through a process specific to the blockchain or platform they are associated with. The process may vary depending on whether the tokens are fungible (like cryptocurrencies e.g., Bitcoin and Ethereum) or non-fungible (like unique digital assets e.g., a voluntary carbon credit). The minting process for fungible tokens is often based on consensus mechanisms such as Proof of Work (PoW) or Proof of Stake (PoS). Non-fungible tokens (NFTs) are typically minted on platforms that support the Ethereum blockchain, which uses the ERC-721 or ERC-1155 token standards for NFTs. The minting process for NFTs involves creating a new token with unique metadata that defines its properties and attributes. For example, NFTs can be created through smart contracts on the blockchain. Such smart contracts define the rules for ownership, transfer, and interaction with the NFT. When a user wants to mint an NFT, they initiate a transaction with the smart contract and provide the necessary metadata and properties for the NFT. The metadata associated with an NFT includes information about the digital asset, such as its title, description, image, and any other relevant attributes. This metadata may be stored off-chain (outside the blockchain) due to the limited storage capacity of blockchain networks. In a first example of the first embodiment, a token is pre-created for every land parcel in the land parcel data, but is not yet minted or submitted to the blockchain. In a second example of the first embodiment, a token is pre-minted for every land parcel in the land parcel data. The owner of a project may then request that one or more of these tokens be associated with their project. In the second embodiment, tokens are created and / or minted on request by the owner of a project. The creation of the tokens according to the first embodiment may be associated with one or more processors associated with a platform or service provider system for managing projects for one or more land parcels. Creating the tokens in the first embodiment is shown in Figure 3. At step 301, land-parcel data defining a plurality of land parcels is accessed, and at step 302 a digital token is created for each land parcel. The new token may be created using one or more smart contracts or software protocols. The created tokens can be used for transactions or investments associated with a given project on the blockchain. While minting tokens through minting does not involve the use of a significant amount of energy or computational work, there are transaction fees associated with such minting. At step 303, the geolocation attribute 211 is updated to include or refer to the land parcel, and at step 304 the plurality of digital tokens are stored in repository 207. In a first example, this may be an off-block repository where the tokens are held / stored until minting on the blockchain occurs. In a second example, step 304 includes minting the created token, the minting being associated with one or more processors of the platform or service provider, i.e., via a digital wallet associated with the entity responsible for creating the tokens. Figure 4 shows steps carried out to link a project with a land parcel. This may be carried out by the same entity as the steps in Figure 3, such as a platform processor, or may be carried out by a different entity. Until this point, the digital token refers only to a location, and does not include any information about a project or any carbon credits., i.e., the digital token does not have a project owner associated with it, for example. Upon receiving a request at step 401 from a client to associate a project with a land parcel, a digital token is identified that has a geolocation attribute 211 associated with that land parcel. At step 403 a question is asked as to whether that token is available, and if it is answered in the negative then a notification rejecting the request is returned to the client at step 404, to the effect that the land parcel is already occupied or is associated with a project owner, and the ownership of such a token can change only upon a successful transfer of ownership. For a UTXO blockchain, this means successfully spending an output of a transaction associated with the token. If it is answered in the affirmative, then at step 405 the identifier 212 is updated to indicate the client, or another entity identified by the client as the owner for a project associated with the land parcel. Ownership of a token may be transferred using Bitcoin transactions and scripting mechanisms. Examples include: P2PKH (Pay-to-Public-Key-Hash); P2SH (Pay-to-Script-Hash); and SIG HASH OP RETURN. P2PKH is a common type of Bitcoin transaction where funds are sent to a recipient’s public key hash. The recipient can spend these funds by proving ownership of the corresponding private key. P2SH is another Bitcoin transaction type that allows the recipient to define a more complex spending condition using a redeem script. This script is hashed, and the hash is used as the recipient’s address. The OP_RETURN opcode is used to embed arbitrary data directly into a transaction’s output, and is often used for purposes like attaching metadata or proof of existence to the blockchain. Actual transactions will involve inputs that reference previous transaction outputs, digital signatures, and other necessary elements for the transaction to be valid on the Bitcoin blockchain. In the first example, where the token is created but not yet minted, following step 405 the token is minted on the blockchain via a first blockchain transaction. This step may be performed by the one or more processors of the platform provider. However, in the alternative, it is expected that said minting is carried out by a device associated with the client, such as a digital wallet. This may be a preferred as the transaction fee associated with minting is the responsibility of the client for the respective digital token it has ownership of. In the second example, where there all digital tokens associated with land parcels are already minted, a second blockchain transaction is generated to assign, update or transfer the ownership of the pre-minted token to the owner or client requesting the project associated with the given land parcel. The updated details associated with the token may then be stored in the repository again at step 406, or updated metadata may be available in a data output such as an OPRETURN. The client is then able to populate other layers of the digital token. Alternatively, a degree of auto-tagging may be used to populate the metadata. The second embodiment is shown in Figure 5. Again this may be may be associated with one or more processors associated with a platform or service provider system for managing projects for one or more land parcels. At step 501, a request is received from a client to create a VCC digital token. At step 502 a land parcel on which the project is located is obtained, possibly from the request or from a further data-collection exercise. At step 503 the repository is searched to determine if a digital token associated with the land parcel exists. A degree of fuzzy searching may be used, given that projects may occupy more than one land parcel, and locations may be overlapping but not coterminous. In the example described herein, searching the repository involves searching the Bitcoin blockchain by a known method or crawlers. A question is then asked at step 504 as to whether a prior digital token has been found. If this question is answered in the negative then at step 505 a new digital token is created, in the same way as at step 302 except that the owner is included and potentially data in other layers of the token. At step 506 the digital token is stored in the repository, which in this example involves submitting the transaction created at step 505 to the blockchain. Alternatively, if a prior digital token is found, then a notification rejecting the request is sent to the client at step 507 and no digital token is created. Thus, in both embodiments, a client is prevented from creating a VCC digital token for a land parcel that is already associated with a carbon capture project, thus preventing double counting of projects. In order for the owner of a token to be changed, a transferring blockchain transaction must include cryptographic information sufficient to unlock the previous blockchain transaction in order for the ownership of the token to be changed, such as by proving ownership of the private key corresponding to the public key included in the previous transaction, as discussed above. Therefore using a blockchain or other immutable distributed ledger as the base layer for the digital token provides a public and searchable repository of the tokens, while preventing unauthorised changes to the tokens. However, the owner of a token cannot alter the geolocation attribute in the token. This can only be done by submitting a request as described in Figure 4, or by destroying the token and reminting it. Thus the system does not allow two tokens to identify the same land parcel, thereby preventing double counting. Figure 6 shows a system 600 which enables a transfer of an asset between a first user and second user of the system 600 to be recorded. System 600 comprises first computing device 602 and second computing device 604. First computing device 602 and second computing device 604 may be any computing resource. Each of first computing device 602 and second computing device 604 are configured to interact with payment processing resource 606 that includes a Payment Protocol Module 620 via respective first and second application programming interfaces (API) 608a and 608b. The payment processing resource 606 is configured to initialise and / or interact with event streams provided in respect of at least each of a first user 610a, a second user 610b, and a payment processing resource 610c using the event stream resource 610. It is connected to a key storage module 622 and a payment data store 624. The payment processing resource 606 is further configured to interact with the blockchain 612. The blockchain 612 may comprise at least one public proof-of-work blockchain in accordance with the Bitcoin Satoshi Vision (BSV) protocol in that it is an append-only ledger of blocks (BSV1, BSV2, BSV3) which are made up of transactions. The blockchain 612 comprises a plurality of nodes 626 configured by the software which is now described in relation to Figure 7. Each node is configured in accordance with this software as part of the blockchain as described below in relation to Figure 8. Figure 7 illustrates an example of the node software 701 that is run on each blockchain node 626 of a network, in the example of a UTXO- or output-based model. Note that another entity may run node software 701 without being classed as a node on the network, i.e., without performing the actions required of a node. The node software 701 may contain, but is not limited to, a protocol engine 702, a script engine 703, a stack 704, an application-level decision engine 705, and a set of one or more blockchain-related functional modules 706. Each node may run node software that contains, but is not limited to, all three of: a consensus module 706C (for example, proof-of-work), a propagation module 706P and a storage module 706S (for example, a database). The protocol engine 702 is typically configured to recognize the different fields of a transaction 852 (shown in Figure 8) and process them in accordance with the node protocol. When a transaction 852j ^Xj) is received having an input pointing to an output (e.g. UTXO) of another, preceding transaction 852i (Txm^), then the protocol engine 702 identifies the unlocking script in Txj and passes it to the script engine 703. The protocol engine 702 also identifies and retrieves Txt based on the pointer in the input of Txj. Txt may be published on the blockchain 612, in which case the protocol engine may retrieve Txt from a copy of a block 851 of the blockchain 612 stored at the node 126. Alternatively, Txt may yet to have been published on the blockchain 150. In that case, the protocol engine 451 may retrieve Txt from the ordered set 154 of unpublished transactions maintained by the node 126. Either way, the protocol engine 702 identifies the locking script in the referenced output of Txt and passes this to the script engine 703. The script engine 703 thus has the locking script of Txt and the unlocking script from the corresponding input of Txj. The script engine 703 runs the two scripts together as discussed previously, which will include placing data onto and retrieving data from the stack 704 in accordance with the stack-based scripting language being used (e.g. Script). By running the scripts together, the script engine 703 determines whether or not the unlocking script meets the one or more criteria defined in the locking script -i.e. does it “unlock” the output in which the locking script is included? The script engine 703 returns a result of this determination to the protocol engine 702. If the script engine 703 determines that the unlocking script does meet the one or more criteria specified in the corresponding locking script, then it returns the result “true”. Otherwise it returns the result “false”. In an output-based model, the result “true” from the script engine 703 is one of the conditions for validity of the transaction. Typically there are also one or more further, protocol-level conditions evaluated by the protocol engine 702 that must be met as well; such as that the total amount of digital asset specified in the output(s) of Txj does not exceed the total amount pointed to by its inputs, and that the pointed-to output of Tx, has not already been spent by another valid transaction. The protocol engine 702 evaluates the result from the script engine 703 together with the one or more protocol-level conditions, and only if they are all true does it validate the transaction Txj. The protocol engine 702 outputs an indication of whether the transaction is valid to the application-level decision engine 705. Only on condition that Txj is indeed validated, the decision engine 705 may select to control both of the consensus module 706C and the propagation module 706P to perform their respective blockchain-related function in respect of Txj. This comprises the consensus module 706C adding Tx} to the node’s respective ordered set of transactions 854 for incorporating in a block 851, and the propagation module 706P forwarding Tx} to another blockchain node 826 in the network 106. Optionally, in embodiments the application-level decision engine 705 may apply one or more additional conditions before triggering either or both of these functions; e.g. the decision engine may only select to publish the transaction on condition that the transaction is both valid and leaves enough of a transaction fee. Note also that the terms “true” and “false” herein do not necessarily limit to returning a result represented in the form of only a single binary digit (bit), though that is certainly one possible implementation. More generally, “true” can refer to any state indicative of a successful or affirmative outcome, and “false” can refer to any state indicative of an unsuccessful or non-affirmative outcome. For instance, in an accountbased model, a result of “true” could be indicated by a combination of an implicit, protocol-level validation of a signature and an additional affirmative output of a smart contract (the overall result being deemed to signal true if both individual outcomes are true). Some embodiments above have been described in terms of a bitcoin network, bitcoin blockchain, and bitcoin nodes. However, it will be appreciated that the bitcoin blockchain is one particular example of a blockchain and the above description may apply generally to any distributed ledger. That is, the present disclosure is in by no way limited to the bitcoin blockchain. In preferred embodiments of the disclosure, the blockchain network is the Bitcoin SV network and Bitcoin SV nodes perform at least all of the described functions of creating, publishing, propagating and storing blocks of the blockchain. It is not excluded that there may be other network entities (or network elements) that only perform one or some but not all of these functions. That is, a network entity may perform the function of propagating and / or storing blocks without creating and publishing blocks. In non-preferred embodiments of the disclosure, the blockchain network may not be the Bitcoin SV network. In these embodiments, it is not excluded that a node may perform at least one or some but not all of the functions of creating, publishing, propagating and storing blocks of the blockchain. For instance, on those other blockchain networks a “node” may be used to refer to a network entity that is configured to create and publish blocks but not store and / or propagate those blocks to other nodes. Even more generally, any reference to the term “bitcoin node” above may be replaced with the term “network entity” or “network element”, wherein such an entity / element is configured to perform some or all of the roles of creating, publishing, propagating and storing blocks. 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, comprising:accessing land-parcel data defining a plurality of land parcels;creating a plurality of digital tokens by creating a digital token for each land parcel among the plurality of land parcels, whereineach digital token comprises an attribute associated with the corresponding land parcel; andstoring the plurality of digital tokens in a repository.

2. A computer-implemented method, comprising:obtaining a request from a client to associate a project with a land parcel;identifying a respective digital token in a repository that comprises an attribute associated with the land parcel; andlinking the identified digital token with the project.

3. A computer-implemented method according to claim 2, further comprising assigning the client as a current owner of the identified digital token.

4. A computer-implemented method according to claim 3, wherein the current owner is an owner of the project.

5. A computer-implemented method, comprising:obtaining a request from a client to create a digital token for a project;identifying a land parcel on which the project is located;searching a repository to determine if a prior digital token having an attribute associated with the land parcel already exists; andbased on a determination that a prior digital token does not exist in the repository, creating a new digital token linked to the project and comprising an attribute associated with the land parcel, and assigning the client as a current owner of the new digital token, and optionally wherein the token is minted on a distributed ledger.aa6. A computer-implemented method according to claim 5, wherein based on a determination that such a digital token already exists on the distributed ledger, sending a notification to reject the request from the client.

7. A computer-implemented method according to claim 5 or claim 6, wherein identifying the land parcel on which the project is located comprises performing fuzzy matching of locations.

8. A computer-implemented method according to any preceding claim, wherein the digital token is minted on a distributed ledger.

9. A computer-implemented method according to claim 8, wherein the distributed ledger is immutable.

10. A computer implemented method according to either of claims 8 or 9, wherein the distributed ledger is blockchain based.

11. A computer-implemented method according to any previous claim, wherein the repository includes a public blockchain.

12. A computer-implemented method according to any previous claim, wherein the attribute comprises:global positioning system (GPS) coordinates, a geocode system address, a street address, or a postcode.

13. A computer-implemented method according to any previous claim, wherein the digital token represents:a property asset, a smart device, a bond, fractionalised gold, or oil.

14. A computer-implemented method according to any previous claim, wherein the digital token represents a voluntary carbon credit.

15. A computer-implemented method according to claim 14, wherein the project is a carbon capture or avoidance project.

16. A computer-implemented method according to any previous claim, wherein the attribute comprises one or more types of metadata relating to the land parcel.

17. A computer-implemented method according to any previous claim, wherein the attribute includes a link to a file wherein data identifying the land parcel is provided.

18. A computer-implemented method according to any of claims 1-16, wherein the attribute comprises a field wherein data identifying the land parcel is provided.

19. A computer-implemented method according to any of claims 2-18, wherein the client is represented by a unique identifier.

20. A computer-implemented method according to any of claims 6-21, wherein minting the token further comprises:generating a transaction, comprising:a transaction input pertaining to a digital signature associated with the current owner;a transaction output related to a quantity of cryptocurrency associated with the attribute;a data output pertaining to the attribute; anda locking script pertaining to at least one cryptographic key associated with the current owner.

21. A system, comprising:one or more processors; andat least one memory storing instructions that, when executed by at least one processor among the one or more processors, cause the at least one processor to perform the method of any previous claim.

22. The system of claim 21 when dependent on claim 5, wherein the at least one processor is associated with a project management service.

23. A computer readable storage medium including instructions that, when executed by a processor, cause the processor to perform the method of any of claims 1-20.5 24. A digital token, comprising an attribute associated with a land parcel.

25. A digital token according to claim 24, further comprising an identifier identifying a current owner of the digital token.

Images