Revolutionizing the Climate Market: How ERC3525 Empowers Fractionalized Carbon Credit and Renewable…
This article was initially written by @abbagarba1
Revolutionizing the Climate Market: How ERC3525 Empowers Fractionalized Carbon Credit and Renewable Energy Certificate Trading on the Web3 and ReFi Platform
This article was initially written by @abbagarba1
Introduction
The traditional methods of processing and transacting Carbon Credits(CCs)/Renewable Energy Certificate (RECs) have recently taken an innovative step to revolutionize the entire system. Thanks to the power of blockchain and Web3 technologies, innovation allows us to solve massive coordination problems critical for responding to the climate challenge. The main aim is to address the complex and inefficient processes of validating and issuing CCs/RECs managed by authorized legacy registries (i.e., the Verra registry for CCs or I-REC for RECs issuance) now being handled on-chain. To represent the type and amount of CCs/RECs, hybrid ERC standards are used; ERC721 is used to create CCs/RECs, CCs/RECs can be fractionalized into ERC20 tokens. However, in terms of representing CCs/RECs, the hybrid protocol has some limitations, such as the use of multilateral contracts to create CCs/RECs. Furthermore, many contract addresses are required for each project across multiple regions or geolocations. Consequently, utilizing the hybrid ERC token protocol (i.e., ERC721, ERC20) to represent CCs/RECs requires a complex process for deployment.
ERC-3525, known as the “Semi-Fungible Token” (SFT), is an all-purpose and unidirectional asset token standard that merges the quantitative features of an ERC-20 token with the illustrative features of an ERC-721 token (NFT). ERC-3525 provides a new method of representing CCs/RECs. ERC-3525 has a slot ID and value field, which makes it easy to transfer some of the value to another token in the same slot; thus, even if they have different IDs, for example, in the ERC-3525 SFT protocol, CCs/RECs with the same slot can be tokenized and be fungible.
In this article, we first provide a general introduction, then explain how the existing bridging protocols tokenized CCs or RECs and their shortcomings, why the ERC-3525 SFT protocol is an alternative choice to tokenize CCs/RECs, and finally provide a conclusion.
Background of the Existing Carbon Bridge protocols
Bridging protocols such as Toucan/FlowCarbon have been developed in order to add CCs to the chain. For example, anyone can use a bridging protocol such as Toucan to bridge their CCs from approved legacy registries (Verra registry) on-chain to ensure that bridged CCs come from trusted and reliable sources. Moreover, CCs can be added to the Toucan Meta-Registry as tokenized CCs, and they can be fractionalized to form fungible tokens known as TCO2s. These tokenized carbon credits can be deposited into carbon pools while retaining their metadata, and for each TCO2 submitted, a fungible carbon reference token is issued.
Consequentially, with blockchain and smart contracts as fundamental principles to accelerate the Web3 ecosystem, fungible carbon-referencing tokens like Based Carbon Tone (BCT) and Nature Carbon Tone (NCT) can now be offset with on-chain transparency.
How the Existing Bridging Protocols Tokenized CCs/RECs?
The bridging protocol, exemplified by Toucan, facilitates the transfer of verified CCs along with all their associated attributes to the blockchain. Once tokenized, these CCs take the form of NFTs, which are digital assets capable of being divided into fractional units, pooled, traded, or withdrawn as required. The details of the CCs, including their type, year, location, and carbon tonnage, are stored within a contract called BatchNFT. To represent the type and quantity of CCs, hybrid ERC standards are employed. Specifically, the ERC721 standard is used to create individual CCs as unique NFTs. Moreover, these CCs, represented by ERC721, can be further fractionated into ERC20 tokens, adhering to the ERC20 standard, allowing for seamless divisibility and fungibility of the CCs on the blockchain.
Fig.1 Shows the general framework of the current bridging protocol
The above diagram illustrates the detailed description of the on-chain CCs/RECs bridging framework.
The protocol mainly realizes tokenization through the following functions: the project owner and sources, carbon bridge, carbon pools, and market DeFi integration. The process of transferring legacy CCs/RECs on-chain via the bridging protocol is as follows:
1) Projects
CCs/RECs/offset owner (projects): The entity that owns or controls the Verra carbon offsets and wants to use the bridge protocol to convert them into blockchain-enabled tokens to trade or burn.
2) Bridging protocol process
CCs/RECs are transferred on-chain via the carbon bridge protocol such as Toucan and become a “BatchNFT,” an NFT that encompasses details of the CCs/RECs type, year, location, and carbon tonnage or RECs amounts.
3) A fractionalized asset or token
To enhance liquidity, these CCs/RECs are formed into BatchNFT, which is fragmented into ERC-20 fungible token.
4) Market integration or DeFi
Subsequently, the ERC-20 tokens are deposited into various “Carbon Pools” in accordance with predetermined criteria; depositors can then swap the ERC-20 tokens for alternative “carbon reference tokens” in exchange.
Reasons for using the hybrid protocol to tokenize CCs/RECs
In order to bring the different types of CCs/RECs on-chain without losing the essential properties of each CC/REC. Because each CC/REC is a separate NFT and all specific information is explained in the metadata of the minted CCs/RECs, hybrid protocols (e.g., ERC-3525 and ERC-20) are now the current method used in the bridging protocol to tokenize CCs/RECs.
Based on different properties such as geographical location, there are several kinds of CCs/RECs. Each category is bound by a combination of types, years, amounts, etc. ERC-721 can describe these properties and represent a certain asset. However ERC-721 lacks the concept of value (e.g. carbon tonne), hence to allow the transaction of a portion of an asset, the ERC-721 token have to be further fractionalized to ERC-20 tokens.
Yet ERC-20 cannot describe any non-fungible properties among the tokens. For example, the price of RECs in Malaysia may differ from those in Australia. Thus, ERC-721 tokens representing Malaysia RECs must be fractionalized to different ERC-20 tokens from Australia’s. So multiple smart contracts are deployed to distinguish them.
Shortcomings of the Current Approaches
In the present bridging protocols, the tokenization of CCs or RECs can be accomplished through two endorsed methods, namely, those supported by Toucan or FlowCarbon. The tokenization process involves the utilization of either the ERC-721 token to represent individual CCs/RECs or multiple ERC-20 contracts to represent fractionalized CCs/RECs. Nonetheless, these approaches possess certain drawbacks concerning the representation of CCs/RECs. For example, the current CCs/RECs incorporate at least the following information fields, which the aforementioned ERC standards do not support:
- Country/Region
- Vintage (date range)
- CCs/RECs Amount (Tone/MWh)
- Retirement State
- Proof to verify the above
Consequently, utilizing the hybrid ERC token protocol (i.e., ERC721, ERC20) to represent CCs/RECs requires a complex process for deployment. Since multilateral contracts are used to create CCs/RECs, many contract addresses are created for different projects across many regions, which cost more blockchain resources and may pose additional complexity in handling transactions.
As for ERC721, it is nothing more than a verifiable URL pointing to any useful information. However, no contract-native field exists to represent the required information, such as the amount of green asset data for the minted RECs. For this reason, when considering applying ERC-721 to form an CCs/RECs, two parameters (the owner’s address and the unique token ID) should be considered, and then everything is included in the location where the URL specifies in the blockchain. One point to note is that ERC721 does not standardize the metadata structure of the minted CCs/RECs; it only shows simple representations to indicate how the URL is specified. Hence, some essential features such as the vintage, location, and region as for the case of RECs are not included. In order to suitably utilize ERC721 to create a CCs/RECs, a customizable field in the metadata is needed. Considering that in ERC721, there is no value field, there is a need to store the value in the metadata, notwithstanding that this is not the standardized way to store the token.
In ERC-20, it is nothing but a verifiable digit. There is no on-chain field to store any information about what the digit represents. The transfer is simple for ERC-20, but CCs/REC is more than just a digit (e.g., metadata). If we use ERC20 to record an CCs/RECs, for example we use the value information to report 5 MWh of green data assets generated for the minted REC, but the main issue with ERC20 in recording a REC is that it has limited information, only the owner’s address and the value of the green electricity generated. In this case, there is no other way to specify the region, the vintage, the time slot, etc.
Why is the ERC-3525 SFT protocol a better choice for issuing fractionalized CCs/RECs?
ERC-3525 SFT introduces a novel type of digital asset rooted in blockchain technology, blending the features of both fungible and non-fungible characteristics. Distinguished from ERC-20 or ERC-721 tokens, ERC-3525 presents a cutting-edge digital representation encompassing ownership, value, rights, status, and identity. The standard supports various attributes, such as texts, images, links, or file data, which can be subdivided into multiple fractions. Furthermore, ERC-3525 SFT disrupts the conventional token-to-address transfer mechanism, unlocking an array of unprecedented use cases, distinct from the ERC-20 token model. These SFTs possess a high level of descriptiveness, enabling the display of image formats (e.g., jpeg and gif), real-time on-chain data feeds, and file attachments. Similar to the aggregation of multiple ERC-20 tokens, users can fractionalize an SFT or combine multiple SFTs using the unique mechanism inherent to ERC-3525 tokens, facilitating the grouping of otherwise unique entities under the notion of like-kindness.
Each ERC-3525 token is identifiable by a unique ID, but it also permits quantitative operations on other SFTs, provided that they reside in the same slot. This functionality enhances the versatility and utility of ERC-3525 SFTs, making them a powerful tool for various applications in the blockchain ecosystem.
Slot
ERC-3525 has a slot ID and value field, which makes it easy to transfer some of the value to another token in the same slot. That is generally ERC-3525 transfer value from a specified token to another specified token with the same slot. As a result, even if they have different IDs, for example CCs/RECs in the same slot can be fungible. For example, RECs produced by solar panels in the same country or region can be tokenized using ERC-3525 tokens within the same slot. ERC-3525’s Slot ID is a key feature, allowing CCs/RECs NFT to be natively classified by country or region.
Fig. 2 Shows how part of the REC can be transferred to other entities in the same slot ID or region
In the figures above, it is illustrated that the CCs/ RECs are fungible, can be fractionalized into parts, and transferred to other entities in the same slot ID or region. This means that a green asset owner with RECs equal to 5.3 MWh in a specific region or location can transfer some of the RECs to third parties or use them for other purposes such as trading, burning, or conducting climate action. Part 1 REC was left with 2.3 MWh, while the remaining 3 REC were transferred to Parts 2–4, each of which received 1 MWh of REC.
Token-to-Token Transfer
SFTs are digital containers that allow users to easily send, receive, or store digital assets. A project or offset owner, for example, can transfer fragmented REC assets to another person. What makes ERC-3525 unique is its ability to transfer only a fraction of the underlying digital asset (e.g., CCs/RECs) within an ERC-3525 token. Moreover, ERC-3525 provides a paradigm shift in the asset transfer method called token-to-token transfer**.** Such a transfer is implemented using the token-to-token (tokenID) transfer for tokens that have the same slot. It enables the receiving, storing, and transferring of an asset using tokens rather than addresses.
The diagram below, illustrates the token-to-token transfer for the RECs. Assuming Bob has 10MWh of the tokenized REC, Alice transfers some of her tokenized REC to Bob. Alice has 5.3 MWh of REC and decided to transfer it to Bob’s 1.3 MWh since they are in the same slot. Alice transferred 1.3 MWh of the REC to Bob, while Alice still remained with 4 MWh of the RECs. Bob now has 11.3MWh of the tokenized RECs.
Fig. 3 illustrates how the token-to-token transfer for the RECs
How does ERC-3525 is deployed for fractionalized RECs issuing?
The data structure of fractionalized RECs based on ERC3525 SFT contain the following parameters:
1. A Token ID: is the unique identifier code for an NFT. It is a key data point that is used to differentiate one CC/REC from another on a blockchain. The tokenID in ERC-3525 is outlined as a value type in terms of a uint256, which is an equivalent to the tokenID in ERC-721. For example in ERC-3525 tokenID reflects the non-fungible aspect of the CCs/RECs.
2. Slot: is a new attribute that categorizes variables in the CCs/RECs. Using ERC-3525 protocol, the Country/Region can be pulled out as the Slot ID of the ERC-3525 for classification, and the number CCs/RECs can be pulled out as the value of the ERC-3525, forming fractionalized CCs/RECs.
3. Value: same as the balanceOf() / value mechanism in ERC-20, balanceOf() in ERC-3525 is used to query the amount of the underlying asset (e.g., in tones for the CCs or MWh for the REC,) of an ERC-3525 token. Put in another away, transferring ERC-3525ʼs value to other addresses works similarly to transferring value for ERC-20 tokens.
4. Metadata in CCs/RECs: The data contained in a CC/REC, such as the country or region in which the CCs/RECs are located, the year, and so on.
Assuming Alice has an REC of 5.3MWh as an example. If Alice wants to retire portion of her RECs using ERC-3525 SFT, she can use a standardized way to offset 1.3MWh out of the total 5.3MWh. With ERC-3525 RECs can be easily fragmented and aggregated to form full RECs as follows:
Assuming Alice has an ERC-3525 REC of 5.3MWh as an example. If Alice wants to retire portion of her REC, she can use a standardized way to offset 1.3MWh out of the total 5.3MWh. With ERC-3525 RECs can be easily fragmented and aggregated to form full RECs as follows:
1. Alice generated 5.3MWh of REC
a. Slot ID is the location of the REC (e.g., country or region).
2. Alice is willing to offset her carbon by retiring her REC.
a. Alice transfers some portion of her REC (1.3MWh) to the Burner address
3. Burner is an on-chain service for the REC retirement.
4. Burner helps Alice to permanently freezes the specified portion of REC value. The freezing action is known as RECs retirement.
Fig. 4 typical of data structure of fractionalized RECs based on ERC3525 SFT
Assuming Alice has an REC of 5.3MWh as an example. If Alice wants to retire portion of her RECs using ERC-3525 SFT, she can use a standardized way to offset 1.3MWh out of the total 5.3MWh. With ERC-3525 RECs can be easily fragmented and aggregated to form full RECs as follows:
Assuming Alice has an ERC-3525 REC of 5.3MWh as an example. If Alice wants to retire portion of her REC, she can use a standardized way to offset 1.3MWh out of the total 5.3MWh. With ERC-3525 RECs can be easily fragmented and aggregated to form full RECs as follows:
1. Alice generated 5.3MWh of REC
a. Slot ID is the location of the REC (e.g., country or region).
2. Alice is willing to offset her carbon by retiring her REC.
a. Alice transfers some portion of her REC (1.3MWh) to the Burner address
3. Burner is an on-chain service for the REC retirement.
4. Burner helps Alice to permanently freezes the specified portion of REC value. The freezing action is known as RECs retirement.
Fig. 5 Simple example of how RECs are transfer using ERC3525 SFT
Country/Region of the RECs can be pulled out as the Slot ID for classification. Amount of an REC can be pulled out as the value of the ERC-3525 SFT.
Conclusion and Closing thoughts
Considering the potential for a hybrid approach to tokenize and fractionalize CCs/RECs generated from diverse global sources, the hybrid bridging protocol converts CCs/RECs to ERC-721 to establish a compatible ERC-20 token. This allows for fractionalization, retirement, withdrawal, pooling, swapping, or trading of CCs/RECs alongside other digital assets with on-chain transparency. However, this hybrid method lacks the ability to differentiate the regions or locations of CCs/RECs using only one ERC-20 contract. A solution proposed is to create multiple ERC-20 contracts, each dedicated to a specific region or country, but this could be economically impractical.
Undoubtedly, ERC-3525 SFT represents a significant opportunity within the NFT domain. Specifically, ERC-3525 SFTs combine quantitative attributes of fungible tokens with descriptive features of non-fungible tokens. Being an extension of ERC-721, ERC-3525 maintains full backward-compatibility with the latter. Although there is currently no popular DEX (Decentralized Exchange) for ERC-3525, like UNISWAP for ERC-20, Notwithstanding that there has recently been an increase in interest in 3525 SFT among the various players in the blockchain ecosystem. Despite being in its early stages, the ERC-3525 SFT protocol has substantial potential to introduce new use cases in Ethereum protocols.
By Arkreen on July 31, 2023.