program-guide.adoc

Regen Registry Program Guide

Table of Contents

• 1. Introduction
• 2. Overview
• 3. Definitions
• 4. Acronyms
• 5. Basics
  • 5.1. Regen Registry Description
  • 5.2. Regen Registry Objectives
  • 5.3. Scope
  • 5.4. Guiding Principles
• 6. Governance
• 7. Credit Classes and Methodologies
  • 7.1. New Credit Classes and Methodologies
  • 7.2. Modifications to an Approved Credit Class or Methodology
  • 7.3. Governance of Adding and Removing Credit Classes and Methodologies to the Regen Registry
  • 7.4. Access and Use of Credit Classes and Methodologies
• 8. Project Requirements
  • 8.1. General Requirements
  • 8.2. Land Tenure
  • 8.3. Project Area
  • 8.4. Project Boundary
  • 8.5. Project Ownership
  • 8.6. Project Start Date
  • 8.7. Project Crediting Period
  • 8.8. Regulatory Compliance
  • 8.9. Registration on other Registries
  • 8.10. Aggregate Projects
  • 8.11. Safeguards
  • 8.12. Project Plan Deviations
• 9. Project Rules and Regulations
  • 9.1. Project Registration
  • 9.2. Project Monitoring and Credit Issuance
  • 9.3. Project Renewal
  • 9.4. Project Termination
  • 9.5. Project On Hold
  • 9.6. Non-Compliant Projects
  • 9.7. Previous Rejection by other Registries
  • 9.8. Personal / Commercially Sensitive Information
  • 9.9. Managing Property Under Restrictive Permanence Covenants Obligation
• 10. GHG Removal and Emission Reduction Requirements
  • 10.1. Adherence to GHG Accounting Principles
  • 10.2. Additionality
  • 10.3. Leakage
  • 10.4. Permanence
  • 10.5. Buffer Pools
  • 10.6. Permanence Reversal Buffers
  • 10.7. Avoiding Double Counting
• 11. Monitoring Requirements
  • 11.1. Monitor Requirements
  • 11.2. Payment for Monitoring
  • 11.3. Monitoring Procedure
  • 11.4. Monitor Procedure Deviations
  • 11.5. Monitoring Acceptance
  • 11.6. Monitoring Schedule
  • 11.7. Monitoring Oversight
• 12. Verification Requirements
  • 12.1. Verifier Requirements
  • 12.2. Payment for Verification
  • 12.3. Evidence Gathering
  • 12.4. Verification Report
  • 12.5. Verification Acceptance
  • 12.6. Verification Schedule
  • 12.7. Unscheduled Verification
  • 12.8. Verification Oversight
• 13. Purchasing, Selling, and Retiring Credits
  • 13.1. Wallet Address Creation
  • 13.2. Retiring Credits
  • 13.3. Tradability
  • 13.4. Selling Credits
  • 13.5. Fee Structure
• 14. Complaints and Appeals
  • 14.1. Complaints Procedure
  • 14.2. Appeals Procedure
• 15. Linkages to other Registry Systems
• 16. References

Note	A PDF version of this document is available here

Disclaimer

This document has been prepared for informational and procedural purposes only. Its contents are not intended to constitute legal advice. Regen Network Development, PBC (RND) maintains the right to amend or depart from any procedure or practice referred to in this guideline as deemed necessary.

1. Introduction

Every day, business is done while neglecting our most important partners: farmers, land stewards, and the Earth. The result are destructive global consequences like climate change, desertification, biodiversity loss and resource depletion that affect nearly every aspect of human life. The United Nations FAO estimates 33% of the Earth’s soils are already degraded and over 90% could become degraded by 2050^[1].

The price tag to 'fix' these problems is estimated to be in the trillions, paralyzing global efforts to quickly address climate change. There may be nothing of more critical importance today than the regeneration of the world’s ecosystems.

Land Stewards, the stewards of our global landscapes, offer one of the most powerful pathways for reversing climate change and unlocking a massive untapped market in the world: the services and products generated by Earth’s ecosystems. Regen Registry, coupled with Regen Ledger, an ecological blockchain-based ledger, creates a new platform for Land Stewards to monetize their ecological data while receiving rewards for regenerative practices. By improving the understanding of the state of our land, oceans, and watersheds and enabling rewards for verified positive changes, Regen Network catalyzes the regeneration of our ecosystems.

Regen Network Development, PBC was launched in Q2, 2018 and is headquartered in Great Barrington, Massachusetts. The mainnet blockchain of Regen Ledger was launched in April 2021.

2. Overview

The Regen Registry Program Guide details the general requirements and specifications for the quantification, monitoring, reporting and verification (MRV), project registration, and issuance of credits on Regen Registry. The common characteristic of all Regen Registry credits is that they are all nature-based solutions, and each can provide one or more ecosystem services, including GHG emissions reductions and removals, biodiversity/habitat protection, improvement in water quality, and more^[2].

The Program Guide establishes the requirements for the use of Regen Registry, including the development and use of credit classes and methodologies, the project registration process, project eligibility, and the issuance of tradable environmental assets to projects. This guide is intended to be used by Credit Designers, Methodology Developers, Credit Class Admins, Registry Agents, Project Proponents, Buyers, Monitors, Verifiers, and all other stakeholders.

Regen Registry aims to maximize flexibility and usability for Project Proponents while maintaining the environmental integrity and scientific rigor necessary to ensure that projects developed against its credit classes and methodologies are of the highest quality.

Project Proponents and other interested stakeholders should refer to the Regen Registry Handbook for the latest version of the Program Guide, Credit Classes, Approved Methodologies, document templates, and other guidance.

3. Definitions

