♨️Improved Cookstove

Policy developed by Tolam Earth, Inc and Nova Institute

Introduction

Currently, there are many different types of cookstoves and several Standards Bodies, each with their own Standard that must be followed in order to prove the quality of a given GHG emission reduction claim. This process is time and labor-intensive, creating barriers to those willing to enter the market. Digitization of this manual, paper-driven process is a necessary step to scaling at the speed required for climate change.

The Value of Digitizing the Methodology:

Creates trust via

● Traceability and transparency of data

● Digital quality assurance

● Immutability of data

● Transparency of Verifier credentials and approval data

Reduces barriers to entry

● Accessible and standardized policies and processes inform and encourage suppliers to bring their projects to market

● Decentralized project management reduces dependency on Standards Bodies and reduces time to market.

Contributes to Climate Goals

● Achieves higher confidence in carbon project outcomes, and scales the finance and rollout of carbon projects at the speed required by the climate emergency

This first-of-its-kind Improved Cookstove Guardian Policy was designed per the Anthropogenic Impact Accounting Ontology found here An ontology for anthropogenic impact accounting. To this end, the Guardian Policy does not adhere to a specific Standard or approved methodology for carbon offset quantification, rather it abstracts concepts from all known standards and methodologies, categorizes them, models their relationships, and then instantiates them in the form of this digitally native Guardian Policy and its associated Guardian Schema. This policy issues a non-fungible Improved Cookstove Carbon Credit (ICCC) Token.

Scope and Applicability

Guardian implementation of a digitally native methodology for quantifying greenhouse gas (GHG) emission reductions from improved biomass cookstoves developed by the Nova Institute and Tolam Earth, Inc.

Applicable to activities reducing GHG emissions from cookstoves:

1. Switching to more efficient stove technology

Token: Non-Fungible Type: Carbon Offset Standard: Multiple Methodology: Multiple

Required Documents: Project Design Document (PDD), PDD Validation Report, Monitoring Report, Monitoring Report Verification, Double Counting Certification,

VVB Certification and Conflict of Interest Statement

NFT Owner:

Preconditions

1. Standard Registry accounts on a Guardian instance to import the policy. See Guardian documentation at (https://docs.hedera.com/guardian/policy-creation-using-the-guardian-apis/prerequesite- steps) for steps to create an account and import a policy.
2. User accounts within the Guardian to fill the roles defined in this policy.

3. Required Project Documentation is posted to the traceable, immutable source which can be accessed by the Tolam Earth Marketplace.

Policy User Roles

1. Project Developer: The person responsible for executing the Project Design and Collecting Data as per the Project Application. The Project Developer submits Monitoring Reports and is the beneficiary of the Credit Claims.

2. Verifier: Approved, independent person or organization that Verifies the Project Application and Claims Data in the form of Monitoring Reports.

3. Standard Body: Administrative role that approves Verifiers, approves Project Applications, and manages the issuance of claims.

Policy Guide

We have 3 ways to import the Policy

Once imported, there will be 2 additional users with different roles (aside from the Standard Registry) that need to be created. Create a user account for the Project Developer. Once created and entered into the Policy, select the Project Developer role from the drop-down.

Fill out the Agent Application and wait for the approval.

The next step is to create a user account for the verifier. Once created and entered into the Policy, select the Verifier role from the drop-down.

Fill out the Agent Application to become a verifier and wait for approval.

Now log back into the Standard Registry account and go into the policy. You will notice now two approvals waiting for action.

The next step is for the Project Developer to create a new project. Do this by logging into the Project Developer policy screen, clicking on the "Create new project" button, and filling out the "Project Listing Application" form.

Logging back into the Standard Registry role, you can see that the Project Listings now has a new review request.

The Standard Registry can now assign a review ID and "Finalise review"

Now, the Project Developer must go into their screen and "Submit a PDD" and fill out the Project Design Document form.

The Verifier must now go into their Policy screen and view the PDD by click on the "Review button" and filling out the review form.

After that, the Verifer can select a Review ID and "Finalise review."

Once the PDD has been verified, the Project Developer can "Request registration."

The Standard Registry can log into their Policy screen, view the incoming Project Registration, and approve it.

Once the Standard Registry approved the Project Developer's Project Registration, the Project Developer can submit the report by clicking on the "Submit MR" button and filling out the form.

Once the Monitoring Report has been submitted to the Verifier, the Verifier can log into their Policy screen, review it, and fill out the review form.

The Verifier can submit the Review ID and "Finalise review"

At this point in the methodology workflow, the Project Developer can "request credit issuance" by clicking on the "Request credit issuance button" and filling out the Request ICCC issuance form.

The Standard Registry can now see the Credit Issuance request and approve it.

Once approved, you can see the Trustchain in the Token History tab of the Standard Registry's policy account.