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.

Project Developers that seek to issue credits eligible as emissions units for the Carbon Offsetting and Reduction Scheme for International Aviation (CORSIA) or Article 6.2 of the Paris Agreement must also comply with Rainbow's CORSIA and Article 6procedures.

Project Developers that seek to issue credits that comply with the EU Carbon Removals and Carbon Farming (CRCF) Regulation (EU/2024/3012) must also comply with Rainbow's CRCF Requirements.

Additionality

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

All projects shall prove their additionality by meeting the requirements of at least three additionality tests:

regulatory surplus analysis,
common practice analysis, and
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 scope 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 avoidance/removals than what is required by regulations. In this case, only the project activities that surpass the mandated amount are eligible for RCCs.
If regulations promote or subsidize technologies, set targets for increased adoption of a technology, or otherwise support the technology, the resulting lower baseline scenario emissions shall be explicitly considered and accounted for in the establishment of the baseline scenario.

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

Upcoming regulations include those that are confirmed and set to go into effect within 5 years.

Common practice analysis

Mitigation activities shall not already be common practice. Project Developers shall demonstrate that the mitigation activity is not common practice using the Market prevalence rate or Small number of peers approaches detailed below.

Methodologies may specify the required method, indicator, or further conditions for the common practice analysis. In the absence of methodology specific requirements, Project Developers may use any of the methods below, provided it is relevant for their application and conservatively applied.

All common practice analyses shall:

Use the most recent available data.
Define a geographic scope that is relevant and conservative.
Document all assumptions and data sources transparently.

Market prevalence rate

Calculate the portion of the current or potential market that the project activity and other actors carrying out the same activity have collectively reached. Two variants are available:

Total market prevalence rate: the share of the current total market for the same function, service, or output that is met by the mitigation activity.
Target market prevalence rate: the share of the realistic potential market for the mitigation activity that the activity already makes up.

Steps:

Define the mitigation activity, its main function or output, and the geographic scope of the analysis.
Define the denominator:
- For total market prevalence: the current total market for activities serving the same function or producing the same output, at a comparable level of service.
- For target market prevalence: the realistic addressable market for the mitigation activity, taking into account technical, economic, geographic, regulatory, and behavioral constraints on uptake.
Define the numerator using the same units and scope as the denominator: the current deployment of the mitigation activity, including uptake of the same activity type by other actors in the geographic area. Document the criteria used to identify the same activity type (e.g. technology, feedstock, end use).
Calculate the prevalence rate as numerator divided by denominator.

Rules common to both variants:

The indicator may be a count (sites, facilities, companies, units sold) or a capacity, output, or performance metric.
The analysis may consider current cumulative stock or recent uptake over a defined period (e.g. uptake over the last three years).
Exclude from both numerator and denominator any activities already registered for carbon credit issuance under Rainbow or another carbon standard.
A total market prevalence rate below 20% demonstrates that the activity is not common practice. Methodologies may set lower rates.

Examples: total market prevalence rate

Denominator (current total market for the same function or output):

Electronic device refurbishing: total devices of the relevant category sold annually in the area.
Biochar production: total annual biomass residues managed by any means in the area (tonnes biomass).
Enhanced rock weathering: total annual farmland area receiving any soil amendment (hectares).

Numerator (mitigation activity and other actors doing the same):

Electronic device refurbishing: refurbished devices of the relevant category sold annually.
Biochar production: biomass residues converted to biochar via pyrolysis annually (tonnes biomass).
Enhanced rock weathering: farmland area receiving silicate rock dust application annually (hectares).

Examples: target market prevalence rate

Denominator (realistic addressable market for the activity):

Biobased construction: new-build and major-retrofit floor area where bio-based insulation is technically and economically substitutable for conventional insulation
Biochar production: annual biomass residues technically and economically available for pyrolysis, given feedstock logistics and end-use demand (tonnes biomass).
Enhanced rock weathering: farmland area whose soil chemistry, crop types, and farm economics make ERW feasible (hectares).

Numerator (current deployment of the activity):