Aggregate Project	A project in which multiple independently managed projects at different sites or locations within the same geographic region are registered together as a single project to strategically reduce the amount of data required for monitoring, reporting, and verification.
Approved Methodology	A methodology (or set of methodologies) that has been approved for use within Regen Registry, or more specifically, within a Regen Registry approved Credit Class..
Baseline Scenario	The hypothetical situation that represents the state or condition of an ecological system (like a habitat, species population, or ecosystem function) that would be expected in the absence of a proposed Project Activity. The Baseline scenario serves as a reference point against which outcomes resulting from the Project Activity can be measured to determine the net impact or benefit of those efforts. A baseline can be static, dynamic, project specific, or based on performance standard (or a combination of those)[3].
Buffer Pool	A tool to mitigate credit class or project-specific risk factors associated with unintentional or intentional reversal events, or overestimation of credits issued. Buffer pools hold credits that cannot be sold to buyers, and reserve credits for potential cancellation from the Registry System to maintain accurate credit accounting.
Buyer	An individual or organization that is purchasing credits from the registry.
Cancelation	The permanent removal of an ecological credit from circulation in the Regen Registry System for purposes other than retirement. Reasons for cancellation could include reversals, non-compliance with Regen Registry or Credit Class standards, or migrating credits to a different registry system.
Credit	A digital asset, representing a quantifiable unit of measurement either tied to ecological or social benefit resulting from the implementation of a Project Activity, or tied to the successful implementation of a Project Activity rather than an explicitly measured benefit. Credits within the Registry System are tracked on Regen Ledger, and can exist in a Tradable, Retired, or Canceled state. Credits on the Regen Registry can also sometimes be referred to as tokens.
Credit Class	A standard or protocol[4] which details the procedures for project registration and credit issuance for a specific set of Project Activities which provide ecological and social benefits. Such benefits could include GHG removal, emission reduction, environmental stewardship, and enhanced ecosystem function. Credit Classes define the structure, procedures, and prerequisites for registering projects and issuing credits. Typically, a Credit Class will establish one or more Approved Methodologies used to measure the impact of Project Activities. It also lays down the programmatic rules and stipulations for project registration and credit issuance, such as project eligibility criteria, Buffer Pool management and Verification requirements.. In certain instances, the process for measuring, reporting, and verifying ecological and social benefits might be directly integrated into a Credit class, rather than being outlined in a separate methodology. Within the Regen Registry, each Credit Class operates as an independent standard or crediting program. This means that every Credit Class can possess its unique governance and issuance structure, buffer pool requirements, project registration prerequisites, and distinct group of project actors, all of which operate autonomously from other Regen Registry Credit Classes. Credit Classes on Regen Registry also have a specific set of features provided by Regen Ledger (the Registry System used by Regen Registry). These include: A governance body known as the Credit Class Admin A set of on-chain anchored metadata defining the rules and regulations for this Credit Class, as well as a list of Approved Methodologies which may be used by projects registered in this Credit Class One or more on-chain Registry Agents who manage project registration and credit issuance
Credit Class Admin	An individual, organization, or group of individuals/organizations (private or public) that manages the rules and conditions necessary to issue credits under a Credit Class. The Credit Class Admin is responsible for maintaining the credit class protocol, list of approved methodologies, and subsequent documentation in accordance with the Regen Registry Program Guide. Additionally, the Credit Class Admin maintains the list of approved Registry Agents, maintains on-chain metadata for the Credit Class, and (if applicable) manages Buffer Pool Accounts for the Credit Class. To the extent that active management of the above allows, Credit Class Admins are responsible for ensuring integrity of all ecological claims accounted for in the Credit Class. Credit Class Admins have sole control over the above on-chain components of a Credit Class, and can also transfer Credit Class Admin privileges to a new address at their own discretion. Credit Classes may be delisted from Regen Registry if a Credit Class Admin falls out of compliance with the Regen Registry Program Guide.
Credit Designer	An individual or organization that develops a new Credit Class or updates an existing one.
Crediting Period	The finite length of time for which a Project Plan is valid, and during which a project can generate credits.
Credit Vintage	The Credit Vintage refers to the year in which ecological credits were issued. Credit Vintages can generally refer to the year in which GHG emission reductions/removals or other ecological and social benefits occurred, however, the exact time frame might span multiple years for longer Reporting Periods.
Issuance	Issuance is the act of recording and assigning initial ownership of quantified ecological outcomes and carbon offsets in the form of a digital asset, known as credits, on the Regen Registry System, a public blockchain for recording all data, information, and transaction history related to carbon credits and other environmentally-related assets.
Land Steward	The individual or organization that is implementing a Project Activity. This can be a farmer, rancher, conservationist, forester, fisherman, etc.
Land Owner	The individual or organization that holds title to the land where the project is occurring.
Methodology	A specific set of scientifically based criteria and procedures which outline the process for monitoring, reporting, verification of ecological and social benefits and practices for a defined Project Activity or set of Project Activities. This can include setting project boundaries, determining the Baseline Scenario, quantifying net GHG emission reductions or removals, measuring improvements in ecosystem function, and specifying monitoring procedures.
Methodology Developer	An individual or organization that develops a new Methodology or updates an existing one.
Monitor	An individual or organization that is contracted to measure the benefits / indicators defined in a given Credit Class based on the stipulations in the Approved Methodology.
Monitoring	The ongoing, systematic process of collecting and analyzing data to track the ecological and social benefits provided by a Project Activity, following the guidelines of an Approved Methodology.
Permanence Reversal Buffer	A dedicated Buffer Pool account that allocates a percentage of credits from each issuance in order to mitigate permanence related reversal risk, i.e. GHG removal reversal that has occurred over the permanence period of the project.
Project Activity	The specific land management practice or conservation activity employed by a project to support ecological or social benefits.
Project Area	The geographic area in which Project Activities are implemented.
Project Boundary	The geography within which the direct and indirect environmental, economic, and social impacts of the project are accounted for. This includes the Project Area as well as areas that may be indirectly affected, including potential offsite changes in GHG emissions or other ecological impacts attributable to the project’s implementation.
Project Developer	The individual or organization responsible for the detailed management of the project. The project developer, who can be the land steward or a third party, handles detailed planning, design, construction and implementation of the project.
Project Plan	The document used to apply for Project Registration under a given Credit Class. The Project Plan describes the Project Activity or Activities, demonstrates project eligibility requirements, establishes project boundaries, specifies project stakeholders, justifies application of the Credit Class and Methodology, and more.
Project Proponent	The individual or organization that advocates for a project, identifies its requirements, and drives its initiation. The Project Proponent serves as the main point of contact with the Registry Agent throughout the course of the project and is responsible for initiating project registration, submission of all materials required by the Credit Class, Methodology, and Program Guide, and coordinating project actors. The Project Proponent must ensure correctness and compliance of all submitted documentation with the standards outlined in the Credit Class, Methodology, and Regen Registry Program Guide prior to to ensure credit quality. The Project Proponent receives the credits upon issuance and is responsible for coordinating sale and distribution between project actors.
Project Start Date	The date on which the project commences and begins generating and accounting for GHG emission reduction or removals or other ecological and social benefits. The Project Start Date may be before or after the project registration date as stipulated in the Credit Class. The Project Start Date marks the beginning of the Crediting Period.
Regen Registry	A comprehensive program, platform, and process designed to establish community standards and legal frameworks for quantifying, monitoring, and trading ecological credits and managing other types of ecological claims. Regen Registry offers processes and tools for setting standards for Methodology and Credit Class development and approval, establishing and upholding frameworks for decision-making processes and appeals, and overseeing the use of the Regen Registry System by stakeholders using Credit Classes registered under the Regen Registry. Central to its operation is the active engagement of the community. Designed with modularity in mind, the Regen Registry promotes shared decision-making among stakeholders. These stakeholders have the ability to propose and vote on pivotal decisions, form committees to supervise specific facets of the registry process, and collaboratively address disputes or challenges. As of Q3 2023, the stewardship of the Regen Registry is undertaken by RND PBC.
Registry Agent	The individual or organization appointed by the Credit Class Admin that operates the Registry System to register projects and/or issue credits under a given Credit Class. The Registry Agent is responsible for maintaining accurate accounting and ensuring compliance of registered projects, issued credits, and other ecosystem service claims as set forth in the Regen Registry Program Guide, Credit Class, Approved Methodology, and Project Plan. The Registry Agent is also responsible for ensuring updates made to the Registry Program, Credit Class, Approved Methodology and Project Plan are, if applicable, applied to existing projects in a way that is transparent and fair. Selection of the Registry Agent is a crucial part of establishing checks-and-balances for credit issuance. As such, acceptance of Credit Classes to be registered under Regen Registry is contingent upon having a Registry Agent that has been approved or appointed by RND PBC as the stewards of Regen Registry.
Registry System	The technical infrastructure responsible for tracking information and claims related to ecological state. This system encompasses specific business logic, computer code, and programs that facilitate certain functions associated with the Regen Registry. While the Regen Registry sets the standards and frameworks, the Registry System provides the technical means to implement these functions. Built atop Regen Ledger, the Registry System’s capabilities include, but are not limited to, registering projects, monitoring the issuance, ownership, transfer, and retirement (or cancellation) of ecological credits, anchoring and signing data, and transparently tracking decision-making practices. Regen Ledger serves as the foundational blockchain layer upon which the Registry System operates to ensure transparency, security, and decentralization verification of all transactions and activities. The Regen Ledger is open-source and is publicly accessible.
Reporting Period	A period of time following the methodology guidelines in which Monitoring and Verification activities are completed.
Retirement	The permanent removal of an ecological credit from circulation in the Registry System after it has been claimed.
Reversal	A situation where project outcomes, such as carbon removals, improvements in biodiversity, or successful implementation of a practice are unexpectedly reversed. Reversal events can happen due to a variety of reasons, including natural disasters, changes in land use, poor project management, or failure to comply with project protocols.
Site	The location where a project implements the Project Activity or Activities. A project area does not need to be continuous and can have multiple sites.
Validation	The systematic, independent third-party assessment of a project prior to registration to determine whether a project conforms to the rules and requirements outlined in the Regen Registry Program Guide, Credit Class, and Approved Methodology, and evaluates the reasonableness of assumptions, limitations, and methods that support claims about the future outcome of Project Activities.
Verification	The systematic, independent, and documented assessment by a qualified and impartial third party of the Monitor’s assertions for a specific Reporting Period.
Verifier	An individual or organization that is contracted to execute the verification requirements stipulated in a given Credit Class.

4. Acronyms

GHG	Greenhouse Gases
IPCC	Intergovernmental Panel on Climate Change (IPCC) is an intergovernmental body of the United Nations that is dedicated to providing the world with objective, scientific information relevant to understanding the scientific basis of the risk of human-induced climate change.
AFOLU	Agriculture, Forestry and Other Land Use; a category of carbon credit projects that are related to agriculture, forestry, and other land uses (e.g. conservation).
RND PBC	Regen Network Development, Public Benefit Corporation , the entity developing and operating the Regen Registry.
SDG	the United Nations' Sustainable Development Goals.
GIS	Geographic information system is a conceptualized framework that provides the ability to capture and analyze spatial and geographic data.

5. Basics

5.1. Regen Registry Description

Regen Registry is a comprehensive tool, platform and process designed to establish community standards and frameworks for quantifying, monitoring, and trading ecological credits and managing other types of ecological claims. Central to its operation is the active engagement of the community.

Regen Registry offers processes and tools for setting standards for methodology and credit class development and approval, establishing and upholding frameworks for decision-making processes and appeals, and overseeing the use of the Regen Registry System by stakeholders using Credit Classes registered under the Regen Registry Program.

Designed with modularity in mind, the Regen Registry promotes shared decision-making among stakeholders. These stakeholders have the ability to propose and vote on pivotal decisions, form committees to supervise specific facets of the registry process, and collaboratively address disputes or challenges. At present, the stewardship of the Regen Registry is undertaken by RND PBC.

1. Registry System - technical infrastructure responsible for tracking information and claims related to ecological state. This system encompasses specific business logic, computer code, and programs that facilitate certain functions associated with the Regen Registry. While the Regen Registry sets the standards and frameworks, the Registry System provides the technical means to implement these functions. Built atop the Regen Ledger, the Registry System’s capabilities include, but are not limited to, registering projects, monitoring the issuance, ownership, transfer, and retirement (or cancellation) of ecological credits, anchoring and signing data, and transparently tracking decision-making practices.

2. Marketing Platform - showcases the unique story of each project, highlighting the land stewards, the impact on the land and environment; provides Buyers and policy makers with impact analytics on a portfolio (regional, national, and global) of key ecological indicators.

5.2. Regen Registry Objectives

Regen Registry’s objectives are to:

• Encourage nature-based solutions. For example, solutions based on regenerative agriculture, conservation, and best management practices, as a strategy to mitigate (by removing/reducing GHG emissions) and/or adapt to climate change.

• Provide guidance for, and promote scientifically rigorous methodologies and credit classes to foster high quality ecological assets.

• Create an open-source infrastructure that allows cost-effective and rigorous MRV implementation, issues and tracks credits while avoiding double counting, and provides payments, billing, and marketing functionality.

• Support best practices in project-level GHG accounting and ecosystem services.

• Commercialize innovative types of credits bundled with valuable co-benefits and ecosystem services.

• Provide an environment to develop new types of ecological assets that will inform voluntary and regulated markets.

• Incorporate cutting-edge technologies, such as IoT sensors, satellite remote sensing, and digital signatures in the use of project monitoring and verification.

• Enhance public confidence in market-based action for GHG removal and ecosystems' regeneration.

• Support interoperability between climate markets emerging from the UNFCCC’s Paris Agreement and global NDC commitments.

5.3. Scope

5.3.1. Geography

1. Regen Registry accepts projects from locations worldwide, provided they conform to an approved Credit Class and Methodology.

5.3.2. Project Activities

Regen Registry was developed to be a catalyst for ecosystem regeneration around the globe using blockchain, decentralized finance, and other Web 3.0 tools. To accomplish this, we are developing innovative ways to financially support people working to improve and maintain ecosystem health through the use of nature-based solutions (NbS). We follow a definition of NbS that is similar to the International Union for Conservation of Nature (IUCN) definition but we replace "sustainably" with “regeneratively” to define NbS as:

“actions to protect, [regeneratively] manage and restore natural or modified ecosystems that address societal challenges effectively and adaptively, simultaneously providing human well-being and biodiversity benefits”.

This definition includes, but is not limited to, projects reducing negative direct impacts that humans have on ecosystem function, improving climate adaptation, and reducing global warming. Examples of projects that we support will be reflected in our growing list of methodologies and projects.

1. Regen Registry accepts any projects using nature-based solutions as defined above.

5.3.3. Data Submission and Record Keeping

1. Regen Registry provides a Registry System which can be used to track information and claims made on ecological state, which may comprise of specific business logic, computer code and programs that execute some of the functions of the Regen Registry. The Regen Registry’s Registry System is built on Regen Ledger, and supports (but not limited to) registering projects, tracking the issuance, ownership, transfer, and retirement (or Cancelation) of ecological credits, data anchoring and signing, and transparent tracking decision making practices.

5.4. Guiding Principles

5.4.1. Accuracy

The Project Proponent shall reduce, as far as is practical, uncertainties related to the quantification of GHG removals and/or any other applicable ecological indicator, such as species habitat, tree coverage, etc.

Methodologies submitted for Regen Registry approval shall include methods for estimating the uncertainty for each indicator.

The use of models, such as biogeochemical models, must include an estimate of structural uncertainty related to the inadequacy of the model, model bias, and model discrepancy. Monitors shall quantify these using the best available science, Monte Carlo analyses, uncertainty estimates from peer reviewed literature, and/or consulting model experts who have either developed or worked directly with the model in an academic setting.

5.4.2. Comparability

Methodologies approved on Regen Registry shall rely on comparable peer-reviewed studies as best as possible.

5.4.3. Transparency

Regen Registry is built to provide stakeholders, including Project Proponents, Buyers, scientists, and market experts, with a high level of transparency. We achieve this by:

• Credit Classes and Methodologies are publicly available and receive public comment. We also encourage engaging a broad set of subject matter experts during the design process.

• All pertinent project data is publicly available, including the Project Plan, monitoring reports, credit issuance certification, and verification reports.

• Regen Ledger will provide an immutable record and digital audit trail of monitoring and verification outcomes, and credit issuance and sales.

See also the GHG Accounting and Policies section.

5.4.4. Collaboration

Regen Registry believes deeply in collaboration. We are convening a broad set of independent parties to participate in:

Methodology development and Credit Class design - scientists, economists and subject matter experts are invited to create new, cutting-edge ecological assets, to provide feedback, and to govern the library of methodologies and credit classes.

Monitoring and verification - remote sensing companies, experts, IoT providers, surveying tools, etc. are invited to provide their monitoring services to streamline the costs of MRV while maintaining scientific rigor.

Regen Registry System and Regen Ledger development - software developers who are eager to mitigate climate change are welcome to contribute to these open source projects.

5.4.5. Practicality

Regen Registry aims to balance the time and cost required by Project Proponents to collect data for monitoring, verification and reporting and the need for assurances from credit Buyers. To that end, Regen Registry encourages an adaptive approach to methodology development that will provide different levels of assurances to cater to different needs of credit Buyers.

5.4.6. Security

RND will conduct security audits of major releases of its software, including Regen Ledger and Registry System, to ensure the data integrity and fidelity of credit ownership and the underlying MRV data.

5.4.7. Open Source and Open Data

Following the collaboration principle above, RND is a strong proponent of open-source software and open data. We firmly believe that in order to achieve the best results, provide transparency, ensure fair governance, and invite collaboration from multiple stakeholders, we need to develop open source software and share our research data openly. Our software code repositories are available on GitHub^[5].

5.4.8. User-Centric Design

Relative to their potential, Agriculture, Forestry and Other Land Use (AFOLU) carbon credits have seen limited adoption in regulatory and voluntary markets. Historically, the supply of these credits has been limited because credit design has not incorporated enough feedback from land stewards, resulting in credit requirements that were complicated, expensive and/or time consuming. Regen Registry follows a user centric design of credit classes and methodologies with input not only from buyers but also land stewards and project developers.

6. Governance

Regen Registry is built on the principles of openness, collaboration, accountability, user centric design, transparency, responsiveness, and participation. This is applied to Credit Class administration and Methodology design, provision of monitoring and verification services, integration with other registries, and with 3rd-party service providers.

Credits issued under Regen Registry rely on a software implementation that includes two layers:

1. Regen Marketplace - a centralized software layer that provides user interfaces for managing accounts, project pages, buy/sell functionality, administrative functions; and

2. Regen Registry System - a decentralized software layer that is used to issue, transfer, and retire credits and tracks all pertinent monitoring, reporting and verification (MRV) information as immutable records.

Regen Registry is operated by Regen Network Development, PBC (RND), a private for-profit company. Regen Ledger is a public decentralized ledger that is not owned by a single entity (including RND) and is a Digital Commons^[6] that is operated by a network of independent stakeholders called Validators that are incentivized to maintain the integrity of the underlying ecological data and credits tracked on the ledger. Regen Network believes this is the best way to maintain long term data integrity, auditability, transparency, and viability, and enables a just allocation of resources and sustained regeneration of ecological ecosystems (see blog post^[7] for more details).

Regen Registry is committed to fully complying with all relevant U.S. Commodity Futures Trading Commission (CFTC) and the U.S. Securities and Exchange Commission (SEC) standards and other applicable regulations.

In the event that RND dissolves, the Regen Registry’s contractual agreements bind both Registry Agents and Project Proponents and buyers to uphold any outstanding contractual commitments.

7. Credit Classes and Methodologies

Regen Registry aims to democratize and invigorate the design of ecological credits. To that end we are separating out the typical set of definitions that are part and parcel of most registry standards and allow Credit and Methodology Designers to modify and upgrade these as needed and appropriate. These include:

• Credit definition

• Project eligibility requirements

• GHG accounting related requirements including permanence, leakage and additionality.

• Verification requirements

• Reporting and compliance requirements

The Regen Registry Program Guide and the Credit Class templates provide the guidelines for creating new credits, thus enabling innovation while maintaining a high standard of rigor.

While a subset of Credit Classes might be developed by RND, the intention is to build a vibrant community of Credit Designers that will take the lead going forward.

Regen Registry aims to steward a broad set of Credit Classes that cover different ecosystems, geographical regions and localities, and are tailored for different stakeholders (e.g. smallholder farmers, corporate farms, indigenous communities, conservation organizations, etc).

One of our key assumptions is that creating a one-size-fits-all solution is suboptimal and does not tap into collective potential. Ecological systems are inherently complex. Regenerative farming, grazing ,and conservation are complex, nuanced, and locale specific. Similarly, the needs and risk profile of credit buyers vary substantially depending on the size of the company, its sector, climate goals, etc. As such, we believe a successful solution needs to leverage commonalities and best practices, while simultaneously allowing for flexibility in design.

7.1. New Credit Classes and Methodologies

1. All new Credit Classes and Methodologies must go through an Expert Peer Review and Public Comment process The requirements for Expert Peer Review and Public Comment are outlined in the Regen Registry Handbook.

2. Regen Registry may grandfather in new Methodologies or Credit Classes into the Regen Registry Methodology Library from another Registry if the applicant submitting the Methodology or Credit Class can demonstrate the Methodology has gone through a process of similar merit to the one above.

3. Regen Registry must document the entire Credit Class or Methodology process for Expert Peer Review or Public Comment including submitted versions, responses of reviewers, comments and responses of the Methodology or Credit Designer, and corresponding changes made to each version Credit Class or Methodology at each stage.

   While successful completion of Expert Peer Review and Public Comment (or sufficient alternative) is a necessary prerequisite for approval of a Credit Class or Methodology for use under Regen Registry, such completion does not guarantee approval, as approval may also be contingent upon other factors to ensure credit quality. Other criteria, such as the appointment of adequately qualified organizations as the Credit Class Admin and Registry Agent, and ensuring the proposed Credit Class upholds the standards of integrity, also influence the final decision.

7.2. Modifications to an Approved Credit Class or Methodology

7.2.1. Proposed Modifications to Approved Credit Classes and Methodologies

1. Credit Class Admins may propose modifications to an existing approved Credit Class or Methodology where they maintain the guidelines stipulated in the Regen Registry Program Guide. Credit Class and/or Methodology modifications may be submitted for review to Regen Registry.

2. Regen Registry, currently managed by RND, will review the extent of the modification and determine what steps in the approval process outlined in Section 5.1 are required to approve modifications.

3. If changes to Credit Class or Methodology are approved by the Regen Registry, Credit Class Admins are required to indicate the changes made to the Credit Class or Methodology and release the updated document as an updated version.

4. Upon releasing an updated version of a Credit Class or Methodology, Credit Class Admins are compelled to specify whether the updated version necessitates enforcement/updates for pre-existing projects registered under the same Credit Class. If such enforcement is required, Admins must supply a comprehensive justification detailing the reasons behind the implementation of these changes.

7.2.2. Credit Class and Methodology Update Requirements for Existing Projects

1. If a new version of a Credit Class or Methodology is released, the Registry Agent must inform the Project Proponent of any updates made to the Credit Class or Methodology and indicate if changes are to be made to the project.

2. Project Proponents are required to implement changes to the best of their ability.

3. If a Project Proponent is unable to implement changes for an updated version of a Credit Class or Methodology, they must submit an application for variance to the Credit Class Admin to remain under a previous Credit Class or Methodology version. Applications for variance must state why the Project Proponent is unable to implement the new changes under the new version of the Credit Class. Such applications must be approved by the Credit Class Admin. Projects with approved applications for variance shall be denoted as issued under the previous version of the Credit Class.

7.3. Governance of Adding and Removing Credit Classes and Methodologies to the Regen Registry

Regen Registry, currently managed by RND, will govern the process of adding new Credit Classes and Methodologies per the above process. In the future our aim is to move towards an independent, decentralized governance of these Credit Classes and Methodologies by a broad set of stakeholders, including subject matter experts, land stewards, project developers, monitors, and verifiers.

