TW202414305A - Method and system for trading assets and their carbon footprint status - Google Patents

Abstract

The present application relates to systems and methods for trading assets taking into account carbon footprint of assets. The system is configured to allow a party to obtain carbon emission certificates and carbon emission redemption certificates from an offsetting activity in a country, and uses these to create a non fungible digital twin representing the offsetting activity which comprises a time series of emission reduction smart contracts on a blockchain which are used to generate carbon neutrality tokens based on the amount of carbon emission reductions which can then be traded in any country. Similarly an asset holder can create a Non-Fungible Digital Twin (NFDT) representing the offsetting activity which comprises a time series of asset smart contracts on a blockchain which capture the carbon footprint of the asset over time. A trading exchange is configured to allow listing of assets and trading of carbon neutrality tokens, and includes a ledger to track the carbon neutrality status of listing entities and investor portfolios.

Description

Method and system for trading assets and their carbon footprint status

This application relates to asset trading, and more particularly, to systems and methods for global trading of carbon emission reduction credits and assets taking into account the carbon footprint of the carbon emission reduction credits and assets.

Carbon taxation and carbon trading are currently the main mechanisms used for global carbon pricing and emission reduction; however, there is still a huge gap between the goals of effective carbon transfer, carbon emission reduction and carbon pricing between countries and organizations proposed in the Paris Agreement.

There are many problems in the current carbon trading market, such as lack of information transparency: companies are reluctant to disclose information such as carbon emissions, total carbon quotas, carbon credit plans and transaction data, information asymmetry between trading entities, and lack of information transparency in the carbon trading market; fragmentation of participation: there is no mature linkage mechanism between countries and regions around the world, and various actors involved in carbon emissions, carbon absorption and carbon offsets, such as governments, manufacturing companies, environmental organizations, individual consumers and non-profit organizations, are separated and disconnected from each other. There is a unified interactive platform and mechanism; low marketization: the current carbon reduction policies and carbon emission trading mechanisms of governments around the world are based on the agreement reached under the Kyoto Protocol, which are more administrative actions, with a low degree of marketization, unable to organize the effective participation of consumers and individuals, and unable to achieve interconnection and communication between social individuals; lack of individual participation awareness and participation mechanism: consumption is an important source of carbon emissions, but most individual consumers lack awareness of their personal carbon reduction responsibilities and do not have a feasible participation mechanism.

Specifically, in the existing carbon trading system, the government's carbon policy, especially in the issuance of carbon quotas, is the cornerstone of the carbon market and carbon pricing. However, the pre-establishment of the total amount of carbon quotas forms a conditional supply and demand relationship, which is difficult to adapt to changes in demand caused by economic fluctuations (Chevallier, Pen and Sevi, 2011, Option introduction and volatility in the EU ETS. Resource and Energy Economics, 33(4), 855-880), and may even be strongly biased towards carbon emitting entities (Breetz, Mildenberger and Stokes, 2018, The Political Logics of Clean Energy Transitions. Business and Politics, 20(4), 492-522). Excessive reliance on policies leads to the inflexibility of the timing and reverse adjustment mechanism, and seriously affects the effective market-based carbon pricing.

One of the most important challenges facing the current global carbon trading market is that it is highly fragmented and lacks an effective cross-border trading mechanism to form a global carbon trading system. In theory, carbon emissions are a global problem faced by all parties on the planet, and therefore a global trading system for carbon quotas or carbon voluntary reductions should be formed and well controlled to solve this problem. However, National Determined Contributions ("NDCs") specify each country's contribution to carbon reduction, and therefore unfortunately create the problem of "autonomous ownership" of any carbon reduction work (including voluntary reductions) when each specific country attempts to meet its own NDC target. This makes the free transfer of carbon reduction credits across borders impractical, which is ironic because carbon should be a global issue and should be handled on a global scale. Article 6 of the Paris Agreement aims to address this issue by establishing a cross-border and global trading system for carbon emission reduction credits. However, to date, Article 6 of the Paris Agreement is still being negotiated between the world's major powers, and therefore global stakeholders are in a waiting mode for further negotiations and, hopefully, final ratification of Article 6 of the Paris Agreement. As a result, this raises issues associated with the separation of participants and the lack of a firmly established linkage mechanism across national and global regions. As outlined above, carbon allowances are issued on a national or regional basis, and their allocation and compliance are based on carbon emissions generated by emission-controlled companies, without taking into account carbon emissions transferred abroad via products or services (transferred carbon emissions). For example, some studies show that 15-23% of China’s carbon emissions come from production to meet demand for products and services in developed economies, and that China’s carbon responsibility based on domestic consumption is much lower than its carbon responsibility based on production (Li, Xu, Wang, Zhang, & Yu, 2020, Industrial path analysis for CO2 transfers induced by final consumption: A comparison of the United States and China. Journal of Cleaner Production, 251, doi.org/10.1016/j.jclepro.2019.119604; Zhang & Peng, 2016, Analysis on CO2 Emissions Transferred from Developed Economies to China through Trade. China & World Economy, 24(2), 68-69). Although the international carbon credit mechanism allows international trading of emission rights, it cannot effectively track and price all transferred carbon emissions, and often results in non-counting or double counting. At the same time, high-emission companies transfer their production capacity to countries and regions with more moderate quota and carbon tax policies, thus generating the "carbon leakage" problem (CEPS, 2014, Carbon Leakage: Options for the EU). Monitoring the path and scale of regional and international carbon emission transfers and incorporating them into policies related to carbon trading and carbon pricing will be the basis for more effective carbon pricing.

Since high-emission industries and companies (e.g., thermal power, cement, and steel) are the main actors in carbon emission quota allocation and compliance supervision, the cost of proactive emission reduction is first borne by these entities and then passed on to downstream industries and end consumers. On the one hand, depending on the competitive market position of the energy or products provided by emission-control companies, passing on the cost of carbon emission reduction by raising product prices may cause companies to lose market share in competition with international competitors with lower carbon intensity or more moderate carbon emission reduction policies (Aldy and Pizer, 2015; Fowlie, Regaunt, and Ryan, Market-Based Emissions Regulation and Industry Dynamics. Journal of Political Economy, 124(1), 249-302). On the other hand, when emission allowances are issued in excess, companies may profit from the zero cost of the allowances, while this part of the carbon cost cannot be passed on to downstream.

There is also a disconnect between carbon reduction in the consumer sector and the carbon market. Consumption is an important source of carbon emissions. UNEP estimates that consumption-related carbon emissions, including those associated with household use of products and services, account for 65-72% of global carbon emissions (UNEP, 2020, 2020 Emissions Gap Report). To meet the climate goals set out in the Paris Agreement, carbon emissions in the consumer sector need to be reduced from the current level of more than 3 tCO2e per capita to 0.7 tCO2e per capita by 2050 (UNEP, 2020). In the consumer (or consumption) sector, changing consumption behavior through the Avoid-Shift-Improve (ASI) approach has the potential to produce huge emission reductions. By improving travel, food and residential energy use, per capita emissions are expected to be reduced by 3 tCO2e. In developed countries with high carbon footprints, this reduction potential is as high as 15 tCO2e per capita (Ivanova et al., 2020, Quantifying the potential for climate change mitigation of consumption options. 15(9), doi. org/10.1088/1748-9326/ab8589). However, the existing carbon trading market is mainly focused on emission control in high-emission industries and carbon credit trading for large and medium-sized emission reduction projects. In the consumer consumption area where per capita consumption is small but the total amount of carbon neutrality is huge, there is a lack of efficient decentralized mechanisms that can enable participation in carbon trading and form consumption habits that respond quickly and reward ASI.

It is also difficult for investors to assess the carbon status of the companies they wish to invest in (e.g., investing in companies that reduce or offset their emissions). Currently, major exchanges including the London Stock Exchange, the New York Stock Exchange, Nasdaq and the Hong Kong Exchanges and Clearing Limited require listed companies to follow international standards such as the Carbon Disclosure Project (CDP), the Climate Disclosure Standards Board (CDSB), GRI, SASB and TCFD for mandatory or semi-mandatory disclosure of environment, social and governance (ESG) and other non-financial indicators. According to GRI or similar standards, disclosure of environmental components usually needs to include direct and indirect _CO2 emissions or _CO2 equivalents from other greenhouse gas emissions from the company's production activities and energy consumption. Companies are also encouraged to disclose the carbon offset results of their carbon offset activities in terms of direct _CO2 or _CO2 equivalent of other greenhouse gas emissions during the reporting period.

Corporate carbon emissions and carbon offsets are usually disclosed in the trading market in the form of social responsibility reports or ESG reports for a specific reporting period (usually annually); however, investors must relate ESG indices to the financial returns of assets on a more macro scale to build their ESG investment strategies and asset portfolios, and cannot instantly and quantitatively grasp the ESG attributes and economic value of the assets they trade and hold. Therefore, it is currently difficult for investors to use this information or instantly grasp the economic value of the assets they trade and hold.

In summary, the current carbon trading market has a high entry threshold, it is difficult for investors to assess the carbon status of their investments, it is difficult for consumers to participate, and there are many restrictions. In particular, the current ESG reporting requirements lack information transparency, and many companies are reluctant to disclose all relevant information about carbon emissions, emission quotas, quota plans, and trading data. Participants are scattered, and there is no firmly established cross-national and global regional linkage mechanism (that is, there is no effective cross-border trading mechanism). The marketization level is low, and carbon reduction policies and carbon emission trading mechanisms are promoted by the government, and consumers are not encouraged to participate. For most consumers, there is insufficient awareness of how to contribute to carbon emission reduction, and there is no feasible participation mechanism. In addition, it is difficult for investors to identify the carbon status of a company, and therefore encourages investment in carbon-neutral companies. Based on the current rules and status of the carbon trading market, it is difficult to quickly achieve the global carbon emission reduction targets set internationally.

Therefore, there is a need to provide improved systems and methods for efficiently conducting global trading of carbon emission reduction credits and assets while taking into account their carbon footprint, or at least to provide useful alternatives to existing markets and systems.

According to the first aspect of this application, a method for generating a plurality of carbon neutral tokens representing carbon offset actions for trading is provided, which comprises: Obtaining a carbon emission reduction certificate and a carbon emission redemption certificate associated with a carbon offset action that generates a carbon emission reduction from an issuing authority in a country, wherein the carbon emission reduction is verified by a third-party verification authority or the issuing authority, and the redemption certificate prevents further trading of the carbon emission reduction certificate in the country; Placing the carbon emission redemption certificate in a regulatory agency to prevent further trading or use of the carbon emission reduction certificate; Generate an information package and store it at a reporting address, wherein the information package at least includes the carbon emission reduction, the carbon emission reduction certificate, the redemption certificate and information about the carbon offset action; Cryptographically sign the information package and obtain a hash for authenticating the information package; Input at least an owner address, an identifier, the carbon emission reduction, the reporting address and the hash of the information package into an emission reduction smart contract in a blockchain, wherein once published on the blockchain, the emission reduction smart contract defines a birth smart contract, and the submitted information is stored on the blockchain at a birth smart contract address; Using the birth smart contract and the carbon emission reduction contained therein to obtain a plurality of carbon neutrality tokens (CNT) by executing a CNT smart contract on the blockchain, wherein the amount of carbon neutrality tokens issued is determined from the carbon emission reduction in the birth smart contract; Storing the plurality of CNTs; Selling one or more of the plurality of CNTs for trading; Publish a plurality of smart emission reduction contracts on the blockchain, wherein each smart emission reduction contract is published at a different time, and each smart emission reduction contract after the birth smart contract includes an additional carbon emission reduction since the publication of the previous smart emission reduction contract and a link to one or more of the previous smart emission reduction contracts published on the blockchain including the birth smart contract, wherein the birth smart contract and the plurality of smart emission reduction contracts form a time series of smart emission reduction contracts, which defines a unique non-fungible digital twin (NFDT) representing the offset action, and If the additional carbon emission reduction in one of the plurality of smart emission reduction contracts is positive, then Using the respective emission reduction smart contract to obtain an additional plurality of carbon neutral tokens (CNTs) by executing a CNT smart contract on the blockchain, wherein the amount of carbon neutral tokens issued is determined from the carbon emission reduction amount in the respective emission reduction smart contract; Storing the additional plurality of CNTs; and Selling one or more of the additional plurality of CNTs for trading.

In one form, for each of the plurality of smart emission reduction contracts, the method further comprises: Obtaining from the issuing authority in the country a subsequent carbon emission reduction certificate and a subsequent carbon emission redemption certificate associated with the carbon offset action that produced the additional carbon emission reduction, wherein the additional carbon emission reduction is verified by a third-party verification authority or the issuing authority, and the subsequent redemption certificate prevents further trading of the carbon emission reduction certificate in the country; Placing the subsequent carbon emission redemption certificate in the regulatory agency to prevent further trading or use of the subsequent carbon emission reduction certificate; Generate a subsequent information package and store it at a subsequent reporting address, wherein the subsequent information package at least includes the additional carbon emission reduction, the subsequent carbon emission reduction certificate and the subsequent redemption certificate; Cryptographically sign the subsequent information package and obtain a subsequent hash for authenticating the subsequent information package; and At least the owner address, the identifier, the additional carbon emission reduction, the subsequent reporting address and the subsequent hash of the subsequent information package are input into the smart emission reduction contract in the blockchain, wherein once published on the blockchain, the smart emission reduction contract forms a subsequent smart emission reduction contract of the NFDT, and the submitted information is stored on the blockchain at a subsequent smart contract address.

In one form, the one or more of the plurality of CNTs are sold for trading outside of the country that issued the carbon emission reduction certificate.

In one form, the CNTs are offered for trading on a digital asset exchange, the digital asset exchange maintains a ledger of CNTs for trading on the digital asset exchange, and the plurality of CNTs are stored in a cold wallet associated with the digital asset exchange.

In another form, the digital asset exchange includes a plurality of listings, wherein each listing is a digital representation of an asset that can be traded on the digital asset exchange by an issuing entity, and the ledger stores a carbon footprint attribute value for each listed asset.

In another form, an issuing entity of an asset having a carbon offsetting action establishes a NFDT on the digital asset exchange to represent the asset associated with a carbon offsetting action, and lists a plurality of asset-backed tokens, each of which has a zero carbon footprint attribute value representing a financial and/or operating profile of the asset and a plurality of CNTs generated as a result of the carbon offsetting action; An issuing entity of an asset that generates carbon emissions establishes a NFDT on the digital asset exchange to represent the asset that generates such carbon emissions, and lists a plurality of asset-backed tokens, each of which has a negative carbon footprint attribute value attributable to the carbon emissions associated with the asset, wherein the carbon footprint attribute value is updated on the ledger as additional carbon emissions data is obtained over time, The carbon footprint attribute value of each listed item traded on the digital asset exchange is tracked via the ledger of the digital asset exchange, and the digital asset exchange is configured to provide an investor of the digital asset exchange who holds a portfolio on the exchange with a portfolio value of the portfolio and a carbon footprint attribute value of the portfolio obtained by summing the carbon footprint attribute values of each investment in the portfolio.

In another form, each listed item further includes one or more environmental, social and governance (ESG) metrics, and the ledger tracks each of the one or more ESG metrics for each listed item, and the digital asset exchange is configured to provide an investor in the digital asset exchange with an overview of each of the one or more ESG metrics obtained by summing each of the one or more ESG metrics for each investment in the portfolio.

In another form, the CNTs are offered for trading on the digital asset exchange as part of a package with one or more of the plurality of listed items to offset the carbon footprint attribute value of the respective one or more assets associated with the one or more listed items.

In one form, the method further comprises permanently freezing one or more of the plurality of CNTs to achieve carbon neutrality of a neutralizing asset, comprising: Purchasing a CNT neutralization amount on the exchange by a first entity; Submitting a neutralization information package to the digital asset exchange by the first entity, the neutralization information package comprising at least information about: the neutralizing asset to be neutralized, a certification of a carbon footprint of the neutralizing asset obtained from a third-party verification authority, and the purchased CNT neutralization amount to be used to offset the carbon footprint; Removing the purchased CNTs from transactions on the digital exchange and removing the first entity's entry from the ledger; The digital asset exchange cryptographically signs the neutralization information package and obtains a neutralization hash for authenticating the neutralization information package; Establishes a node on a public carbon neutrality blockchain, the node including an address of the neutralization information package, the neutralization hash, and a record indicating that the purchased CNT is permanently frozen; and Issues a neutralization certificate linked to the node by the digital asset exchange.

In one form, the method further comprises collecting carbon offset data from the carbon offset action, and submitting the carbon emission data to the third-party verification authority to obtain verification of the carbon emission reduction.

In another form, the carbon offset data is obtained using a secure data acquisition system comprising a plurality of hardware and software components configured to securely collect and store the carbon offset data.

In one form, the blockchain is an Ethereum blockchain, and the emission reduction smart contract is based on the ERC721 standard, and the CNT smart contract is based on the ERC20 standard.

In one form, the report address is a Uniform Resource Identifier (URI) address or a Uniform Resource Locator (URL) address.

In one form, the plurality of CNTs are stored in a cold wallet for use in a closed regulatory facility or on a public blockchain.

According to the second aspect of this application, a method for generating a digital representation of an asset for trading is provided, which includes: Calculating a carbon footprint attribute value of an asset based on a preset standard or based on carbon emission related data provided by an asset holder; Obtaining a verification certificate from a third-party verification authority that verifies the carbon footprint attribute value of the asset, Generating an information package and storing it at a reporting address, wherein the information package at least includes the carbon footprint attribute value, the verification certificate and information about the carbon footprint of the asset and financial and/or operational information of the asset; Cryptographically signing the information package and obtaining a hash for authenticating the information package; Inputting at least the hash of an asset owner address, an identifier, the carbon footprint attribute value, the reporting address, and the information package into an asset smart contract on a blockchain, wherein once published on the blockchain, the asset smart contract defines a birth smart contract and the submitted information is stored on the blockchain at the birth smart contract address; Listing the asset for trading; Storing the carbon footprint attribute value associated with the asset in a ledger; and A plurality of asset smart contracts are published on the blockchain, wherein each asset smart contract is published at a different time, and each asset smart contract after the birth smart contract includes an additional carbon emission amount since the issuance of the previous asset smart contract and a link to one or more of the previous asset smart contracts published on the blockchain including the birth smart contract, wherein the birth smart contract and the plurality of asset smart contracts form a time series of emission reduction smart contracts that define a unique non-fungible digital twin (NFDT) representation of the asset, and after the issuance of the additional asset smart contract, the carbon footprint attribute value associated with the asset in the ledger is updated based on the additional carbon emission amount.

In one form, the asset is listed for trading on a digital asset exchange, wherein the digital asset exchange includes the ledger.

In one form, if the carbon footprint attribute value is positive, the asset smart contract is used to obtain a plurality of carbon neutral tokens (CNT) by executing a CNT smart contract on the blockchain and the plurality of CNTs are issued to an issuer and recorded on the ledger, wherein the amount of carbon neutral tokens issued is determined from the carbon footprint attribute value, and the plurality of CNTs are issued. CNT for trading, and if the carbon footprint attribute value is negative, the asset smart contract is used to obtain multiple asset-backed tokens by executing an asset-backed token smart contract on the blockchain, and the ABTs are issued to an issuer and recorded in the ledger, where the amount of asset-backed tokens issued is determined from the financial and/or operating information of the asset.

In one form, the method further comprises collecting carbon offset data from the asset and submitting the carbon emission data to the third-party verification authority to obtain verification of the carbon emission reductions.

In another form, the carbon emissions data is obtained using a secure data acquisition system comprising a plurality of hardware and software components configured to securely collect and store the carbon emissions data.

In one form, the blockchain is an Ethereum blockchain, and the asset smart contract is based on the ERC721 standard, and the asset-collateralized token smart contract is based on the ERC20 standard.

In one form, the report address is a Uniform Resource Identifier (URI) address or a Uniform Resource Locator (URL) address.

According to the third aspect of the present application, a method for trading on a digital asset exchange comprising a ledger is provided, the method comprising: listing one or more CNTs generated by the method of the first aspect; generating multiple listing items of multiple assets, each listing item being generated by the method of the second aspect; updating the ledger by updating a carbon footprint attribute value of the trader stored in the ledger based on the total carbon footprint attribute value associated with the listed asset when a trader purchases a share of a listed asset, and/or updating the ledger when a trader purchases one or more CNTs, wherein the carbon footprint attribute value of the trader stored in the ledger is updated based on the number of one or more CNTs purchased.