Biobased construction: Actual m² of bio-based insulation installed annually in the defined addressable market.
Biochar production: actual annual biochar production today (tonnes biomass converted).
Enhanced rock weathering: farmland area under ERW today (hectares).

Small number of peers

Where the mitigation activity is early in deployment and total or target market data are unreliable or unavailable, common practice may be assessed by counting comparable peer activities in the geographic area. If 3 or fewer comparable peer activities are identified, the mitigation activity is considered not common practice.

A comparable peer activity is one that:

Is located in the geographic area of the analysis
Produces the same output or delivers the same function as the mitigation activity
Began commercial operation before the Project start date.

The definition of "the same" output and function used to identify peers shall be conservative, and broad enough that the assessment reflects the genuine prevalence of the activity type, not a narrow technical subset. Project Developers shall document and justify the level of specificity used. Distinctions that may be considered material include but are not limited to:

Energy source or fuel used
Feedstock characteristics
Market and policy conditions at the time of the investment decision (e.g. subsidies, regulatory frameworks, technology access)
Level of investment cost per unit of capacity or output.

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. For investments in expansion, only the additional avoided or removed carbon enabled by the expansion shall be eligible for Rainbow Carbon Credits.

Investment analysis shall be done using either:

Benchmark analysis: Compute a financial indicator for the project against a benchmark hurdle rate, with and without carbon finance. Demonstrate that:

the mitigation activity would not meet the required financial benchmark without carbon credit revenues, and
carbon finance can raise the economic performance at or above the required financial benchmark, and
economic performance of the mitigation activity increases decisively through carbon finance.

Choose a financial benchmark that is consistent with the weighted average cost of capital (or the cost of equity, as applicable) that is commonly applicable to the country, sector and type of mitigation activity.

Comparison analysis: Compute a financial indicator for the project and for each alternative scenario. Demonstrate that:

the mitigation activity would not be the economically most attractive scenario in absence of carbon credits, and
competitiveness with alternative scenarios increases decisively through carbon finance.

Ensure the alternative scenarios considered are mutually exclusive and provide the same type of products or service levels as the mitigation activity, where applicable

Project Developers shall conduct one of the above analyses and provide the accompanying spreadsheet and calculations, meeting the following requirements:

Include all of the project's funding sources, including government subsidies.
Provide project costs and revenue with actual financial results as much as possible, plus well documented, reasonable and conservative assumptions where necessary.
Provide the fraction of total project expected revenue from carbon finance (for informational purposes only).
Perform a sensitivity analysis, by increasing and decreasing the value of key input data points by 20%, and recalculating the financial indicator. Confirm that the original conclusion holds across all scenarios, and the project remains additional under each tested realistic condition.
Document and explain the assumptions and conclusions underpinning the analysis.
Demonstrate that the assumptions, data and conclusions in the investment analysis or business plan are consistent with information presented to the company’s decision-making management and investors/lenders.
Use parameters and assumptions that are internally consistent with one another (e.g., cash flows expressed in either real or nominal terms consistently), and perform calculations that are consistent with the indicator used (e.g., project IRR or equity IRR)
For retrofit or expansion projects, prove that revenue from the existing operations would not have been sufficient to finance the project.

Methodologies may provide further requirements on which financial indicators shall be used. If Project Developers use either the project’s Internal Rate of Return (IRR) or Net Present Value (NPV), with and without carbon finance as the basis for investment analysis, the calculations shall meet the following requirements:

Calculations shall reflect the period of expected operation of the project activity, or shall be a period of at least ten years, and not the crediting period.
Fair value of project activity assets at the end of the assessment period should be included as a cash inflow.
Depreciation and other non-cash items should be added back to net profits for calculating financial indicators.
Cost of financing expenditures should not be included in calculations.
In equity-based calculations, only the portion of investment costs financed by equity shall be considered as the net cash outflow.
Appropriate benchmarks (for IRR) or discount rates (for NPV) shall be selected and justified based on the type of calculation performed.
Market return values shall be selected and justified for the calculation of equity cost.

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. Barriers shall be categorized as either:

Financial (e.g. lack of access to loans or other forms of financing)
Institutional (e.g. the investor not being the beneficiary of cost savings associated with the investment)
Information (e.g. households not aware of life-cycle costs of efficient appliances)

Project Developers shall identify, describe and quantify the barrier, with verifiable proof. Proof may include independent studies, publicly available surveys, relevant market data, or data from national or international statistics. 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, and
all proof are interpreted and applied conservatively,
in case of uncertainty in the level of the identified barrier, the proof and indicators shall be interpreted to assure that it is very unlikely that the effect of the barrier is overestimated.

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 avoided or removed carbon enabled by the expansion shall be eligible for Rainbow Carbon Credits.

GHG quantification

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

Durability

Durability requirements ensure that GHG avoidance 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 avoidance 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 tCO₂eq. Reversals can result from natural disturbances or project mismanagement, and be avoidable or unavoidable.

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)
Carbon storage in long-lived products
Accelerated mineralization
Enhanced rock weathering

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

This includes activities such as:

conservation and avoided conversion (e.g., grassland/rangeland management, avoided deforestation)
agriculture soil carbon sequestration
forestry sequestration (improved forest management, afforestation/reforestation, agroforestry)
wetland and marine ecosystem restoration/management (including seagrasses, saltmarshes, mangroves, peatlands)

Such activity types are not currently covered by Rainbow. If Rainbow develops methodologies for these project types, Rainbow will also develop relevant requirements and procedures for assessment of GHG reversal risk, contribution to buffer pool and any other relevant requirements and procedures.

Durability and reversal risks are not evaluated for avoidance methodologies currently offered by Rainbow, because they are considered to have little to no material reversal risks (e.g. Battery second life, Biogas from anaerobic digestion...).

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 Reversal risk assessment instructions 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.

Reversal risk assessment instructions

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 at validation.

The Reversal Risk Assessment template 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.

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 Rainbow Carbon Credits section of 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.

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.

Project Developers shall outline the risks of double counting for their mitigation activity, and the VVB shall verify the risks and accordingly conduct cross checks across relevant registries and platforms.

Any instances of double counting shall result in the project being suspended and undergoing a review by Rainbow, which may result in deregsitration and/or cancelation of credits.

Double issuance

Project Developers shall not issue carbon credits for their mitigation activity for the same monitoring period, under a different project at another crediting program or Rainbow.

If a project is registered with Rainbow to issue RCCs, and also registered (or seeking registration) with another crediting program, the Project Developer shall disclose this with Rainbow, including the following details:

Complete name of the project
Date of the registration of the project
Link to the publicly available registry of the crediting program
Vintage and serial number of the credits issued with the crediting program
The geographic and operational boundaries of the project scope registered under each program.

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 Double Counting requirements outlined in the present document.

Rainbow shall perform a double-registration check before registering any project, to ensure they are not already registered for the same mitigation activity under another crediting standard.

If a project transfers from another crediting program to the Rainbow registry, the monitoring period shall not overlap. The Project Developer shall provide follow the deregistration procedure and 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 Rainbow Carbon Credits 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),
Carbon Offsetting and Reduction Scheme for International Aviation (CORSIA),
national climate policies and emissions trading schemes, or
other GHG-related environmental credits.

See the Procedures Manual for the detailed authorized uses of retired credits.

Project Developers shall prove that credit issuance for their mitigation activity is compatible with a transition to net zero by reference to the net zero objectives of the host country. This includes but is not limited to proving that credit issuance for the given authorized credit use is allowed by the project's host country.

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 General Terms of Arc Platform (Certification Platform), where all Project Developers agree to follow the requirements outlined in the present document.

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.

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.

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:

Any material negative environmental and/or social impacts or adverse outcomes shall be clearly documented in the PDD.
Project Developers shall take measures to minimize and address these impacts in the project design, and document these mitigation measures in the PDD.
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.
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. Available risk assessment templates can be found in each methodology and grouped in this page.

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 hello@rainbowstandard.io, or via this form.

