Principles & requirements

All projects must meet the Principles & requirements described below. Their compliance with the following requirements shall be audited by a VVB and checked by the Rainbow team. Detailed instructions and examples are presented in Methodologies.

Criteria
Description

Additionality

The mitigation activity would not have occurred without the revenues from carbon finance.

GHG quantification

GHG reductions and removals are rigorously and conservatively quantified.

Durability

Carbon will be removed for the entirety of the commitment period.

No double counting

Carbon benefits of mitigation activities are only counted once, and are not double used, issued or claimed.

Environmental & social safeguards

Projects do not contribute to environmental or social damage, and has conducted a stakeholder consultation.

Co-benefits

Projects deliver positive impact towards environmental and social sustainability beyond climate benefits.

Leakage

Mitigation activities do not cause GHG emissions to be indirectly transferred elsewhere.

Traceability

The project mitigation activity and credit issuance are well documented and easily traceable.

Delivery

Projects deliver real emission reductions and/or removals, as claimed.


Additionality

The Rainbow Standard certifies projects that would not have occurred without revenue from carbon finance. This principle ensures that carbon financing spurs additional action to fight climate change, rather than subsidizing actions that would have happened anyway.

All projects shall prove their additionality by meeting the requirements of at least two additionality tests: regulatory surplus analysis, plus either investment or barrier analysis.

Project Developers shall fill in the Rainbow Additionality Template to demonstrate their additionality, using project-specific justifications and verifiable evidence. Methodologies may provide further instructions or requirements for demonstrating additionality.

Note that RCCs are only issued for GHG reductions and/or removals that are additional to the baseline environmental conditions. This is sometimes referred to as environmental or carbon additionality. This is addressed in the baseline scenario requirements.

Regulatory surplus analysis

Mitigation activities must go beyond what is required by regulations. Project Developers shall prove the following:

  • There is no enforced law, regulation, statute, legal ruling or other regulatory framework that makes the implementation of the project or specific mitigation activity mandatory.

  • If there is an enforced regulation related to the project, the project results in greater GHG emission reductions/removals than what is required by regulations. In this case, only the project activities that surpass the mandated amount are eligible for RCCs.

Project Developers shall describe the current and upcoming regulatory environment related to their mitigation activity in the Rainbow Additionality Template.

Investment analysis

Project Developers using investment analysis shall prove that revenue from carbon finance is necessary to make the project investment financially viable.

Project Developers shall prove that revenue from carbon finance is necessary for investments to launch or expand the project. Note that for investments in expansion, only the additional carbon reductions enabled by the expansion shall be eligible for Rainbow Carbon Credits.

Project Developers shall provide an investment analysis and/or business plan, with accompanying spreadsheet and calculations, showing that funding from carbon finance is necessary for the project investment. They shall include all funding sources in the investment analysis and/or business plan. The analysis should be based on the project’s Internal Rate of Return (IRR) with and without carbon finance.

Barrier analysis

Project Developers using barrier analysis shall prove that barriers prevent the mitigation activity from continuing or expanding, and that revenue from carbon finance is necessary to allow projects to overcome these barriers. These may be financial, institutional, or technological barriers.

Examples of barriers include but are not limited to:

  • Financial: high upfront costs, uncertain or low returns on investment, long payback periods

  • Institutional: complex or costly regulatory requirements, limited access to financing, lack of supportive infrastructure, limited market demand, resistance from incumbents

  • Technological: cost competitiveness and economic viability, scale and manufacturing challenges

Project Developers shall identify, describe and quantify the barrier, with verifiable proof.

Project Developers shall demonstrate that revenue from carbon finance is decisive in overcoming this barrier, including justification that:

  • the magnitude of revenue from carbon finance is similar to the amount of funding needed to overcome the barrier, and

  • the project could not have provided the funding itself, providing financial results and considering all project funding sources.

Project Developers shall demonstrate that at least one alternative to the project activity does not face significant barriers, including the barriers faced by the project.

Note that for overcoming barriers to expansion, only the additional carbon reductions enabled by the expansion shall be eligible for Rainbow Carbon Credits.


GHG quantification

GHG reductions and removals shall be rigorously and conservatively quantified. Further details are provided in the following section.


Durability

