Data Module

The data module serves the purpose of anchoring content hashes for various types of data along with timestamps, validation by verifiers, and registration with a resolver. Its primary function is to offer verifiable supporting data for credit classes, projects, and credit batches managed through the ecocredit module.

Data anchoring involves the use of a secure content hash for either raw data (non-canonical) or graph data (following the RDF data model). This process establishes a tamper-proof timestamp, essentially confirming the existence of the data at a specific point in time, often referred to as "secure timestamping." It's important to note that the sender of the transaction anchoring the data does not vouch for the accuracy of the data itself.

Following data anchoring, verifiers have the capability to attest to the accuracy of the data. Attesting to data is akin to endorsing a legal document, signifying that the attestor agrees with all conditions and, to the best of their knowledge, believes the data to be truthful. Multiple attestors can provide attestations for the same data, and each attestation is accompanied by a tamper-proof timestamp, indicating when the data was verified.

Additionally, the data module facilitates the creation and management of data resolvers. When a data resolver is established, the creator assumes the role of administrator. The admin can then proceed to register anchored data with the resolver, providing a list of content hashes that the data resolver claims to handle.

Ecocredit Module

The ecocredit module is divided into three separate components, including "Core functionality" and two submodules, the "basket submodule" and the "marketplace submodule".

Core Functionality

The fundamental capabilities of the ecocredit module encompass the establishment and administration of credit types, credit classes, and projects. Moreover, it enables the issuance, transfer, and retirement of ecosystem service credits, spanning various categories such as carbon credits, biodiversity credits, and energy credits.

Credit classes serve as the foundation for accommodating a range of ecosystem service credits and can be created and supervised by individuals, collectives, or organizations. Each credit class is linked to a credit type, which represents the principal unit of measurement for the methodologies defined within the credit class (e.g., carbon, energy, etc.). Importantly, credit types can only be introduced through on-chain governance procedures.

Ecosystem service credits are brought into existence through a batch issuance mechanism, where exclusively approved issuers associated with a particular credit class can generate credits within that class. Each credit batch is associated with a project, signifying the real-world initiative that implements the methodologies outlined within the credit class. A distinctive feature of credit batches is the inclusion of start and end dates, signifying the period during which positive ecological outcomes were assessed.

Credits produced within a credit batch can only be exchanged with credits from the same batch. These credits can be issued in either a tradable or retired state. Tradable credits afford their owners the ability to transfer or retire them, with retirement representing a permanent action that signifies the consumption of the credit as an offset.

Basket Submodule

The basket submodule provides the functionality to establish and oversee baskets within the ecosystem. These baskets are designed to accommodate ecosystem service credits that adhere to specific criteria defined by the basket. In exchange for eligible credits meeting the criteria, users receive tokens that possess full fungibility with other tokens within the same basket. These tokens are generated using the bank module from Cosmos SDK, ensuring compatibility with the Inter-Blockchain Communication (IBC) protocol. This compatibility enables ecosystem service credits to be represented as tokens, facilitating their transfer across different blockchains. When desired, ecosystem service credits can be withdrawn from the basket by returning the tokens to the basket.

Marketplace Submodule

The marketplace submodule empowers users to establish and oversee sell orders for ecosystem service credits, as well as engage in direct purchases of these credits through buy orders. It's important to note that credits can only be listed for approved token denominations, which are managed through an on-chain governance procedure. When a sell order is created, the credits associated with it are held in escrow until one of the following events occurs: the order expires, the owner cancels the order, or the order is purchased through a direct buy order. The owner of a sell order retains the flexibility to update or cancel the order at any point in time.

Last updated