In one form, the trader may purchase a package, wherein the package includes a share of a listed asset and an amount of CNTs to offset carbon emissions associated with the share of the listed asset.

According to the fourth aspect of the present application, an asset trading system is provided, which includes: A plurality of computing devices, which include one or more processors, one or more memories, one or more storage devices and one or more interfaces, wherein the one or more interfaces are configured to receive one or more information packages and store them in the one or more storage devices, and the plurality of computing devices are configured to execute the method of any one of the first aspect, the second aspect or the third aspect.

In one form, the plurality of computing devices are configured to implement a blockchain.

In one form, the plurality of computing devices are further configured to implement a digital exchange and the one or more storage devices are configured to implement a ledger and a cold wallet.

In one form, the system further includes a secure data acquisition system comprising a plurality of hardware and software components configured to securely collect and store carbon offset data and carbon emissions data generated by one or more assets.

According to a fourth aspect of the present application, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the method of any one of the first aspect, the second aspect or the third aspect is implemented.

According to the fifth aspect of the present application, a method for generating a non-homogeneous digital twin (NFDT) of an asset is provided, which comprises: Generating an information package and storing it at a reporting address, wherein the information package comprises information about an asset, including at least one attribute value; Cryptographically signing the information package and obtaining a hash for authenticating the information package; Inputting at least an owner address, an identifier, the at least one attribute value, the reporting address, and the hash of the information package into an asset smart contract in a blockchain, wherein once published on the blockchain, the smart contract defines a birth smart contract, and the submitted information is stored on the blockchain at the birth smart contract address; Using the birth smart contract to obtain a plurality of asset-backed tokens (ABTs) by executing an ABT smart contract on the blockchain, wherein the amount of the issued asset-backed tokens is determined from the at least one attribute value in the birth smart contract; Storing the plurality of ABTs; Offering one or more of the plurality of ABTs for trading; and Publishing a plurality of asset smart contracts on the blockchain, wherein each asset smart contract is published at a different time, wherein the value of the at least one attribute value in each asset smart contract after the birth smart contract is a change in the value since the publication of the previous asset smart contract and a link to one or more of the previous asset smart contracts published on the blockchain including the birth smart contract, and each smart contract is used to issue, store and sell a plurality of ABTs based on the value in the respective smart contract, wherein the birth smart contract and the plurality of emission asset contracts form a time series of asset smart contracts that define a unique non-fungible digital twin (NFDT) representation of the asset.

In order to better understand the objectives, technical solutions and advantages of the specific examples of this application, the technical solutions of the specific examples will be clearly and fully described with reference to the attached drawings of the specific examples. Of course, the specific examples described in this article are only some examples of this application; any other specific examples obtained by a person with ordinary knowledge in the relevant technical field based on the specific examples in this article without creative efforts will fall within the scope of protection of this application.

In the following detailed description, reference is made to the accompanying drawings, which are part of the present application for illustrating specific embodiments of the present application. In the accompanying drawings, similar symbols may represent substantially similar components in different figures. The following describes the specific embodiments of the present application in sufficient detail to enable a person having ordinary knowledge in the art to implement the technical solution of the present application. It should be understood that other embodiments or structural, logical or electrical changes of the specific embodiments of the present application may also be used.

ESG disclosure has become a mandatory requirement in more and more exchanges, and corporate carbon emissions and carbon offsets are usually disclosed in the trading market in the form of social responsibility reports or ESG reports for a specific reporting period (usually annually); however, investors must relate ESG indexes to the financial returns of assets on a more macro scale to construct their ESG investment strategies and asset portfolios, and cannot grasp the ESG attributes and economic value of the assets they trade and hold in real time and quantitatively.

To address the above issues, this application provides a method for generating a non-fungible digital twin (NFDT) representation of an asset or carbon offset action or project, which represents a time series of smart contracts on a blockchain (e.g., based on the Ethereum ER721 standard) that capture carbon offset actions and carbon emissions over time. Carbon offset actions can be used to generate carbon neutral tokens (CNT; e.g., based on the Ethereum ERC-20 standard). A digital asset trading system can be implemented that allows the listing of assets and the listing of CNT. The ledger is also used to store the carbon footprint attribute value (ENV) of each listed asset. Each asset smart contract includes the carbon footprint (e.g., tons of carbon dioxide equivalent or tCO2e for short) generated since the last asset smart contract, so the carbon footprint (ENV) is tied to the digital asset. The carbon footprint attribute value (ENV) of each listed project traded on the digital asset exchange is tracked via a ledger, and the digital asset exchange is configured to provide investors who hold a portfolio on the exchange with the portfolio value of the portfolio and the carbon footprint attribute value of the portfolio obtained by summing the carbon footprint attribute values of each investment in the portfolio. Similarly, the total carbon footprint attribute value (ENV) of the asset holder can be obtained by summing the carbon footprint attribute value of each listed project and any offsetting CNT held, providing a mechanism to easily and explicitly meet environmental, social and governance (ESG) reporting requirements. In detail, the method described herein (and in detail, the process of establishing a NFDT for use in offsetting assets or projects) provides a method for establishing a cross-border carbon credit trading mechanism without triggering NDC constraints and without relying on Article 6 of the Paris Agreement. In detail, it allows countries where emission reductions occur to record emission reductions in their registers and contribute to their NDCs, and freeze such emission reductions, while allowing the establishment of a digital representation of the asset or project that can be freely traded across borders (whether by the original owner/offsetter or another party). Emission reductions may also be permanently frozen and used to neutralize the carbon footprint of real-world assets.

To solve the above problems, this application provides an asset trading platform or exchange, on which the assets to be traded are marked (bound) with their carbon footprint attribute value (ENV). The carbon footprint attribute (ENV) is a carbon emission indicator attached to an asset, and quantifies the carbon emissions or carbon offsets of the asset relative to its industry standard baseline emissions since the asset's existence; that is, the negative/positive contribution of the asset to carbon neutrality. This is expressed as a numerical value (ENV) and is bound to the asset as an inherent attribute. We use the abbreviation ENV to represent the carbon footprint attribute value, and it should be noted that it can be equivalently regarded as a carbon neutrality attribute value, because it can be used together with CNT to evaluate the carbon neutrality status of the asset "ENV".

When trading assets, the carbon footprint attribute (ENV) attached to the asset flows with it, and the buyer obtains the carbon footprint attribute (ENV) attached to the asset. The assets here can be traditional assets, such as shares of buildings or factories, or cryptocurrencies, such as BTC or ETH, or alternative physical assets, such as art, jewelry, etc.

In recent years, environmental issues and climate change have gradually become important issues of concern to society. Against this background, impact investment is being recognized by the market at an accelerated pace, which will prompt more investors to enhance their awareness of carbon neutrality and be more willing to purchase assets with positive (or zero) carbon footprint (ENV). At the same time, due to the existence of negative values, assets with negative carbon footprint (ENV) may not be traded on the trading platform at an appropriate trading price and volume.

The inventors of this application have additionally established the concept of Carbon Neutral Tokens (CNTs) as a means of conducting carbon offsetting and carbon capture, storage and utilization (CCSU) activities. As described above, a NFDT is a time series of linked emission reduction smart contracts associated with an asset or carbon offsetting action (or project), each of which captures emission reductions since the previous contract. Following the issuance of each emission reduction smart contract, an equal amount of CNTs are issued to reflect the emission reductions included in the emission reduction smart contract. As outlined above, these are cross-border tradable, do not trigger NDC restrictions, and do not need to rely on Article 6 of the Paris Agreement. Possible ways to earn CNTs include: companies with positive carbon offsets or capture (e.g., photovoltaic, wind, forest projects), companies with products or assets with carbon emissions below recognized industry benchmarks, companies or situations that aggregate the green contributions of consumers/individuals in society (e.g., shared mobility companies, distributed renewable energy, and companies that manufacture low-carbon and/or negative-carbon consumer products).

According to a specific example, the correspondence between CNT and negative ENV can be 1:1; or, some other correspondence can be used as needed. For example, the value of CNT can be defined as follows: 1 CNT = 1 ton of _CO2 equivalent carbon emissions when carbon neutral (when net emissions are zero).

According to a specific example, CNT can be regulated by a trading platform; and a trader or asset holder with negative ENV can purchase CNT to increase his total ENV value (which is tracked in the ledger). In other words, the total ENV value of the trader's portfolio or asset holder is equal to the sum of the carbon footprint attribute values of all of the trader's or asset holder's assets and the positive carbon footprint attribute values corresponding to the CNT held by the trader or asset holder.

According to a specific example, the carbon footprint attribute value ENV and the carbon neutrality token CNT can be calculated or audited by a professional third-party entity to avoid data falsification.

According to a specific example, NFDT, smart contracts, ENV and/or carbon neutral tokens (CNT) may be recorded using blockchain and/or smart contract technology. As will be known to those skilled in the art, a blockchain is a digital distributed ledger that operates using a peer-to-peer network on typically distributed computing devices, where entries/transactions are secured by cryptographic signatures so that the historical record of transactions cannot be tampered with and a verifiable audit trail is left. There are many different blockchain technologies, such as Bitcoin and Ethereum. In some specific examples, generation and publication may be performed, for example, via the Ethereum public blockchain. Ethereum is an efficient distributed virtual machine that allows end users to construct smart contracts for transactions. Smart contracts are stateful applications or software codes stored on the Ethereum public blockchain. These contracts are secured by cryptographic algorithms for verification or enforcement of contracts. When a smart contract is deployed on a virtual machine and the triggering conditions are met, the smart contract will be automatically executed and published on the blockchain, providing a reliable and trusted mechanism for NFDT representation of assets and CNT issuance. At the same time, smart contracts executed on the Ethereum public blockchain have characteristics such as traceability, tamper-proofing, and decentralization, and have the important feature of being permanently recorded on the blockchain. Other blockchains and private blockchains can be used.

According to a specific example, the trading platform is not involved in pricing CNT; instead, CNT is freely traded between asset holders and carbon neutral token holders on the exchange. Of course, the trading platform can provide references to CNT prices and can also recommend possible CNT trading options, such as asset and CNT packages, to traders, asset holders or CNT holders.

Various specific examples will now be discussed in more detail with reference to the figures to further illustrate various methods and systems. FIG1A is a structural diagram of an asset trading system according to a specific example of the present application.

As shown in the figure, the asset trading system 100 includes: an exchange 110, a CNT holder 120, an asset holder 130, and a third-party entity 140. The asset holder and the CNT holder may be the owner of an asset that generates emissions or reduces emissions, or the asset holder may be an individual who purchases emission or emission reduction certificates in a country where emission or emission reduction activities occur. Traders (or investors) can use the asset trading system to trade to purchase listed projects and/or CNTs to build a portfolio. The asset holder 130 lists the assets, and the carbon footprint attributes (ENV) of each asset are determined and verified by a third-party entity, and the carbon footprint attributes (ENV) are tied to the digital representation of the asset on the exchange. This captures the carbon footprint (e.g., carbon emissions) when the physical asset is created, or is created by the physical asset (e.g., power plant) over time. Investors or asset holders can purchase CNTs from CNT holders 120 via exchange 110 to increase their total carbon footprint attribute (ENV) value, for example to achieve carbon neutrality of the asset. Computing equipment used to implement the functionality (e.g., blockchain, computing) of the various components of system 100 is represented by dashed rectangles.

The exchange 110 may be a distributed system on a public or private blockchain or other computing device (e.g., a distributed server), or it may be a formally registered asset exchange that is regulated and performs additional trading, listing, and verification services. The exchange 110 may be a transaction matching system and a transaction monitoring system that serves multiple compliant exchanges in various countries and regions around the world. It ensures strong and efficient transaction matching processing requirements, and also monitors illegal transactions in real time to effectively protect the legal rights and interests of investors.

In some specific examples, assets traded in exchange 110 may include, for example: various digital tokens based on physical assets such as stocks; digital currencies (e.g., BTC/ETH); or alternative physical assets (e.g., art, diamonds), as well as assets such as non-renewable power plants, vehicles or equipment, or assets that generate carbon emissions during use or over time (whether directly or indirectly, such as by consuming electricity).

According to a specific example, from the perspective of energy conservation and emission reduction, CNT holder 120 can be a green company, such as a new energy technology research and development and supply company (photovoltaic, wind power or hydropower company) or a reforestation company, which can obtain the dual benefits of economic benefits from its own products and CNT as a reward. According to other specific examples, CNT holder 120 can also be an ordinary company. Due to its energy conservation and emission reduction actions, whether for production or for life (green office, green travel, etc.), it can be rewarded with CNT according to CNT rules, as long as an authoritative third party proves that the actual carbon emissions of its production or life process are lower than the benchmark, so that the emission reduction actions can obtain economic rewards.

According to another specific example, from the perspective of industrial nature, CNT holder 120 may be an information technology company, such as a digital payment platform, bicycle sharing, car sharing, decentralized renewable energy management, etc., which has the ability to organize and aggregate consumers' green consumption and provide key information in the form of big data for quantifying the carbon offset contribution of such actions; once verified by a third party, it can also receive corresponding CNT rewards.

In addition, CNT holders 120 can also be ordinary consumers or environmentalists. Through corporate organizations, ordinary consumers and environmentalists can also participate in the CNT system. Through their green consumption behavior, ordinary consumers and environmentalists not only contribute to the carbon neutral ecological cause, but also receive corresponding rewards and rewards by trading CNT on the exchange.

CNT holder 120 may also be an investor or entity that purchases CNT from the above parties (or intermediaries). Therefore, CNT holder may be an entity that performs carbon offsetting activities, or may be an entity that obtains emission reduction certificates from a previous owner (and the original entity that ultimately performs carbon offsetting activities).

The exchange 110 allows asset holders to list assets on the exchange. However, in order to facilitate the disclosure of the carbon neutrality status of asset holders, the exchange 110 requires asset holders 130 to provide verified carbon footprint attributes (ENV) of the assets to be included in the listing documents of the exchange 110. In a specific example, this includes establishing a NFDT, which is a digital representation of the assets on the exchange through the use of a time series of linked smart contracts. Each smart contract includes the carbon emissions (or carbon footprint) generated since the previous smart contract (or in the case of a birth contract, the emissions when the asset was created), and therefore the carbon footprint attribute (ENV) is tied to the representation of the asset. The carbon footprint attribute (ENV) is stored in the ledger of the exchange. This number (NFDT) will reflect the ENV reality of the asset by tracking changes in the ENV value (such as additional carbon emissions over time) or by buying or selling CNT, all of which will change the carbon footprint attribute (ENV) of the asset.

This is further illustrated in FIG. 1B , which is a schematic diagram of a chain of smart contracts for digitally representing the change of an asset's carbon footprint attribute (ENV) over time according to a specific example. At time t ₀ , the asset is listed on an exchange 110. This requires obtaining carbon emission data 164a to determine the asset's carbon footprint. This can be the sum of all carbon emissions measured in tons of carbon dioxide equivalent (tCO2e) involved in the manufacture or production of the asset. Generate an information package 160a, which in one specific example includes an asset name 161 and an asset ID 162, a description 163a, emissions data 164a, a carbon footprint 165a estimated from the emissions data 164a, and a verification certificate 166a generated by a third party entity 140 that performed the carbon footprint 165a calculation or verified that the calculation was performed correctly. The description may include a description of the asset and how it is made, as well as any other relevant information, such as how the calculation of the carbon footprint 165a was performed. The carbon footprint 165a may be provided as a value in tons of carbon dioxide equivalent (tCO2e). The information package 160a may then be stored as a PDF report, or similar electronic container file in a database 167 with an associated report address, which is a unique access location, such as a uniform resource identifier address or uniform resource locator address. In this specific example, the address is a URL (report URL 181a), but it should be understood that this can be a URI address. This storage address can be on a storage device of the digital exchange 110 (for example, in a web server) and can be accessed by an associated web server of the digital exchange or other digital interface provided by a computing device of the digital exchange 110. However, it can also be on a storage device on another server or in a cloud storage device. The information package is submitted to the exchange, which checks and then cryptographically signs the information package to produce a unique hash 182a for the information package and can be used to verify the authenticity of the information package at the access location (report_URL 181a). Therefore, when the report_URL (or URI) is accessed, the hash can also be provided, and the file will only be served if the hash authenticates the information package (and therefore verifies that it has not been modified). If the authentication fails, a warning can be issued, which can indicate that the report may have been changed. The asset name 161, asset ID 162, description 163a, report_URL 181a, hash 182a, and carbon footprint 165a are provided as input to a smart asset contract 180a, which is executed on a blockchain that generates an asset token 186a that can be used to represent the asset. Address 183b indicates the storage address (e.g., a block on the blockchain) where the asset contract 180a is stored. Token 186a serves as a birth certificate for the asset, and address 183b then indicates where on the blockchain the birth certificate is stored (and can therefore be viewed). Token 186a may then be stored in a database by exchange 110 and used to access published smart contracts or information contained in published smart contracts. The initial carbon footprint attribute (ENV) value is carbon footprint 165a, and this ENV value is stored in the ledger (and therefore, the initial ENV value will be the initial carbon footprint 165a).

Rather than being a single record or snapshot, the digital representation of an asset (NFDT) is a live (or continuous) representation of an asset over time, and is therefore designed to capture changes in the value of a carbon footprint attribute (ENV) over time. For example, in this specific example, physical assets continuously generate carbon emissions that are reported at regular time intervals (e.g., quarterly). Therefore, at time _t1 , additional emissions data 164b for the asset 132 over the time period ( _t1 - _t0 ) is collected and stored. A second information package 160b is prepared. This information package 160b is generated to include the asset name 161 and asset ID 162, a description 163b, emissions data 164b, a carbon footprint 165b estimated from the emissions data 164b, and a verification certificate 166b generated by the third party entity 140 that performed the carbon footprint 165b calculation or verified that the calculation was performed correctly. The description may include a description of the asset, a timer period or timestamp _t1 , and any other relevant information, such as how the calculation of the carbon footprint 165b was performed. The information package 160b may then be stored as a PDF report or similar electronic container file in a database 167 with an associated unique access location (report URL 181b) and then submitted for inspection to the exchange, which then digitally signs 168b to generate a hash 182b. The asset name 161, asset ID 162, description 163b, report_URL 181b, hash 182b, address 183b and carbon footprint 165b are provided as input to the smart asset contract 180a, along with the address of the previous asset contract, which in this case is the birth address (i.e., previous address 184b = birth address 183a). This address may be provided as a token 186a. This generates another asset token 186b that can be stored by the exchange 110. The value of the carbon footprint attribute (ENV) of the asset (ENV) is then updated on the ledger to include the additional emissions (eg, ENV = Carbon Footprint 165a + Carbon Footprint 165b).

This creation and submission of information packages 160 is repeated over time to execute additional asset contracts 180 for the asset, with each subsequent asset contract linked and the associated carbon footprint attribute (ENV) value updated after each contract (based on the carbon footprint 165 in the asset contract). FIG. 1B shows information packages 160i and 160j and asset contracts 180i and 180j at times _{tN - 1} and _tN , respectively. As previously mentioned, asset contract 180j at time _tN includes a reference to the address of the previous asset contract 180j generated at time _{tN - 1} . In this way, a linked list of asset contracts is generated for the asset, all of which are (immutably) stored on the blockchain 152.

FIG1C is a graph (curve 185) of the carbon footprint attribute value (ENV, in tCO2e) of the asset in FIG1B over time, as maintained in the exchange's ledger. At time _t0 , the carbon footprint attribute (ENV) value of the asset is the carbon footprint value 165a included in the asset contract 180a. Then, at time _t1 , the asset contract 180b is executed, and the additional emissions 165b are listed, resulting in a decrease in the carbon footprint attribute (ENV) value of the asset (by the carbon footprint value 165b). Then at time _t2 , the asset contract 180c is executed, listing the additional emissions 165c, causing the asset's carbon footprint attribute (ENV) value to decrease further (by carbon footprint value 165c). As further illustrated in Figure 1C, at additional time points _t3 and _t4 , additional emissions are reported, and ENV gradually decreases by additional amounts, namely carbon footprint value 165d and carbon footprint value 165e. Thus, Figures 1A, 1B, and 1C illustrate an exchange configured to record an asset's carbon footprint attribute (ENV) value according to a specific example. This facilitates ESG reporting by asset holders.