Durability requirements ensure that GHG reductions and/or removals persist through the entire duration of the commitment period.

Methodologies shall establish all of the following:

  • durability for removals, in years

  • requirements for proving that a project's mitigation activity will meet or surpass the durability threshold

  • minimum buffer pool contributions

  • reversal risk assessment requirements, detailed below

Project Developers shall prove that their GHG emission reductions or removals meet the durability threshold established in the methodology. All projects issuing removal RCCs are subject to the Reversal risk assessment requirements outlined below.

To prove durability, Project Developers shall meet the following requirements, listed here and detailed below:

  • Risk assessment: evaluate the technology-specific risks of carbon sequestration reversal

  • Mitigate: intervene in the project design or processes to reduce risk of reversal; establish buffer pool contribution or reversal insurance

  • Monitor: include remaining, unmitigated reversal risks in the project's Monitoring Plan

  • Compensate: follow detailed procedure to report any reversals and replace with equivalent removal RCCs

Reversal risk assessment

Carbon removals are not permanent if the carbon is re-emitted (i.e. the removal is reversed). A GHG reversal occurs when previously sequestered carbon is re-released into the atmosphere, resulting in a partial or complete loss of stored carbon of at least 1 tCO2eq. Reversals can result from natural disturbances or project mismanagement, and be or .

The following types of projects/reversals can be considered:

Technological, non-nature based removals based on chemically bound carbon are not likely to have material reversal risks, upon meeting the durability requirements set out in the methodology to issue credits. Such removals are covered by several Rainbow methodologies, and may include but are not limited to:

  • BiCRS: Biomass carbon removal and storage (e.g., biochar)

  • BioCCS and DACCS (biogenic carbon or direct air carbon capture and storage)

  • Long-term carbon capture and use in products

  • Enhanced rock weathering

Such project activities shall follow the methodology- and project-level requirements below.

By default, at least 2% of all verified removal RCCs shall be transferred to the buffer pool upon issuance. Methodologies may define higher default minimum buffer pool contributions.

Methodology-level reversal risk assessment

Methodologies shall assess the risk of reversals for the technology type. Where material risk is identified, they shall establish project design requirements that mitigate reversal risk, which may render the reversal risk negligible or lowered.

If material reversal risks remain, which cannot be mitigated by project design requirements, methodologies shall establish:

  • procedures to assess GHG reversal risks at the project level, including the methodology reversal risk assessment template

  • requirements for projects to mitigate and compensate for reversal risks, such as increased minimum contributions to the buffer pool and/or reversal risk insurance.

Project-level reversal risk assessment

All projects eligible for removal RCCs under methodologies that have identified outstanding material reversal risks must assess reversal risks during the validation step. An assessment procedure and a minimum list of reversal risks to assess shall be provided in each methodology, tailored to the specific technology. Further details on completing the assessment are in the Risk assessment section below.

Where a material risk of reversal is identified in the project reversal risk assessment step, Project Developers shall address those risks by creating a risk mitigation plan. The risk mitigation plan shall account for both the technology type and the project design, and outline how the project will prevent, monitor, report and compensate identified reversal risks.

Risk assessment

Risks are identified in Risk Assessment Templates, which are provided in each methodology and tailored to the given project type. These templates guide Project Developers in evaluating the likelihood and severity of each risk type. Project Developers must assess the likelihood and severity scores of each risk for their specific project. This is completed during the validation step, and presented in the PDD. The Risk Assessment Template is composed of two parts:

  • The Reversal Risk Evaluation section covers carbon reversal risks, and responds to the Durability criteria. This is evaluated to identify and mitigate potential reversal risks. Reversal risks may include social, economic, natural, and delivery risks.

  • The Environmental and Social Evaluation section covers risk of environmental and social damages, and responds to the Environmental and Social Do No Harm criteria. This is evaluated to transparently identify environmental and social risks, and determine which risks shall be monitored on an ongoing basis.

Each identified material risk (defined as issues with a risk score of moderate or higher) is subject to creation of a risk mitigation plan, developed by the Project Developer, that details the long-term strategies and investments for preventing, monitoring, reporting and compensating carbon removal reversal and/or environmental and social damages.

