Registry requirements
User roles and access control
Roles & Permissions
The Rainbow Registry has the following four distinct user roles, which are built into the technical specifics of the registry and cannot be bypassed.
Registry administrator
The registry administrator has the highest level of permissions, including the management of RCCs, projects, and users. This role is held by the Secretariat.
Certification
The Rainbow Certification team is responsible for creating and managing projects within the registry. They issue and cancel RCCs. They upload project-related files and update project statuses.
Account holder
Account holders (such as developers or buyers) have the authority to hold RCCs in their accounts and manage them (i.e., through transfers and retirements).
Validation/Verification Body (VVB)
Independent third-party entities accredited to validate and verify project performance.
Account holder types
Account holder organizations on the Rainbow Registry are limited to one of the following account holder types:
General Account (Buyer)
Organizations interested in purchasing Rainbow Carbon Credits for offsetting or sustainability reporting.
View and purchase Rainbow Carbon Credits
Access transaction history
Not allowed to issue or list projects
Project Developer
Organizations responsible for developing carbon credit-generating projects following Rainbow methodologies.
List and manage project activities
Submit documentation for issuance of Rainbow Carbon Credits
View credit status, issuance, and retirements
Retire, transfer and sell carbon credits from managed projects.
Trader
Organizations authorized to engage in the buying and selling of carbon credits (including brokers and agents).
Buy, hold, transfer, and sell carbon credits on behalf of themselves or a Project Developer
Must have valid and current authorization from the Project Developer
Not allowed to issue or list projects
Individual/natural person accounts are not permitted under any of the categories.
Account creation
Account Holder
Account holders shall accept the Terms of Use and go through KYC and AML assessment.
To open an account, the organization must submit all required documentation and identification information to Rainbow, including:
Account holder type
Legal entity name
Organization registration number
Organization phone number
Registration address (postal code, city, address)
Country
Industry/Sector
Website
VAT number (if relevant)
Requests shall be sent through the website here or via email at [email protected].
Following document verification, and confirmation that the organization is an eligible Account Holder type, Rainbow will submit KYC and AML assessment materials to the organization.
Once the KYC and AML procedures are successfully completed, Rainbow will activate the account. Rainbow reserves the right to refuse account creation at its sole discretion.
User account
Once the Account Holder account is approved, user accounts within that organization may be created. The organization is responsible for:
Creating and managing user access within its organization account
Ensuring that each user operates under the appropriate role
Promptly revoking access when a user no longer represents the organization
Each User must act on behalf of their organization and may not use the registry for personal or investment purposes.
User responsibilities
All users must:
Use their credentials securely and not share them
Comply with Rainbow Standard Rules, Procedures Manual and applicable laws
Avoid misuse of the platform (e.g., fraudulent activity, promoting unrelated services, system interference)
Rainbow conducts periodic reviews of access rights and user activity. Rainbow may suspend or terminate access in cases of non-compliance, fraud, revoked authorization, or any activity that brings the platform into disrepute. Account Holders are expected to:
Review and update their user lists regularly
Notify Rainbow of any changes in user roles or legal authorizations
Project documentation
The Rainbow Registry is the central platform for publishing project information, ensuring transparency, traceability, and accessibility. All projects must provide a minimum set of publicly available information on their registry page. This information may appear directly on the registry page, or within documentation linked from it, as detailed in below sections.
Exceptions apply if disclosure is restricted by confidentiality, proprietary rights, privacy laws, or data protection regulations.
Information on the registry
The following information shall be available directly on the Rainbow registry for each project:
the name and type of the project
name and contact details of the Project Developer
the applicable methodology and version number
the location of the activity, including the geographically explicit location of the activity boundaries, respecting 1:5000 mapping scale requirements
the duration of the monitoring period and crediting period, including the start date and end date
compliance with any accreditation or regulatory schemes such as CRCF, ICVCM, CORSIA...
quantified co-benefits
type of credit (e.g. removal vs avoidance)
durability in years (if applicable)
certification status, including certificates of compliance and validation and verification audit reports
GHG quantification results (i.e. without application of the buffer pool and discount factor)
quantity and status of RCCs (e.g. issued, retired, expired, cancelled or allocated to a buffer)
end-use of the certified units, and the entity that uses the certified units.
Project documents publicly available on the registry
The following information must be publicly accessible in linked project documents available on the registry:
Demonstration of project compliance with the Rainbow Standard Rules and the applicable methodology. This includes, at a minimum:
Additionality template
ESDNH risk assessment template
Stakeholder consultation process and outcome
Sufficient detail on the quantification of issued RCCs to allow independent replication of calculations at validation and for all subsequent verification events/credit issuances, including but not limited to quantification spreadsheet exports displaying:
calculation formulas
default values/secondary data
assumptions, and
project input data/primary measurements.
The Audit Reports of every project validation and verification audit
The Project Design Document (PDD) and any subsequent Monitoring Reports, with the following minimum content:
Commercially sensitive information may be redacted from publicly available documentation, where it can be proven that disclosure of such information is harmful. Such redaction shall be approved by the Rainbow team, and the information shall always be provided to the VVB.
Procedure for requesting non-public information
A thorough description of the project’s design, implementation, and assessment findings must always be publicly disclosed. However, the primary proof supporting these assessments (such as raw monitoring data, internal reports, or proprietary models) may contain commercially sensitive or confidential information. These documents are not required to be made publicly available, but must be listed in the PDD and/or Monitoring Reports as proof, and made available to the VVB and the Rainbow team.
Stakeholders may request access to non-public documents by contacting either the Rainbow team at [email protected] or the Project Developer via the contact details listed on the project page.
If the request is made to the Rainbow team, they must forward it to the Project Developer within 5 working days. Access must be granted if the information can be shared without:
violating licensing agreements,
disclosing commercially sensitive information,
violating privacy and data protection restrictions, or
where it cannot be proven that disclosure of such information is harmful.
The Project Developer must respond to the requester within 10 working days, either by granting access or providing a justification for non-disclosure.
Registry IT security
Security standards
The following security measures are the minimum requirements for the Rainbow Registry:
Data transfers shall always use industry-standard encryption technology (SSL/TLS/HTTPS).
Application authentication shall be enabled and verified by a third-party provider that meets industry best practice, is internationally recognized, and is ISO27001 certified.
Backend service and database hosting shall be enabled by a third-party provider that enables encryption.
Administrative tools shall be provided 2FA for admin authentication and sign-in.
Security audit
The Rainbow Secretariat shall verify at least twice per calendar year that the IT security requirements are met, and summarize the findings in a report made publicly available on the Rainbow website. The following elements shall be verified:
Verify compliance with the above requirements
Verify security vulnerability status and upgrade all JavaScript dependencies with npm.
Review Authentication provider access
Review Cloud provider IAM accounts and access
Rotate database passwords, API keys (internal and external)
Review Database connection allowlist
Review repository history for leaked secrets
Verify application authorization rules
Incident procedures
Incident definition
A technological incident is defined as:
Theft or loss of data
Transfer of data to those unauthorized to receive it
Attempts to gain unauthorized access to Rainbow data or systems
Unintended disruption of the availability of Rainbow systems
Other significant events or bugs that compromise Rainbow's position as a trusted actor in the VCM ecosystem
Reporting incidents
The general public is encouraged to report suspected incidents or vulnerabilities to [email protected]
Employees shall report incidents to the internal Rainbow oncall engineer, [email protected], or to their manager
Incident response
Within one working day (24 hours) of being informed of a suspected incident, the oncall engineer shall confirm reception of the incident report and begin an investigation to verify and assess the scope of the issue.
If the engineering oncall finds that the issue qualifies as an incident, they shall set up a dedicated channel to coordinate a response, including members of relevant teams as dictated by the nature of the problem.
The response team shall then work to contain, eliminate and then recover from the problem as their highest-priority task.
The response team shall communicate information about the incident to all relevant parties affected by the incident, including but not limited to clients, certifying bodies, employees, during and after recovery.
The response team shall hold a post-mortem meeting to deeply understand the underlying causes of the incident and plan proportional follow-up tasks to prevent similar failures from happening in the future. Findings from the post-mortem shall be shared internally or externally as appropriate.
Last updated