According to a specific example, asset holder 130 may wish to trade its assets on an exchange. In order to better price its assets for trading, or because of its institutional carbon neutrality goals and commitments, or as required by the exchange, or for other reasons, the asset holder may wish that its total carbon footprint attribute (ENV) value is not less than 0. According to a specific example, asset holder 130 may purchase CNTs to balance the negative ENV attached to its assets and the _total negative impact of the total carbon footprint attribute value ENV, and bundle these CNTs with the trading of its assets. Of course, asset holder 130 may already hold CNTs, but its CNTs are not enough to bring its _total ENV to a level greater than or equal to 0; therefore, asset holder 130 may still need to purchase CNTs. Alternatively, asset holders may work with CNT holders or exchanges to issue bundled transactions where the asset transaction includes the purchase of CNT from CNT holders to offset the negative ENV of the asset being issued for trading. Alternatively, traders may purchase CNT individually to offset the negative ENV of the purchased asset to minimize the carbon footprint of their portfolio (or make it carbon neutral or carbon positive). As explained below, the creation of CNT is similar to the process illustrated in Figure 1 and illustrated in Figure 1D. However, instead of using emission data to calculate emissions, emission reduction data is used to calculate a verified emission reduction value. A smart contract (based on ERC 721) is executed to generate a non-fungible digital avatar (token) of the emission reduction that generates a certain amount of CNT using a smart contract (based on ERC 20). As outlined below, smart contracts require that emission reductions be recorded and redeemed (phased out or frozen) from a national carbon account processing registry, and that an exchange or other trusted party monitors the redemption certificate to prevent the trading of carbon emission reduction certificates and avoid the redemption certificate being used for carbon neutrality offsets. Therefore, Figures 1A, 1B, and 1C illustrate an exchange configured to record the carbon footprint attribute (ENV) value of an asset according to a specific example. This facilitates ESG reporting by asset holders.

FIG1D is a schematic diagram of a method for generating emission reduction smart contracts and carbon neutral tokens (CNT) relative to an offsetting action to create a non-fungible digital twin (NFDT) representation of the offsetting action according to a specific example. Each smart contract in the time series of smart contracts forming the NFDT is uniquely identified by a contract address (on the blockchain) and a token ID (uint256) that provides a mapping to the address. The NFDT contains a time series of birth asset contracts and subsequent asset contracts that capture all details of the asset and its carbon footprint (ENV), each subsequent asset contract storing subsequent emission data or carbon footprint attribute values (ENV) that have changed due to, for example, emission reduction activities or purchases of CNTs at the current time (t). That is, after the contract is generated, each subsequent asset contract stores the new carbon footprint information at the current time (t) and the address of the previous smart contract (t-1). Figure 1D illustrates the process used to generate the generated contract and CNTs generated by the emission offset action. The modified process can be used to generate subsequent emission reduction smart contracts and CNTs associated with later additional emission reduction activities.