If a Credit Class Admin manages a Credit Class or Methodology in a way that deviates from the rules as stipulated in the Regen Registry Program Guide, Regen Registry may revoke its approval of said Credit Class or Methodology, removing it from Regen Registry. For avoidance of doubt, the Credit Class or Methodology would still exist as a managed on-chain credit class on Regen Network, but would no longer be recognized under the Regen Registry Program.

7.4. Access and Use of Credit Classes and Methodologies

1. All Methodologies and Credit Classes registered under the Regen Registry must be either open source or open access, as designated by the original Methodology Developer or Credit Designer.

   • Open Source Methodologies/Credit Classes are ones where the methodology and all subsequent software, tools, and modules, are publicly available and freely available for use, modification, and distribution.

   • Open Access Methodologies/Credit Classes are those where the Methodology/Credit Class is publicly accessible and free for use, but may not come with subsequent software, tools, and modules, and may not be available for modification without the approval of the Methodology or Credit Designer.

2. For every new Methodology or Credit Class submitted to Regen Registry, the submitting party must explicitly declare whether their Methodology or Credit Class is open source or open access at the time of registration. This declaration forms part of the official registration documentation and cannot be changed retroactively.

3. While all Methodologies or Credit Classes registered with the Regen Registry must be open source or open access, implementations of the Methodology or Credit Class by Monitors can be closed source. This means that Monitors may use proprietary tools or modules to implement the Methodology or Credit Class, as long as they can demonstrate that their implementation accurately follows the Methodology or Credit Class and meets all other requirements of the Regen Registry Program.

4. Modifications to the Methodology and Credit Class submitted to the Regen Registry must comply with the open source or open access declaration made by the original Methodology or Credit Class Designer.

8. Project Requirements

8.1. General Requirements

1. Projects shall meet all applicable rules and requirements outlined in the Regen Registry Program Guide.

2. Projects shall only apply Credit Classes and Methodologies approved by into the Regen Registry. Credit Classes and Methodologies shall be applied in full and adhere to any applicable rules and requirements. The full list of approved Credit Classes and Methodologies can be found in the Regen Registry Handbook.

3. Projects shall apply the latest version of the applicable Credit Class and Methodology.

8.2. Land Tenure

1. Land tenure is a legal term representing rights and interests in project lands.

2. The Project Proponent shall own, have control over, or document effective control over the GHG sources/sinks from which the removals originate.

3. The Project Proponent shall provide documentation and/or attestation of land tenure.

4. In the case of leased land, the landowner shall agree to all contractual obligations taken by the Project Proponent, and the Project Proponent shall provide documentation and/or attestation of title agreement to credits.

5. The Registry Agent may require a legal review by an expert in local law.

8.3. Project Area

1. The Project Area may only include land meeting the following requirements:

   • The land was not converted from forest land, wetlands or any other natural ecosystem in the ten-year period prior to the Project’s Start Date.

2. The Project Area may include portions of land which are not eligible land, only if they are excluded from any GHG or co-benefit estimation. Those areas will be clearly demarcated in the Project Plan.

8.4. Project Boundary

1. The Project Boundary shall be described in the Project Plan, including any GHG sinks, sources, and reservoirs, or other ecological indicators.

8.5. Project Ownership

1. The Project Proponent shall stipulate the ownership of credits issued to the project in the Project Plan. Regen Registry supports fractional ownership of the credits allocated to a project in a given issuance event, therefore credits can be split between Land Stewards, Land Owners, Project Developers, and Buyers.

8.6. Project Start Date

1. Each Credit Class must specify the Project Start Date requirements.

2. The Project Proponent shall stipulate the Project Start Date and justify how it meets the eligibility requirements outlined in the Credit Class.

3. If a Project Start Date precedes project registration, the Project Proponent must justify how the project has met the eligibility and data requirements outlined in the Credit Class and Approved Methodology prior to project registration

8.7. Project Crediting Period

1. Each Credit Class must specify the Crediting Period projects in that Credit Class are eligible to receive Credits.

2. Project Proponents shall stipulate the Crediting Period in the Project Plan.

8.8. Regulatory Compliance

1. Projects must maintain material regulatory compliance, that is, adherent to all laws, regulations, and other legally binding mandates directly related to Project Activities.

2. Project Proponent is required to provide a regulatory compliance attestation for the project(s) in the Project Plan. This attestation must disclose all relevant laws, regulations, or other legally binding mandates directly related to Project Activities and indicate (if applicable) where Project Activities violate compliance.

3. Project Proponents are required to disclose on an ongoing basis any potential or imminent or actual violations of laws, regulations, or other legally binding mandates related to Project Activities.

4. The Registry Agent retains discretion to decide on a case-by-case basis whether a violation requires canceling the project or putting it on hold until the issue is addressed.

8.9. Registration on other Registries

1. Project Proponents are required to state if they plan to apply in the future, or have applied for and been listed, registered, and/or been issued GHG emission reduction or removal credits, biodiversity credits or any other ecological credit through any other GHG emissions program, biodiversity program or any other certification program.

2. Project Proponent will include detailed information on any credit issuance (volume, vintage, status), and information on any rejections of the project application on other registries.

3. Regen Registry will review the information provided by Project Proponent and approve or reject concurrent registration with another registry(s). Regen Registry will permit concurrent project registration only if the following conditions are met:

   • No double issuance - credits issued for the same unique emissions reductions (project boundary and vintage) do not reside concurrently on more than one registry.

   • No double sale - once any credits have been sold on another registry, the Project Proponent will be required to cancel that project in order to register on the Regen Registry.

8.10. Aggregate Projects

1. Project Proponents may be able to create efficiencies around reporting and verification by strategically combining a group of project areas participating in an Aggregate Project. To that end, project areas should be grouped so their defining characteristics are as homogeneous as possible. Verifiers may select randomly which project areas will receive on-site visits, or apply a risk analysis to identify project areas with the strongest influence over an Aggregate Project’s outcomes. Verifiers can use their own discretion to determine the data sampling approach, yet all sites require at least a desk-based review.

2. Sites must be located in the same pre-defined climatic or geographic region and share similar soil, phytophysiognomy, and other ecological characteristics, and share the same land-management practice. Project Proponents must justify registration of aggregated projects in the Project Plan.

8.11. Safeguards

1. Project Activities must not negatively affect the environment or local communities. The Project Proponent must identify and address any negative environmental and socio-economic impacts of Project Activities and engage with local stakeholders to mitigate them.

2. Safeguard conditions hold, not only during project registration but throughout the lifetime of the project. That is, Project Proponents with an existing project on Regen Registry shall follow the same procedure above if planning to register on another registry concurrently.

8.11.1. No Net Harm

1. The Project Proponent shall detail any potential negative socio-economic and environmental impacts of the project and the steps taken to mitigate them. This includes risks of project implementation to local stakeholders, how risks are mitigated and plans to protect local stakeholder property rights. This also includes detailing the process for conflict resolution between Project Proponent and local stakeholders, such as grievance redress.

8.11.2. Local Stakeholder Consultation

1. The Project Proponent shall indicate how local stakeholders were identified and consulted prior to the project implementation.

8.11.3. Environmental Impact

1. The Project Proponent must indicate if environmental impact assessments were undertaken and describe the process and findings.

8.11.4. Public Comment

1. The Project Proponent shall specify if a community public consultation was undertaken prior to the project implementation and detail how comments were addressed, either in updates to the project or justified as irrelevant.

8.12. Project Plan Deviations

1. Deviations from the Credit Class or Approved Methodology are permitted where they do not negatively affect the conservativeness of the Credit Class or Approved Methodology’s approach to the quantification of GHG emissions reductions and removal enhancements, or other ecological benefits, and do not affect the Safeguards specified in Section 6.10.

2. Project Proponents submitting Project Plan deviations must provide evidence that the proposed deviation meets the conservativeness standards of the Credit Class and Approved Methodology.

3. The Registry Agent will permit project-specific deviations from the Approved Methodology where they do not negatively affect the conservativeness of an Approved Methodology’s approach to the quantification of GHG emissions reductions and removal enhancements.

4. The Registry Agent will review deviation requests, and if approved, deviations can be applied to a specific project, but are not published as modifications to the Credit Class or Approved Methodology. Any approved deviations must be communicated to the Credit Class Admin, and may be overridden by the Credit Class Admin.

9. Project Rules and Regulations

9.1. Project Registration

1. Project Proponents must submit a Project Plan and subsequent documentation to the Registry Agent to apply for Project Registration under a given Credit Class.

2. The Registry Agent shall conduct an exhaustive review of the Project Plan and subsequent documentation to ensure the Project Proponent has met all the requirements outlined in the Credit Class, Methodology, and Regen Registry Program Guide and register the project upon satisfactory confirmation that all documentation is complete.

9.2. Project Monitoring and Credit Issuance

1. Monitoring and Verification reports shall be created for each Reporting Period. Monitors and Verifiers shall submit reports to the Registry Agent, including any corrections/revisions identified by the verifier (if applicable).

2. The Monitoring and Verification Reports shall describe the current status of project operation, and include the data monitored, the monitoring plan, the calculated emission reductions and ecological indicators for the Reporting Period stated in the Credit Class and following the guidelines in the Approved Methodology.

3. The Registry Agent shall conduct an exhaustive review of all submitted information to ensure that Monitors and Verifiers have met the requirements stipulated in the Credit Class and Approved Methodology and issue credits upon satisfactory confirmation that all documentation is complete.

9.3. Project Renewal

1. At the end of the project, the Project Proponent can elect to renew the project. The Project Proponent may do so by:

   1. Choosing from a renewal period as stipulated in the Credit Class.

   2. Submitting an updated Project Plan in compliance with up-to-date Credit Class and Approved Methodology.

2. The final project monitoring and verification round of carbon stock and/or other ecological indicator estimates will be automatically used as the renewal up-to-date baseline.

3. Project Proponents may renew a project multiple times. Regen Registry does not limit the number of periods of renewal that are allowed for a given project.

9.4. Project Termination