Note that some risks shall be monitored and reported regardless of the risk score. This are defined at the methodology level, and include technology-specific risks that are particularly sensitive, likely, or variable, and/or subject to project design requirements.

Any remaining reversal risks that could not be fully prevented and deemed negligible by risk mitigation shall be monitored regularly and added to the project's Monitoring Plan. Methodologies shall define whether reversal monitoring requirements are set at the methodology level, and/or whether they shall be assessed at the project level. Reversal monitoring may continue after the project's crediting period ends, until a negligible risk of reversal has been proven, using models or other scientifically-backed methods.

If a reversal is detected during monitoring, the credit cancelation and compensation procedure described in the Procedures Manual shall be applied.

Projects shall follow the applicable methodology's requirements regarding minimum contributions to the buffer pool and/or reversal risk insurance.


No double counting

Double counting includes double issuance, double use and double claiming, defined as follows:

  • Double issuance:

    • On multiple registries: simultaneously issuing carbon credits for the same mitigation activity, in the same crediting period, under the Rainbow Standard and a different standard.

    • Along the value chain: issuing multiple carbon credits for the same mitigation activity by multiple actors along the supply chain. RCCs are issued to projects that are fundamental in the value chain, and are fully allocated to the project.

  • Double use: retiring a credit more than once.

  • Double claiming: both issuing RCCs and claiming the environmental benefit of the mitigation activity under other environmental schemes.

Rainbow Carbon Credits shall be used, issued and claimed only once. Double counting is prevented under the Rainbow Standard via the requirements listed in sections below.

Rainbow’s Double Counting Policy provides full explanations and requirements regarding this eligibility criteria. Key points are summarized here.

Double counting policy

Double issuance

Project Developers shall not use another program to issue carbon credits for the given mitigation activity, for the same year.

Project Developers shall ensure that specified upstream and downstream actors in the supply chain have not and will not issue carbon credits for their role in the mitigation activity. Specific requirements are outlined in methodologies.

Double issuance is prevented by the signing of the Rainbow MRV & Registry Terms & Conditions, where all Project Developers agree to follow the No double issuance requirements outlined in the present document.

If a project transfers from another crediting program to the Rainbow registry, the monitoring period shall not overlap. The Project Developer shall provide the deregistration certificate from the other carbon-crediting program, stating from which date the project's activity is no longer credited under the other carbon-crediting program, and the end date of the last monitoring period.

Double use

Double use is prevented by the Rainbow Registry, where each project is automatically assigned a unique identification number from issuance to retirement, with project ID, location, and Project Developer name and contact information.

An immutable certificate is generated upon retirement, and all retirement transactions are transparently and publicly available on the registry (see example here). This ensures that all RCC retirements can be uniquely identified and traced back to the project and credit batch. See the RCC retirement section for more details.

Double claiming

RCCs shall not be claimed by both the entity retiring the carbon credit for the purpose of making a GHG emission offsetting claim, and

  • nationally determined contributions (NDCs),

  • national climate policies and emissions trading schemes, or

  • other GHG-related environmental credits.

For double claiming between entities retiring carbon credits, and the end-users of products that have been issued carbon credits, guidance from reporting schemes, GHG Protocol, and other accounting mechanisms shall be followed.

Double claiming with NDCs shall be prevented by signed agreements with host countries and confirmation of corresponding adjustments. Such agreements will be made publicly available with the project documentation, and updated as needed.

Double claiming with national climate policies and emissions trading schemes shall be prevented by proof that the mitigation activity is outside the scope of such policies and schemes. If this is not the case, Project Developers must obtain proof of an accounting adjustment or cancellation in the emissions trading scheme.

Double claiming with other GHG-related environmental credit frameworks is not allowed. This is prevented by the signing of the Rainbow MRV & Registry Terms & Conditions, where all Project Developers agree to follow the requirements outlined in the present document.

For double claiming between entities retiring carbon credits, and the end-users of products that have been issued carbon credits, guidance from reporting schemes, GHG Protocol, and other accounting mechanisms shall be followed.

For purposes of voluntary climate pledges and reporting (e.g. GHG protocol), Project Developers must inform upstream and downstream supply chain entities of claimed project/intervention/insetting emission reductions, report them to Rainbow, document any transfer of emission reduction units, and seek guidance in cases of conflicting claims from reporting bodies like the GHG Protocol.