Project activities that use or share land, resources, and/or knowledge with indigenous people/local communities (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.

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,
be positive environmental or social impacts that are substantial and additional, and
if applicable, include any SGD indicators that are required by the host country.

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.

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.

Projects shall minimize leakage, where carbon-emitting activities are geographically displaced or relocated to areas outside the project boundaries as a direct result of the project's implementation.

Project Developers shall perform a robust leakage assessment, mitigate any identified leakage, and justify any steps taken to do so. Any material sources of leakage identified shall be quantified or conservatively estimated and deducted in the project GHG quantification. Material sources of leakage shall be monitored and added to the project's Monitoring Plan.

Project Developers shall follow any further methodology-specific instructions to conduct their project's leakage assessment, and document all of the above-mentioned steps to manage leakage risks in publicly available project documentation.

For activities that physically replace or decommission baseline equipment, methodologies shall outline requirements to quantify any leakage emissions from disposal and continued use of baseline equipment outside the project boundary (unless under the GHG quantification cutoff). Methodologies may require such baseline equipment to be destroyed, decommissioned, or otherwise phased out.

Projects are ineligible if their quantified leakage impacts exceed:

20% of total induced emissions for avoidance credit calculation or
20% of gross removals for removals credit calculation.

Upstream and downstream emissions can be considered a form of leakage, and are already accounted for in the Rainbow GHG quantification requirements. The comprehensive life cycle assessment approach 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.

Only net-negative leakage impacts shall be counted towards the project's GHG quantification (i.e. those that result in higher climate change impact, and fewer RCCs issued). Any net-positive leakage impacts may be treated as co-benefits.

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 legal predecessor 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 within the past 3 years, 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 within the past 3 years, 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 technology readiness level (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 to demonstrate that:

the ex-post mitigation activity has occurred,
the GHG quantification and credits issued are accurate and real,
any mitigation measures established in the Environmental and social risk assessment are implemented,
any measures established in the Reversal risk assessment are in place,
any claimed co-benefits are quantified and verifiable,
the project's ongoing compliance with the Rainbow Standard Rules and the relevant methodology.

First, at validation, Project Developers shall submit a Monitoring Plan to Rainbow and the VVB, outlining the parameters to monitor and procedures for monitoring them. Then, at the end of every monitoring period, when undergoing verification for credit issuance, Project Developers shall submit a Monitoring Report to Rainbow and the VVB that demonstrates the execution of the Monitoring Plan and provides the monitored parameters and information.

Monitoring Plan

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 and outlined below. It shall be approved by the Rainbow team, and audited by a VVB during the validation audit.

Upon submission at validation, Monitoring Plans shall be as complete as possible. If it is not possible to fully complete parts of the Monitoring Plan at validation, incomplete Monitoring Plans may be submitted with proper justification of why they cannot be finalized at that time, clearly identifying any non-final aspects, and plans for how they will be addressed later. The Monitoring Plan shall be completed and finalized by the end of the first Monitoring Period.

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.

Minimum requirements for the Monitoring Plan

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, including but not limited to environmental and social risks and leakage,
critical to confirm the mitigation measures established in the Environmental and social risk assessment are in place,
critical to confirm the measures established in the Reversal risk assessment are in place,
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:

a description of the parameter to be monitored
monitoring frequency
emission sources and sinks
data storage and management plan, including the format, location and duration of data keeping records
Primary data
- description of measurement methods/procedures, and their level of accuracy and calibration procedures
- quality assessment or quality control procedures
- laboratory name and relevant accreditations for any measurement conducted by external laboratories
- responsible party for collecting and archiving data, including how they are assigned/selected, and how their competence to monitor the parameter is assessed
- plan in case of unexpected interruption or errors in monitoring, ensuring conservative treatment of data and an appropriate deduction of emission reductions
Secondary data
- data source and, where applicable, value and frequency of update

Monitoring Report

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.

PreviousProject and baseline scope

NextGHG quantification

Last updated 3 months ago