9.4.1. End of Crediting Term

1. At the end of the Crediting Period, the Project Proponent will engage in a final project verification. The report will be made public.

2. The Project Proponent has the choice to renew the project (renewal duration stipulated in Credit Class).

3. In the case of a GHG removal credit, based on the end of project carbon stock estimation, the Credit Class Admin will retire or issue credits from the Buffer Pool. See the Buffer Pool section for more details.

9.4.2. Premature Project Termination

1. Prior to credit sales transactions (i.e. sold, transferred, or retired), a Project Proponent can decide to end the project prematurely with no penalties.

2. Regen Registry, Credit Class Admin, and Registry Agent fees will still apply, along with any outstanding obligations between Project Proponent and 3rd parties, such as Verifiers and/or Monitors.

9.4.3. In the case of a GHG removal credit

1. Before credit sales transactions, project credits in the Project Proponent’s account will be canceled including the respective Buffer Pool and Permanence Reversal Buffer allocations.

2. After credit sales transactions, the Project Proponent:

   1. Shall engage with a final monitoring and verification round to calculate the carbon stock levels and determine Buffer Pool allocations and/or further compensation required. See the Buffer Pool section for more details. If the Project Proponent fails to engage with a final monitoring and verification round, the project will be deemed to be non-compliant.

   2. Comply with permanence requirements of the vintage that was sold.

9.5. Project On Hold

1. A project may be put on hold by the Registry Agent if:

   • Project Proponent fails to comply with the reporting requirements stated in Credit Class and the Approved Methodology.

   • A Verification Report is submitted with a Rejection rating.

   • In the case of a GHG removal credit, an intentional reversal of carbon stock is identified.

2. A project in on hold status will not be issued credits until the identified issues are resolved.

3. The Project Proponent will be allowed 60 days to remedy the fault found or the project will be deemed non-compliant. The Registry Agent may require an additional monitoring and verification round after the fault has been remedied.

9.6. Non-Compliant Projects

1. Projects that are non-compliant include the following cases:

   • In the event that a project was put on-hold and the Project Proponent did not comply with the satisfaction of the Registry Agent’s requests within 60 days.

   • The Project Proponent terminated the project prematurely and did not comply with final monitoring and verification round requirements.

2. These cases will be seen as a breach of contract, subject to dispute resolution as stipulated in the project registration agreement between the Project Proponent and Registry Agent. If the dispute is not resolved, the project will be terminated and all issued credits remaining in Project Proponent’s account along with the project credits allocated to Buffer Pool and Permanence Reversal Buffer (if applicable) will be canceled.

3. Non-compliant projects will be marked as non-compliant and, depending on the case, at the Registry Agent’s discretion, the Project Proponent might be restricted from listing any future projects on Regen Registry.

9.7. Previous Rejection by other Registries

1. Regen Registry may consider a project rejected by other registries, due to procedural or eligibility requirements, if the project complies with the Credit Class and Approved Methodology. The Project Proponent for such a project shall include a statement in the Project Plan that lists all other programs to which the Project Proponent has applied for registration and was rejected, the reason(s) for the rejection, and pertinent documentation.

9.8. Personal / Commercially Sensitive Information

1. Project Proponents may request to designate portions of the Project Plan or project documentation as Personal / Commercially Sensitive Information. This information must be available for review by the Registry Agent and the approved Verifier (with non-disclosure agreements, as necessary), but will not be posted publicly as part of the project documentation on Regen Registry. This information will be restricted to these Project Plan items:

   1. Entity name and contact information (for project actors other than the Project Proponent, Monitor, and Verifier)

   2. Underlying documents proving attestation of land tenure

   3. Underlying contractual agreements between project actors

2. To promote transparency, Regen Registry shall presume by default all project information to be available for public scrutiny, unless requested otherwise by the Project Proponent.

9.9. Managing Property Under Restrictive Permanence Covenants Obligation

1. Property placed under permanence obligations from a project registered with Regen Registry must maintain those obligations through the defined permanence period to ensure ongoing protection of Project Activities. A change in ownership of the land does not change these requirements, therefore a Project Proponent is required to burden the property with a restrictive covenant to ensure these permanence obligations remain in place in the event of all subsequent transfers of property rights to new owners that may occur prior to the end of the Permanence Period.

2. The Project Proponent shall attest to its intent to have the restrictive covenant run with the land at creation of the covenant through the the end of the defined Permanence Period

3. The covenant shall relate to the direct use or enjoyment of the land in order to protect the permanence obligations , for example, restrictions from deforestation in the event of a reforestation project

4. The Project Proponent shall inform the subsequent landowner of the restrictive covenant that runs with the land and take appropriate action to document this covenant in writing in the relevant jurisdiction, such as through the creation of a separate deed or placing notice on the register of title.

5. The Project Proponent shall ensure privity between covenantor and covenantees and other legal requirements necessary for the restrictive covenant to run with land per the jurisdiction in which the land is located

6. If the Project Proponent is not the land owner, it shall enter into an agreement with the land owner such that the land owner burdens her land with a restrictive covenant that shall run with the land and burden subsequent landowners and covenantees

7. The Project Proponent is required to submit documentation of the covenant to the Registry Agent.

8. Project Proponents must also inform prospective land buyers of any restrictive covenants that run with the land registered under projects with Regen Registry

10. GHG Removal and Emission Reduction Requirements

This section outlines the requirements to GHG removal and emission reduction credits issued on Regen Registry.

The Regen Registry attempts to follow the best practices as applied to carbon credit markets and Agriculture, Forestry and Other Land Use (AFOLU) carbon credits. The core GHG accounting principles laid out in ISO 14064 Part 2:2019^[8] have informed this guide and are summarized below:

Relevance	Select the GHG sources, sinks and reservoirs (SSRs), data and methodologies appropriate to the needs of the intended user.
Completeness	Include all relevant GHG emissions and removals. Include all relevant information to support criteria and procedures.
Consistency	Enable meaningful comparisons in GHG-related information.
Accuracy	Reduce bias and uncertainties as far as is practical.
Transparency	Disclose sufficient and appropriate GHG-related information to allow intended users to make decisions with reasonable confidence.
Conservativeness	Use conservative assumptions, values, and procedures to ensure that GHG emission reductions or removal enhancements are not overestimated.

10.1. Adherence to GHG Accounting Principles

10.1.1. Boundary Selection

1. GHG project boundaries include a project’s physical boundary and implementation area (i.e. where the Project Activity takes place), the GHG sources, sinks, reservoirs (SSRs) considered, and the project duration.

2. The Approved Methodology establishes the criteria for the selection of relevant GHG SSRs, and procedures for quantifying GHG emissions.

3. The Project Proponent shall provide maps, Geographic Information System (GIS) shapefiles, and other relevant information to delineate the project physical boundary.

10.1.2. Relevance and Completeness

1. Project Proponent shall consider all relevant information that may affect the accounting and quantification of GHG emissions or reductions including all relevant SSRs.

2. The Program Guide and Credit Class include mechanisms to account for estimation uncertainty and carbon retention risk. See the Buffer Pool and Permanence sections for more details.

10.1.3. Consistency

1. The assumptions, methods, and data used in the Approved Methodology to quantify GHG reductions and removals rely on peer reviewed data that enables meaningful comparisons to other methods and data.

10.1.4. Accuracy

1. The Project Proponent shall reduce, as far as is practical, uncertainties related to the quantification of GHG emission reductions or removal enhancements.

10.1.5. Transparency

1. The Approved Methodology, Credit Class and Program Guide disclose sufficient and appropriate GHG-related information to allow all intended users to make decisions with reasonable confidence.

2. Regen Registry is built to provide public access to all key pertinent information related to GHG estimations such as project monitoring and verification reports.

10.1.6. Conservativeness

1. The Approved Methodology shall define assumptions and specify quantification methods and monitoring requirements to ensure that GHG emission reductions and removals are not overestimated.

10.1.7. Emission Reduction & Removal Factors

1. When estimating GHG emission reductions or removals, methodologies shall specify GHG emissions or removal factors that are:

   • Derived from a scientific peer-reviewed source

   • Appropriate for the GHG source or sink concerned

   • Account for uncertainty in the quantification method

10.1.8. Independently Verified

1. The baseline report, monitoring reports, and Project Plan are validated by a verifier approved by the Registry Agent, or Credit Class Admin (unless otherwise stipulated in the Credit Class).

10.1.9. Managing Data Quality

1. The Monitor shall follow the guidelines in the Approved Methodology and establish quality assurance and quality control (QA/QC) procedures to manage data and information, including the assessment of uncertainty in the Baseline and ongoing monitoring.

10.2. Additionality

The concept of additionality is often raised as a vital consideration for quantifying project-based GHG reductions. Additionality is a criteria that requires GHG reductions to only be recognized for project activities that would not have “happened anyway.”

While there is general agreement that additionality is important, its meaning and application remain difficult to define, frequently framed with imprecise language, and in many cases subject to interpretation.^[9]

Greenhouse Gas Protocol Initiative, a multi-stakeholder partnership of businesses, NGOs, governments, and academics convened by the World Business Council for Sustainable Development (WBCSD) and the World Resources Institute (WRI), does not require demonstration of additionality, but instead recommends incorporating it as an implicit part of the procedures used to estimate baseline emissions^[10]. Depending on the methodology, as appropriate for each context, this may be either a performance-based approach or a project-based approach, using either a static or a dynamic baseline, and takes into account different considerations and barriers to adoption.

1. Each Credit Class shall stipulate the relevant additionality requirements to that credit.

10.3. Leakage

Leakage is an increase in GHG emissions or decrease in sequestration outside the project boundaries that occurs because of the project’s actions.

1. Each Credit Class shall define the appropriate procedures to address leakage.

2. Over time, if certain land management activities have consistently been found to create substantial leakage across multiple projects, Regen Registry may remove those activities from the approved list of practices.

10.4. Permanence