This is further illustrated in FIG. 1D , which is a schematic diagram of a method for generating smart contracts and CNTs according to a specific example. The owner 120 of a real-world project such as a wind, solar or energy emission project (or asset) prepares an information package containing data related to the carbon offset activities of the project. The carbon emission related data includes relevant documents (e.g., description of the project, time frame) and/or data captured by data acquisition systems and devices as described above and/or by sensors (including IoT sensors) and software. The information package can be submitted to an authoritative third-party verification and certification vendor 140 to calculate emission reductions or verify the calculation of emission reductions in appropriate units (e.g., tons of CO ₂ emissions). Submit the information package to the national carbon registry of the country (or region) where the real-world project is located or where the information package can be attributed (for example, if the project is not carried out in the country's interior (such as in the ocean)). After review and approval by the national carbon registry, the owner of the real-world project is issued a tradable voluntary emission reduction (VER) certificate. For example, in China, this is called China Certified Emission Reduction (CCER).

As explained above, in some specific examples, the generation of CNTs is conditional on the redemption (or elimination) of the underlying VER. Therefore, in this specific example, the owner of the VER undergoes the VER elimination process to prevent it from being further traded. After verification by the National Registry, the CNT issuer shall receive a certificate of VER elimination from the National Registry. In China, this is called a "Certified Emission Reduction Exchange Certificate." This ensures that the Nationally Determined Contribution (NDC) will not be affected because the VER will not leave the country. In another specific example, the owner of the VER may sell or transfer the VER to another party through a national carbon exchange, a local carbon exchange, or a two-way transaction until the VER is purchased by a subsidiary or related party of the CNT issuer in the country. Then, the subsidiaries or related parties of the CNT issuer in that country will go through the VER phase-out process, making the VER unable to be traded anywhere forever. Again, this ensures that the NDC will not be affected because the VER will not leave the country.

An application 111 running on the exchange system hardware is used to submit, approve VER certificates (and information packages), and then generate the appropriate amount of CNT tokens. The application programming interface enables the owner to upload information (or data) packages, such as PDF reports (or similar files) that meet the Exchange Listing Rule Requirement 811, which are then stored on a file system 112 such as the cloud-based AWS s3 file system. In a specific example, this information package (PDF report) includes the sales memorandum, the carbon offset action related data submitted to the national carbon registry (including any information captured by the above data acquisition system and equipment), VER certificate (e.g., China's CCER) and VER redemption/redemption certificate (e.g., it is called Certified Emission Reduction Redemption Certificate in China). The information package can be a single document or a collection of documents, and can be provided in a container or similar file or data structure.

The Exchange reviews the submitted information package (PDF report) and if the package meets the listing criteria, it will approve the listing and digitally sign at least the VER Certificate and the VER Redemption Certificate, and preferably digitally sign the entire information package by a hashing algorithm or hash function (e.g., a 256-bit hash). This hash function can be stored on the blockchain (e.g., in a smart contract) to serve as proof that the Exchange has approved the information package and allows verification that the information package has not been altered. In a specific example, when accessing the information package, the hash is provided and the hash is used to authenticate that the information package has not been altered (and the information package can only be served if the verification passes).

The application 111 submits (e.g., by a service call) the information package address (VER report URI, however, this can also be a URL) and the digital signature (hash) to the VER smart contract 154. In this specific example, the blockchain is the Ethereum blockchain, and the VER smart contract 154 is based on (or inherited from) the ERC721 smart contract. The time series of the VER smart contract 154 establishes the NFDT of the real-world asset/activity (i.e., carbon offset activity). The smart contract stores the information of the asset in the blockchain to provide an unalterable certificate. In this specific example, the asset information includes the name, ID, CO2 emission reduction (e.g. in tCO2e), the download address (e.g. URI or URL) of the information package (e.g. PDF report), the signature of the information package (hash of the PDF report) and the URI of the JSON metadata file (according to the ERC721 standard; token_URI). Similar to the real world, NFDT is a digital birth certificate. Therefore, the signed listing document including the information package (and VER certificate and VER redemption certificate) forms the birth document package of NFDT.

Each NFDT is identified by a unique uint256 ID inside the ERC-721 smart contract. This identification number is fixed and therefore cannot change during the validity period of the contract. The pair (contract address, uint256 tokenId) will then become a globally unique and fully qualified identifier for a specific asset on the Ethereum chain. The choice of uint256 allows for a wide range of applications, as UUIDs and SHA3 hashes can be directly converted to uint256. After a NFDT is generated, the record will remain on the blockchain (and will not disappear). RC-721 standardizes the safe transfer function safeTransferFrom (overloaded with and without byte parameters) and the unsafe function transferFrom. Transfers can be initiated by the owner of the NFDT, an approved address of the NFDT, or an authorized operator of the current owner of the NFDT. Additionally, authorized operators can configure approved addresses for use with NFDT. This provides a powerful toolkit for e-wallet, proxy and auction applications to quickly use large numbers of NFDTs.

Table 4 below illustrates a smart contract for issuing CCER asset contracts based on ERC-721 according to a specific example. This can be modified for other assets based on VER. This asset contract can be used to record carbon emissions (e.g., the carbon footprint of an asset) or emission reductions. Table 4 Smart contract code for CCER asset contracts based on ERC-721 (CCERAsset.sol) //Contract/CCERAsset.sol pragma solidity ^0.8.0; import "@openzeppelin/contracts/token/ERC721/ERC721.sol"; import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol"; import "@openzeppelin/contracts/utils/Counters.sol"; import "@openzeppelin/contracts/access/AccessControl.sol"; import "./ICNTToken.sol"; import "./ICarbonFootprint.sol"; Contract CCERAsset is ERC721URIStorage, AccessControl { //Create a new role identifier for the minter role bytes32 public constant ISSUER_ROLE = keccak256("ISSUER_ROLE"); struct EmissionData { uint256 co2; //Store CO2 emissions/reductions } struct Certificate { string websiteUrl; //Official website for each CCER project string reportUrl; //URL where the PDF report is stored string reportHash; //Hash of PDF report } //CCER report structure used to describe key CCER features struct CCERItem { uint256 id; //Unique ID of the contract string assetId; //ID assigned by the CCER official accreditation organization to identify the CCER project string assetName; //Assigned name of the CCER project string description; //Key points of the report in text format string tokenURI; //Point to the JSON file containing the metadata of the NFT EmissionData emissionData; //See above Certificate certificate; //See above } using Counters for Counters.Counter; Counters.Counter private _tokenIds; using Strings for uint256; mapping(string => constructor(address administrator) ERC721("CCER Asset", "CRA") { _setupRole(DEFAULT_ADMIN_ROLE, administrator); } function _setHashToken(string memory hash, uint256 tokenId) internal virtual { _hashTokenMapping[hash] = tokenId; } function _setTokenCcer(uint256 tokenId, CCERItem memory ccer) internal virtual { _ccerReportMapping[tokenId] = ccer; } function _existsHash(string memory hash) internal view virtual returns (bool) { return _hashTokenMapping[hash] != 0; } //Create a new token for the ccer asset, store it on the blockchain, and assign it to the recipient function create( address recipient, string memory ccerName, string memory ccerId, string memory description, uint256 co2, string memory websiteURI, string memory reportURI, string memory reportHash, string memory tokenURI ) public onlyRole(ISSUER_ROLE) returns (uint256) { //Check if the hash has been used by the contract, if so, raise an exception require(!_existsHash(reportHash), "CCERAsset: ccer report has been submitted");_tokenIds.increment(); uint256 newItemId = _tokenIds.current(); _mint(recipient, newItemId); _setTokenURI(newItemId, tokenURI); //Store hash and token id in mapping _setHashToken(reportHash, newItemId); //Store ccer asset in memory together with token id EmissionData memory emissionData = EmissionData(co2); Certificate memory certificate = Certificate(websiteURI, reportURI, reportHash); CCERItem memory ccer = CCERItem( newItemId, ccerId, ccerName, description, tokenURI, emissionData, certificate ); _setTokenCcer(newItemId, ccer); return newItemId; } //Approve ccer asset. Once the ccer asset is approved, the contract calls another ERC 20 contract (CNT token contract) to issue CNT tokens to the owner of the ccer asset. function approveCCERAsset(uint256 amount, uint256 tokenId721) public onlyRole(DEFAULT_ADMIN_ROLE) { //Get the address of the owner of the ccer asset token address recipient = ERC721.ownerOf(tokenId721); //Link to the CNT token contract and call the issue function to issue CNT tokens to the owner of the ccer asset token ICNTToken cntToken = ICNTToken(_tokenContractAddress); cntToken.issue(recipient, amount, tokenId721); } //Create a new carbon footprint token for the ccert asset, which is //another ERC 721 contract, and assign the carbon footprint to the owner of the ccer asset, //that is, first create a CCERitem (birth contract), and //Then use addCarbonfootprint for continuous contracts in time series function addCarbonFootprint( string memory reportURI, string memory reportHash, string memory description, string memory tokenURI, uint256 tokenId ) public returns (uint256) { ICarbonFootprint carbonFootprint = ICarbonFootprint( _carbonFootprintContractAddress ); //Get the address of the owner of the ccer asset token address recipient = ERC721.ownerOf(tokenId); uint256 carbonFootprintTokenId = carbonFootprint.create( recipient, reportURI, reportHash, description, tokenURI, tokenId ); uint256[] storage tokenIdList = _childTokenIds[tokenId]; tokenIdList.push(carbonFootprintTokenId); return carbonFootprintTokenId; } //Get all carbon footprint tokens for the token id of the ccer asset //This allows to get/review all contracts in the time series function getCarbonFootprintIdsByParentTokenId(uint256 parentTokenId) public view virtual returns (uint256[] memory) { uint256[] memory tokenIdList = _childTokenIds[parentTokenId]; return tokenIdList; } //Grant (address) issuer role to user, only admin role is allowed to call function function grantIssuerRole(address account) public onlyRole(DEFAULT_ADMIN_ROLE) { grantRole(ISSUER_ROLE, account); } //Set the address of the carbon footprint contract (ERC 721) function setCarbonFootprintContractAddress(address carbonFootprintContractAddress) public onlyRole(DEFAULT_ADMIN_ROLE) { _carbonFootprintContractAddress = carbonFootprintContractAddress; } //Set the address of the CNT token contract (ERC 20). The CNT token contract is used to issue CNT tokens to the receiver. function setTokenContractAddress(address tokenContractAddress) public onlyRole(DEFAULT_ADMIN_ROLE) { _tokenContractAddress = tokenContractAddress; } //Revoke the issuer role of the user (address). Only administrators are allowed to call functions. function revokeIssuerRole(address account) public onlyRole(DEFAULT_ADMIN_ROLE) { revokeRole(ISSUER_ROLE, account); } /** * Get ccer assets by token id */ function getCcerByTokenId(uint256 tokenId) public view virtual returns (CCERItem memory) { require(_exists(tokenId), "CCERAsset: Query URI for non-existent tokens"); CCERItem memory ccer = _ccerReportMapping[tokenId]; return ccer; } /** * Get ccer assets by report hash */ function getCcerByHash(string memory hash) public view virtual returns (CCERItem memory) { require( _existsHash(hash), "CCERAsset: Query ccer report for non-existent hash"); uint256 tokenId = _hashTokenMapping[hash]; CCERItem memory ccer = _ccerReportMapping[tokenId]; return ccer; } /** * Change support interface */ function supportsInterface(bytes4 interfaceId) public view virtual override(ERC721, AccessControl) returns (bool) { return interfaceId == type(IERC721).interfaceId || interfaceId == type(IERC721Metadata).interfaceId || interfaceId == type(IAccessControl).interfaceId || super.supportsInterface(interfaceId); } } //Contract/ICarbonFootprint.sol pragma solidity ^0.8.0; interface ICarbonFootprint { function create( address recipient, string memory reportURI, string memory reportHash, string memory description, string memory tokenURI, uint256 ccerAssertTokenId ) external returns (uint256); } //Contract/ICNTToken.sol pragma solidity ^0.8.0; interface ICNTToken { function issue(address account, uint256 amount, uint256 tokenId721) external; } //Contract/CarbonFootprint.sol pragma solidity ^0.8.0; import "@openzeppelin/contracts/token/ERC721/ERC721.sol"; import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol"; import "@openzeppelin/contracts/utils/Counters.sol"; import "@openzeppelin/contracts/access/AccessControl.sol"; import "./ICarbonFootprint.sol"; contract CarbonFootprint is ERC721URIStorage, AccessControl, ICarbonFootprint { //Create a new role identifier for the minter role bytes32 public constant ISSUER_ROLE = keccak256("ISSUER_ROLE"); struct FootprintItem { //See struct CCERItem for description field uint256 ccerAssertTokenId; string reportUrl; string reportHash; string description; string tokenURI; uint256 tokenId; } using Counters for Counters.Counter; Counters.Counter private _tokenIds; using Strings for uint256; mapping(string => uint256) private _hashTokenMapping; mapping(uint256 => FootprintItem) private _footprintMapping; //child tokenId, parent tokenId //link CCERAsset to carbonfootprint (e.g. to build a time series) mapping(uint256 => uint256) private _tokenIdMapping; constructor(address administrator) ERC721("CCER Carbon Footprint", "CCF") { _setupRole(DEFAULT_ADMIN_ROLE, administrator); } function _setHashToken(string memory hash, uint256 tokenId) internal virtual { _hashTokenMapping[hash] = tokenId; } function _setTokenCcer(uint256 tokenId, FootprintItem memory footprintItem) internal virtual { _footprintMapping[tokenId] = footprintItem; } function _existsHash(string memory hash) internal view virtual returns (bool) { return _hashTokenMapping[hash] != 0; } //Generate a new token and then assign it to the recipient // onlyRole(ISSUER_ROLE) function create( address recipient, string memory reportURI, string memory reportHash, string memory description, string memory tokenURI, uint256 ccerAssertTokenId ) public override virtual returns (uint256) { //Check if the hash has already been used by the contract and raise an exception if so require(!_existsHash(reportHash), "CCERAsset: ccre report already committed");_tokenIds.increment(); uint256 newItemId = _tokenIds.current(); _mint(recipient, newItemId); _setTokenURI(newItemId, tokenURI); //Store hash and token id in mapping _setHashToken(reportHash, newItemId); //Store ccer asset with token id in memory FootprintItem memory footprintItem = FootprintItem( ccerAssertTokenId, reportURI, reportHash, description, tokenURI, newItemId ); _setTokenCcer(newItemId, footprintItem); _setCcerAssertTokenId(newItemId, ccerAssertTokenId); return newItemId; } //Set ccer confirmation id of carbon footprint function _setCcerAssertTokenId(uint256 tokenId, uint256 ccerAssertTokenId) internal virtual { _tokenIdMapping[tokenId] = ccerAssertTokenId; } //Get ccer asset token id of carbon footprint function getCcerAssertTokenIdByTokenId(uint256 tokenId) public view virtual returns (uint256) { uint256 ccerAssertTokenId = _tokenIdMapping[tokenId]; return ccerAssertTokenId; } //Grant the (address) issuer role to the user, and only allow the administrator role to call the function function grantIssuerRole(address account) public onlyRole(DEFAULT_ADMIN_ROLE) { grantRole(ISSUER_ROLE, account); } //Revoke the user (address) issuer role, and only allow the administrator role to call the function function revokeIssuerRole(address account) public onlyRole(DEFAULT_ADMIN_ROLE) { revokeRole(ISSUER_ROLE, account); } /** * Get the carbon footprint of ccer assets by token id */ function getFootprintByTokenId(uint256 tokenId) public view virtual returns (FootprintItem memory) { require(_exists(tokenId), "CCER's Carbon Footprint: Query URI for a non-existent token"); FootprintItem memory footprintItem = _footprintMapping[tokenId]; return footprintItem; } /** * Get the carbon footprint of the ccer asset by reporting hash */ function getFootprintByHash(string memory hash) public view virtual returns (FootprintItem memory) { require( _existsHash(hash), "CCER's Carbon Footprint: Query Carbon Footprint for a Non-Existent Hash"); uint256 tokenId = _hashTokenMapping[hash]; FootprintItem memory footprintItem = _footprintMapping[tokenId]; return footprintItem; } /** * Change support interface */ function supportsInterface(bytes4 interfaceId) public view virtual override(ERC721, AccessControl) returns (bool) { return interfaceId == type(IERC721).interfaceId || interfaceId == type(IERC721Metadata).interfaceId || interfaceId == type(IAccessControl).interfaceId || super.supportsInterface(interfaceId); } }

Table 5 below provides the code for the ERC-20 based carbon neutral token (CNT) contract to issue a certain amount of CNT tokens to an account. Table 5 Carbon neutral token (CNT) contract based on ERC-20 (CNTToken.sol). //Contract/CNTToken.sol pragma solidity ^0.8.0; import "@openzeppelin/contracts/access/AccessControl.sol"; import "@openzeppelin/contracts/token/ERC20/ERC20.sol"; import "./ICNTToken.sol"; contract CNTToken is ERC20, AccessControl, ICNTToken { struct ReportItem { uint256 tokenId721; address recipient; uint256 amount; } mapping (uint256 => uint256) private _tokenId721s; mapping (uint256 => ReportItem) private _reportItems; //Create a new role identifier for the minter role bytes32 public constant ISSUER_ROLE = keccak256("ISSUER_ROLE"); constructor(address administrator) ERC20("Carbon Neutral Token", "CNT") { //Grant the contract deployer the default administrator role: it will be able to //grant and revoke any role _setupRole(DEFAULT_ADMIN_ROLE, administrator); } // The minimum unit of CNT is 1. function decimals() public view virtual override returns (uint8) { return 0; } //Create a "amount" token and assign it to "account" // onlyRole(ISSUER_ROLE) function issue(address account, uint256 amount, uint256 tokenId721) override virtual public { //Verify that tokenId has been issued //require(_tokenId721s[tokenId721] == tokenId721, "This report has been published"); ReportItem memory reportItem = ReportItem ( tokenId721, account, amount ); _setReportItem(tokenId721, reportItem); //_tokenId721s[tokenId721] = tokenId721; _mint(account, amount); } function _setReportItem (uint256 tokenId721, ReportItem memory reportItem) internal { // _reportItems[tokenId721] = reportItem; } function getReportItem (uint256 tokenId721) public view virtual returns(ReportItem memory) { ReportItem memory reportItem = _reportItems[tokenId721]; return reportItem; } //Grant an account the "Issuer role", which is used to generate new tokens and then assign them to addresses function grantIssuerRole(address account) public onlyRole(DEFAULT_ADMIN_ROLE) { grantRole(ISSUER_ROLE, account); } //Revoke the "Issuer role" from an account (address) function revokeIssuerRole(address account) public onlyRole(DEFAULT_ADMIN_ROLE) { revokeRole(ISSUER_ROLE, account); } //Change, only allow administrator roles to call functions function transfer(address recipient, uint256 amount) public virtual override onlyRole(DEFAULT_ADMIN_ROLE) returns (bool) { return ERC20.transfer(recipient, amount); } //Change, only allow administrator role to call function function allowance(address owner, address spender) public view virtual override onlyRole(DEFAULT_ADMIN_ROLE) returns (uint256) { return ERC20.allowance(owner, spender); } //Change, only allow administrator role to call function function approve(address spender, uint256 amount) public virtual override onlyRole(DEFAULT_ADMIN_ROLE) returns (bool) { ERC20.approve(spender, amount); return true; } //Change, only allow administrator role to call function function transferFrom( address sender, address recipient, uint256 amount ) public virtual override onlyRole(DEFAULT_ADMIN_ROLE) returns (bool) { _transfer(sender, recipient, amount); return ERC20.transferFrom(sender, recipient, amount); } //Change, only allow administrator role to call function function increaseAllowance(address spender, uint256 addedValue) public virtual override onlyRole(DEFAULT_ADMIN_ROLE) returns (bool) { return ERC20.increaseAllowance(spender, addedValue); } //Change, only allow administrator role to call function function decreaseAllowance(address spender, uint256 subtractedValue) public virtual override onlyRole(DEFAULT_ADMIN_ROLE) returns (bool) { return ERC20.decreaseAllowance(spender, subtractedValue); } }

According to a specific example, the code shown in Tables 4 and 5 defines the CCERAsset smart contract and the CNT token contract for CCER projects. The data structures EmissionData, Certificate, and CCERItem define the fields (or elements/variables/attributes) stored by the CCERAsset smart contract. The emissionData structure has a field "co2" for storing CO2 emissions or reductions in tCO2e. The certificate structure is used to store information about CCER verification and redemption certificates. Each CCER project is published on the official website and is assigned a unique ID and name. The certificate structure therefore includes a field websiteURL to store the URL that can be used to access the website for the CCER project. Similarly, the CCERItem structure has two fields called assetID and assetName, which are used to store the assigned ID and name of the CCER item. The certificate structure is also used to store the URL of the report (or information package), which includes the CCER certificate (and redemption certificate) in the reportUrl field and a hash used to authenticate that the report has not been changed in the reportHash field. The CCERItem data structure also includes a description field, which includes the keys of the report in text format. The field tokenURI points to a JSON file that includes metadata for the NFT (for example, see https://eips.ethereum.org/EIPS/eip-721).

Once a CCERAsset is approved, the CNT token contract is called using the function approveCCERAsset to issue CNT to the owner of the asset. To establish a time series of linked contracts where subsequent contracts include additional emissions (or reductions) since previous contracts, the CCERAsset contract includes an addCarbonFootprint function, and Table 4 lists the code for the CarbonFootprint contract. The data structure FootprintItem in the CarbonFootprint contract has fields that are equivalent to the CCERItem fields. That is, the CCERAsset contract is first established as a birth contract, and then additional CarbonFootprint contracts are added to the blockchain and linked together. The function getCarbonFootprintIdsByParentTokenId obtains all carbon footprint tokens for a token id of a CCER asset and therefore allows obtaining all contracts in a time series.

The code shown in Tables 4 and 5 represents the code for AssetContract and CNT, which are used to execute and store on the Ethereum blockchain based on the ERC721 (non-fungible tokens) and ERC 20 (fungible tokens) Ethereum standards. More details can be found at https://eips.ethereum.org/EIPS/eip-721 and https://eips.ethereum.org/EIPS/eip-20. See also https://ethereum.org/en/, https://ethereum.org/en/developers/docs/standards/tokens/erc-721/ and https://docs.openzeppelin.com/contracts/3.x/erc721. Extension code may also be written based on this pseudo code to implement specific interfaces or features, such as using snapshots and error checking as needed. Similar code may be written for other blockchains based on the above code, and the code may be modified to work with other types of emission reduction certificates (in addition to CCER certificates). Similarly, some (or all) fields (e.g., websiteUrl, assetName, assetID, and description) may be incorporated into a report obtained, for example, at reportURL and may be omitted thereby. reportUrl and reportHash may be used for a single report (or information package) containing all relevant information about an asset. Alternatively, the information package may be split into multiple files, each with a separate reportUrl and hash, such as authentication certificates, redemption certificates, item descriptions, and any other associated documents that may be associated with an item or listing on an exchange. More generally, the report address (and indeed all addresses) may be a Uniform Resource Identifier (URI) address rather than a Uniform Resource Locator (URL) address. While a URL defines the location of a resource, a URI identifies a resource by name at a location (URL), and thus a URL is a subset of a URI. The report address will be used to define a URI or URL address.

As illustrated in Figure 1D, a VER asset contract 154 is published on the blockchain at a block address (VER smart contract address) and acts as a digital birth certificate. VER reports (information packages) are stored in the description section of the contract. The block information (block address) of the published VER asset contract is received 174 by the application 111 and stored 175 in a database 113 such as an AWS RDS database. The exchange approves the VER report (information package) 176, and this approval 176 triggers (or calls) the CNT token contract 156 (generated via an ERC 20 smart contract, as described above in Table 5) to issue (or generate) CNT tokens to an account based on the CO2 emission reductions included in the VER report (information package). The issued CNT tokens are then listed 178 against the assets (and asset holders) in the ledger 114. In one specific example, CNT is stored in a cold wallet of a trading platform for a closed regulatory agency. Alternatively, it can be stored on a public blockchain or in some other storage location. When a file stored in a URL or anywhere else is called by an existing or potential CNT investor (or any asset-collateralized token investor), the file is verified by its hash code corresponding to the ERC721 contract to ensure its authenticity.

This VER asset contract 154 thus corresponds to a generated information package signed by the exchange. Subsequent data (e.g., daily, monthly, quarterly, or annually) generated by real-world assets such as other documents or captured via data acquisition systems is submitted to the exchange to form subsequent (or subsequent) information packages with a timestamp (time t ). Whenever such a subsequent timestamped information package is submitted to the exchange, the application 111 will use the information package to establish another VER asset contract linked to the previous VER asset contract.

That is, any new information submitted to the exchange will be captured by subsequent VER asset contracts. Thus, each subsequent VER asset contract will have not only one description of the uint256 ID of the information at this time t , but also another description linking to the address of the VER asset contract of the previous information submitted to the exchange (i.e., at t -1). This enables the creation of a time series of linked emission reduction smart contracts that form a NFDT representing a real-world asset with a real-life information flow of carbon neutral status. The digital representation of an asset is therefore a time series (or time ordered chain) of smart contracts.

Therefore, the birth information package signed by the exchange and all subsequent information packages with timestamps form a real-world information flow of the carbon neutrality status of the real-world asset. NFDT is built on the blockchain to reflect and protect the authenticity of real-world information in the digital world.

Similar to the listing of carbon emission reduction activities and the generation of CNTs through the submission of an information package as illustrated in FIG. 1D , an asset holder may appeal to an exchange to list an asset, as illustrated in FIG. 1B and Table 4. In this specific example, an asset holder 130 prepares an information package containing carbon emission-related data of the asset, and the data is used to calculate the carbon footprint attribute value (ENV value) of the asset. This calculation may be performed by the asset holder 130 and verified by a third-party entity 140, or the asset holder may submit the information to a third-party entity 140 to perform the calculation. This certificate is included in the information package uploaded to the file system 112. The exchange reviews the submitted information package, and if the package meets the listing criteria, it will approve the listing and digitally sign the package. This is submitted to a smart contract, such as the VER asset contract 154 or similar, to generate a NFDT representing the asset, and store (and therefore bind) the asset's carbon footprint attribute value (ENV value) to the NDFT (digital twin) at birth. This is then approved and stored in the database 113, and the asset can then be listed on an exchange. If the asset's ENV value is positive, the appropriate amount (or appropriate number) of CNT tokens is issued using the CNT token contract 156. If the ENV value is negative, the asset holder can then purchase CNT tokens from CNT token holders to achieve a net zero carbon neutral value, as illustrated in Figure 3. This can be performed using the safeTransferFrom or transferForm interface of the VER asset contract or by another smart contract, and the details of the transaction are stored on the blockchain. Additionally (and as discussed above), in the event that an asset continues to (or subsequently) generate additional emissions (such as a thermal power plant, chemical plant, etc.), another information package can be submitted to the exchange to record the additional emissions at a subsequent time t , and the asset's ENV value is then updated with this transaction recorded on the blockchain. Transactions can be linked to previous transactions to provide a chain of traceable transactions.

When a VER is redeemed (or retired) in a jurisdiction, the redemption certificate issued by the National Registry will be locked to a regulatory body directly controlled by the exchange (or trusted party). This is to prevent the redemption certificate from being used by the owner for any other purpose. In addition, in applications for CNT issuance, third parties can be used to verify and authenticate the authenticity of the redemption certificate.

When an investor buys CNT on an exchange, he or she can use CNT for two purposes. The first purpose is to keep CNT alive, such as for trading purposes, or to use it for carbon footprint management purposes in his or her own financial trading account. Investors can buy and sell CNT at any time to obtain profits and income, and the investor's portfolio will reflect the carbon value of all assets.

The second purpose is to freeze CNT permanently. That is, investors may have other assets in their real life that produce carbon footprints, and they may want to be "carbon neutral". Therefore, investors can buy the same amount of CNT on the exchange, and then request the exchange that they want to burn CNT to neutralize their carbon footprint in the real world. Therefore, in a specific example, this can be implemented using the following method: 1. The investor works with a whitelist certification vendor to certify the carbon footprint of the asset they want to neutralize (such as their office building). 2. The certification/verification vendor (i.e., a third-party entity) provides a certificate that proves that this asset has a certain amount of CO2 at a specific time (for example, 10 tons in 2020). 3. The investor purchases the required amount of CNT on the exchange (for example, 10 CNT). 4. The investor then submits a Neutralization Information Package containing a carbon neutrality report to the exchange, which has an application form, a certificate of its asset footprint, and CNT purchased on the exchange. 5. After the exchange reviews the documents and deems them in order, the exchange, the certification provider, and the investor digitally sign the entire Neutralization Information Package and generate one or more hashes for authenticating the documents and/or the Neutralization Information Package. 6. The exchange will deduct the amount of CNT (e.g., 10 CNT) from the investor's ledger and mark these CNT as permanently frozen on the exchange's CNT blockchain. 7. The Exchange will create a block on the Exchange's CNT blockchain that will record the investor's name, the asset to be neutralized, the certification vendor, the certificate, the hash of the neutralization information package (used to protect such information) and the hash of the "Carbon Neutral Certificate" document issued by the Exchange. 8. The Exchange, together with an authoritative institution, will issue a unique non-homogeneous carbon neutrality certificate to the investor to prove its efforts in carbon neutrality. Investors' carbon neutrality efforts for real-world assets also represent the deflationary part of the CNT economy, while building green projects to generate CNT is the inflationary part of the CNT economy.

2A to 2F further illustrate specific examples.

2A is a flow chart of a method for establishing NFDT and CNT on a digital exchange according to a specific example. An offering memorandum is created as a PDF 201. The offering memorandum may contain asset information, third-party verification, and ENV values (electronic carbon footprint tags). The PDF may be password protected to prevent editing or copying. The password may be randomly generated and kept or discarded if there is no intention to edit the file. A hash (Hash 1) is generated 203 from the PDF. This is used to verify the integrity of the PDF file. Hash 1 will be published in the public Ethereum chain and used to verify the PDF in the NFDT and smart contract to ensure authenticity. The PDF is then uploaded to the website 205. In a specific example, a PDF is uploaded to a department in an exchange (e.g. CTX.sg), and we publish Hash 1 in a NFDT in public Ethereum. Hash 1 can be used by the public to verify the integrity of the file. We then create NFDT 207. This is based on ERC 721 (the NFT standard). The NFDT is a time series of ERC-721 contracts, where the time N smart contract has an identifier that links to the address of the smart contract at time N-1. The first ERC-721 will contain a URL link to the PDF and Hash 1 of the PDF file. This serves as the birth smart contract for the NFDT. We then create CNT 209. This is based on ERC-20. The smart contract with the identifier linked to the address of the ERC-721 contract that created the NFDT will contain the same URL as the URL of the NFDT it points to. More generally, this is a way to generate asset-backed tokens (ABTs) for carbon emitters or assets. We then connect to the Ethereum network 211. Anyone who encounters the NFDT and ABT (or CNT in this case) on the blockchain can access the PDF via the published URL. The PDF file will be verified by the published hash code to ensure authenticity.

FIG. 2B is a schematic diagram of an asset owner 220 with a positive environmental footprint (positive ENV) 222 for generating carbon neutral tokens (CNTs) according to a specific example. Each asset generates 2 values: financial data and/or operating data 224 and environmental (ENV) data 222. Environmental data includes offsetting data collected from the asset. Data can be collected using a secure data acquisition system as described below. ENV data 222 is verified by a third-party authorized institution 226 and used to use CNTs. In addition, financial and operating data 224 are prepared and verified by third-party accountants and lawyers who provide additional or supporting documents to verify financial and operating data 228. The offering memorandum is submitted to the exchange 230 (CTX) and reviewed by the listing committee. Asset-backed tokens (ABTs) may then be issued and listed on the exchange 230, where each asset-backed token is based on one or more financial and/or operating metrics from financial and/or operating data with zero ENV. ABTs and CNTs may be traded on the digital exchange 230. CNTs may then be used to carbon neutralize real-world assets 232. That is, entities with a carbon footprint in the real world may purchase CNTs on the exchange 230 and permanently freeze them, and use them to neutralize their real-world carbon footprint, and obtain a carbon neutral certificate, and the exchange (CTX) stores information of such actions on the carbon neutral blockchain. Financial investors 234 can purchase CNT, ABT or both from the exchange (CTX) and update the carbon footprint of the portfolio based on the purchase to obtain a positive or zero ENV portfolio 236 on the exchange.

2C is a schematic diagram of an asset owner 220 with a positive environmental footprint (positive ENV) to generate autonomous emission reduction certificates, which are sold to buyers 246 who use the autonomous emission reduction certificates 242 to obtain carbon neutral tokens (CNT) 252 and generate NFDT 250 representing the asset on the Ethereum blockchain 254, according to a specific example. This figure illustrates the registration of offset activities in the National Carbon Registry 240, the issuance of autonomous emission reduction certificates, which are then frozen in the carbon registry, thereby triggering the issuance of redemption certificates. This can be done by the original asset owner or the buyer 246. As discussed above, these are submitted to exchanges 230 that allow the creation of NFDTs and CNTs that can be traded outside the country of origin that issued the VER.

2D is a diagram of an asset owner 260 having a negative environmental footprint (negative ENV) 262 listed on a digital asset exchange 230, according to one specific example, where the negative carbon footprint can be offset by an investor 232 by also purchasing CNTs. As discussed in FIG. 2B , financial and/or operating data are prepared and submitted to an exchange, which issues asset-backed tokens (ABTs) with negative ENV based on this information (e.g., one or more numerical values/quantitative metrics within the financial and/or operating data (e.g., profit, revenue, number of products sold, production rate, uptime or uptime percentage, etc.). ABTs with negative ENV can be traded by asset owners, who can purchase some CNTs to offset the negative ENV. Alternatively or additionally, CNTs can be bundled with listed assets to enable asset owners to meet ESG requirements from shareholders or listing locations.

FIG2E is a flow chart of a method for establishing a NFDT 250 for representing an asset 220 with a positive environmental footprint (positive ENV 222) according to a specific example. At times T0, T+1 and T+2, we obtain a carbon reduction certificate 242, a redemption certificate 244, and use this to issue a series of smart contracts 250, where each smart contract is linked to the previous smart contract and is used to generate CNT 252.

FIG2F is a flow chart of a method for establishing a NFDT 274 for representing an asset 260 with a negative environmental footprint (negative ENV 262) according to a specific example. The offering memorandum 272 captures the carbon emissions of the asset at the time of listing and is used to form a birth contract at T0. Quarterly reports are then generated, each capturing additional emissions, and each report is used to issue additional smart contracts to form a time series of linked smart contracts 274, which can be used to issue asset-backed tokens ABT, and the ENV value on the ledger is updated after each smart contract 276.

According to one specific example, CNT holder 120 may also be an asset holder at the same time, and may trade his CNT on an exchange, or alternatively, hold CNT for his own use.

According to a specific example, CNT and corresponding carbon offset data can be secured and stored by using a blockchain and/or smart contract, and the blockchain and/or smart contract can be provided and maintained by the exchange 110 or an independent third party.

According to a specific example, the value of ENV and the corresponding carbon emission data can also be fixed and stored by using a blockchain and/or a smart contract, and the blockchain and/or the smart contract can be provided and maintained by the exchange 110 or an independent third party.

According to other specific examples, the CNT holder 120 may not hold assets to be traded on the exchange, for example, when the CNT holder 120 is an individual or an environmental organization, but only contributes to carbon offsets by performing green actions, such as green travel, tree planting and garbage sorting, and thereby obtains corresponding CNTs.

According to a specific example, the third party entity 140 can monitor, calculate and evaluate the assets of the asset holder 130 for the carbon footprint attribute (ENV) value, and can also have the ability to monitor, calculate and evaluate the generation of CNT. In some specific examples, the third party entity calculates and/or audits data corresponding to the carbon footprint attribute (ENV) value and/or carbon neutrality tokens in an offline manner; in other specific examples, the third party entity calculates the carbon footprint attribute (ENV) value and/or the amount of carbon neutrality tokens online in real time in the asset trading system, generates a secure digital certificate and triggers a smart contract on the carbon neutrality blockchain based on the secure digital certificate. This application can be implemented in an online authorization setting, allowing companies to authorize access to third-party entities and upload carbon emissions or carbon offset data in real time for real-time or scheduled calculation of ENV or CNT quantities. This can greatly improve the efficiency of third-party calculations and audits of data and shorten the time to issue secure digital certificates.

Depending on the specific instance, the calculation of ENV and the calculation of CNT may be performed by the asset holder 130 and the CNT holder 120, respectively, and then audited by the third party entity 140, or alternatively, ENV and CNT may be calculated and determined by the third party entity 140. In some cases, the asset holder may not be willing to provide its carbon emission data, and the third party entity may determine the ENV of the asset based on a preset standard. If the asset holder believes that the ENV determined by the third party entity based on the preset standard is inaccurate, it may file a complaint and receive an offset in the form of CNT if the complaint is verified by the third party entity.

According to another specific example, the system may include a support system (not shown in the figure) that assists third-party entities and CNT holders in issuing CNT. For example, the support system may include: a data acquisition module for CNT holders who self-perform carbon offset actions to obtain carbon offset action related data; a calculation module for assisting third-party entities to calculate positive ENV and the amount of carbon neutral tokens corresponding to positive ENV based on the carbon offset action related data, wherein the calculation method may be provided by the third party or provided by the support system and approved by the third-party entity; an authentication module for assisting third-party entities to generate a secure digital certificate related to the amount of CNT; a communication module for providing the amount of CNT and the secure digital certificate to the blockchain in real time to trigger a smart contract, wherein the smart contract may also be provided by the support system. Furthermore, according to a specific example, the blockchain may also be provided by the support system.

FIG. 3A is a flow chart of a method 200 for calculating ENV according to one embodiment of the present application.

At step 310, actual carbon emission data corresponding to the asset and normalized carbon emission data for the asset class are obtained. Depending on the asset class, the type and amount of normalized data may vary.

In step 320, ENV is calculated using a method corresponding to the asset class. Specifically, Equation 1: _Ebaseline is the _CO2 equivalent emissions ( _tCO2e ) in the baseline scenario determined based on the normalized carbon emissions data of the asset class; _Eactual is the _CO2 equivalent emissions ( _tCO2e ) determined based on the actual emissions data of the asset.

When an asset's carbon emissions are below the baseline, its ENV is positive, indicating a positive carbon footprint attribute; conversely, when emissions are above the baseline, ENV is negative.

If the holder holds multiple assets, the sum of the carbon footprint attribute values can be represented by the total attribute value (ENV _total ): Equation 2 Where i is the series number of the asset, and n represents the number of assets held by the asset holder.

Based on the asset tag, _{the total} ENV of the asset portfolio held by the investor in the holding year can be calculated. For example, if in 2021, the asset holder holds the BTC issued in that year and the thermal power plant asset STO issued in 2019, the depreciation period is 20 years, as shown in Table 1: Table 1 The total ENV of the asset portfolio held by the investor in the holding year. ENV (tCO ₂ e)/asset share Issue Year Emission duration (years) Number of shares held 2021 Thermal Power Plant Assets STO -100 2019 2 1000 -200000 BTC -170 2019 One time only 1000 -170000 _Total ENV (tCO ₂ e) -370000

When ENV is _always 0, it means that all assets of the asset issuer or holder are carbon neutral; when ENV is _always negative, it means that the total carbon offset of green assets held by the asset issuer or investor cannot offset the carbon emissions of high-emission assets held by the asset issuer or inventor.

According to a specific example, in response to asset holders choosing not to self-declare carbon emission-related data for assets, third-party entities may set a default ENV for assets based on the asset category. As appropriate, asset holders may apply to the exchange to correct the ENV tied to their assets within 12 months after the asset is issued by providing an authoritative third-party entity's ENV audit report and relevant data sources; and the exchange may, after verifying the ENV, record it in the carbon neutral blockchain and make corrections by granting or not granting CNT.

At step 330, the calculated ENV is bound to the asset (e.g., by inclusion in a smart contract).

For traditional physical assets, calculating their ENV requires considering how long the asset has been held and how the asset's carbon emissions change over time.

For commodity/product based assets, such as gold, diamonds and bitcoins, their carbon footprint or emissions are generated once and for all during the acquisition, discovery or production of the commodity/product, and the ENV and acquisition time of the asset are recorded in the carbon footprint attribute value included in the smart contract when the NFDT smart contract is issued, and are therefore tied to the asset. For these assets, the ENV does not usually change over time, and therefore the NFDT may only include the ENV value for the generated contract. The journal can also be used to store the ENV value.

For example, mining digital currencies such as Bitcoin (BTC) itself does not produce carbon emissions; however, the process of obtaining virtual assets may consume energy, and the same amount of virtual assets may produce different amounts of carbon emissions.

The calculation method of CNT is basically the same as that of ENV, and when the calculated ENV is positive, the corresponding CNT amount can be obtained. According to a specific example, the positive ENV or corresponding certification report provided is only valid after being verified by an authoritative third-party entity.

According to a specific example, each CNT holder could be capped on the amount of CNTs that can be obtained each year, i.e., carbon offsets that can be verified by a third party and are below the baseline emission standard: Equation 3 Wherein CNT _MAX is the upper limit of the amount of CNT that can be obtained each year, i is the series number of the asset that meets the carbon offset criteria, n is the amount of all assets that meet the carbon offset criteria, _Ebaseline is the baseline emissions corresponding to the asset category and verified by a third-party authorized organization, and _Eactual is the actual emissions verified by a third-party entity.

According to other specific examples, planting one tree may correspond to one CNT; of course, there may be an upper limit on the amount of CNTs that can be obtained in a year.

According to a specific example, an exchange can trigger a smart contract on the carbon neutral chain to issue and store ENV and/or CNT of assets. For example, the organization can be verified by a third-party authoritative entity in a monitorable, traceable and quantifiable manner. For example, if in 2021, the positive ENV from consumers' green travel totals 10,000 tCO ₂ e, 10,000 CNTs can be generated on the CNT chain. The economic benefits brought by CNT can be distributed to consumers through the platform, thereby promoting green consumption.

Different types of companies or projects may use different methods to calculate ENV or CNT, especially for virtual assets such as Bitcoin. The calculation methods used for different asset categories including Bitcoin, green travel, photovoltaic and wind power generation, and building distributed energy resource systems are described below as examples.

As a specific example, for project-based assets that continuously generate greenhouse gas emissions, such as thermal power plants, photovoltaic power plants, and chemical plants, the ENV of the asset is the annual average of _CO2- equivalent emissions above the threshold value calculated based on the size of the asset: Equation 4 Where n is the depreciation period of the asset; ENV _LC is the total carbon footprint attribute value of the asset during its life cycle, assuming the emissions are the same each year. When an asset is issued in an exchange, an electronic tag for the carbon footprint attribute with the asset's ENV _ave and the asset's starting year T ₁ is recorded. An investor holding an asset at time T has the asset's ENV value (TT ₁ )•ENV _ave . In addition, the ENV of a project-based asset can be determined based on the cumulative audited ENV value of the asset each year, where the audited ENV value can be based on the audit report of an authoritative third-party entity and related data sources.

According to a specific example, because the mining machines that mine Bitcoin perform a lot of calculations and consume electricity, obtaining Bitcoin will generate a certain amount of carbon emissions. The carbon footprint of Bitcoin mining in a certain period of time and space mainly depends on: HP_s: The computing power required to mine one BTC per unit time (one hour), which is determined based on the computing difficulty of the Bitcoin operating network during that period; P_to_H: The ratio of power to computing power of all mining machines at that time and space; PUE: The ratio of the total energy consumption of all mines (including auxiliary equipment such as heat sinks) to the energy consumption of mining machines at that time and space, because the mine consumes energy in other parts besides mining machines; and EF: The average carbon emission factor of the local power grid. Among them, the carbon emission factor may vary depending on the region where the mine operates and the type of energy used.

In the case of thermal power, the carbon emission factor is calculated based on the national average carbon emission factor of thermal power: 0.997 kg/kwh; in the case of dedicated power supply such as photovoltaic, hydropower and wind power, the carbon emission factor can be regarded as 0 kg/kwh; in the case of commercial power supply, the carbon emission factor is calculated based on the local operating marginal emission factor and China's regional power grid carbon emission factor.

Then, the average carbon footprint of each Bitcoin in that time and space is: _Eactual = HP_s • P_to_H • PUE • EF Equation 5

The power to hashrate ratio P_to_H of a mining machine can be calculated in several ways.

Calculation method 1: P_to_H is obtained by training with the following data (Hardware_data, Power_data, Hp_data). Through supervised learning, Hardware_data (a database of performance parameters of all available mining machines on the global market), Power_data (a database of energy consumption data of all known mines in the world) and Hp_data (a database of computing power of all known mines in the world) are used for training and predicting the average P_to_H in a given time and space;

Calculation method 2: Equation 6 Where Difficulty_Data is the global computing power change curve; Power_Price_Data is the electricity price at that time and space; Capex is the mining machine hardware cost level at that time and space; Profit_Margin is the minimum profit margin level for the Bitcoin mine owner to maintain the mine operation at that time and space; L is the lag time between the owner's decision to replace the equipment/mining machine and the actual replacement of the equipment, in other words, the time required to replace the mining machine; and BTC_Price is the Bitcoin price change curve.

Through the above method, taking into account the lag time of hardware replacement decisions, the changes in Bitcoin prices in time and space, the computing power requirements, the Bitcoin mining costs (capital expenditures and operating expenses) and the minimum profit margin requirements of the owner are all taken into account to calculate the minimum P_to_HP that meets the above requirements.

Assuming the expected profit rate is 30%, the current P_to_HP is used to determine whether the expected profit rate can be met. If not, the owner has the motivation to replace the mining machine (replace it with a more expensive or cheaper mining machine) to meet the profit rate. There may be a lag time L between the decision to replace the mining machine and the actual replacement, and taking this lag time into account can make the calculation result more accurate.

Alternative methods can also be used, for example in the mining area, equation 5 can be modified by replacing HP_s•P_to_H with P*t, where P is the average power (kW) of the mining machine used and t is the time (hours) required to generate Bitcoin for the average hashing power of the mining machine hardware. The average time t required for each mining machine to theoretically generate Bitcoin depends on the mining machine's own computing power (hashing power, HP, TH/h) and the mining difficulty (network hashing rate requirement) defined by pay per share (PPS, 1 BTC/h•TH), then t=1/(PPS; HP). According to the Bitcoin generation rule, the fluctuation of PPS mainly depends on the mining difficulty and the periodic halving of Bitcoin rewards. Among them, mining difficulty is a measure of the hashing rate required to generate a new transaction block. As time goes by, the difficulty of Bitcoin mining gradually increases, so we need to choose mining machines with more powerful computing power.

On average, Bitcoin produces a block every 10 minutes. After every 210,000 blocks, the block reward is halved. Therefore, the Bitcoin reward is halved every four years on average. In order to ensure that there is an average of one block every 10 minutes, the difficulty of Bitcoin is adjusted dynamically, once per cycle, and therefore each cycle has 2016 blocks, and the difficulty is adjusted every 14 days (on average). Each block contains a certain number of Bitcoins. Initially, each block contained 50 Bitcoins, which is halved every four years on average. The current block reward is 6.25, and the next (fourth) halving time is expected to be March 16, 2024. As the number of miners and mining machines increases, the computing power of the entire network will be improved. In order to ensure the stability of block time, the difficulty will also increase, which makes PPS smaller and the mining time t increases. Due to the increase in global computing power and the increase in computing power difficulty much faster than the increase in mining machine efficiency, the carbon footprint generated by Bitcoin is rapidly increasing.

Based on the above calculation principle, the exchange can use the following parameters to calculate the default carbon emission value (ENV value) of Bitcoin issued by the exchange. According to the default ENV value issuance rules of the exchange, this set of coefficients represents the computing power and energy consumption standards of the relatively backward industry-level mining machines in issuance. P=3360, HP=80; PPS=0.0000065; PUE=1.1 and EF=0.997. Based on these values, the time required for a single mining machine to mine Bitcoin is t=49156.2 h, and the carbon emission of Bitcoin is . Therefore, the default ENV of Bitcoin issued on exchanges in January 2021 is defined as -170 tCO2e. If the actual mining machine has a higher energy efficiency ratio, this value will change (for example, if P is 3245W, it will be reduced to -130). If the issuer can pass the authoritative certification of a third party and prove that it does use mining machines and verifies that the carbon footprint is -130 tCO ₂ e, the issuer can issue the difference between the default ENV and the actual ENV, which is 40CNT. If the issuer passes the authoritative certification of a third party and proves that its Bitcoin is completely generated from renewable energy (such as hydropower) and proves that its emission factor is 0, the actual ENV of Bitcoin is 0, and the issuer can issue 170 CNT.

The above method is also applicable to other digital currencies that need to be mined, such as Ethereum (ETH).

According to a specific example, when clean energy is used as a driving source for green travel vehicles, for example, when electric vehicles or hydrogen fuel vehicles are used for travel, the E _baseline can be determined based on the existing carbon emissions generated by, for example, gasoline or diesel vehicles, and the estimated carbon emissions can be determined based on green travel data (including but not limited to the actual electricity consumption of the vehicle at each driving speed and mileage, combined with the local grid carbon emission factor and fossil fuel emission factor). Because the data of shared travel or online car-hailing platforms are easier to obtain and analyze, the following description is based on the example of an online car-hailing platform that operates green travel: Green travel carbon emissions E _actual = actual electricity consumption per order × regional grid carbon emission factor. Fossil fuel travel carbon emission E _baseline = fossil fuel consumption of fuel vehicles simulated using digital twin technology under actual order boundary conditions × fossil fuel carbon emission factor.

More specifically, the online ride-hailing platform can output the driving conditions of electric vehicles in real time, including but not limited to the charging and discharging data of clean energy vehicles, driving speed, mileage and other driving data; all boundary conditions can be input into the digital twin simulation system, and through computer simulation, the fossil fuel consumption and carbon emissions of fuel vehicles under the same operating conditions can be calculated based on the boundary conditions, thereby determining the carbon emissions of fuel vehicles under the same order conditions.

Therefore, the carbon offset for each order of new energy vehicles is Formula 1: .

Specifically, a ride-hailing platform may upload the required data instantly at the end of each order; using the methods discussed previously, the ENV of each order can be calculated and electronically verified by a third party, and CNT can be obtained. Similarly, a shared bicycle or payment system can also upload data and calculate CNT instantly.

The above calculation method may also be applicable to personal or business travel purposes according to other specific examples.

According to a specific example, CNT can also be calculated for photovoltaic or wind power generation projects. Because photovoltaic and wind power generation do not consume carbon emission energy, E is _actually 0, and the final ENV is the E _baseline , and the corresponding CNT can be obtained, that is, ENV = grid-connected energy × carbon emission factor of the local power grid; Among them, the grid-connected energy is the actual grid-connected energy of the photovoltaic/wind power plant; the carbon emission factor is the carbon emission factor of the thermal power plant when generating the same grid-connected energy.

Parameters associated with grid-connected energy include but are not limited to: installed capacity, location and power generation hours of the photovoltaic/wind power plant. The grid-connected energy can be calculated from the installed capacity and power generation hours.

According to a specific example, CNT can also be calculated for carbon offsets in distributed energy projects such as microgrids. The relevant parameters include but are not limited to microgrid self-generation/energy generated by building/residential users in the microgrid, purchased electricity, grid-connected energy (electricity sold to the grid outside the microgrid), and electricity purchased or sold by users within the system. The carbon emissions caused by the actual operating energy consumption of the project can be calculated, and in the equivalent case of using a learned energy system provided by the municipal authority, the baseline carbon emissions can be calculated based on the same boundary conditions of the project.

The actual carbon emissions of the project are defined as the difference between the actual operation situation ( _Eactual ) and the situation where there is no microgrid and all reliance is placed on the known grid ( _Ebaseline ), according to Formula 1: .

Among them, since the carbon emissions of energy consumed by the new energy microgrid are zero, E _actually only comes from the carbon emissions corresponding to the electricity purchased by the user from the self-learning grid (external electricity), which can be calculated according to the following equation: Equation 7

Moreover, the total electricity consumption of users is the sum of electricity purchased from the power grid outside the microgrid, electricity purchased from other users in the microgrid, self-generated electricity (grid-connected energy) sold to the power grid outside the microgrid and sold to other users in the microgrid. Therefore: Equation 8 Where Qself _{-generation , i} is the amount of electricity generated by the building/residential users within the microgrid area through self-generation; _{Qpurchase , i} is the amount of electricity purchased by the building/residential users within the microgrid area from the power grid outside the microgrid. _{QGrid , i} is the amount of grid-connected electricity/energy that is spontaneously generated by building/residential users in the microgrid area and sold to the grid outside the microgrid; _{QSold within the microgrid , i} is the amount of electricity sold by building/residential users in the microgrid area to other building/residential users in the same microgrid area; _{QPurchased within the microgrid , i} is the amount of electricity purchased by building/residential users in the microgrid area from other building/residential users in the same microgrid area; EF(t) is the real-time regional grid carbon emission factor that comprehensively considers the impact of real-time photovoltaic power feedback in the microgrid area on the regional grid carbon emission factor.

The carbon offset is then given by Equation 1 (ENV = _Eactual - _Ebaseline ).

Specifically, in addition to considering the carbon offset brought by the microgrid system, the microgrid data can be captured in real time. The method of the present invention calculates the weighted average of the energy generation data in the regional power grid in real time and obtains the real-time regional power grid carbon emission factor.

FIG3B is a flow chart of a method 340 for trading carbon neutral tokens CNT according to one specific example of the present application.

At step 350, the ENV of the asset to be traded is calculated based on a preset standard or carbon emission related data generated by acquiring or maintaining the asset, and the ENV is bound to the asset.

At step 360, the CNTs are monitored.

At step 370, after a CNT transaction between an asset holder with negative ENV and a CNT holder, the asset holder's ENV _total is updated.

As appropriate, in step 380, the CNT transaction record is stored on the carbon neutral blockchain. Using blockchain technology and smart contracts to build a distributed shared ledger and database, its decentralization, tamper-proof, visible and invisible, traceability characteristics are jointly maintained, and openness and transparency can effectively record actions at any point in time, which is important for users and regulators to analyze and track such actions.

Tables 2 and 3 show the changes in account details before and after the transaction between the two parties. Table 2 Account details before the transaction Account A before the transaction Account B before the transaction ECON _Total = $6M ECON _Total = $200,000 ENV _total = -17000 ENV _total = 20000 Assets Asset Type Number of shares ECON ENV Assets Asset Type Number of shares ECON ENV BTC Token 100 $5M -17000 CNT Token 20000 $200000 20000 USD Legal tender Not applicable $1M 0 Table 3 Account details after the transaction Account A after the transaction Account B after the transaction ECON _Total = $6M ECON _Total = $200,000 ENV _total = 0 ENV _total = 3000 Assets Asset Type Number of shares ECON ENV Assets Asset Type Number of shares ECON ENV BTC Token 100 $5M -17000 CNT Token 3000 $30000 3000 CNT Token 17000 $170000 17000 USD Legal tender Not applicable $170000 0 USD Legal tender Not applicable $830000 0

As shown in the table, account A purchased 17,000 CNT from account B. The market price of CNT is $10/CNT. Before the transaction, the total carbon footprint attribute value ENV of account A _is -17,000; the total carbon footprint attribute value ENV of account B _is 20,000, and the CNT value is 20,000. Account A spent $170,000 to purchase 17,000 CNT at a price of $10/CNT. After the transaction is completed, the _total ENV in account A is zero; therefore, the income in account B is $170,000, and its CNT balance is 3,000.

Based on the above discussion, we can now define specific examples of methods for generating carbon neutral tokens, generating digital representations of assets for trading, and trading them on digital exchanges while taking into account the carbon footprint of the assets.

4A and 4B are flow charts of a method 400 for generating a plurality of carbon neutral tokens representing carbon offset actions for trading according to a specific example. The method may include: Obtaining 401 a carbon emission reduction certificate and a carbon emission redemption certificate associated with a carbon offset action that generates carbon emission reductions from an issuing authority in a country. The carbon emission reduction is verified by a third-party verification authority or issuing authority, and the redemption certificate prevents further trading of the carbon emission reduction certificate in the country. Placing the carbon emission redemption certificate in a regulatory agency to prevent further trading or use of the carbon emission reduction certificate 402. Generate an information package and store it 403 at a reporting address, wherein the information package includes at least the carbon emission reduction, the carbon emission reduction certificate, the redemption certificate and information about the carbon offset action. Additional information may also be included, including basic information about the assets that generate carbon emission reductions and data used to calculate emission reductions. Cryptographically sign the information package and obtain a hash 404 for authenticating the information package. In a specific example involving a trading platform such as a digital exchange, the information package can be cryptographically signed by the exchange listing committee, the issuer and the key service provider of the information package, and multiple hashes can be generated for authenticating and verifying the information package or the components contained therein. Inputting 405 the hash of at least an owner address, an identifier, the carbon emission reduction, the reporting address, and the information package to an emission reduction smart contract in a blockchain, wherein once published on the blockchain, the emission reduction smart contract defines a birth smart contract, and the submitted information is stored on the blockchain at a birth smart contract address. Using the birth smart contract and the carbon emission reduction contained therein to obtain a plurality of carbon neutral tokens (CNT) by executing a CNT smart contract on the blockchain 406, wherein the amount of carbon neutral tokens issued is determined from the carbon emission reduction in the birth smart contract. Storing the plurality of CNTs 407. This may be in a cold wallet, on a blockchain, or other storage location. Selling one or more of the plurality of CNTs for trading 408. Publishing 409 a plurality of smart emission reduction contracts on the blockchain, wherein each smart emission reduction contract is published at a different time, and each smart emission reduction contract after the birth smart contract includes an additional carbon reduction since the publication of the previous smart emission reduction contract and a link to one or more of the previous smart emission reduction contracts published on the blockchain including the birth smart contract. The birth smart contract and the plurality of emission reduction smart contracts form a time series of emission reduction smart contracts, which define a unique non-fungible digital twin (NFDT) representing the offset action. In addition, if the additional carbon emission reduction in one of the plurality of emission reduction smart contracts is positive, the respective emission reduction smart contract is used to obtain additional carbon neutrality tokens (CNTs) by executing a CNT smart contract on the blockchain, wherein the amount of carbon neutrality tokens issued is determined from the carbon emission reduction in the respective emission reduction smart contract; storing the additional CNTs; and selling one or more of the additional CNTs for trading.

The above method can be changed and improved. In a specific example, for each of the plurality of smart emission reduction contracts, the method further includes: Obtaining a subsequent carbon emission reduction certificate and a subsequent carbon emission redemption certificate related to the carbon offset action that generates the additional carbon emission reduction from the issuing authority in the country, wherein the additional carbon emission reduction is verified by a third-party verification authority or the issuing authority, and the subsequent redemption certificate prevents further trading of the carbon emission reduction certificate in the country; Placing the subsequent carbon emission redemption certificate in the regulatory agency to prevent further trading or use of the subsequent carbon emission reduction certificate; Generate a subsequent information package and store it at a subsequent reporting address, wherein the subsequent information package at least includes the additional carbon emission reduction, the subsequent carbon emission reduction certificate and the subsequent redemption certificate; Cryptographically sign the subsequent information package and obtain a subsequent hash for authenticating the subsequent information package; and At least the owner address, the identifier, the additional carbon emission reduction, the subsequent reporting address and the subsequent hash of the subsequent information package are input into the smart emission reduction contract in the blockchain, wherein once published on the blockchain, the smart emission reduction contract forms a subsequent smart emission reduction contract of the NFDT, and the submitted information is stored on the blockchain at a subsequent smart contract address.

CNTs may be offered for trading outside of the country that issued the carbon reduction certificate. The CNTs may be offered for trading on a digital asset exchange, which maintains a ledger of CNTs for trading on the digital asset exchange, and the plurality of CNTs are stored in a cold wallet associated with the digital asset exchange. The digital asset exchange may contain a plurality of listings, each of which is a digital representation of an asset that can be traded on the digital asset exchange by an issuing entity, and the ledger stores the carbon footprint attribute value of each listed asset.

An issuing entity of an asset having a carbon offsetting action establishes an NFDT on the digital asset exchange to represent the asset associated with the carbon offsetting action, and lists a plurality of asset-backed tokens, each of which has a zero carbon footprint attribute value representing a financial aspect of the asset and a plurality of CNTs generated as a result of the carbon offsetting action; An issuing entity of an asset generating carbon emissions establishes an NFDT on the digital asset exchange to represent the asset generating such carbon emissions, and lists a plurality of asset-backed tokens, each of which has a negative carbon footprint attribute value attributable to the carbon emissions associated with the asset, wherein the carbon footprint attribute value is updated on the ledger as additional carbon emissions data is obtained over time, The carbon footprint attribute value of each listed item traded on the digital asset exchange is tracked via the ledger of the digital asset exchange, and the digital asset exchange is configured to provide an investor of the digital asset exchange who holds a portfolio on the exchange with a portfolio value of the portfolio and a carbon footprint attribute value of the portfolio obtained by summing the carbon footprint attribute values of each investment in the portfolio.

Each listed project may further include one or more environmental, social and governance (ESG) metrics, and the ledger tracks each of the one or more ESG metrics for each listed project, and the digital asset exchange is configured to provide an investor in the digital asset exchange with a summary of each of the one or more ESG metrics obtained by summing each of the one or more ESG metrics for each investment in the portfolio. The CNTs may be offered for trading on the digital asset exchange as part of a package with one or more of the plurality of listed projects to offset the carbon footprint attribute value of the respective one or more assets associated with the one or more listed projects.

The method may further include permanently freezing one or more of the plurality of CNTs to achieve carbon neutrality of a neutralizing asset, which includes: Purchasing a CNT neutralization amount on the exchange by a first entity; Submitting a neutralization information package to the digital asset exchange by the first entity, the neutralization information package including at least information about the following: the neutralizing asset to be neutralized, a certification of a carbon footprint of the neutralizing asset obtained from a third-party verification authority, and the purchased CNT neutralization amount to be used to offset the carbon footprint; Removing the purchased CNTs from the transaction on the digital exchange, and removing the entry of the first entity from the ledger; The digital asset exchange cryptographically signs the neutralization information package and obtains a neutralization hash for authenticating the neutralization information package; Establishes a node on a public carbon neutrality blockchain, the node including an address of the neutralization information package, the neutralization hash, and a record indicating that the purchased CNT is permanently frozen; and Issues a neutralization certificate linked to the node by the digital asset exchange.

The method further includes collecting carbon offset data from the carbon offset action and submitting the carbon emission data to the third-party verification authority to obtain the verified carbon emission reduction. The carbon offset data may be obtained using a secure data acquisition system, which includes a plurality of hardware and software components configured to securely collect and store the carbon offset data.

The blockchain may be an Ethereum blockchain, the emission reduction smart contract is based on the ERC721 standard, and the CNT smart contract is based on the ERC20 standard. The reporting address is a uniform resource identifier (URI) address or a uniform resource locator (URL) address. The plurality of CNTs may be stored in a cold wallet for an exchange of a closed regulatory institution or on a public blockchain.

FIG. 4C and FIG. 4D are flow charts of a method 410 for generating a digital representation of an asset for trading according to a specific example of the present application. The method comprises: Calculating 411 a carbon footprint attribute value of an asset based on a preset standard or based on carbon emission related data provided by an asset holder. Obtaining 412 a verification certificate from a third-party verification authority that verifies the carbon footprint attribute value of the asset. Generating an information package and storing it 413 at a reporting address, wherein the information package at least includes the carbon footprint attribute value, the verification certificate and information about the carbon footprint of the asset and financial and/or operational information of the asset. Cryptographically signing the information package and obtaining a hash 414 for authenticating the information package. Inputting 415 the hash of at least an asset owner address, an identifier, the carbon footprint attribute value, the reporting address, and the information package to an asset smart contract on a blockchain, wherein once published on the blockchain, the asset smart contract defines a birth smart contract and the submitted information is stored on the blockchain at the birth smart contract address. Listing the asset for trading 416. Storing the carbon footprint attribute value associated with the asset in a ledger 417. Publish 418 a plurality of asset smart contracts on the blockchain, wherein each asset smart contract is published at a different time, and each asset smart contract after the birth smart contract includes an additional carbon emission amount since the issuance of the previous asset smart contract and a link to one or more of the previous asset smart contracts issued on the blockchain including the birth smart contract. The birth smart contract and the plurality of asset smart contracts form a time series of emission reduction smart contracts that define a unique non-fungible digital twin (NFDT) representation of the asset, and after the issuance of the additional asset smart contract, the carbon footprint attribute value associated with the asset in the ledger is updated based on the additional carbon emission amount.

The asset may be listed for trading on a digital asset exchange, wherein the digital asset exchange includes the ledger. If the carbon footprint attribute value is positive, then we may use the asset smart contract to obtain a plurality of carbon neutral tokens (CNT) by executing a CNT smart contract on the blockchain and issuing the plurality of CNT to an issuer and recording on the ledger, wherein the amount of carbon neutral tokens issued is determined from the carbon footprint attribute value, and the plurality of CNT is issued for trading, And if the carbon footprint attribute value is negative, the asset smart contract is used to obtain a plurality of asset-backed tokens by executing an asset-backed token smart contract on the blockchain, and the ABTs are issued to an issuer and recorded on the ledger, wherein the amount of the asset-backed tokens issued is determined from the financial and/or operating information of the asset (or a metric derived from such data). The method may further include collecting carbon offset data from the asset, and submitting the carbon emission data to the third-party verification authority to obtain the verified carbon emission reduction. The carbon emission data may be obtained using a secure data acquisition system, which includes a plurality of hardware and software components configured to securely collect and store the carbon emission data. The blockchain may be an Ethereum blockchain, the asset smart contract is based on the ERC721 standard, and the asset-collateralized token smart contract is based on the ERC20 standard. The report address may be a uniform resource identifier (URI) address or a uniform resource locator (URL) address.

FIG4E is a flow chart of a method 420 for trading on a digital asset exchange according to one embodiment of the present application. The method may include listing 421 one or more CNTs generated by the method 400 described in FIG4A and FIG4B. The method may further include generating 422 a plurality of listing items of a plurality of assets, each listing item being generated by the method 410 described in FIG4C and FIG4D. The method may further include updating the ledger 423 when a trader purchases a share of a listed asset by updating a carbon footprint attribute value of the trader stored in the ledger based on the total carbon footprint attribute value associated with the listed asset, and/or updating the ledger when a trader purchases one or more CNTs, wherein the carbon footprint attribute value of the trader stored in the ledger is updated based on the number of the one or more CNTs purchased. In a specific example, the trader may purchase a package, wherein the package includes a share of a listed asset and an amount of CNTs to offset carbon emissions associated with the share of the listed asset.

The above specific example creates new digital representations of assets and carbon offset projects, which we call non-fungible digital twins (NFDTs). We can therefore extend this scenario to generate NFDTs for any asset. We can therefore define a method for generating a non-fungible digital twin (NFDT) of an asset. This can be implemented using a computer system as described herein. The method may include: generating an information package and storing it at a reporting address, wherein the information package includes information about an asset, including at least one attribute value; cryptographically signing the information package and obtaining a hash for authenticating the information package; inputting at least an owner address, an identifier, the at least one attribute value, the reporting address, and the hash of the information package into an asset smart contract in a blockchain, wherein once published on the blockchain, the smart contract defines a birth smart contract, and the submitted information is stored on the blockchain at the birth smart contract address; Using the birth smart contract to obtain a plurality of asset-backed tokens (ABTs) by executing an ABT smart contract on the blockchain, wherein the amount of the issued asset-backed tokens is determined from the at least one attribute value in the birth smart contract; Storing the plurality of ABTs; Selling one or more of the plurality of ABTs for trading; and A plurality of asset smart contracts are published on the blockchain, wherein each asset smart contract is published at a different time, wherein the value of the at least one attribute value in each asset smart contract after the birth smart contract is the change of the value since the publication of the previous asset smart contract and a link to one or more of the previous asset smart contracts published on the blockchain including the birth smart contract, and each smart contract is used to issue, store and sell a plurality of ABTs based on the value in the respective smart contract, wherein the birth smart contract and the plurality of emission asset contracts form a time series of asset smart contracts that define a unique non-fungible digital twin (NFDT) representation of the asset.

The trading system, platform and method provided in this application directly link carbon emissions to asset transactions, so that the price and trading volume of the traded assets are directly affected by carbon emissions, which enhances the incentive to offset carbon or purchase carbon credits. In addition, the use of such trading systems can allow more participants to participate in the carbon trading cycle, more fully capture carbon emission data, and more fully utilize carbon offset actions, thereby facilitating the international community to achieve global emission reduction goals faster and more effectively. In addition, the audit and calculation of data by third-party entities can improve the authenticity and accuracy of ENV and CNT. The use of blockchain and smart contracts to store ENV and/or CNT also increases authenticity. This is not possible under the existing carbon trading mechanism. Additionally, embodiments of the method and system enable a cross-border carbon credit trading mechanism without triggering NDC constraints and without reliance on Article 6 of the Paris Agreement. By allowing the registration of emission reduction certificates in national registries, NDCs can be attributed to the source country. These can then be frozen to prevent further use through redemption of certificates and, can also be frozen to prevent their reuse. With this information, a digital twin can be created, which can then be securely traded across borders knowing that NDC requirements have been met and taken into account. Embodiments of this system are market-based mechanisms, do not rely on Article 6 of the Paris Agreement, and establish a truly global carbon trading system to solve a global problem. The system facilitates ESG reporting by asset holders and provides much-needed carbon footprint visibility to investors, allowing them to quickly and efficiently determine the carbon footprint of their portfolios. Finally, the specific example allows entities to neutralize the carbon footprint of real-world assets by permafrost CNTs to offset emissions.

The implementation of the specific examples of the asset trading system and method as illustrated in Figures 1 to 4E and described above is performed using a dedicated computing device configured to implement a specific example of the trading system (including CNT generation). In a specific specific example, secure computing equipment and devices, blockchain and smart contract technology are used. Smart contracts are used to generate non-homogeneous digital twins (NFDTs) on the blockchain, which represent real assets and their corresponding carbon footprint attributes (ENVs), and CNTs can be issued and traded based on them.

The technical implementation may include the following parts or stages: data acquisition; data security processing; data transmission and confirmation; and NFDT formation and CNT generation. The specific examples of the technical implementation will be further explained and illustrated with reference to Figures 5A to 7. In short, Figure 5A is a schematic diagram of a computing device (or computing platform) according to a specific example used in a secure data acquisition system, and Figure 5B illustrates a layered security model in the design of an operating system for the computing device illustrated in Figure 5A according to a specific example. Figure 6 is a schematic diagram of data security processing of a secure data acquisition system according to a specific example, and Figure 7 is a schematic diagram of the technical architecture of a system including a blockchain-based exchange according to a specific example.

Carbon reduction measurement based on real-world projects is the beginning of CNT-NFDT, and the authenticity of the measurement data is extremely important. Currently, the core data that can be measured comes from a wide range of equipment/devices, including Internet of Things (IoT) devices. In a specific example, the system further includes a secure data acquisition platform, which includes multiple hardware and software components developed and/or manufactured by the system or under the control and certification of the system to ensure a high level of security and trust.

Carbon reduction measurements based on real-world projects are the basis for CNT generation, and the authenticity of the measurement data is extremely important. Therefore, in some embodiments, the system includes a secure data acquisition system that is used to obtain and verify data related to emission reduction activities used to generate CNT. In some embodiments, the data acquisition system can also be used to collect data on carbon emissions associated with the establishment of assets (e.g., for generating ENV values).

The secure data acquisition system may include hardware and/or software components for capturing emission reduction data associated with projects and assets. This may include field sensors and/or hardware deployed in the field that can securely collect data and securely transmit the data back to the system (e.g., using encryption and associated security techniques) to enable estimation of _CO2 equivalents from activities. Exemplary equipment includes carbon emission gas detection equipment, greenhouse gas (Green House Gas; GHG) measurement equipment, environmental multi-function measurement instruments, gas flow meters, power meters, etc. Data acquisition can also be configured to receive documents about emission reduction activities or assets, which can be used to calculate ENV values and CNT.

To ensure high levels of trust and security, hardware and software are designed according to the following guidelines: ●   Create a virtual and highly secure private network for organizations operating on commercial communication facilities; ●   Minimize the attack surface; ●   Operate on trusted hardware and official drivers for full control and security assurance. ●   Integrate an intelligent policy engine that performs real-time command and control, providing end-to-end governance and visibility for enterprise devices; ●   Design multiple layers of protection, including granular allow/deny mechanisms and threat detection through crowd control; ●   Build dedicated components to eliminate the possible malicious impact of malware that has infiltrated the device; ●   Allow rapid recovery from device failures and suspected violations, and eliminate the need for remediation measures outside the organization; and ●   Allow organizations to jointly manage secure phones (e.g., IntactPhone) and BYOD devices through a single system.

Each system device includes a security platform that integrates the following security components: ●   Purpose-built trusted hardware and drivers; ●   Customized security-rich operating systems that provide security-enhanced architecture and utilities to block cybercrime attack vectors; ●   Integrated command and control center that manages clustered drive inventory and security usage policies; ●   Encrypted end-to-end (E2E) communications to prevent eavesdropping and wiretapping; ●   Security tools that provide antivirus software and AppsOps management; and ●   Performance assurance toolset based on remote control technology and self-troubleshooting for seamless operation and security.

To ensure a high level of trust, system hardware for secure data acquisition, data processing and system operations for generating ENV and CNT can be performed using trusted hardware that has been certified by Evaluation Assurance Level 7 (EAL7). A specific example can implement TrustZone technology, which is a system-on-chip (SoC) and CPU-wide security approach. TrustZone is hardware-based security built into the SoC to provide secure endpoints and device root of trust. At the core of the TrustZone approach is the concept of secure and non-secure worlds that are hardware-isolated from each other. Inside the processor, software resides in either the secure world or the non-secure world; switching between these two worlds is achieved by a secure monitor (application processor) or via hardware (microcontroller). This concept of secure (trusted) and non-secure (untrusted) worlds extends beyond the CPU, its memory, and software to include transactions on the bus, interrupts, and peripheral interfaces within the SoC.

TrustZone technology for application processors is typically used to run trusted boot and trusted OS to establish a trusted execution environment (TEE). Typical use cases include authentication mechanisms, passwords, key materials and DRM protection. Applications running in the secure world are called trusted applications. TrustZone technology for application processors lays the foundation for full system security and the establishment of a trusted platform. Any part of the system can be designed as part of the secure world, including debugging, peripherals, interrupts and memory. By establishing a secure subsystem, assets can be protected from software attacks and common hardware attacks.

The division between the two worlds is achieved by the AMBA bus mesh architecture, peripherals, and hardware logic present in the processor. Each physical processor core has two virtual cores: one considered secure and one non-secure, with a robust mechanism for context switching between them (secure monitor calls). Entry into the secure monitor can be triggered by software executing a dedicated Secure Monitor Call (SMC) instruction or by a number of exception mechanisms. The monitor code typically saves the state of the current world and restores the state of the world being switched to.

This is further illustrated in FIG. 5A , which shows a trusted computing device 500, including one or more processors 510, each processor having two virtual cores: a secure core 512 and a non-secure core 516, and a context switch 514 to switch between the two cores. The device further includes one or more memories 520, which may further include secure memory 522 associated with the secure core 512 and non-secure memory 524 associated with the non-secure core 516. The computing device may further include one or more input devices 530 and one or more output devices 540. In some specific examples, the device may be both an input device and an output device (e.g., a touch screen). As noted above, the input device and the output device may be secure or non-secure. The input device 530 may include a sensor, a keyboard, a mouse, a touch screen, etc. The output device may include a display device or a touch screen.

One or more processors may be a central processing unit (CPU), a graphical processing unit (GPU), a microprocessor or a microcontroller, and may include an input/output interface, an arithmetic and logic unit (ALU), and a control unit and a program counter element, which communicate with input and output devices via the input/output interface. The computing device may also include a network interface and/or a communication module for communicating with an equivalent communication module in another computing device using a predefined communication protocol (e.g., WiFi, Bluetooth, IEEE 802.15, IEEE 802.11, TCP/IP, UDP, etc.). The memory 520 is operatively coupled to the processor 510 and may include RAM and ROM components and may be located inside or outside the device. The memory may be used to store the operating system and additional software modules or instructions. The processor may be configured to load and execute the software modules or instructions stored in the memory. Applications or computer programs for execution on the device may be written in a general programming language (e.g., Pascal, C, C++, Java, Python, JSON, etc.) or in a dedicated application-specific language and may utilize or call software libraries or packages as needed. The operating system and application software may provide a user interface.

To implement the Secure World in the SoC, a Trusted Operating System (Trusted OS) is developed to leverage protected assets. The code implements Trusted Boot, Secure World Switching Monitor, Small Trusted OS, and Trusted Applications. Multiple levels of Secure World privileges are provided for isolation between Trusted Boot, Trusted OS, and Trusted Applications. The combination of TrustZone-based hardware isolation, Trusted Boot, and Trusted OS constitutes the Trusted Execution Environment (TEE). TEE provides security features for confidentiality and integrity for multiple trusted applications. The specific instance uses a high level of encryption and meets EAL7 certification (the highest level of certification available).

In some specific examples, system equipment including sensors and computing equipment, such as those used to collect emission-related data, or process data within the system is performed in a trusted environment. In this trusted environment, all components are assembled and monitored under strict inspection policies, thereby achieving isolation between the hardware assembly process and the software installation process. Software installation is performed directly and exclusively by system experts in their system facilities.

The manufacture of control system sensors and computing devices further allows control and ownership of the entire device code, including drivers and boot loaders. This enables the development of trusted drivers and boot loaders to achieve secure boot and prevent the replacement of modified boot code (i.e., "unauthorized replacement"), which may introduce malware or security backdoors into the processor after the processor is initialized. Devices can be configured to restrict the boot parameters that can be changed when the device loads, such as multi-stage boot code originating from the device, so that malicious attacks cannot interrupt the boot process and replace erroneous commands or security backdoors into the device settings. In one specific example, devices based on the IntactPhone platform can be developed and the driver and boot loader code can be fully audited. That is, the system can be granted full audit access to the IntactPhone source code, including its drivers and boot loaders to ensure the security of system devices based on these devices.

In one specific example, self-destruct protection is implemented. In this specific example, a hardware date protected boot loader supports a unique data self-destruct mechanism, wherein a self-destruct process is triggered when a physical access attack is detected.

In one specific example, the system device implements a secure operating system that focuses on security and fully protects the device from attacks from the network or malware as well as from the user (by enforcing strict organizational policies that users cannot circumvent). In one specific example, this is based on a heavily customized version of Android. Secure OS is developed under the strict security assumption that given enough time and money, everything can be attacked, so most simple secure OS approaches are ineffective. Therefore, in a specific example, a Total Shield approach is used, thereby implementing a multi-layered security approach, where each layer is protected with different measures, allowing the OS to eliminate even unknown threats, and which is characterized by improved resource management controls at the kernel and driver level for privacy-sensitive resources.

This is further illustrated in FIG. 5B , which illustrates a layered security model 550 used in the design of an operating system for the computing device illustrated in FIG. 5A according to a specific example. This model includes: ●   Block known Trojan virus day patches 551; ●   Encrypted communications 552; ●   Usage and content governance application permissions 553; ●   Crowd analysis enhanced resource and connectivity controls 554; ●   Resource abstraction and custom push notifications 556; and ●   Internal encryption 557;

Once the data is collected, the system processes the data to estimate carbon emissions and enable the generation of CNT and ENV values. Figure 6 is a schematic diagram of data security processing according to a specific example. The data security process processes the data collected from the trusted computing device 500 and stores it in the cloud to ensure the accuracy and security of the data collected on the platform at any time.

The data security process consists of four components: fragmentation, encryption, storage, and authentication.

In one embodiment, the high-strength fragmentation encryption engine includes a core unit 620 and a parallel processing unit 630, which receives a data stream from a data source 610 and performs high-density fragmentation 622 and real-time individual encryption of the fragments 612. The engine can also provide fragmentation reorganization 624 and decryption 614. In one embodiment, the high-strength fragmentation encryption engine achieves a transmission and encryption efficiency of more than 100 MB per second. A scalable specification can be implemented. The file fragment parameters can be adjusted in strength according to the actual application scenario, and different levels from 100 fragments to 100,000 fragments are supported, and different encryption strengths can correspond to the alertness of the file.

Distributed storage of highly secure and highly available data is also implemented. File fragments from a high-strength fragmented encryption engine are stored in a storage unit 640 using a distributed architecture (e.g., a distributed database 660). Files are stored in a non-file type and a file correction function is integrated to achieve file correction within a certain allowable range to avoid malicious and illegal tampering. It also has a scalable and highly available backup function. The high-strength fragmented encryption engine can be configured to perform fragmented decryption, hash calculations, and fragment index generation on the storage unit storing the fragment 644 in the distributed database 660. Similarly, when data is sent from the distributed database 660 with fragmented asymmetric encryption, hash calculations and fragment index generation can be performed. The blockchain unit 650 can store or provide segment index verification 634 and index decentralized storage.

Dynamic encryption algorithms are also implemented. During the high-density fragmentation of the original file by the core engine, the fragments are randomly combined using a secure encryption algorithm to encrypt the fragments using array dynamic parameters. A range of high-strength encryption algorithms can be used to greatly reduce the possibility of the encryption algorithm being cracked.

Blockchain unit 650 provides blockchain verification. In a specific example, the blockchain unit is a specially tuned enterprise-level blockchain technology that allows up to 700 to 1000 records per second to be uploaded to the chain, and the fingerprint of the source file can be stored in the block so that the content of the source file can be verified and will not be maliciously and illegally tampered with during storage, thereby protecting the user's file security.

7 is a schematic diagram of a technical architecture 700 of a system according to a specific example. The technical architecture 700 is composed of four components: a BAAS management and control platform 710, a blockchain 720, an operation platform 730, and a data transmission and communication module 740.

The Business As A Service (BAAS) management and control platform 710 includes front-end and back-end architectures. The main front-end architecture and user interface are implemented using Vue, Element UI and Echarts, while the back-end is mainly a Spring Boot application architecture responsible for implementing the user interface service. The Java security framework Shrio and the cross-domain authentication solution JWT (JSON Web Token) are used to implement authentication, authorization, password and session management. MySQL is used as a database, and Mybatis is used as a data persistence mapping architecture that supports customized SQL, storage procedures and advanced mapping. The BAAS platform uniformly manages and maintains the deployment of infrastructure nodes. Shell scripts are used for the deployment of infrastructure nodes, which can provide convenient and efficient functions in node deployment.

Implement the Blockchain 720 module, which uses the Springboot language framework and the Certificate Authority (CA), peer/ledger node and order/consensus node modules to develop the basic chain. The node and certificate management center (CA module) is responsible for node certificate management, private key management and node management. The peer (ledger node) module is mainly responsible for the initialization of smart contracts, synchronization of data to the ledger, storage and maintenance. The order/consensus node is mainly responsible for the implementation of consensus algorithms such as RAFT, IBFT and Kafka for the entire network consensus. It is also responsible for the login of transaction data, the filling, storage and maintenance of blocks to the ledger. Use a high-performance RPC framework (such as gRPC) for communication. To provide security, asymmetric encryption is used for data transmission, and SSL encryption and verification are used to authenticate the client that accesses the message. In a specific example, the RSA algorithm and the domestic SM2 algorithm are used for signing and verification, and the international Des, domestic SM4, SM3 hash algorithm Sha256, and Ed25519 signature algorithms can also be supported. The data storage module supports/implements MySQL database, RocksDB database, SQL lite small database, and FastDFS distributed file storage system.

The operating platform 730 implements the CentOS 7+ operating system to provide an execution (execution or running) environment for the BAAS platform and the blockchain and infrastructure nodes, which can be executed on a specific physical machine (such as a server) or a cloud platform. In a specific example, the system is designed and configured using the trusted computing device 500 as discussed above or according to the trusted security criteria as discussed above to provide layered security throughout the system, such as using encrypted data communications.

The data transmission and communication module 740 is configured to use SDK or RESTful to communicate with external infrastructure and gRPC to transmit data internally, and provide a communication interface to the Internet.

Specific examples of the above technical framework can be used to create and store NFDTS, CNT tokens, and store the ENV value of assets and enable trading. Binding assets to verified carbon footprint attribute values allows not only issuers but also investors to quantitatively identify the carbon footprint attributes of portfolios, and thus enables ESG disclosure to issuers and investors on exchanges. The above technical framework implements an exchange, which includes a digital ledger that can track the carbon footprint attributes of assets based on immutable data stored in the blockchain, and can clear and settle transactions on the exchange, fully tracking the bound carbon neutrality status.

The NFDT CNT used in the exchange is established using a smart contract published on the blockchain. Similarly, NFDT and related smart contracts are used to store the carbon footprint attribute (ENV) value of assets at multiple time points so that the ledger can maintain the latest carbon footprint attribute (ENV) value of assets traded on the exchange. The non-fungible digital twin (NFDT) is established on the blockchain for the smart contract via an interface, and it acts as an immutable digital twin to protect the authenticity of the carbon footprint attribute (ENV). In a specific example, the blockchain is the Ethereum blockchain, and the smart contract of NFDT is based on the ERC-721 smart contract. Each smart contract in the NFDT is distinct (non-fungible), distinguishable, and by linking smart contracts, the NFDT can track carbon footprint status over time. The NFDT is uniquely identified by its contract address on the blockchain and a tokenID (uint256) that provides a mapping to the address. As described above, an asset or carbon offset activity or project can be digitally represented by a time series of asset contracts that form the NFDT (i.e., a live/continuous digital representation of the asset or project). This includes the birth asset contract and its carbon footprint (ENV) that captures all the details of the asset, as well as a time series of subsequent asset contracts that each store subsequent emissions data or changes in carbon footprint attribute values (ENV) (such as due to emission reduction activities or purchases of CNT at the current time (t)). That is, after the contract is created, each subsequent asset contract stores the new carbon footprint information at the current time (t) and the address of the previous smart contract (t-1).

The goal of issuing and trading CNTs is to transform the incentive mechanism for carbon emission reduction from being task- or obligation-driven to being economically driven. This monetization of carbon assets will view emission reduction as a benefit rather than a cost, and will enable companies and individuals to monetize their green behaviors. In the above emission reduction mechanism and trading model, carbon assets are used as an independent asset type for quota compliance, and these carbon assets have trading value through circulation and trading in a dedicated carbon trading market.

Contributions to energy conservation and emission reduction (EER), whether it is technological breakthroughs, energy recycling, low-carbon behavior, or afforestation or other green behaviors, all create valuable behaviors that can promote emission reduction. The specific instance of the system enables CNT to be created from a wide range of activities to help achieve the global carbon neutrality goal. Green behavior is a "mining" mechanism and generates CNT as a reward for green asset owners (green behavior entities). Because it is a tradable asset, CNT enables green behavior to obtain economic value and the corresponding economic driving tailwind, thereby realizing an incentive mechanism.

Traditional carbon emission pricing is affected by many factors, including global carbon emission reduction policies, macroeconomics (economic activities and carbon emission intensity), various energy prices, quota allocation methods and quantities. Carbon price expectations based on the above factors will affect companies' willingness to develop carbon credits, and thus affect the supply of carbon emission rights. In this pricing mechanism, the quota allocation mechanism and the marginal cost of emission reduction play the most important role. Specifically, when the marginal cost of emission reduction is higher than the market price of carbon emission rights, companies will be willing to purchase carbon emission rights, resulting in an increase in demand for carbon emission rights. When the marginal cost of emission reduction is lower than the market price of carbon emission rights, companies will be willing to make a profit by selling carbon emission quotas in the market.

On the exchange, 1 CNT is always equal to 1 tCO2e, so the price of CNT reflects the carbon price recognized by participants. The supply of CNT depends on the number and scale of "green" asset issuers who choose to issue positive ENV as independent CNT on the exchange. The demand for CNT depends on the total amount of negative ENV assets appearing on the exchange platform and the willingness of "grey" asset issuers to "neutralize" their negative ENV on the platform.

Driven by this supply and demand relationship, the price of CNT can be directly determined through CNT transactions. Since CNT corresponds to 1 tCO2e emission reduction under global carbon neutrality, the CNT price when the asset completely neutralizes its negative ENV by purchasing CNT should reflect the marginal emission reduction cost of the asset to achieve zero emission under the premise of supply and demand balance (since the asset holder may not be an emitting enterprise, the marginal emission reduction cost is also called the marginal carbon neutrality cost), which can also be shown as follows: Equation 9

P _CNT is the current price of CNT on the exchange (in legal currency, such as USD), and MAC is the marginal carbon neutrality cost curve of the asset. Extended to all assets, under equilibrium conditions, the CNT price on the exchange should be as follows: Equation 10

Among them, ENV _all is the total ENV of all assets with negative ENV on the platform, and ENV _i and MAC _i are the ENV and marginal carbon emission neutrality curve of the i-th asset with negative ENV, respectively.

In addition to the price of CNT, carbon trading on the exchange includes assets (represented as ABT on the exchange) and CNT, as well as crypto transactions (BTC, ETH). For example: Equation 11

Among them, P _Traditional represents the asset valuation using traditional valuation methods such as FCF and DCF and the corresponding ABT pricing (the unit should be the legal currency on the exchange, such as the US dollar). P _CNT is the current price of CNT on the exchange (the unit should be the legal currency, such as the US dollar), or the buyer's marginal carbon neutrality cost for the corresponding emission reductions of the purchased CNT.

Similarly: Equation 12

When trading between ABT and BTC, ABT and fiat currency, BTC and fiat currency, the transaction price should be the ECON value of the respective assets after fully considering the economic value of ENV.

The CNT price is also the carbon price of the exchange, which reflects the price of 1 tCO2e carbon emission right when carbon neutrality is achieved (based on the information of all participants at the deadline).

Compared with traditional quota-based pricing, exchange-based carbon pricing has the following characteristics:

Beyond the constraints of carbon emission limits in specific regions, at specific times and by policy, the price of CNT is based on the reduced cost per ton of carbon equivalent when achieving global carbon neutrality, so its dependence on policy is significantly reduced.

CNT can be transferred with asset transactions, and transactions between emission enterprise issuers, non-emission enterprise issuers, green asset issuers and investors transcend regions, quota policy boundaries and industrial supply chains, which is conducive to the rapid and efficient redistribution of carbon neutrality costs and benefits among different countries and stakeholders, thereby forming a more effective pricing mechanism.

Based on the carbon pricing and blockchain design of the exchange (ENV and CNT of assets) and authoritative tripartite emission reduction verification, the objective fairness and traceability of data sources, as well as the security of data and transactions and the timeliness of data (especially compared with the annual ESG disclosure report) can be guaranteed. This move greatly simplifies the transaction process and reduces transaction costs.

Due to the above characteristics, the CNT trading and carbon pricing of the exchange system are closer to the asset pricing of the efficient market than the traditional carbon trading market. That is, the price of CNT reflects the market's pricing of asset carbon neutrality based on all known information, including historical carbon price information, quota expectations of various countries and regions, and carbon emission information that affects the marginal cost curve of carbon neutrality.

In addition, all issuances of CNT are recorded on the exchange's carbon neutral blockchain and correspond to the issuance and trading of assets. Blockchain technology and smart contracts can be used as distributed shared ledgers and databases, with the characteristics of decentralization, immutability, full record keeping, tracking, collective maintenance, and transparency. It can effectively record all carbon neutral behaviors of various countries and industries on the exchange at any time. This is especially important for market participants and policymakers who analyze and track such behaviors.

In summary, specific examples of methods for generating non-fungible digital twins (NFDT) representations of carbon offset actions or projects that represent a time series of smart contracts on a blockchain (e.g., based on the Ethereum ER721 standard) have been described, which capture carbon offset actions and carbon emissions over time. Carbon offset actions can be used to generate carbon neutral tokens (CNT; e.g., based on the Ethereum ERC-20 standard). A digital asset trading system can be implemented that allows the listing of assets and the listing of CNT. A ledger is also used to store the carbon footprint attribute value (ENV) of each listed asset. Each asset smart contract includes the carbon footprint (e.g., tons of carbon dioxide equivalent or tCO2e for short) generated since the last asset smart contract, so the carbon footprint (ENV) is tied to the digital asset. The carbon footprint attribute value (ENV) of each listed project traded on the digital asset exchange is tracked via a ledger, and the digital asset exchange is configured to provide investors who hold a portfolio on the exchange with the portfolio value of the portfolio and the carbon footprint attribute value of the portfolio obtained by summing the carbon footprint attribute values of each investment in the portfolio. Similarly, the total carbon footprint attribute value (ENV) of the asset holder can be obtained by summing the carbon footprint attribute value of each listed project and any offsetting CNT held, providing a mechanism to easily and explicitly meet environmental, social and governance (ESG) reporting requirements. In detail, the method described herein (and in detail, the process of establishing a NFDT for use in offsetting assets or projects) provides a method for establishing a cross-border carbon credit trading mechanism without triggering NDC constraints and without relying on Article 6 of the Paris Agreement. In detail, it allows the country where emission reductions occur to record the emission reductions in its registry and contribute to its NDC, and freeze such emission reductions, while allowing the establishment of a digital representation of the asset or project that can be freely traded across borders (whether by the original owner/offsetter or another party). Emission reductions may also be permanently frozen and used to neutralize the carbon footprint of real-world assets.

The specific example also allows for the secure collection, transmission and verification of data from ongoing projects, enabling the continuous updating of the carbon neutrality status (ENV value) of assets and the generation of CNT from ongoing projects. This enables consumers to participate and contribute to emission reductions.

Those skilled in the art will understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, optical fields or optical particles, or any combination thereof.

Those skilled in the art will further appreciate that the various illustrative logic blocks, modules, circuits, and algorithm steps described in conjunction with the specific examples disclosed herein may be implemented as electronic hardware, computer software or instructions, middleware, platforms, or a combination of the two. To clearly illustrate this interchangeability of hardware and software, various illustrative component blocks, modules, circuits, and steps have been generally described above in terms of their functionality. Whether this functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in different ways for each specific application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

The steps of the methods or algorithms described in conjunction with the specific examples disclosed herein may be directly embodied in hardware, in a software module executed by a processor, or in a combination of the two, including cloud-based systems. For hardware implementations, the processing may be implemented in one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, other electronic units designed to perform the functions described herein, or combinations thereof. Various middleware and computing platforms may be used.

In some specific examples, the computing device may include one or more processors. The one or more processors may include one or more central processing units (CPUs) or graphic processing units (GPUs) configured to perform some of the steps of the methods. Similarly, the computing device may include one or more CPUs and/or GPUs. The CPU may include an input/output interface, an arithmetic and logic unit (ALU), and a control unit and a program counter element, which communicate with input and output devices via the input/output interface. The input/output interface may include a network interface and/or a communication module for communicating with an equivalent communication module in another device using a predefined communication protocol (e.g., Bluetooth, ZigBee, IEEE 802.15, IEEE 802.11, TCP/IP, UDP, etc.). The computing device may include a single CPU (core) or multiple CPUs (multiple cores) or multiple processors. The computing device may be a server-based computing device or a cloud-based computing device using a GPU cluster, but may be a parallel processor, a vector processor, or a distributed computing device. The memory is operatively coupled to the processor and may include RAM and ROM components and may be provided within or outside the device or processor module. The memory may be used to store an operating system and additional software modules or instructions. The processor can be configured to load and execute software modules or instructions stored in memory.

A software module (also referred to as a computer program, computer code, or instruction) may contain multiple source code or object code segments or instructions and may reside in any computer-readable medium, such as RAM memory, flash memory, ROM memory, EPROM memory, register, hard disk, removable disk, CD-ROM, DVD-ROM, Blu-ray disc, or any other form of computer-readable medium. In some embodiments, the computer-readable medium may include non-transitory computer-readable media (e.g., tangible media). In addition, for other embodiments, the computer-readable medium may include transient computer-readable media (e.g., signals). Combinations of the above should also be included in the scope of computer-readable media. In another aspect, the computer readable medium may be integral to the processor. The processor and the computer readable medium may reside in an ASIC or related device. Software code may be stored in the memory unit and the processor may be configured to execute the software code. The memory unit may be implemented within the processor or external to the processor, in which case the memory unit may be communicatively coupled to the processor via various components known in the art.

In addition, it should be understood that modules and/or other appropriate components for performing the methods and techniques described herein may be downloaded and/or otherwise obtained by a computing device. For example, the device may be coupled to a server to facilitate the transfer of components for performing the methods described herein. Alternatively, the various methods described herein may be provided via a storage component (e.g., RAM, ROM, physical storage media such as a compact disc (CD) or a floppy disk, etc.) so that the computing device may obtain the various methods after the storage component is coupled or provided to the device. In addition, any other suitable technology for providing the methods and techniques described herein to a device may be utilized.

The methods disclosed herein include one or more steps or actions for implementing the described methods. The method steps and/or actions may be interchanged with one another without departing from the scope of the claims. In other words, unless a specific order of steps or actions is specified, the order and/or use of specific steps and/or actions may be modified without departing from the scope of the claims.

In one embodiment, a computer-readable storage medium storing a computer program is provided, wherein the computer program, when executed by a processor, implements the steps in each of the method embodiments described above.

Reference to any prior art in this specification is not and should not be taken as an acknowledgement or any form of suggestion that the prior art forms part of the common general knowledge.

It should be understood that, unless otherwise stated or implied, the terms "comprise" and "include" and their derivatives (e.g., comprises, comprising, includes, including) when used in this specification and subsequent claims shall be construed to include the features to which the terms refer, and are not intended to exclude the existence of any additional features.

In some cases, a single specific example may combine multiple features for the purpose of brevity and/or to assist in understanding the scope of the present invention. It should be understood that in such cases, these multiple features may be provided individually (in individual specific examples) or in any other suitable combination. Alternatively, when individual features are described in individual specific examples, unless otherwise specified or implied, these individual features may be combined into a single specific example. This also applies to technical solutions that can be recombined in any combination. That is, a technical solution can be modified to include features defined in any other technical solution. The phrase "at least one of" a list of reference items refers to any combination of those items, including a single component. As an example, "at least one of a, b, or c" is intended to cover: a, b, c, a-b, a-c, b-c, and a-b-c.

It will be appreciated by those skilled in the art that the present invention is not limited in its use to the specific applications described. The present invention in its preferred embodiments is not limited with respect to the specific elements and/or features described or depicted herein. It will be appreciated that the present invention is not limited to the specific embodiments disclosed, but is capable of many rearrangements, modifications, and substitutions without departing from the scope as described and defined by the following claims.

100:Asset Trading System 110:Exchange 111:Application 112:File System 113:Database 114:Ledger 120:CNT Holder 130:Asset Holder 132:Asset 140:Third Party Entity 150:Blockchain/Smart Contract 152:Blockchain 154:VER Smart Contract 156:CNT Token Contract 160a:Information Kit 160b:Second Information Kit 160i:Information Kit 160j:Information Kit 161:Asset Name 162:Asset ID 163a:Description 163i:Description 164a:Carbon Emission Data 164b:Additional Emission Data 165a:Carbon Footprint 165b:Carbon Footprint/Carbon Footprint Value 165c:Additional Emissions/Carbon Footprint Value 165d:Carbon Footprint Value 165e:Carbon Footprint Value 166a:Verification Certificate 166b:Verification Certificate 167:Database 180a:Smart Asset Contract 180b:Asset Contract 180c:Asset Contract 180i:Asset Contract 180j:Asset Contract 181a:Report URL 181b:Report URL 182a:Hash 182b:Hash 183a:Birth Address 183b:Address 184b:Previous Address 185:Curve 186a: Asset tokens 186b: Asset tokens 220: Asset owners 222: Positive environmental footprint/environmental (ENV) data 224: Financial and operational data 226: Third-party authorized institutions 228: Financial and operational data 230: Exchanges 232: Real-world assets 234: Financial investors 236: ENV portfolios 240: National Carbon Registry 242: Voluntary emission reduction certificates 244: Redemption certificates 246: Purchasers 250: NFDT/smart contracts 252: Carbon neutral tokens 254: Ethereum blockchain 260: Asset owners 262: Negative environmental footprint 272: NFDT/Sales memorandum 274: NFDT 276: Smart contract 310: Step 320: Step 330: Step 340: Method 350: Step 360: Step 370: Step 380: Step 400: Method 410: Method 420: Method 500: Trusted computing device 510: Processor 512: Secure core 514: Context switch 516: Non-secure core 520: Memory 522: Secure memory 524: Non-secure memory 530: Input device 540: Output device 550: Layered security model 551: Block known Trojan virus same-day patch 552: Encrypted communication 553: Usage and content governance application permissions 554: Crowd analysis enhanced resource and connectivity control 610: Data source 612: Real-time individual encryption 614: Decryption 620: Core unit 622: High-density fragmentation 624: Fragment reorganization 630: Parallel processing unit 634: Fragment index verification 640: Storage unit 644: Fragment 650: Blockchain unit 660: Distributed database 700: Technical architecture 710: BAAS management and control platform 720: Blockchain 730: Operation platform 740: Data transmission and communication module

The preferred specific examples of this application will be described in more detail in conjunction with the accompanying drawings. Specifically,

[Figure 1A] is a diagram of the architecture of the asset trading system according to the specific example of this application;

[FIG. 1B] is a schematic diagram showing a chain of smart contracts for digitally representing the temporal evolution of an asset over time (including potential changes in carbon footprint) according to a specific example;

[Figure 1C] is a graph of the carbon footprint attribute value (ENV, in tCO2e) over time, which is tied or associated with the non-fungible digital twin (NFDT) representation of the asset in Figure 1B];

[ FIG. 1D ] is a schematic diagram of a method for generating a smart contract for emission reduction and a carbon neutral token (CNT) relative to an offsetting action to establish a non-fungible digital twin (NFDT) representation of the offsetting action according to a specific example;

[Figure 2A] is a flow chart of a method for establishing NFDT and CNT in a digital exchange according to a specific example;

[Figure 2B] is a schematic diagram of an asset owner with a positive environmental footprint (positive ENV) for generating carbon neutral tokens (CNT) according to a specific example;

[Figure 2C] is a diagram of an asset owner with a positive environmental footprint (positive ENV) that generates Emission Reduction Certificates according to a specific example, which are sold to purchasers who use the Emission Reduction Certificates to obtain Carbon Neutral Tokens (CNT) and generate NFDT representing the assets;

[Figure 2D] is a diagram of an asset owner with a negative environmental footprint (negative ENV; i.e., generating carbon emissions) listed on a digital asset exchange according to a specific example, where the negative carbon footprint can be offset by also purchasing CNT;

[Figure 2E] is a flow chart of a method for establishing a NFDT for representing assets with a positive environmental footprint (positive ENV) according to a specific example;

[FIG. 2F] is a flow chart of a method for establishing a NFDT for representing assets with a negative environmental footprint (negative ENV) according to a specific example;

[Figure 3A] is a flow chart of a method for calculating the carbon footprint attribute ENV according to a specific example of this application;

[Figure 3B] is a flow chart of a method for trading carbon neutral tokens CNT according to one specific example of this application;

[Figure 4A] is a flow chart of the first part of a method for generating a plurality of carbon neutral tokens representing carbon offset actions for trading according to one specific example of this application;

[Figure 4B] is a flow chart of the second part of a method for generating a plurality of carbon neutral tokens representing carbon offset actions for trading according to one specific example of this application;

[Figure 4C] is a flow chart of the first part of a method for generating a digital representation of an asset for trading according to one specific example of this application;

[Figure 4D] is a flow chart of the second part of the method for generating a digital representation of an asset for trading according to one specific example of this application;

[Figure 4E] is a flow chart of a method for conducting transactions on a digital asset exchange according to a specific example of this application;

[Figure 5A] is a schematic diagram of a secure computing device (or computing platform) according to a specific example;

[FIG. 5B] illustrates a layered security model in the design of an operating system and operating software for the secure computing device illustrated in FIG. 5A according to a specific example;

[Figure 6] is a schematic diagram of data security processing in a secure data acquisition system according to a specific example; and

[Figure 7] is a schematic diagram of the technical architecture of a digital asset trading system based on a specific example.

100:Asset trading system

110: Exchange

120: CNT holders

130:Asset holders

140: Third-party entity

150: Blockchain/Smart Contract

Claims (30)

A method for generating a plurality of carbon neutral tokens representing carbon offset actions for trading, comprising: Obtaining a carbon emission reduction certificate and a carbon emission redemption certificate associated with a carbon offset action that generates a carbon emission reduction from an issuing authority in a country, wherein the carbon emission reduction is verified by a third-party verification authority or the issuing authority, and the redemption certificate prevents further trading of the carbon emission reduction certificate in the country; Placing the carbon emission redemption certificate in a regulatory agency to prevent further trading or use of the carbon emission reduction certificate; Generate an information package and store it at a reporting address, wherein the information package at least includes the carbon emission reduction, the carbon emission reduction certificate, the redemption certificate and information about the carbon offset action; Cryptographically sign the information package and obtain a hash for authenticating the information package; Input at least an owner address, an identifier, the carbon emission reduction, the reporting address and the hash of the information package into an emission reduction smart contract in a blockchain, wherein once published on the blockchain, the emission reduction smart contract defines a birth smart contract, and the submitted information is stored on the blockchain at a birth smart contract address; Using the birth smart contract and the carbon emission reduction contained therein to obtain a plurality of carbon neutral tokens (CNT) by executing a CNT smart contract on the blockchain, wherein the amount of carbon neutral tokens issued is determined from the carbon emission reduction in the birth smart contract; Storing the plurality of CNTs; Selling one or more of the plurality of CNTs for trading; Publish a plurality of smart emission reduction contracts on the blockchain, wherein each smart emission reduction contract is published at a different time, and each smart emission reduction contract after the birth smart contract includes an additional carbon emission reduction since the publication of the previous smart emission reduction contract and a link to one or more of the previous smart emission reduction contracts published on the blockchain including the birth smart contract, wherein the birth smart contract and the plurality of smart emission reduction contracts form a time series of smart emission reduction contracts, which defines a unique non-fungible digital twin (NFDT) representing the offset action, and If the additional carbon emission reduction in one of the plurality of smart emission reduction contracts is positive, then Using the respective emission reduction smart contract to obtain an additional plurality of carbon neutral tokens (CNTs) by executing a CNT smart contract on the blockchain, wherein the amount of carbon neutral tokens issued is determined from the carbon emission reduction amount in the respective emission reduction smart contract; Storing the additional plurality of CNTs; and Selling one or more of the additional plurality of CNTs for trading. The method of claim 1, wherein for each of the plurality of smart emission reduction contracts, the method further comprises: Obtaining from the issuing authority in the country a subsequent carbon emission reduction certificate and a subsequent carbon emission redemption certificate associated with the carbon offset action that generated the additional carbon emission reduction, wherein the additional carbon emission reduction is verified by a third-party verification authority or the issuing authority, and the subsequent redemption certificate prevents further trading of the carbon emission reduction certificate in the country; Placing the subsequent carbon emission redemption certificate in the regulatory agency to prevent further trading or use of the subsequent carbon emission reduction certificate; Generate a subsequent information package and store it at a subsequent reporting address, wherein the subsequent information package at least includes the additional carbon emission reduction, the subsequent carbon emission reduction certificate and the subsequent redemption certificate; Cryptographically sign the subsequent information package and obtain a subsequent hash for authenticating the subsequent information package; and At least the owner address, the identifier, the additional carbon emission reduction, the subsequent reporting address and the subsequent hash of the subsequent information package are input into the smart emission reduction contract in the blockchain, wherein once published on the blockchain, the smart emission reduction contract forms a subsequent smart emission reduction contract of the NFDT, and the submitted information is stored on the blockchain at a subsequent smart contract address. A method as claimed in claim 1 or 2, wherein one or more of the plurality of CNTs are sold for trading outside the country that issued the carbon emission reduction certificate. A method as claimed in claim 1, 2 or 3, wherein the CNTs are offered for trading on a digital asset exchange, the digital asset exchange maintains a ledger of CNTs for trading on the digital asset exchange, and the plurality of CNTs are stored in a cold wallet associated with the digital asset exchange. A method as claimed in claim 4, wherein the digital asset exchange comprises a plurality of listed items, each of which is a digital representation of an asset that can be traded on the digital asset exchange by an issuing entity, and the ledger stores a carbon footprint attribute value for each listed asset. The method of claim 5, wherein: An issuing entity of an asset having a carbon offsetting action establishes an NFDT on the digital asset exchange to represent the asset associated with a carbon offsetting action, and lists a plurality of asset-backed tokens, each of which has a zero-carbon footprint attribute value representing a financial and/or operating profile of the asset and a plurality of CNTs generated attributable to the carbon offsetting action; and An issuing entity of an asset that generates carbon emissions establishes a NFDT on the digital asset exchange to represent the asset that generates the carbon emissions, and lists a plurality of asset-backed tokens, each of which has a negative carbon footprint attribute value attributable to the carbon emissions associated with the asset, wherein the carbon footprint attribute value is updated on the ledger as additional carbon emissions data is obtained over time, The carbon footprint attribute value of each listed item traded on the digital asset exchange is tracked through the ledger of the digital asset exchange, and the digital asset exchange is configured to provide an investor of the digital asset exchange who holds an investment portfolio on the exchange with a portfolio value of the investment portfolio and a carbon footprint attribute value of the investment portfolio obtained by summing the carbon footprint attribute values of each investment in the investment portfolio. A method as in claim 6, wherein each listed item further includes one or more environmental, social and governance (ESG) metrics, and the ledger tracks each of the one or more ESG metrics for each listed item, and the digital asset exchange is configured to provide an investor in the digital asset exchange with an overview of each of the one or more ESG metrics obtained by summing each of the one or more ESG metrics for each investment in the portfolio. The method of claim 5, wherein the CNTs are offered for trading on the digital asset exchange as part of a package having one or more of the plurality of listed projects to offset the carbon footprint attribute value of respective one or more assets associated with the one or more listed projects. The method of claim 4, further comprising permanently freezing one or more of the plurality of CNTs to achieve carbon neutrality of a neutralized asset, comprising: A first entity purchases a CNT neutralization amount on the exchange; The first entity submits a neutralization information package to the digital asset exchange, the neutralization information package comprising at least information about the following: the neutralized asset to be neutralized, a certification of a carbon footprint of the neutralized asset obtained from a third-party verification authority, and the purchased CNT neutralization amount to be used to offset the carbon footprint; Removing the purchased CNTs from the transaction on the digital exchange, and removing the entry of the first entity from the ledger; The digital asset exchange cryptographically signs the neutralization information package and obtains a neutralization hash for authenticating the neutralization information package; Establishes a node on a public carbon neutrality blockchain, the node including an address of the neutralization information package, the neutralization hash, and a record indicating that the purchased CNT is permanently frozen; and Issues a neutralization certificate linked to the node by the digital asset exchange. The method of any one of claims 1 to 9, further comprising collecting carbon offset data from the carbon offset action, and submitting the carbon emission data to the third-party verification authority to obtain verified carbon emission reductions. The method of claim 10, wherein the carbon offset data is obtained using a secure data acquisition system, the secure data acquisition system comprising a plurality of hardware and software components configured to securely collect and store the carbon offset data. A method as in any one of claim 1 to 11, wherein the blockchain is an Ethereum blockchain, and the emission reduction smart contract is based on the ERC721 standard, and the CNT smart contract is based on the ERC20 standard. A method as in any one of claim 1 to 12, wherein the report address is a uniform resource identifier (URI) address or a uniform resource locator (URL) address. A method as in any of claims 1 to 13, wherein the plurality of CNTs are stored in a cold wallet used in a closed regulatory facility or stored on a public blockchain. A method for generating a digital representation of an asset for trading, comprising: Calculating a carbon footprint attribute value of an asset based on a preset standard or based on carbon emission related data provided by an asset holder; Obtaining a verification certificate from a third-party verification authority that verifies the carbon footprint attribute value of the asset; Generating an information package and storing it at a reporting address, wherein the information package at least includes the carbon footprint attribute value, the verification certificate, information about the carbon footprint of the asset, and financial and/or operational information of the asset; Cryptographically signing the information package and obtaining a hash for authenticating the information package; Inputting at least the hash of an asset owner address, an identifier, the carbon footprint attribute value, the reporting address, and the information package into an asset smart contract on a blockchain, wherein once published on the blockchain, the asset smart contract defines a birth smart contract and the submitted information is stored on the blockchain at the birth smart contract address; Listing the asset for trading; Storing the carbon footprint attribute value associated with the asset in a ledger; and A plurality of asset smart contracts are published on the blockchain, wherein each asset smart contract is published at a different time, and each asset smart contract after the birth smart contract includes an additional carbon emission amount since the issuance of the previous asset smart contract and a link to one or more of the previous asset smart contracts published on the blockchain including the birth smart contract, wherein the birth smart contract and the plurality of asset smart contracts form a time series of emission reduction smart contracts that define a unique non-fungible digital twin (NFDT) representation of the asset, and after the issuance of the additional asset smart contract, the carbon footprint attribute value associated with the asset in the ledger is updated based on the additional carbon emission amount. The method of claim 15, wherein the asset is listed for trading on a digital asset exchange, wherein the digital asset exchange includes the ledger. The method of claim 15 or 16, wherein if the carbon footprint attribute value is positive, the asset smart contract is used to obtain a plurality of carbon neutral tokens (CNT) by executing a CNT smart contract on the blockchain and the plurality of CNTs are issued to an issuer and recorded on the ledger, wherein the amount of the carbon neutral tokens issued is determined from the carbon footprint attribute value, and the issuance The plurality of CNTs are available for trading, and if the carbon footprint attribute value is negative, the asset smart contract is used to obtain a plurality of asset-backed tokens by executing an asset-backed token smart contract on the blockchain, and the ABTs are issued to an issuer and recorded in the ledger, wherein the amount of the asset-backed tokens issued is determined from the financial and/or operating information of the asset. The method of any one of claims 15 to 17, further comprising collecting carbon offset data from the asset and submitting the carbon emission data to the third-party verification authority to obtain verified carbon emission reductions. A method as in claim 18, wherein the carbon emission data is obtained using a secure data acquisition system, the secure data acquisition system comprising a plurality of hardware and software components configured to securely collect and store the carbon emission data. A method as in any of claims 15 to 19, wherein the blockchain is an Ethereum blockchain, and the asset smart contract is based on the ERC721 standard, and the asset-collateralized token smart contract is based on the ERC20 standard. A method as in any one of claim 15 to 20, wherein the report address is a uniform resource identifier (URI) address or a uniform resource locator (URL) address. A method for trading on a digital asset exchange including a ledger, wherein the method includes: listing one or more CNTs generated by a method such as any one of claim items 1 to 14; generating multiple listings of multiple assets, each listing being generated by a method such as any one of claim items 15 to 21, updating the ledger by updating a carbon footprint attribute value of the trader stored in the ledger based on the total carbon footprint attribute value associated with the listed asset when a trader purchases a share of a listed asset, and/or updating the ledger when a trader purchases one or more CNTs, wherein the carbon footprint attribute value of the trader stored in the ledger is updated based on the number of one or more CNTs purchased. The method of claim 22, wherein the trader may purchase a package, wherein the package comprises a share of a listed asset and an amount of CNTs to offset carbon emissions associated with the share of the listed asset. An asset trading system, comprising: A plurality of computing devices, comprising one or more processors, one or more memories, one or more storage devices and one or more interfaces, wherein the one or more interfaces are configured to receive one or more information packages and store them in the one or more storage devices, and the plurality of computing devices are configured to execute the method of any one of claims 1 to 23. An asset trading system as claimed in claim 24, wherein the plurality of computing devices are configured to implement a blockchain. An asset trading system as claimed in claim 24 or 25, wherein the plurality of computing devices are further configured to implement a digital exchange, and the one or more storage devices are configured to implement a ledger and a cold wallet. An asset trading system as claimed in claim 24, 25 or 26, further comprising a secure data acquisition system comprising a plurality of hardware and software components configured to securely collect and store carbon offset data and carbon emission data generated by one or more assets. A computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the method of any one of claims 1 to 23. A method for generating a non-fungible digital twin (NFDT) of an asset, comprising: Generating an information package and storing it at a reporting address, wherein the information package contains information about an asset, including at least one attribute value; Cryptographically signing the information package and obtaining a hash for authenticating the information package; Inputting at least an owner address, an identifier, the at least one attribute value, the reporting address, and the hash of the information package into an asset smart contract in a blockchain, wherein once published on the blockchain, the smart contract defines a birth smart contract, and the submitted information is stored on the blockchain at the birth smart contract address; Using the birth smart contract to obtain a plurality of asset-backed tokens (ABTs) by executing an ABT smart contract on the blockchain, wherein the amount of the issued asset-backed tokens is determined from the at least one attribute value in the birth smart contract; Storing the plurality of ABTs; Selling one or more of the plurality of ABTs for trading; and A plurality of asset smart contracts are published on the blockchain, wherein each asset smart contract is published at a different time, wherein the value of the at least one attribute value in each asset smart contract after the birth smart contract is the change of the value since the publication of the previous asset smart contract and a link to one or more of the previous asset smart contracts published on the blockchain including the birth smart contract, and each smart contract is used to issue, store and sell a plurality of ABTs based on the value in the respective smart contract, wherein the birth smart contract and the plurality of emission asset contracts form a time series of asset smart contracts that define a unique non-fungible digital twin (NFDT) representation of the asset. An asset trading system, comprising: A plurality of computing devices, comprising one or more processors, one or more memories, one or more storage devices and one or more interfaces, wherein the one or more interfaces are configured to receive one or more information packages and store them in the one or more storage devices, and the plurality of computing devices are configured to execute the method of claim 29.