Environmental and Social Safeguards

Climate action should not come at the expense of environmental and social wellbeing, and should do no net harm.

Environmental and social safeguards are managed through the following, detailed in sections below:

  • Environmental and social risk assessment: Project Developers shall evaluate the risk of environmental and social impacts during the validation step using the Environmental and Social Damage evaluation section of Risk Assessment Templates. Identified risks shall be minimized and addressed.

  • Stakeholder consultation: Project Developers shall conduct a comprehensive and documented stakeholder consultation to provide insights into unintended outcomes, and foster collaboration with local impacted communities.

  • Free prior and informed consent procedure: for applicable project types, indigenous people/local communities (IPLCs) shall be explicitly consulted, ensuring free, prior and informed consent (FPIC), as part of the stakeholder consultation.

  • Benefit sharing: projects involving IPLCs shall set up, and demonstrate the execution of, a benefit sharing scheme with IPLCs.

Project activities shall comply with all applicable local, state, national, and international regulations. Project Developers shall provide any relevant documentation (such as permits, licenses, or regulatory applications) obtained at the start of the project, or on an ongoing basis, to demonstrate this compliance. Depending on the methodology used, additional evidence may be required to confirm adherence to regulations specific to the project’s technology type.

Environmental and social risk assessment

Project Developers shall assess material risks of negative environmental and social impacts or adverse outcomes that could potentially occur across the entire project scope (e.g., onsite, upstream, and downstream). The minimum list of safeguard principles and their general requirements listed in Table 1 below shall be evaluated for all projects, alongside any technology-specific requirements outlined in an applicable methodology. Risk assessment includes the following steps:

  1. Any identified negative environmental and/or social impacts or adverse outcomes shall be clearly documented in the PDD.

  2. Project Developers shall take measures to minimize and address these impacts in the project design, and document these mitigation measures in the PDD.

  3. Identified impacts and mitigation measures shall also be included in the Monitoring Plan, to ensure they are continuously tracked, addressed, and minimized throughout the project lifetime.

  4. Monitoring results shall inform project adaptation strategies to enhance environmental and social performance over time.

Project Developers shall complete the methodology’s Risk Assessment Template for their project type, evaluating the likelihood and severity of all potential negative impacts or adverse outcomes that could result in violations of safeguard principles or misalignment with their associated requirements.

Risk assessment

Risks are identified in Risk Assessment Templates, which are provided in each methodology and tailored to the given project type. These templates guide Project Developers in evaluating the likelihood and severity of each risk type. Project Developers must assess the likelihood and severity scores of each risk for their specific project. This is completed during the validation step, and presented in the PDD. The Risk Assessment Template is composed of two parts:

  • The Reversal Risk Evaluation section covers carbon reversal risks, and responds to the Durability criteria. This is evaluated to identify and mitigate potential reversal risks. Reversal risks may include social, economic, natural, and delivery risks.

  • The Environmental and Social Evaluation section covers risk of environmental and social damages, and responds to the Environmental and Social Do No Harm criteria. This is evaluated to transparently identify environmental and social risks, and determine which risks shall be monitored on an ongoing basis.

Each identified material risk (defined as issues with a risk score of moderate or higher) is subject to creation of a risk mitigation plan, developed by the Project Developer, that details the long-term strategies and investments for preventing, monitoring, reporting and compensating carbon removal reversal and/or environmental and social damages.

Note that some risks shall be monitored and reported regardless of the risk score. This are defined at the methodology level, and include technology-specific risks that are particularly sensitive, likely, or variable, and/or subject to project design requirements.

Table 1 The minimum list of safeguard principles and their associated requirements, to be evaluated for all projects.

Safeguard Principle
Associated Requirements

Labor rights and working conditions

  • provide safe and healthy working conditions for employees

  • provide fair treatment of all employees, avoiding discrimination and ensuring equal opportunities

  • prohibit the use of forced labor, child labor, or trafficked persons, and protects contracted workers employed by third parties.

Resource efficiency and pollution prevention

  • minimize pollutant emissions to air

  • minimize pollutant discharges to water, noise and vibration

  • minimize generation of waste and release of hazardous materials, chemical pesticides and fertilizers