In GHG accounting, permanence refers to the risk that a carbon reservoir may be subject to gradual long-term or sudden disruptive release that will reverse the benefit that occurred as a result of project implementation. GHG emissions reductions from terrestrial sources and sinks may not be permanent if a project has exposure to risk factors, such as intentional or unintentional events that result in emissions into the atmosphere of sequestered CO2e for which offset credits were issued. Terrestrial projects have the potential for GHG removals to be reversed upon exposure to risk factors, including both unintentional reversals (e.g. fire, flood, and insect infestation) and intentional reversals (e.g., landowners choosing to discontinue land management and/or participate in an activity that reverses the sequestration).^[11]

Land use-based and forestry projects may require the Project Proponent to register covenants on their land and/or restrict land use for the duration of the Permanence Period as defined in the Credit Class. This approach is not financially viable for most Project Proponents as the covenant often results in a reduction in the market value of the land that is greater than the potential additional revenues from credit sales. Further, there is no length of time, short of perpetual, that is equated with the assurance of permanence, nor is there a sound scientific basis or accepted international standard around any number of years that equates to an emission reduction/removal being permanent.

1. Regen Registry requires that Permanence Periods are specified in each Credit Class. The Project Proponent has the following requirements as it relates to permanence assurances:

2. Allocate the additional amount specified in each Credit Class of each credit issuance (in addition to the Buffer Pool) to a dedicated Permanence Reversal Buffer; and

3. Register as necessary, under the requirements of the particular Credit Class, appropriate covenant(s) on the land from the Project Registration until the end of the permanence period specified in the Credit Class. See Section 7.9 (Managing Property Under Restrictive Permanence Covenants Obligation) for requirements surrounding restrictive covenants running with the land to meet permanence requirements. The Project Proponent states their choice in the Project Plan.

4. If the project is renewed, the Project Proponent will choose again a permanence assurance for the renewed project.

5. If the Project Proponent chooses the Permanence Reversal Buffer, at the end of the permanence period , the Project Proponent will conduct a permanence monitoring and verification round in order to verify carbon retention. See Permanence Reversal Buffer section for more details.

6. Each Credit Class can create alternative permanence requirements as appropriate.

10.5. Buffer Pools

Carbon sequestration projects have the potential for GHG removals to be reversed unintentionally or overestimated. The Buffer Pool serves as a tool to mitigate the general and project-specific risk factors, including the overall uncertainty risk in GHG estimations (on top of the portion accounted for already by the Approved Methodology). Buffer pool contributions shall be decided at the Credit Class level, and designed and implemented by Credit Class Admins. While Buffer Pools are primarily used in GHG emission reduction and removal projects, they can be applied to any type of ecological crediting program.

10.5.1. Types of Buffer Pools

Credit Class Buffer Pools are those which aggregate risk across all projects registered under a given Credit Class, meaning that all projects registered under given Credit Class contribute to and can pull from the same Buffer Pool in the event of a reversal.

1. Credit Class Buffer Pools can be created by Credit Class Admins, who will establish a dedicated account, over which it has sole operational management and control.

2. Credits held in Credit Class Buffer Pools may not be sold, transferred, retired, or disposed of until the end of a crediting period, permanence period, or project termination as specified below.

Project Specific Buffer Pools are those set up by individual projects and used to cover reversal events for a specific project.

1. Credit Classes may require each project to have a Project Specific Buffer Pool in addition to a Credit Class Buffer to cover reversal events for a specific project. Project Specific Buffers must be managed by the Credit Class Admin, who shall have sole operational management and control.

2. If a Credit Class does not require a Project Specific Buffer Pool, Project Proponents may still choose to set one up.

10.5.2. Buffer Pool Contributions and Use

1. Each Credit Class shall specify any relevant Buffer Pool contributions as a percentage of credit issuance.

2. Credit Class Admins can dictate the amount of credits a project can use to cover a reversal event or loss at the end of the crediting term to ensure use of the Credit Class Buffer is shared equally between projects registered under a Credit Class.

3. The Registry Agent shall deposit credits into the dedicated Credit Class or Project Specific Buffers upon issuance.

10.5.3. End of Crediting Term Processing

1. Upon the completion of the project and the final monitoring and verification, the Buffer Pool will be reconciled according to the end of project carbon stock level.

2. If the final project carbon stock level was above the level reported in prior monitoring and verification round:

   1. The existing credit balance of Buffer Pool will be released to Project Proponent unless otherwise specified in the Credit Class.

3. If the final project carbon stock level was below the level reported in prior verification:

   1. The gap will be withdrawn from the Buffer Pool and immediately canceled.

   2. If the Buffer Pool balance does not cover the gap, the Project Proponent will have the following options to compensate for the carbon stock loss:

      1. Renew the project and defer the payment to the next issuance(s).

      2. Use non-transacted (sold) credit/other credits in Project Proponent’s Regen Registry account.

      3. Purchase credits to compensate for the carbon loss. The Credit Class Admin must approve any credits purchased to compensate loss. These credits will be canceled upon purchase.

10.5.4. Premature Project Termination

1. In the event that the project prematurely terminates, the Credit Class Admin will follow a conservative approach and automatically cancelall the credits in the Buffer Pool associated with the project.

2. In a final verification report, where the end of project carbon stock level is available, similarly to 'End of Crediting Term Processing', if the Buffer Pool was insufficient to cover the gap in carbon stocks level then the Project Proponent will be required to purchase credits to compensate for the carbon loss.

3. If no final verification report is available, to be conservative, Credit Class Admins will assume a default loss of 10% in carbon stock level from prior levels and cancel credits accordingly. If the Buffer Pool was insufficient to cover that loss, the Project Proponent will be required to purchase credits to compensate for the carbon loss.

10.5.5. Overestimation of Credits Issued during Crediting Period

1. In the event that during the Crediting Term a Verification Report rating was Rejection on the grounds that the carbon stock level was overestimated, then:

2. The gap will be withdrawn from the Buffer Pool and immediately canceled.

3. If the Buffer Pool balance does not cover the gap, the Project Proponent will have the following options to compensate for the carbon stock loss:

   • Use non-transacted (sold) credit/other credits in Project Proponent’s Regen Registry account.

   • Purchase credits to compensate for the carbon loss.

10.5.6. Purchase of Credits to Compensate for Carbon Loss

• In any event, per above, that the Project Proponent is required to purchase credits to compensate for carbon loss, these credits shall be from other projects with similar regional characteristics and co-benefits, either from Regen Registry or from Established Registries. The Credit Class Admin must approve any credits purchased to compensate loss. These credits will be canceled upon purchase.

10.6. Permanence Reversal Buffers

10.6.1. Types of Permanence Reversal Buffers

Credit Class Permanence Reversal Buffers are those which aggregate risk across all projects registered under a given Credit Class, meaning that all projects registered under given Credit Class contribute to and can pull from the same Buffer Pool in the event of a reversal.

1. Credit Class Permanence Reversal Buffers can be created by Credit Class Admins, who will establish a dedicated account, over which it has sole operational management and control.

2. Credits held in Credit Class Permanence Reversal Buffers may not be sold, transferred, retired, or disposed of until the end of a permanence periodor project termination as specified below.

Project Specific Permanence Reversal Buffers are those set up by individual projects and used to cover reversal events for a specific project.

1. Credit Class may require each project to have a Project Specific Permanence Reversal Buffers l in addition to a Credit Class Permanence Reversal Buffers Project to cover reversal events for a specific project. Project Specific Permanence Reversal Buffers must be managed by the Credit Class Admin, who shall have sole operational management and control.

2. If a Credit Class does not require a Project Specific Permanence Reversal Buffer, Project Proponents may still choose to set one up.

10.6.2. Permanence Reversal Buffer Contribution

1. In the event that Project Proponents choose to use the Permanence Reversal Buffer, the permanence pool must be specified by the Credit Class Admin.

2. In the event the Project Proponents choose not to use the Permanence Reversal Buffer and use other alternatives such as long term restrictive covenants, the permanence reversal buffer contributions will not be deducted from each credit issuance.

10.6.3. End of Permanence Period

1. Upon the completion of the permanence period an additional monitoring and verification round will occur and the Permanence Reversal Buffer will be reconciled with the carbon stock level at the last recorded monitoring event during the Crediting Term.

   1. If the final GHG level was above the last recorded GHG level, the existing balance of Permanence Reversal Buffer will be released to Project Proponent.

2. If the final level was below the last recorded level:

   1. The gap will be withdrawn from the Permanence Reversal Buffer and immediately retired. The remainder will be distributed to the Project Proponent.

   2. If the Permanence Reversal Buffer balance does not cover the gap, the Project Proponent will have the following options to compensate for the gap:

      1. Use non-transacted (yet-to-be-sold) credits in Project Proponent’s Regen Registry account.

      2. Purchase credits to compensate for the gap in carbon stock. The purchased credits can be from Regen Registry, or from Established Registries.

10.6.4. Premature Project Termination

1. In the event that the project has ended prematurely, the Project Proponents are still contractually obligated to maintain the permanence requirements for each credit vintage sold.

2. Regen Registry will follow the same approach as the end of permanence period for carbon stock reconciliation - see Section 10.6.3 (End of Permanence Period).

3. If no monitoring and verification report was conducted at the end of the permanence period, in order to be conservative, the Credit Class Admin will assume a default loss of 10% in carbon stock level from last recorded level. If the Permanence Reversal Buffer was insufficient to cover that loss, the Project Proponent will be required to purchase credits to compensate for that loss.

10.6.5. Purchase of Credits to Compensate Carbon Loss

1. In any event, per above, that the Project Proponent is required to purchase credits to compensate for carbon loss, these credits shall be from other projects with similar regional characteristics and co-benefits, either from Regen Registry or from Established Registries.

10.7. Avoiding Double Counting

Double counting refers to situations where a single GHG emission reduction or removal is used more than once to demonstrate achievement of mitigation targets and/or pledges typically made by corporations/entities and countries. Double counting can occur either as double issuance, double sale, or double claiming.

