Rainbow Carbon Credits
Credit attributes
Credit blocks
A credit block refers to a group of Rainbow Carbon Credits (RCCs) that share the same key characteristics. Each credit block contains only RCCs from the same:
project,
mechanism (e.g., avoidance or removal),
vintage year (year of verified carbon impact), and
verification event.
On the Rainbow Registry, each transaction can only involve credits from a single credit block. For example, if credits belong to different credit blocks (e.g., different vintage years or mechanisms), they must be transacted in separate operations.
A project is uniquely described on the registry by:
Project registry ID
Project name
Name of the Project Developer
Location
Host country
Type of mechanism (avoidance and/or removal)
Crediting period
Validation body
Most recent version of the Rainbow Standard Rules and methodology used
Labels where relevant
Each RCC credit block is uniquely described on the registry by:
Credit serial numbers
Number of credits in the block
Project registry ID
Vintage year (year of verified activity in verification)
Type of mechanism (avoidance or removal)
Methodology ID and version number
Rainbow Standard Rules version number
Host country (inherited from Project)
Durability (in years, for removal RCCs only)
Labels where relevant (e.g. CORSIA, Article 6, CCP…)
Labels are supplementary information and do not change the inherent status of a verified avoidance or removal RCC. Labels may cover, for example:
Compliance with trading schemes: e.g. CORSIA eligible, Article 6/PACM eligible
Accredited: e.g. ICROA accredited, ICVCM accredited
Credit serial numbers
Each RCC has its own unique serial number on the Rainbow Registry. Credit IDs are generated using a consistent naming convention with the following components:
Registry identifier:
RIVorRBWCountry code (e.g.
FR,DE)Project ID (internal registry identifier)
Mechanism abbreviated as:
AVDfor avoidanceRMVfor removal
Vintage year (e.g.
2023)Last 5 characters of the issuance transaction UUID
Credit number within the issuance transaction (e.g.
1or248)
RCC status
The Rainbow Registry identifies and tracks the following:
RCC status according to the definitions outlined below
RCC ownership/holding, from issuance to cancellation/retirement.
Rainbow Carbon Credits (RCCs) shall have an assigned status on the Rainbow Registry, including one of the following:
Available
RCCs issued ex-post at the end of the reporting period, following submission of a Monitoring Report and verification audit by a third-party VVB. Available to be transferred and retired.
Retired
Once retired, an RCC and its climate benefit are locked, with its designated purpose for the beneficiary. They are no longer transferable, ensuring exclusivity and preventing any further use or transfer.
Canceled
RCCs that were Available but were found to be invalid (e.g., issued in error, or reversed in the case of removal RCCs. See the Cancelation procedure).
Buffer
Verified removal RCCs issued to the Project Developer account and immediately and automatically transferred to the Rainbow Buffer Pool to cover potential reversal events.
All events (issuance, transfer, retirement, cancellation) shall be recorded on the registry, including the following details:
Transaction ID: unique identification of the transaction
Completed at: date of the event
From: organization initial owner of the units
To: new organization owner of the units
Credit serial numbers
Amount of credits
All events are made public and shall allow for tracking history of ownership of the units.
Discount factor
A fraction of a project’s quantified RCCs may be eliminated using the uncertainty discount factor to mitigate carbon credit overestimation. These verified avoided/removed emissions are never issued as RCCs and will not appear on the registry.
A discount factor shall be applied when material uncertainty is identified in the project's GHG quantification. This may be related to, for example, the project’s measured data, assumptions, or the selection of the baseline scenario.
When material uncertainty is detected:
Steps shall be taken to reduce uncertainty wherever possible.
Conservative choices must be adopted.
If uncertainty remains, a discount factor is applied.
Detailed requirements are provided in the Uncertainty Assessment section of the Rainbow Standard Rules.
The discount factor may vary from 0% to a maximum of 15% of estimated RCCs. If a project requires a discount factor higher than 15%, the uncertainty is deemed too high and the project is not eligible. The specific discount factor value is determined for each project, considering both project-specific uncertainty and the minimum required discount factor defined in the applicable methodology.
Buffer pool
All projects that issue removal RCCs are required to allocate at least 2% of their verified removal RCCs to the Rainbow Buffer Pool. Methodologies may determine a higher minimum buffer pool contribution for projects under them, and/or further instructions for how to determine a project-specific buffer pool contribution amount.
This pool acts as an insurance mechanism against the risk of reversal of sequestered carbon before the agreed upon commitment period. RCCs shall be canceled from the buffer pool if there is a reversal event (see details in the Cancelation section). This may occur due to, for example, natural disaster (fires, drought, pests) or project mismanagement. These RCCs cannot be retired by buyers. The buffer pool is shared across all projects.
The detailed content of Rainbow Buffer Pool is publicly available on the Rainbow Registry.
Issuance
The issuance of RCCs is operated by the Rainbow Certification team once the project's monitoring & verification is conducted, and all Audit Reports are available.
A member of the Rainbow Certification team operates the issuance, and their name is registered and tracked in the Registry.
Upon issuance of removal RCCs, a portion of credits are automatically and immediately transferred from Project accounts to the shared Rainbow Buffer Pool account. The number of RCCs, when calculated as a percentage of the buffer pool contribution, is always rounded up to the nearest whole credit.
All issuance events shall be recorded on the Rainbow registry with at least the following details:
Verified by: Accredited VVB that conducted the audit
Monitoring period: period covered by the issuance
Audit Report: audit report produced but the VVB
The initial owner of all RCCs shall be the Project Developer.
Transfers
Registry users may transfer RCCs between two Account Holders.
Transfer of RCCs are subject to the following rules:
Users can only transfer RCCs that they own; and
Users can only transfer RCCs to Buyers who have an active registry account.
All transfer events shall be recorded on the Rainbow registry with the former owner of the units and the recipient.
The Rainbow registry shall ensure that transactions are secure, with a double validation system, requiring both sender and recipient to acknowledge and validate the transfer.
Rainbow does not allow any transfer of RCCs outside of the Rainbow registry.
Cancelation
RCCs shall be canceled in the event of a reversal or erroneous over-issuance. The cancelation of RCCs is operated by the Rainbow team once a Cancelation Notice is submitted and is validated by the Rainbow Secretariat. The Cancelation Notice shall include:
The project and Project Developer name
Type of credits concerned (vintage, durability, any accreditations/labels)
Reason for the cancelation (reversal or erroneous issuance)
Date, description and type (avoidable or unavoidable) of reversal (if applicable)
Date the Cancelation Notice is sent to Rainbow
Number of credits to be canceled, with quantification and proof
After investigation and compensation by the Rainbow team, a Cancelation Report is generated, stating the party responsible for the compensation.
Canceling removal credits due to reversals
When a GHG reversal is identified, Rainbow shall cancel credits from the buffer pool to compensate for the reversal. A GHG reversal is defined as any event that re-emits at least 1 tCOeq of the carbon removed by the project mitigation activity, before the commitment period ends.
The Project Developer must submit a Cancelation Notice to notify Rainbow within 30 calendar days of becoming aware of the reversal event. Rainbow shall then cancel an equivalent amount of RCCs from the buffer pool, matching the tCO₂eq estimated to have been released in the reversal event. The canceled RCCs must correspond to the same type as the reversed removal RCCs, including durability and labels.
Reversals are classified as avoidable or unavoidable. The replacement of canceled credits in the buffer pool shall be managed according to the procedure in Table 1, depending on the type of reversal.
Table 1 The different types of reversals are defined. In case of any reversal, credits from the Buffer Pool of the same type are canceled to compensate the reversal. The Buffer Pool replacement requirements column outlines the requirements for Project Developers to replace those canceled Buffer Pool credits, depending on the reversal type.
Avoidable
Reversal that
results from actions or omissions within the project’s control,
could have been prevented with reasonable foresight and risk mitigation
typically a result of failure to maintain equipment, follow protocol, or update systems; human error or negligence; or foreseeable and mitigable natural disturbances.
The Project Developer shall fully compensate the cancelled Buffer Pool credits with credits of the same type,
The Project Developer shall do this by either:
transferring already issued credits from their project/s to the buffer pool immediately;
transferring all credits issued in future monitoring periods from their project/s to the buffer pool, or
purchasing credits of the same type, and transferring them to the buffer pool.
Unavoidable
Reversals that
are caused by events beyond reasonable control or prediction,
where mitigation was not feasible or would have imposed unreasonable burden,
resulted from natural disasters (e.g. wildfire, earthquake, extreme weather); pest or disease outbreaks; or policy or regulatory change beyond project control
The Project Developer is not liable for replacing the buffer pool credits.
Classification of a reversal as avoidable or unavoidable will be decided by Rainbow, following inputs from the Project Developer and a VVB.
A Cancelation Report will be generated and attached to the cancelation event in the Registry, that includes the Cancelation Notice provided by the Project Developer, plus a detailed description of the outcome and steps taken to fully compensate the reversal.
Cancelation and insufficient buffer pool size
If the buffer pool holds an insufficient balance of RCCs to fully compensate a project's reversal or erroneous issuance, all subsequent RCCs issued from removals conducted by the Project Developer shall be transferred to the buffer pool and immediately canceled until the full amount of the reversal has been compensated. This requirement applies whether such RCCs originate from the same project or from other projects operated by the same Project Developer.
If the project is not expected to generate sufficient removal RCCs to fully compensate for the reversal during the remaining crediting period (for example, if the project is nearing the end of its crediting period and will not seek renewal), the Project Developer shall procure RCCs of the same type from other projects and transfer them to the buffer pool, where they shall be immediately canceled to offset the reversal.
If the Project Developer ceases operations, Rainbow shall assess and address the situation on a case-by-case basis.
Canceling credits due to erroneous issuance
Verified RCCs may be deemed erroneously issued due to, for example, calculation errors, use of wrong input data, or inaccurate proof. While the comprehensive audit process renders this highly unlikely, a procedure is prepared out of an abundance of caution.
Erroneous issuance may be signaled by the Project Developer, the VBB, the Rainbow team, or any stakeholder by submitting a Cancelation Notice. The Rainbow team shall investigate the incident, determine the number of excess credits issued, and take the following remediating action:
Credits not yet transferred: an amount of credits corresponding to the number of excess credits issued for the given project's credit block shall be frozen during the investigation, and canceled once the Cancelation Report is issued.
Credits already transferred or retired: Rainbow shall notify the Account Holder, and Rainbow shall ensure they are fully compensated with credits of the same type, procured by the Project Developer.
If the Project Developer is deemed responsible for the erroneous issuance, Rainbow shall suspend the project and this Project Developer from further verification, and outline remediation actions for the Project Developer to compensate the erroneous issuance and, if applicable, comply going forward. The Project Developer shall implement the identified remediation action/s within 90 days of notification of suspension.
Failure to do so shall result in the project being de-registered from the Rainbow Registry
Upon resolving or remediating the non-conformities within 90 days, the project is re-registered and is eligible to issue credits in subsequent monitoring periods.
A Cancelation Report will be generated and attached to the cancelation event in the Registry, that includes the Cancelation Notice provided by the Project Developer, plus a detailed description of the outcome and steps taken to fully remediate the erroneous issuance.
Retirements
Retirement marks the final ownership and event for an RCC. By retiring an RCC, the associated climate benefit is locked into a specific accounting purpose, preventing any future use whether by the original owner, the designated beneficiary, or any other party. This guarantees the unit’s exclusivity in its intended claim.
The beneficiary of a retirement is the organization on behalf of whom the RCC was retired, and must be publicly identified on the Rainbow registry. Beneficiaries can be the current holder, or an organization that is specified by the owner of the unit during the Retirement procedure.
Users may request retirements of the RCC owned by their organization, by following the process on the Rainbow registry.
All retirement events shall be recorded with the following additional information shall be required:
Retired by: last known owner of the RCCs
On behalf of: identification of the beneficiary of the the RCCs
Country: location of the beneficiary of the RCCs
Reason: purpose for which the credits were retired;
The retirement certificate, generated automatically on the Rainbow registry, serves as proof of the retirement event, relating to one or more units. Retirement certificates may be downloaded from the registry public page, and shall contain all event details and additional retirement details.
Once RCCs are retired, any event type linked to them shall be prohibited.
Last updated