Land acquisition and involuntary resettlement

  • minimize forced physical and/or economic displacement

Biodiversity conservation and sustainable management of living natural resources

  • avoid and/or minimizes negative impacts on terrestrial and marine biodiversity and ecosystems

  • protect the habitats of rare, threatened, and endangered species, including areas needed for habitat connectivity

  • do not convert natural forests, grasslands, wetlands, or high conservation value habitats

  • minimize soil degradation and soil erosion

  • minimize water consumption and stress in the project

Indigenous Peoples (IPs), Local Communities (LCs), and cultural heritage

  • recognize, respect and promote the protection of the rights of IPs & LCs in line with applicable international human rights law, and the UN Declaration on the Rights of Indigenous Peoples and ILO Convention 169 on Indigenous and Tribal Peoples

  • identify the rights-holders possibly affected by the mitigation activity (including customary rights of local rights holders);

  • when relevant, apply the FPIC principles through the stakeholder consultation process, described below.

  • do not force eviction or any physical or economic displacement of IPs & LCs, including through access restrictions to lands, territories, or resources, unless agreed upon with IPs & LCs during the FPIC process

  • preserve and protect cultural heritage consistent with IPs & LCs protocols/rules/plans on the management of cultural heritage or UNESCO Cultural Heritage conventions

Respect for human rights, stakeholder engagement

  • avoid discrimination and respect human rights

  • abide by the International Bill of Human Rights and universal instruments ratified by the host country

  • take into account and responds to local stakeholders’ views

Gender equality

  • provide for equal opportunities in the context of gender

  • protect against and appropriately responds to violence against women and girls

  • provide equal pay for equal work

Stakeholder consultation

Project Developers shall engage with all relevant local stakeholders who may be directly or indirectly affected by the project’s design, development, implementation, or operations. The goal is to inform stakeholders of project details, gather feedback, ensure their views are considered, and establish a pathway for communication or grievances throughout the project lifetime.

Project Developers shall thoroughly identify and document all relevant stakeholders. Types of relevant stakeholders vary by project, and may include but are not limited to:

  • Local, regional, or national government bodies

  • Community members and groups

  • Neighboring industrial or commercial sites

  • NGOs, CBOs, and other social organizations

  • Landowners or land users impacted by the project

  • Indigenous peoples (IPLC, if involved, Free, Prior, and Informed Consent FPIC must be followed)

The stakeholder consultation process shall include a communication letter sent to all relevant stakeholders and at least one meeting with stakeholders.

The communication letter may follow the Rainbow template, shall be sent at least 14 days before the meeting, and shall contain at least the following information:

  • A summary of the project and mitigation activity

  • Project location and expected start date

  • Key anticipated impacts (positive and negative)

  • Meeting invitation

  • Project Developer contact information and grievance mechanism.

Language, cultural context, and accessibility must be considered. Where relevant, Project Developers are encouraged to use other appropriate methods of communicating with stakeholders, such as letters, calls, posters, announcements, or local media.

The meeting must be hosted in a format that is appropriate and accessible to stakeholders. During the meeting:

  • Project details and expected carbon revenue must be presented

  • A forum must be provided for feedback, concerns, and suggestions

  • All comments must be addressed, and responses recorded

  • Meeting minutes must document attendance, shared information, feedback, and responses

  • The project’s grievance mechanism must be explained

  • It is strongly recommended to provide a meeting recording and/or transcript

Following the meeting, Project Developers shall evaluate stakeholder feedback and incorporate changes into the project design where appropriate. All feedback, responses and resulting project changes must be documented in a separate report made publicly available with other project documentation.

Additionally, a 30-day public comment period shall be open on the Rainbow Registry for every project during validation, where stakeholders can review project details and provide feedback. This feedback is gathered by the Rainbow team and shared with the Project Developer, who shall evaluate all stakeholder feedback, incorporate changes into the project design where appropriate, and document all feedback and resulting changes in the publicly available project documentation. If no feedback is received, this must be clearly stated in the public documentation available on the Rainbow Registry.

If a stakeholder consultation has already been conducted (to obtain a permit for instance), Project Developers may submit the existing stakeholder consultation in lieu of conducting a new one. In this case, Project Developers shall submit proof that the previous stakeholder consultation met the requirements herein, including a list of stakeholders, proof of meetings, results, outcomes, and proof that contact information was shared for a grievance mechanism.