Double claiming is of concern in international carbon trading and in determining Nationally Determined Contributions (NDC) under the Paris Agreement^[12], when an emission reduction is counted once by the country of origin when reporting its emissions inventory, and again by the receiving country (or other entity) when justifying emissions above its pledged climate effort. In the absence of rules, a country of origin could reduce emissions to meet its pledged effort and transfer those to a recipient; the recipient could then claim those same reductions to meet its pledged effort. In that case, only one reduction has actually occurred, but it is being claimed twice. Analyses indicate that such double-claiming could eliminate the entire climate benefit of all the NDCs.^[13]

Regen Registry has program rules and operational processes to mitigate these double counting risks. To avoid double claiming, all credits will be tracked on Regen Ledger, a custom-built ecological ledger leveraging blockchain technology (specifically the Cosmos SDK^[14]), which provides public immutable records for transactions. The data on Regen Ledger is available for external scrutiny and validation and provides a digital audit trail for transactions, at any given point in time. Examples include who was issued credits and their location, who currently owns credits, when each credit was retired, and who claimed the GHG benefit and their location.

Risk	Description	Mitigation
Double Issuance	1) A situation in which more than one carbon credit is issued for the same emissions or emission reductions. 2) The registration of the same project under two different carbon crediting programs or twice under the same program	On Regen Registry, for a given location, only one project applying for any Credit Class with a GHG component, is registered and active. Project Proponent will be required to commit to not claiming credits for the same land and emission reduction/removal concurrently on any other registry. Verifier will confirm this in the verification report prior to credit issuance.
Double Sale	An instance in which a single GHG reduction or removal is sold to more than one entity at a given time.	Credit ownership will be tracked on Regen Ledger, leveraging blockchain technology which prevents the possibility of double selling.
Double Claiming	An instance in which an issued credit is used by the same Buyer toward more than one target (e.g., under systems that are not linked, do not coordinate, or may have inconsistent rules for reporting and/or retirement).	Legal contracts will restrict Buyers from making multiple claims on any given credit. Each retirement will record the exact time, location, beneficiary details and retirement amounts.

When any country or state approves the trading of carbon credits (along with the carbon claims associated with them), Regen Registry will adhere to guidelines as established by the United Nations Framework Convention on Climate Change (UNFCCC)^[15] and Carbon Offsetting and Reduction Scheme for International Aviation (CORSIA)^[16] to prevent double counting towards NDC and CORSIA obligations respectively, and to ensure the environmental integrity of emissions reductions.

11. Monitoring Requirements

The Monitor shall follow the requirements in the Approved Methodology to quantify the benefits and indicators defined in the respective Credit Class.

11.1. Monitor Requirements

1. The Project Proponent or a third party can perform Monitoring as stipulated in the Credit Class. It is recommended that the Monitor satisfies the following requirements:

   • Obtain Errors & Omissions Insurance for at least $1 million.

   • Has demonstrated technical expertise in the methods specified in the Approved Methodology, for example: satellite imagery and GIS analysis, biogeochemical models (if applicable), statistical analysis, GHG estimation, etc.

2. Monitors for all Credit Classes must satisfy these minimum requirements:

   1. Have sufficient proof of identity

   2. Be in a position of fiduciary duty to operate in the best interest of the Project

3. If the Project Proponent, Project Developer, or other Project Actor implementing Project Activities is also acting as the Monitor, they must sign a statement confirming their fiduciary obligations to minimize conflicts of interest and to monitor the Project in the best interest of the Project

4. If an organization other than the Project Proponent is acting as the Monitor, they must sign a statement confirming their fiduciary obligations to minimize conflicts of interest and to monitor the Project in the best interest of the Project. The Registry Agent and the Project Proponent must be satisfied that any potential for conflict of interest can be mitigated.

5. To limit the potential for conflict of interest in this scenario, Monitors will disclose all relationships, such as familial or fiduciary, within the past three years between the Monitor on the one hand, and the project and Project Proponent on the other.

11.2. Payment for Monitoring

1. Project Proponent is responsible for engaging and paying for monitoring.

11.3. Monitoring Procedure

1. The Monitor shall gather all the monitoring data (if applicable) provided by the Project Proponent using the respective Regen Registry templates. If there is missing information, the Monitor will communicate the gaps to the Project Proponent who in turn will resubmit the monitoring data.

2. The Monitor shall gather all other sources of data specified in the Approved Methodology necessary for the quantification process, for example satellite imagery or metrics from scientific literature.

3. The Monitor shall use the appropriate tools and follow the procedures in the Approved Methodology to quantify each ecological indicator.

4. The Monitor shall submit a monitoring report summarizing the quantification results and including the number of credits the Project Proponent is eligible for based on the definitions in the Approved Methodology and the Credit Class. The Monitor shall apply any estimation uncertainty deductions (if applicable per the Approved Methodology) to the number of credits reported.

11.4. Monitor Procedure Deviations

1. The Registry Agent will permit project-specific deviations from the Approved Methodology where they do not negatively affect the conservativeness of an Approved Methodology’s approach to the quantification of GHG emissions reductions and removal enhancements.

2. Monitors shall submit any proposed project-specific deviation to the Registry Agent. Monitors must provide evidence that the proposed deviation, such as a substitute calculation method for missing data, meets the conservative standards of the methodology.

3. The Registry Agent will review each such request, and if approved, deviations can be applied to a specific project, but are not published as modifications to the methodology. Any approved deviations must be communicated to the Credit Class Admin by the Registry Agent, and may be overridden by the Credit Class Admin.

11.5. Monitoring Acceptance

1. The Registry Agent will review each monitoring report to verify it conforms to the templates and the procedures specified in the Approved Methodology. If corrections are needed, the Monitor shall resubmit the monitoring report with the corrections.

2. Credit Issuance - If the monitoring report indicates the Project Proponent is eligible for credits and no verification is needed (see the Verification section requirements), the Registry Agent will issue credits to Project Proponent after the appropriate deductions as specified in the Program Guide and Credit Class.

3. The Registry Agent will make all monitoring reports publicly available.

11.6. Monitoring Schedule

1. The monitoring schedule will be dictated by the requirements in the Approved Methodology or Credit Class and will include:

   • Baseline measurement - performed upon project registration.

   • On-going measurements - as needed per the Approved Methodology.

   • Final Project Monitoring - to be completed at the end of the Crediting Term.

   • End of Permanence Monitoring - if applicable, a final monitoring round will be completed at the end of the permanence period.

11.7. Monitoring Oversight

1. The Registry Agent reserves the right to conduct oversight activities of monitoring performance of participating verifiers. Oversight activities are conducted to ensure an adequate level of quality control and are intended to supplement accreditation body oversight and audit processes.

12. Verification Requirements

This section provides a general overview of the requirements for ex post verification of GHG and Co-Benefits assertions by an independent third-party verifier. As defined in this section, verification will be conducted by an independent verifier chosen by the Project Proponent as per the requirements stipulated in the Credit Class.

Regen Registry seeks a balance between adequate assurances, the overhead, and costs associated with verification. Therefore, each Credit Class can stipulate the requirements that are best suited to the ecosystem, best management practice and/or locale(s) to which it pertains.

12.1. Verifier Requirements

1. Credit Classes must specify the Verifier Requirements. Examples of recommended requirements include:

   • Verification bodies accredited under ISO 14065 and in good standing with their relevant ISO member body.

   • Verifiers approved by Established Registries.

   • Verifiers with Errors and Omissions Insurance for at least $1 million.

   • Has demonstrated technical expertise in the Project Activity specified in the Credit Class.

2. Verifiers for all Credit Classes must satisfy these minimum requirements:

   • Have sufficient proof of identity.

   • Be in a position of fiduciary duty.

3. Verifiers must sign a statement confirming their lack of conflict of interest with the Project Proponent. The Registry Agent and the Project Proponent must be satisfied that any potential for conflict of interest can be mitigated.

4. To limit the potential for conflict of interest, Verifiers will not conduct a verification for any project in which:

   1. Any member of the verification team has a financial interest in the project or the Project Proponent.

   2. The Verifier has played a role in developing the project.

5. The verifier will disclose all relationships, such as familial or fiduciary, within the past three years between the Verifier on the one hand, and the project and Project Proponent on the other.

12.2. Payment for Verification

1. Project Proponent is responsible for engaging and paying for verifications.

12.3. Evidence Gathering

1. Verifiers shall take necessary and appropriate steps to assure the project inputs are authentic, using a random sampling approach whenever appropriate.

Verifiers are required to provide assurance as to the reasonableness, accuracy and validity of the data the Project Proponent has provided to the Registry Agent and the Monitor.

1. The Credit Class and Approved Methodology contains specific guidance on the scope of evidence gathering necessary to provide reasonable assurance with respect to the data the Project Proponent provides the Monitor.

2. The verification requirements specified in the Credit Class should include but is not limited to the following categories:

   1. Project Plan - the verifier shall verify the information provided in the Project Plan.

   2. Project Ownership and Rights

      1. Verifier shall verify that the Project Proponent has legal rights to the land defined in the project boundaries. If the Project Proponent is an organization, the verifier shall also verify the documents provided to the Registry Agent have been signed by the organization’s representatives without a reasonable doubt.

      2. The verifier shall choose the appropriate level of Land Owner rights verification from the list below, where the default shall be the least strictest approach. Documentation verification levels, from strictest to least:

         1. Evidence of land title or deed of ownership - official documentation of Federal / State government.

         2. Rate payments, such as utility services provided by local jurisdictions to the property and Project Proponent.

         3. Copies of email exchanges, letters, agreements or similar documentation (or their extracts).

      3. In the case the land is leased, the verifier shall also verify the lease agreement between Project Proponent (or the entity/individual represented) and Land Owner.

      4. If the Project Proponent is representing the Land Owner, the verifier shall verify the Deed of Representation between the Project Proponent and the Land Owner.

   3. Data inputs provided by Project Proponent to the Monitor - as stipulated by the Approved Methodology.

   4. The Monitor followed the procedures stipulated in the Approved Methodology.

   5. Compliance with Credit Class and Approved Methodology requirements:

      1. Project eligibility - see section above for full details. Including, but not limited to:

         1. Ownership type - matches the type mentioned in Project Plan

         2. Project Activity falls within the defined accepted list of activities

         3. Project Area matches land tenure descriptions

         4. Adoption Date falls after the earliest accepted date and evidence is provided to attest to that

      2. No double issuance - see Avoiding Double Counting section

      3. Compliance with existing laws and regulations

   6. Leakage - verifying estimated leakage by Project Proponent is a reasonable estimate (for example, uses regional default emission factors or is in line with similar projects).

