-
Notifications
You must be signed in to change notification settings - Fork 133
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Signed-off-by: simvalery <[email protected]> Signed-off-by: simvalery <[email protected]>
- Loading branch information
Showing
2 changed files
with
193 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1 +1,98 @@ | ||
## Guardian Policy for Improved Cookstoves | ||
|
||
**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 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. Through 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 account 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 posted to traceable, immutable source which can be accessed by the Tolam Earth Marketplace. | ||
|
||
**Policy User Roles**: | ||
1. Project Developer: 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. | ||
|
||
**Schema**: | ||
|
||
1. Agent Application (AA) | ||
2. Project Listing Application (PLA) | ||
3. Project Listing Application (PLA) - Review | ||
4. Project Design Document (PDD) | ||
5. Project Design Document (PDD) - Review | ||
6. Project Registration Request (PRR) | ||
7. Monitoring Report (MR) | ||
8. Monitoring Report (MR) - Review | ||
9. ICCC Issuance Request (CIR) | ||
|
||
**Glossary**: | ||
|
||
Guardian: The Guardian is a modular open-source solution that includes best-in-class identity management and Decentralized Ledger Technology (DLT) libraries. At the heart of the Guardian solution is a sophisticated Policy Workflow Engine (PWE) that enables applications to offer a requirements-based tokenization implementation. | ||
|
||
Guardian Policy: Defines activities, rules, and interactions between activities on and across all levels of the activity hierarchy, that are performed in order to achieve the outcome of an auditable, transparent claim of climate impact. | ||
|
||
Guardian Schema: Describes the structure and definition of data fields required within an activity, sub-activity, or sub-sub-activity. Essentially, the schema defines the data fields that must be supplied for each activity and the characteristics of those fields. | ||
|
||
Standard: Set of project design, monitoring, and reporting criteria against which activities’ impacts can be certified or verified, e.g. Greenhouse Gas (GHG) emission reductions, or social benefits. | ||
|
||
Standards Body: Organization which defines the standard and approves project design, monitoring, and reporting criteria within it. | ||
|
||
Methodology: As part of a Standard, Methodologies define the rules for calculating emissions increase, footprint, reductions and/or removals. | ||
|
||
Project Documentation: Any documentation required by the Guardian Schema. This may include Monitoring Reports, Project Design Documents, Verifier Credentials, etc. | ||
|
||
Project Design Document: Documentation of plans for an activity to be executed following the prescriptions of the Standard in a concrete context for generation of assets. | ||
|
||
Project Listing Application: Process during which a Project Developer expresses their intent to develop a (cookstove) project towards a specific Registry, and the Registry then acknowledges that intent by assigning a project code to the project and listing it in the Registry’s public database of projects. | ||
|
||
Project Registration: When Project Design Documents are approved by a Registry. | ||
|
||
|
||
**Monitoring Report**: | ||
|
||
Document that describes and justifies any changes to the Project Design Document, based upon what happened during execution of a project. Also includes any data and/or calculations made during the time period covered by the document. A single project can have multiple Monitoring Reports associated, and each Monitoring Report is associated with a Claim. | ||
Claim: The end result of execution of a project, often expressed per unit time, which quantifies the impact of the initiative. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1 +1,97 @@ | ||
## Tolam Earth Non-Digital General Guardian Policy | ||
|
||
**Introduction**: | ||
|
||
In order to increase trust in supply of quality offsets, it is ideal that a Project originate and conclude its Activity within secure, traceable technology such as blockchain. The Tolam Earth Marketplace can not assume that all potential sellers of offsets will have worked with Registries that leverage this technology. This Guardian Policy seeks to initiate a transparent and immutable digital path for offset projects which do not yet utilize the Hedera blockchain. | ||
|
||
This Guardian Policy is a general policy which accepts multiple project types and which allows for entering the accepted Standard under which a project may have been developed. The associated Token that offsets are minted under is a Tolam Non-Digital (TND) Token. By default this policy will mint NFT to the account ID entered into the Issue Request or Claim. | ||
|
||
**Scope and Applicability**: | ||
|
||
This Guardian Policy addresses carbon offset projects that originate outside of the Hedera Ecological ecosystem, and from which claims will be tracked or exchanged within the Hedera ecosystem. | ||
|
||
This Guardian Policy should not be used for Agriculture, Forestry, and Other Land Use (AFOLU) projects due to the risk of non permanence. | ||
|
||
Token: Non-Fungible, No KYC | ||
|
||
Type: Carbon Offset | ||
|
||
Standard: Multiple | ||
|
||
Methodology: Multiple | ||
|
||
Required Documents: Project Design Document (PDD), Validation Report, Monitoring Report, Verification Report, Double Counting Certification, VVB Certification and Conflict of Interest Statement | ||
|
||
NFT Owner: Seller | ||
|
||
**Preconditions**: | ||
|
||
1. The Project Developer or Registry must be approved by Tolam Earth, Inc. The Project Developer or Registry shall: | ||
a. Ensure a Project adheres to the Standard claimed | ||
b. Ensure no Double Counting of claims has occurred | ||
c. Ensure rights to sell both within and outside of the Host Country | ||
d. Ensure Validation and Verification of the Project has occurred by an accredited Third Party | ||
e. Know Your Customer (KYC) analysis has been completed for all parties to the satisfaction of Tolam Earth, Inc. | ||
|
||
2. A traceable, immutable document storage solution exists to store Project Documentation. | ||
|
||
3. All Project Documentation, inclusive of but not limited to project design documents (PDD), validation reports, monitoring reports, verification reports, and conflict of interest statements, is made available to Tolam Earth, Inc. | ||
|
||
4. Originating Registry or Project Developer has a mechanism to “Burn and Tokenize” or transfer offsets once the project is accepted by Tolam Earth, Inc. | ||
|
||
**Policy User Roles**: | ||
|
||
1. Administrator: Approves sellers, accepts projects, approves reports, and initiates offset creation. Assumes the Guardian Standard Registry role. This person is the Tolam Earth accountable party. | ||
|
||
2. Transcriber: The User who manages Project Documentation outside of the Guardian for Tolam Earth and transcribes into the Guardian. | ||
|
||
3. Seller: The User who is to be considered the owner of the offsets and who has authority to offer them for sale on the Tolam Earth Marketplace. | ||
|
||
**Guardian Policy Workflow**: | ||
|
||
<img width="407" alt="image" src="https://user-images.githubusercontent.com/79293833/199070132-10690758-a51e-47e4-9391-0fc7bd5494ee.png"> | ||
|
||
**Schema**: | ||
|
||
1. Common Attributes: Specific attributes required for pricing and transparency to buyers. Aligned with IWA CCA’s and CCP’s, and according to w3 vocabulary standards. | ||
|
||
2. Project Information: A subset of the Common Attributes that are specific to a Project. | ||
|
||
3. Registry Data: A subset of the Common Attributes that are specific to a Registry. | ||
|
||
4. SDG Impact: A subset of the Common Attributes specifically addressing Social Development Goals (SDG). | ||
|
||
5. Project Documentation: Includes links to Project Documentation as Required by the selected Standard for Project Validation, links to documentation that is required by Tolam Earth, and optional links to additional documentation or images. | ||
|
||
6. Report: Project information and Monitoring Documents | ||
|
||
7. Monitoring Documents: Links to one or more verified Monitoring Reports. | ||
|
||
8. Claim: Hedera account ID of the Seller/offset owner, vintage, number of offsets requested, crediting period start and end date, the status of the claim (offset) in the originating Registry, and Monitoring Documents. | ||
|
||
9. Seller: Seller Hedera account ID, contact details, and required attestations. | ||
|
||
|
||
**Glossary**: | ||
|
||
Activity: An action entered into by an individual or group of individuals with intent to achieve a defined outcome. | ||
|
||
Double Counting: Occurs when an offset is claimed or counted by more than one entity or multiple times by a single entity. | ||
|
||
Guardian Policy: Defines activities, rules, and interactions between activities on and across all levels of the activity hierarchy, that are performed in order to achieve the outcome of an auditable, transparent claim of climate impact. | ||
|
||
Guardian Schema: The structure and definition of data fields required within an activity, sub-activity, or sub-sub-activity. | ||
|
||
Host Country: The country’s border within which the majority of the physical Project Activity takes place. | ||
|
||
Project: Activity that adheres to the prescription of the Project Design. A Project is the activity that exists in real life. | ||
|
||
Project Design: Plans for an activity to be executed following the prescriptions of the Standard in a concrete context for generation of assets. | ||
|
||
Project Developer: A person or organization who designs, develops, and manages the life cycle of a Project. | ||
|
||
Project Documentation: Any documentation required by the Guardian Schema. This may include monitoring reports, project design documents, verifier credentials, etc. | ||
|
||
Registry: An organization that ensures a Project adheres to the Standard throughout its life cycle. | ||
|
||
Standard: Set of project design, monitoring, and reporting criteria against which Greenhouse Gas (GHG) emission or reduction activities and/or projects’ environmental and social co-benefits can be certified or verified. |