The stakeholders identified and all outcomes of stakeholder consultation shall be included in the PDD.

All interested parties and stakeholders are encouraged to continuously provide any feedback or raise concerns about projects certified under the Rainbow Standard. They can do so by email at [email protected], or via this form.

Project activities that use or share land, resources, and/or knowledge with / (IPLCs) shall comply with the following free, prior and informed consent (FPIC) principles. These principles shall be incorporated into the stakeholder consultation procedure in an explicit and separate FPIC section.

  • Free: IPLCs are free to decide/consent selling/share of their land, resources and traditional knowledge. IPLCs are not forced to make a decision or give consent through coercion, intimidation or other means, regardless of the decision to give consent.

  • Prior: Any consent that is sought from IPLCs is sufficiently ahead of time in relation to project start date. This time allows IPLCs to discuss and decide within their own community-oriented processes.

  • Informed: IPLCs are provided with all relevant information about the project. This includes but is not limited to potential sharing of resources, traditional knowledge, expectations from IPLCs, and any potential environmental and social risks of the project.

  • Consent: IPLCs consent to the project activity or reject it, a decision made through their community consultative process. The consent given is not of an individual but “collective”, i.e., given by the community. The decision may be communicated via the leaders or representatives of the IPLCs.

Benefit sharing

Where projects include IPLCs, the project shall have a benefit sharing mechanism with the IPLCs. Benefits of the project shall be shared equitably with the IPLCs. Benefits from the project include but are not limited to services and products produced by the projects, and revenues from sales of carbon credits.

Where the project includes sharing of resources with the IPLCs (such as produce from traditional or community forests) or use of traditional knowledge of the IPLCs, the IPLCs shall be provided with appropriate compensation and recognition.

The benefit sharing procedure shall be documented in the PDD upon validation, and updated in the monitoring report at every verification audit.


Co-benefits

Projects should have a positive systemic impact by providing environmental and social benefits along with their climate benefits. The United Nations Sustainable Development Goals (UN SDGs) are used as a framework to measure co-benefits. Co-benefit claims made by projects are real and audited.

Projects should support at least two quantifiable and verifiable environmental or social co-benefits, aligned with the UN SDG framework. If a Project Developer claims co-benefits, these:

  • must be in addition to climate benefits already accounted for in the issuance of RCCs, and

  • must be positive environmental or social impacts that are substantial and additional.

Claimed co-benefits shall be quantified and audited by a VVB using one of the following methods:

  • the project’s GHG quantification results, calculated using the Rainbow MRV platform and the corresponding methodology quantification model,

  • primary data collection from the project (e.g. value displayed on an invoice),

  • an LCA of the project or similar technology, or

  • other reputable scientific documents, calculated by the Project Developer in a separate file and shared with the VVB and the Rainbow team.

Project Developers shall provide information in the PDD on any standardized tools and methods that were used to assess the co-benefits.

All claimed co-benefits shall be monitored by the Project Developer. They shall be:

  • included in the project’s Monitoring Plan,

  • updated with supporting evidence at each credit verification, and

  • audited by a third-party VVB.


Leakage

Carbon leakage refers to the displacement of emitting activities from the project scope to areas outside the project scope, resulting in an indirect transfer of GHG emissions rather than the absolute avoidance/removal of emissions. Types of carbon leakage include:

  • Activity shifting: carbon-emitting activities are geographically displaced or relocated to areas outside the project boundaries as a direct result of the project's implementation.

  • Upstream and downstream emissions: emissions are displaced to other locations or activities upstream or downstream in the supply chain, or elsewhere within the project scope. The comprehensive life cycle assessment approach used for Rainbow GHG reduction quantification considers upstream and downstream emissions as part of the project scope. Therefore, these emissions are included by default in the project’s GHG reduction quantification.

Mitigation activities shall not cause emissions to materially increase elsewhere. Methodologies shall provide requirements for identifying, assessing, mitigating, and where necessary, deducting leakage emissions.

Project Developers shall conduct a project-specific leakage assessment, and document the identified sources of leakage and management strategies in publicly available project documentation.


Traceability