12.4. Verification Report

1. Verifiers shall generate a report summarizing their findings per the requirements stipulated in the Credit Class, including a verification rating using the following or similar language:

   1. Acceptance - if all the corresponding requirements in the Evidence Gathering section (10.4) have been satisfactorily met.

   2. Acceptance with Contingencies

      • If there were any deviations from the Approved Methodology.

      • If data provided by the Project Proponent (e.g. in the Project Plan) which is inconsequential to GHG estimation, could not be satisfactorily verified.

   3. Rejection

      • If project ownership could not be satisfactorily verified.

      • If the Monitor did not follow key Methodology guidelines (excluding minor deviations).

      • If data provided by the Project Proponent for GHG estimation is suspected to be fraudulent.

      • Lack of compliance with Project Eligibility, Double Counting requirements, or existing laws/regulations.

12.5. Verification Acceptance

1. The Registry Agent will review each verification report and proceed based on its rating as specified below.

2. The Registry Agent will post all verification reports publicly.

12.5.1. Acceptance

1. Regen Registry will issue credits (if applicable) to the Project Proponents per the monitoring outcome and Program Guide / Credit Class stipulations.

12.5.2. Acceptance with Contingencies

1. The Project Proponent shall make the necessary corrections and clarifications per the contingencies identified in the report. If needed, the Verifier will resubmit their report after reviewing the information provided by the Project Proponent.

2. Registry Agent will issue credits (if applicable) following the Acceptance procedure above.

3. If the resubmitted verification report still retains the Acceptance with Contingencies, Registry Agent will highlight this in the corresponding MRV section.

12.5.3. Rejection

1. The project is put on hold until the issues identified are addressed (see Project on Hold section).

2. The carbon stock level will revert to the last level that was recorded and verified with the verification report with Acceptance or Acceptance with Contingencies rating. If the project has already been issued credits, then the Buffer Pool will be used to reconcile any gaps (see Buffer Pool section).

12.6. Verification Schedule

1. Verification is required prior to issuance. Any issuance of GHG removal or other forms of ecological credits which require verification based on the requirements stipulated in the credit class shall require a verification report prior to issuance.

2. Project Proponents shall follow the verification schedule required by the Credit Class. The Verification shall be completed within three months of the monitoring round.

12.7. Unscheduled Verification

1. The following circumstances will warrant a potential additional verification:

   1. A previous verification report with a Rejection or Acceptance with Contingencies ranking.

   2. Compliance verifications - when the Registry Agent has reasonable grounds to suspect the Project Proponent has contravened, is contravening, or is proposing to contravene with the rules and regulations.

12.8. Verification Oversight

1. The Registry Agent reserves the right to conduct oversight activities of verification performance participating verifiers. Oversight activities are conducted to ensure an adequate level of quality control and are intended to supplement accreditation body oversight and audit processes.

13. Purchasing, Selling, and Retiring Credits

13.1. Wallet Address Creation

Project Proponents (or sellers) and Buyers must have a wallet address on Regen Network to which credits will be issued or transferred respectively. The registration process might require an appropriate KYC (Know Your Customer) verification depending on the nature of the asset issued and corresponding regulations.

13.2. Retiring Credits

1. Traditionally in carbon markets, credit retirement involves allowances from regulated emission trading schemes^[17] as a method for offsetting carbon emissions. Regen Registry is not a regulated emission trading scheme, but instead provides Buyers a way to voluntarily offset their carbon footprint.

2. Credits can only be retired once. Once a credit has been retired, it cannot be transferred or sold anymore.

3. Regen Registry provides the ability for Buyers to trade their credits, i.e. sell them to other Buyers on a secondary market. In the future, a secondary marketplace functionality will be added.

4. Credit Buyers will have access to the Project Proponent’s information, the project location, monitoring reports, and other pertinent data which is made publicly available on Regen Registry.

13.3. Tradability

Credit buyers will have the option to sell their credits so long as they have not yet been retired. Credits are treated as commodities, not as securities. RND is committed to comply with all relevant regulatory frameworks, both in the US and internationally.

13.4. Selling Credits

Credit holders - whether Project Proponents who have been issued credits or Buyers who had purchased tradable credits - have a few options to sell their credits:

• Direct / offline sale - a seller can negotiate directly with a prospective Buyer and offer them the credits.

• Marketplace - a seller can offer the credits for sale on Regen Marketplace and select their price. The project credits can be sold separately or as part of a portfolio of projects.

• 3rd party integrations - in the future, Regen Network will establish integrations with 3rd parties that offer GHG credits (offsets) for instance to their respective client base.

Note, not all of these options are currently available.

13.5. Fee Structure

The fee structure for the issuance and sale of credits depend on the Credit Class, Methodology requirements and sales approach used. Regen Registry will make the fee structure transparent on the website.

14. Complaints and Appeals

14.1. Complaints Procedure

When a Project Proponent or other stakeholder objects to a decision made by a Registry Agent, Credit Class Admin, or the application of the Regen Registry program requirements, the following confidential complaint procedure shall be followed:

• Project Proponent or other stakeholder sends a written complaint via email to [email protected]. The complaint must detail the following:

  • Description of the complaint with specific reference to the Program Guide, Credit Class or Methodology requirements as applicable.

  • Supporting documentation provided for consideration in the complaint resolution process.

  • Complainant name, contact details, and organization.

Regen Registry, currently managed by RND, shall investigate the complaint by forming a committee of at least three staff members who review the complaint and determine its merits to render a decision on the matter.

14.2. Appeals Procedure

In the event that a plaintiff is not satisfied with the result of a review they may appeal any such decision or outcome reached. The following confidential appeals procedure shall be followed:

• Project Proponent or other stakeholder sends a written appeal via email to [email protected]. The appeal must detail the following:

  • Description of the complaint with specific reference to the Program Guide, Credit Class or Methodology requirements as applicable;

  • Supporting documentation provided for consideration in the appeal process, including previous communication on the complaint and all relevant details of the previously implemented complaint procedure

  • Appellant name, contact details, and organization.

• Regen Registry shall convene a committee to review and discuss the matter. The committee may include Regen Registry staff members, a technical and/or subject matter expert or experts as necessary. The committee members selected will depend on the subject matter and nature of the appeal.

• The decision reached by the committee shall be communicated, via written response, to the Project Proponent or stakeholder. Any decision reached by the committee shall be final.

15. Linkages to other Registry Systems

In the event that a Project Proponent wishes to transfer a project from another GHG (or other ecosystem service) program, the project must adhere to all the requirements in the Program Guide, and respective Credit Class and Methodology. To avoid double issuance of GHG credits (whether removals or emission reduction) see also the requirements in the 'Avoiding double counting' section.

16. References

The Program Guide is based on the foundation laid by the reference standards and documentation below. These assisted RND to articulate our own requirements and specifications for the MRV requirements, especially as it relates to GHG guidelines that apply to AFOLU project-based credits.

In particular the Program Guide has been informed by these organizations:

• American Carbon Registry^[18]

• The Australian Government’s Emission Reduction Fund^[19]

• Gold Standard^[20]

• Verra (VCS)^[21]

• GHG Protocol^[22]

• Nori^[23]

We salute and appreciate the effort of all these organizations!

This is a subset of the reference documentation used in writing this guide:

American Carbon Registry

• ACR Standard v6.0

• ACR Risk Tool v1.0

The Australian Government’s Emission Reduction Fund

• Carbon Credits (Carbon Farming Initiative - Measurement of Soil Carbon Sequestration in Agricultural Systems) Methodology Determination 2018

• The Supplement To the Carbon Credits (Carbon Farming Initiative - Measurement of Soil Carbon Sequestration in Agricultural Systems) Methodology Determination 2018

Verra

• VCS Program Guide v4.0

GHG Protocol

• GHG Project Protocol

• Land Use, Land-Use Change, and Forestry (LULUCF) Guidance for GHG Project Accounting

Nori

• Nori: How it Works

---

1. FAO and ITPS, 2015; IPBES, 2018

2. Note, the taxonomy of carbon markets and climate mitigation varies from ecosystem services

3. https://ghgprotocol.org/sites/default/files/standards/ghg_project_accounting.pdf

4. Protocols and Standards - Carbon Offset Guide

5. https://github.com/regen-network/

6. https://en.wikipedia.org/wiki/Digital_commons_(economics)

7. https://medium.com/regen-network/community-stake-governance-model-b949bcb1eca3

8. https://www.iso.org/obp/ui/#iso:std:iso:14064:-2:ed-2:v1:en

9. https://ghginstitute.org/wp-content/uploads/2015/04/AdditionalityPaper_Part-1ver3FINAL.pdf

10. https://ghgprotocol.org/sites/default/files/standards/ghg_project_accounting.pdf

11. https://americancarbonregistry.org/carbon-accounting/standards-methodologies/american-carbon-registry-standard-3/acr-standard-v6-0-may-2019-public-comment-version.pdf

12. https://unfccc.int/process-and-meetings/the-paris-agreement/the-paris-agreement

13. https://www.edf.org/sites/default/files/documents/double-counting-handbook.pdf

14. https://cosmos.network/

15. https://unfccc.int/

16. https://www.icao.int/environmental-protection/CORSIA/Pages/default.aspx

17. https://en.wikipedia.org/wiki/Emissions_trading#Trading_systems

18. https://americancarbonregistry.org/

19. http://www.cleanenergyregulator.gov.au/ERF/

20. https://www.goldstandard.org/

21. https://verra.org/

22. https://ghgprotocol.org/

23. https://nori.com/