Project information must be easily traceable and publicly documented. This ensures transparency, accountability and rigor at Rainbow, and contributes to a more robust VCM.

Site registration

All sites where the project operates shall be registered during the certification process. This includes all factories, facilities, or operations under direct control of the Project Developer, whose activities are involved in RCC verification and issuance. Site registration procedures are detailed in the Rainbow Procedures Manual.

Upstream and downstream actors in the supply chain are not counted as project sites.

To register sites, Project Developers shall fill in the Rainbow Site registration template, and shall include the site’s:

  • purpose

  • relationship to the project

  • street address or, if not available, GPS coordinates

  • reference person

  • contact information

  • host country

No scheme hopping

Project Developers shall disclose if they or their are currently certified under another standard or registry, which would render the project ineligible under the Rainbow Standard.

Project Developers shall disclose if they have applied for certification under another standard or registry in the last 5 years. If so, they shall inform Rainbow:

  • if they were validated and issued credits, they shall provide auditing reports for the last 2 verification audits under the other standard/registry, including any decision to suspend or withdraw certification, and shall provide proof of deregistration from the other standard/registry.

  • if they were rejected for validation as a result of the validation audit under another standard or registry, Project Developers shall provide a valid reason unrelated to project integrity issues (e.g. the methodology was discontinued by the other standard). Otherwise, the project is ineligible under the Rainbow Standard.

  • if they were validated but withdrew before the first verification audit, Project Developers shall provide a valid reason unrelated to project integrity issues (e.g. the methodology was discontinued by the other standard). Otherwise, the project is ineligible under the Rainbow Standard.


Delivery

Delivery requirements ensure that project mitigation activity occurs as expected. For credit issuance and verification, the project mitigation activity must be ex-post.

These requirements ensure the project is real, it operates with the scale and procedures described by the Project Developer, and transparently assesses and reports delivery risk.

Feasibility

Project Developers shall prove that the project is feasible, likely to occur as expected in a continuous manner, and poses little delivery risk. Project Developers shall assess their project's feasibility by transparently discussing and proving:

  • their (TRL)

  • acquisition and sourcing of key inputs (e.g. feedstock, machinery)

  • demonstrate internal expertise to carry out project activities and monitoring.

Site audit

Projects shall undergo a site audit according to the procedure outlined in the Procedures Manual. The purpose of this site audit is to confirm that:

  • The project exists and is functional

  • The scale of the project is in line with the description

  • Key processes operate as described in the project PDD.

Monitoring

Project Developers shall monitor and report ongoing key parameters about their activities, with proof, to demonstrate that:

  • the ex-post mitigation activity has occurred,

  • the GHG quantification and credits issued are accurate and real,

  • the project's ongoing compliance with the Rainbow Standard Rules and the relevant methodology.

These key parameters, which must be regularly tracked and reported, shall be defined in each project's Monitoring Plan in the PDD. Each methodology defines the minimum requirements for a Monitoring Plan, and individual projects may have include additional parameters to monitor.

Parameters to include in the Monitoring plan:

Monitoring Plans shall include parameters that are:

  • material to GHG quantification,

  • critical for determining project eligibility,

  • quantify the claimed co-benefits.

These may include but are not limited to quantitative values, categorical data, qualitative criteria, descriptive parameters, or justification of procedures.

Information to include per parameter:

Monitoring Plans shall include the following information for each monitored parameter:

  • monitoring frequency

  • emission sources and sinks

  • data source

  • measurement methods/procedures, and their accuracy and calibration

  • quality assessment or quality control procedures

  • responsible party for collecting and archiving data

The Monitoring Plan is created during the project validation stage. It shall be created by the Project Developer (adhering to the minimum requirements for a Monitoring Plan in the given methodology), approved by the Rainbow team, and audited by a VVB during the validation audit.

Parameters in the Monitoring Plan shall be regularly monitored by the designated responsible party, and submitted in the Monitoring Report for each monitoring period, accompanied by verifiable proof. These parameters and their proof are verified by third-party VVBs for every issuance of RCCs.

A project's Monitoring Plan may be revised during the crediting period if the Project Developer proposes a modification. Any such change must be approved by the Rainbow team and audited by a VVB to ensure continued compliance with the methodology and the Rainbow Standard Rules.

Last updated