# ICR Process Requirements v6.0 ![](https://2441265052-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfIdoGcZZdvap67xjb5h1%2Fuploads%2FY48qN7cKjcD1lP2TDHNJ%2F0.png?alt=media) ***Summary*** ICR serves as a framework for *climate projects* of any size, promoting environmental integrity through accelerating credible action and ensuring credibility, consistency, and transparency in quantification, *monitoring*, reporting, *validation*, and *verification* | Version no. | 6.0 | | --------------- | ---------------- | | Date of Version | 15. October 2024 | {% file src="" %} ### Scope This document specifies processes and procedures for *registration* of projects under the *ICR program*. The project cycle, *issuance*, transfers, retirements and cancellations of ICCs. It further specifies *criteria* for transfers of projects from other *GHG programs*, withdrawals from the *ICR program*. In addition, it specifies any assessment of projects, *GHG emission mitigations* adherence to the *ICR program* principles. Other issues addressed are *stakeholders’* engagement, sharing information and exemption requests. ### Normative references * ICR definitions * ICR requirement document * ICR approved methodologies and tools * ISO 14064-2, Greenhouse gases — Part 2: Specification with guidance at the project level for quantification, monitoring and reporting of greenhouse gas emission reductions or removal enhancements. * ISO 14064-3, Greenhouse gases — Part 3: Specification with guidance for the verification and validation of greenhouse gas statements * ISO 14065, General principles and requirements for bodies validating and verifying environmental information * ISO 14066, Greenhouse gases — Competence requirements for greenhouse gas validation teams and verification teams ### Terms and definitions For the purposes of this document, the terms and definitions given in the ICR definitions apply in addition definitions and acronyms from *ISO 14064-2* and *ISO 14064-3* apply. If there exists inconsistency in definitions, ICR definitions prevail. ### Principles The principles of the *ICR program* are adapted from WBCSD/WRI, CDM, and *ISO 14064-2*, *ISO 14064-3* and *ISO 14065*. All *climate projects* shall strive to follow these principles, and methodology development shall adopt these as fundamental principles. Applying the principles is crucial to safeguarding GHG-related information and impact as a true and fair account. The principles are the basis for and will guide the application of the requirements in the *ISO 14064-2*, *ISO 14064-3* and of this document resulting in impactful *climate projects* and solutions. **Relevance -** Use data, methods, criteria, and assumptions that are appropriate for the intended use of reported information. **Completeness -** Consider all relevant information that may affect the accounting and quantification of *GHG emission mitigations*. **Consistency -** Enable meaningful comparisons in GHG-related information. **Accuracy -** Reduce bias and uncertainties as far as is practical/cost-effective. **Transparency -** Provide clear and sufficient information for reviewers to assess the credibility and reliability of *GHG emission mitigations* *claims*. **Conservativeness -** Use conservative assumptions, values, and procedures to ensure that *GHG emission mitigations* are not over-estimated. ***Impartiality*** – Impartial *validation* and *verification* of *GHG emission mitigations* by a competent accredited 3rd party organization. ICR sets further out requirements consistent with the CDM and other *GHG programs* facilitating *registration* of *climate projects* and *issuances* of *carbon credits* that can be traded and used by organizations to contribute to climate actions, to compensating for, and offsetting *GHG emissions*. ### General The International Carbon Registry (ICR) is a GHG program and a comprehensive registry platform that adheres to the principles and goals of the Paris Agreement and the ISO 14064 series of standards, providing a robust framework for managing and validating and verifying *climate projects* and impacts. The *ICR program* is operated and managed by International Carbon Registry ehf. ICR offers a user-friendly registry platform for project proponents to manage the entire lifecycle of *climate projects*, including tracking *carbon credit* inventories, facilitating market reach, and managing *carbon credit* portfolios by organizations. ### ICR projects registrations This document summarizes the ICR processes, i.e., for * *pre-registration* of projects, * registering projects, * issuing ICCs, * conversion of *ex-ante ICCs* to *ex-post ICCs*, * transferring and retiring/cancelling *ex-post ICCs* or other environmental instruments according to the ICR requirement document or other scheme requirements, * Transition from other *GHG programs*, * Withdrawals from the *ICR program*, * Assessment of conformity to *ICR program* requirements, and * Other relevant processes and procedures relating to the *ICR program*. This document intends to serve project proponents, *project developers*, companies, *market participants*, *validation* and *verification* bodies (*VVBs*), and other entities participating in the VCMs. Still, the focus is on project proponents registering their *climate projects*, issuing *carbon credits*, interacting with *VVBs* and ICR. The ICR requirement document, *ISO 14064-2*, and related documents provide rules and requirements for *climate projects* to be eligible for registration. This document, ICR process requirements, complements the ICR requirement document and other normative references. Further, the *ICR registry* user guide provides guidance for users and organizations in familiarizing themselves with the *ICR registry* platform. Projects may have one or more project proponents and may be supported by *project developers* and have more partners. For readability, this document uses *project proponent* in the singular tense, and *project developer* and proponents are not distinct unless specifically addressed. The *project proponent* interacts with ICR when they have project concepts, pre-register projects under development, when undergoing validation, finalizing registering projects post validation, during *issuance* of ex-ante or *ex-post ICCs*, and *conversion* of *ex-ante ICCs* post *verification* of *GHG emission mitigations*. All supporting documentation shall be uploaded to the *ICR registry* by the project proponent, its *authorized representative*, and the *VVB* for any documentation relating to *validation* and *verification*. *Validation* and *verification* bodies (*VVBs*) are responsible for validating *climate projects* and verifying their *GHG emission mitigations*. ICR is responsible for managing the *ICR program*, conducting completeness review, administering registration, *issuance*, conversion of *ex-ante ICCs* to *ex-post ICCs*, and other aspects of administering the *ICR program* and registry as further outlined in the ICR terms and conditions, in ICR terms and conditions for projects, and the *ICR registry* user guide. The *ICR registry* platform provides a central source for all information and documentation relating to projects registered or pre-registered under the *ICR program*. The *ICR registry* platform also provides assurance of the uniqueness of projects and their *GHG emission mitigations*, and *issuance* of serialized ICCs, and tracking of transfers, retirements, and cancellations. ICR makes information and documentation of projects publicly available. Some information may not be publicly disclosed when information is subject to confidentiality and/or intellectual property rights. All documentation is, however, available for *VVBs* and the ICR. ICR is responsible for reviewing project documentation and overseeing *VVBs* accreditation to ensure the integrity of projects and ICCs within the registry platform. The ICR process requirements is updated periodically, and project proponents or other *stakeholders* shall ensure that they are using the most current version of this document or other documentation issued by the ICR. ### Transparency Increasing transparency in VCMs is pivotal for fostering trust and ensuring the effectiveness of *climate projects* and trust from their supporters. To achieve this, it's essential to implement standardized reporting, third-party *validation* and *verification*, public disclosure, clear framework, price transparency, oversight, and global alignment of transparency standards. **Clear reporting**: Clear and standardized reporting requirements for *climate projects*. **Third-party validation/verification**: Third-party *verification* of project GHG statement, ensuring impartial assessment by a competent and accredited *VVB*. **Public disclosure**: Public access to relevant project information, including project documentation, *monitoring* data, and validation/*verification* results. **Standardization**: Adherence to standardized rules and requirements governing *climate projects*, ensuring consistency and integrity. **Additionality transparency**: Make details on the significance of support projects needs to scale, facilitating fair market pricing and accuracy in reflecting climate impact. **Oversight**: Oversight to ensure compliance with relevant laws and regulations. **Global alignment**: Harmonize transparency standards, i.e., CDM, at a global level, aligning with the Paris Agreement and frameworks under article 6 of the Paris Agreement and ISO standards. In addition, the presentation of information in an understandable and user friendly format. ### Traceability Enhancing traceability in VCMs by replacing outdated technology with modern solutions, particularly by leveraging *blockchain* as a native database and tokenizing *carbon credits*, is pivotal in scaling climate action. The phased transition to new technology ensures that *carbon credits* and *climate projects* can be accurately tracked, preventing *double counting* and fostering trust and transparency. Blockchain's role as a native database is crucial because it provides immutable and transparent ledgers, making data tamper-proof and accessible to all *stakeholders*. This enhanced traceability, facilitated by *blockchain* and tokenization, builds confidence, attracts more participants, increases investments, and accelerates climate action. It ensures that the market operates efficiently and with integrity, ultimately driving the transition to a more sustainable, low-carbon future. ICR relies on native *issuance* of *carbon credits* (tokens) on the [Polygon ](https://polygon.technology/)blockchain, which is a public blockchain. As such all transactions can be audited by the public. ![](https://2441265052-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfIdoGcZZdvap67xjb5h1%2Fuploads%2FPaoIgFIcM67HheraEJNN%2F1.png?alt=media) *Figure 1: Comparison of business-as-usual credit issuance and tokenization utilizing public blockchain.* ### Blockchain The *ICR registry* platform leverages *blockchain* technology to *issue carbon credits* and transactions with *carbon credits*. The blockchain-backed nature of the *ICR registry* platform permits live inventory management and dissemination to marketplaces and end users of tools, enhancing transparency and favouring all *stakeholders* involved. Utilizing *blockchain* technology, numerous difficulties confronted by VCMs are tackled right from the beginning as it provides for the traceability of credits in a manner that is auditable by any *stakeholder*. Thus, the *blockchain* functions as a public record, maintaining a permanent and unalterable log where sellers, buyers, and other *stakeholders* can inspect and authenticate, thereby eliminating the possibility of duplication and fraudulent activities. Tokenization is the process of converting rights to an asset into a digital token on a blockchain. #### Tokenization without Blockchain: **Centralized Control:** Without blockchain, tokenization would need a centralized authority or database to keep track of ownership and transactions.\ **Limited Trust and Security:** The central system could be susceptible to manipulation, errors, or hacking.\ **Lower Liquidity:** Traditional systems may not support fractional ownership to the same extent as blockchain, making some assets less liquid.\ **Opacity:** Transactions may not be as transparent or easily verifiable by all parties involved.\ **Limited Interoperability:** Tokens might be confined to specific platforms or systems and may not be easily transferable. #### Tokenization with Blockchain: **Security and Trust:** The *blockchain* ensures the tokens are secure and the ownership records are tamper-proof.\ **Decentralization:** The information is not stored in a centralized server, making it resistant to hacking or manipulation.\ **Liquidity:** Tokenization on *blockchain* allows fractional ownership, improving the liquidity of assets.\ **Transparency:** Every transaction is recorded on the public ledger, ensuring transparency.\ **Interoperability:** Tokens can be easily exchanged and used across different applications and platforms.\ **Smart Contracts:** Automate processes like dividend payments or voting rights. Tokenization with *blockchain* provides more security, transparency, and liquidity compared to traditional tokenization/crediting methods. All credits/tokens issued on the *ICR registry* platform are tokenized on the public *blockchain* [Polygon](https://polygon.technology/) POS, more info on polygon found at . Polygon POS is an [Ethereum](https://ethereum.org/en/) sidechain. Further documentation on *blockchain* applications can be reviewed in the [ICR documentation](https://documentation.carbonregistry.com/documentation/carbonregistry.com/on-chain). ### Registry ICR's registry platform is electronic and can be accessed through all internet-connected computers, tablets, or mobile devices at [www.app.carbonregistry.com](http://www.app.carbonregistry.com/). ICR's registry platform Carbonregistry.com is developed by Mojoflower ehf. (Mojoflower) [www.mojoflower.io](http://www.mojoflower.io/). Mojoflower and ICR are fully owned by Gaia Group ehf. !\[A diagram of a group Description automatically generated]\() Figure 1: Organizational structure of Gaia Group ehf. The registry has user *accounts* and organizational *accounts*. Projects belong to organizational *accounts*, but ICCs may belong to users or organizations. Users make all actions and transactions on behalf of organizations based on their administrative privileges. !\[A screenshot of a computer Description automatically generated]\() *Figure 2: Create an account* *User accounts* are created from app.carbonregistry.com and organizational *accounts* are created by users within the *registry* platform. !\[A black background with arrows pointing to the left Description automatically generated]\() *Figure 3: Accounts relationship.* To effectively prevent *double counting* in all its forms, it is essential to have a robust and transparent registry platform, which includes a publicly accessible, transparent, and easily searchable project, credit and transaction database. The platform needs to provide all relevant information necessary to avoid *double counting* and build trust by interested parties. A registry and its infrastructure need to facilitate project *registration* by assigning a unique identifier to each project. This identifier should be cross-referenced with *carbon credits* issued in the program's *carbon credit* registry, ensuring that project information can be tracked for every *carbon credit* issued. ICR’s registry platform meets these requirements, offering the functionality and transparency needed to prevent *double counting*. 1. Securely and transparently managing the *issuance*, *transfer* of ex-ante and *ex-post ICCs* and retirement, and *cancellation* of *ex-post ICCs*. 2. Serialization and tagging of *issuances* to ensure each ICC is clearly linked to a specific project, country, *issuance* block, and vintage, thereby facilitating the assignment of information necessary to avoid *double counting*. 3. Implementing *retirement* and *cancellation* procedures that clearly indicate the removal of units, ensuring the process is irreversible and unambiguously designated for a specific purpose. For retirements under CORSIA, information includes the aeroplane operator for whom the ICCs were retired and the calendar year in which the underlying requirements are fulfilled through the retirement. 4. Providing public, downloadable, and sortable reports on all ICCs, including project details, *issuances*, retirements, and cancellations, with the following project information: 1. A description of the project, including details on the *GHG emission mitigations* technologies used. 2. The GHG emission SSRs, as well as the GHGs considered in calculating the project’s *GHG emission mitigations*. 3. The *host country* and geographical location where the project is implemented. 4. The project proponent. 5. The year(s) in which the *GHG emission mitigations* occurred (vintage). 6. Any additional information required to unambiguously identify the project and distinguish it from other projects in the same location. 7. indication of whether the project’s activities and *GHG emission mitigations* are covered by the *host country’s* NDC targets (*sector* and target years) for post-2020 credits. 8. A letter of attestation and authorization from the *host country*, which is publicly available on the registry once obtained and submitted to the ICR. 9. Designation of the credits as eligible as *Article 6.2 ICCs* once the *host country* letter of authorization is obtained. 10. Notice that the *host country* has applied a *corresponding adjustment,* once evidence is obtained. Further information about the functionality of the *ICR registry* is available in the [ICR registry user guide](https://documentation.carbonregistry.com/documentation/icr-program/registry-user-guide) found on the ICR documentation site. ### Account opening To benefit from using the *ICR program*, an *ICR registry account* needs to be opened to pre-register, register, issue, trade, or retire ICCs. The *ICR registry* is administered by ICR and maintained by Mojoflower. ### Users Everyone can join the *ICR registry*. Individuals can establish a *user account* from the *ICR registry* platform by providing the necessary information. ![](https://2441265052-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfIdoGcZZdvap67xjb5h1%2Fuploads%2Fl3p0wy5MsGUqH8ezsfIt%2F5.png?alt=media) *Figure 4: Create a user account* For users to be able to perform specific actions, they need to be verified, i.e., complete the Know your Customer (KYC) checks (**"verified users"**). The KYC check is completed within the registry platform. ![](https://2441265052-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfIdoGcZZdvap67xjb5h1%2Fuploads%2F5IoloIvQTBb1yCJdq3ht%2F6.png?alt=media) *Figure 5: KYC* ### Organizations For organizations to participate in the *ICR program* as a project proponent, *project developer*, *market participant*, general *organization* or other *stakeholder* for issuing, transferring, trading, or retiring ICCs or providing services for proponents or *stakeholders*, they need to establish a *registry account* with ICR. Users can create a *registry account* for organizations, i.e., project proponent, developer, *market participants*, etc, from their *user account*\[1]. ![](https://2441265052-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfIdoGcZZdvap67xjb5h1%2Fuploads%2FaULutdk28PA03gxebgUg%2F7.png?alt=media) *Figure 6: Create organizational account* The *account* opening is completed via the ICRs platform by a user who has the authority to represent the *organization* (*Authorized representative*). Organizations that want to have a public profile or intend to participate as a project proponent, *project developer*, *VVBs*, *market participant* or other need to complete a Know Your Business (KYB), and the user creating the organizational *account* shall be a verified user. *Note: Different fees are applicable for organizations based on the type of organizations and their verification.* ![](https://2441265052-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfIdoGcZZdvap67xjb5h1%2Fuploads%2FjygdFkXmZUQWZgKJPqC2%2F8.png?alt=media) *Figure 7: KYB* Organizations (project proponents or *project developers*) who want to register *climate projects* and *issue* ICCs shall have a verified *account* with ICR before any documentation review can proceed and listed publicly. For further information on the *criteria* for registration, refer to the ICR requirement document. A proponent intending to submit a project to ICR needs to open an *account* by a user with the authority to represent the *organization* through the *ICR registry* platform and register as a *project proponent* or a *project developer*. Other organizations may open *registry accounts* as applicable for their use\[2]. User permissions are limited to the purpose of use, and some are subject to special agreements with ICR, e.g., *market participants*, insurance companies, rating agencies and *VVBs*. *Market participants* who want to act as custodians of ICCs for users or trade or retire ICCs on behalf of organizations shall establish a *market participant* *account* with ICR and sign a *market participant* agreement with ICR. Insurance companies need to adhere to ICRs *insurance eligibility criteria*. *VVBs* need to establish an *account* with ICR. When an agreement has been signed with ICR, the *VVB* is explicitly identified in the registry. Only *VVBs* with an agreement for conducting *validation* and *verification* with *ICR program* are identified as *approved VVB*. Organizations holding ICCs need to have an *account* with ICR if they intend to retire or hold *carbon credits* for use later and publicly disclose their aggregated holdings of ICCs and retirements. All applicants for organizational *account* opening ne sign terms and conditions for organizations and are subject to Know Your Business (KYB) check with ICR for them to be verified (**"verified organization"**). Only verified organizations may have a public profile. ICR will inform the *organization* of the review of the KYB and accompanying documentation. If further documentation is needed, ICR will inform the organization. When all applicable fees have been paid, the *account* is verified, and the verified *organization* may perform its actions with the *ICR registry* platform. *Authorized representatives* of organizations can invite individuals to join the organizational *account* and become members of the organizational *account* by adding them to the *account*. The invitation is delivered by email\[3]. The users may be subject to KYC upon request. Users identified as members in organizational *accounts* have different roles, administrative rights (admin), content editing rights (*editor users*), viewing (partner) or an assessor (auditor). All user invitations to the organization's *account* and their roles are the organization's and *authorized representatives*' responsibility. At all times, at least one member needs to be an admin. Detailed information on the *ICR registry* platform, including step-by-step instructions for creating *accounts*, entering information, issuing, transferring, and retiring instruments, can be found in the ICR user guide. Note that some organizations may publicly or privately disclose ICC inventory ownership. Private disclosure is only allowed for certain *account* types. Proponents and developers shall always have information about their inventory public. ### ICR project cycle Project *registration* involves the formal process of submitting a PDD or PDDMR to ICR and to an *approved VVB* for assessment, providing detailed information about the project's objectives, procedures, and expected (and monitored) *GHG emission mitigations*. The *registration* ensures transparency, accountability, and credibility in projects, allowing them to *issue* ICCs that may be traded and used to compensate for *GHG emissions* or contribute towards reducing or removing atmospheric *GHG emissions* by organizations or individuals. The timing of project *registration* may be independent of its start date. In other words, projects may be submitted after they begin operation (subject to eligibility) or before they begin operation. However, the steps outlined in this section shall be followed. The lifecycle of a project may generally be described according to the following diagram. !\[A screenshot of a computer screen Description automatically generated]\() *Figure 8: Project cycle* Projects have different status based on their project cycle. The status of a project may be: 1. Concept (concept, section 7.2) 2. Under development (*pre-registration*, section 7.3) 3. Under *validation* (*pre-registration*, section 7.3) 4. Validated (registered, section 7.5) 5. Closed (*crediting period* finished, section 7.8) 6. Retracted (section 7.3.1) 7. Withdrawn (section 11) The status represents the stage in the project cycle it is in. ### Methodological criteria and procedures A methodology refers to a systematic approach or set of procedures used to quantify and measure *GHG emission mitigations*. These methodologies provide a standardized framework for estimating, monitoring, and verifying emission mitigations, allowing for consistent and comparable results across different projects applying the methodology. These methodologies typically establish *criteria* and prescribe procedures for projects to follow for data collection, quantification, monitoring, and reporting *GHG emission mitigations* for projects ex-ante and ex-post and serve as *good practice guidance*. Project proponents developing a climate project should review approved methodologies under ICR for their applicability and follow them where possible. ![](https://2441265052-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfIdoGcZZdvap67xjb5h1%2Fuploads%2F4byKSbwrKG2AoxkpRc4H%2F10.png?alt=media) *Figure 9: Methodologies* The ICR has approved methodologies listed in ICR approved methodologies and available on the ICR documentation page. When an approved methodologies do not cover the project activities, the *project proponent* may develop a project by establishing methodological *criteria* and procedures following to the requirements of *ISO 14064-2* and the ICR requirement document, e.g. establishing *criteria* and procedures for: * Boundary * Baseline * Additionality * Quantification * *Monitoring* When establishing methodological *criteria* and procedures, *ISO 14064-2* states in section 6.1 that project proponents shall identify, consider, and use all relevant *criteria* and procedures for every stage of the *GHG project* cycle where these are available. Here, consideration of section 0.3 in *ISO 14064-2* is relevant. If *criteria* and procedures are not available, the *project proponent* shall use relevant current *good practice guidance*. The *project proponent* shall select and apply established *criteria* and procedures from a recognized origin if available. Often, methodologies developed under *GHG programs* are considered a recognized origin. If the *project proponent* intends to develop a new methodology, please refer to the ICR methodology approval process. All documentation, irrespective of the origin of methodology, criteria, and procedures, shall use available ICR templates and follow any instructions outlined. Note, however, section 10. #### Intellectual property rights Copyright of methodologies developed by entities other than ICR, following the ICR methodology approval process are theirs, not ICR's. Methodologies developed by ICR are the copyright of ICR. Methodologies not developed by ICR or methodology developers developing methodologies under the ICR, may be subject to copyright. Methodologies, however, contain standardized processes for, e.g., measuring and verifying *GHG emission reductions* or *removals* associated with a project or activity. They outline systematic approach for establishing *criteria* and procedures, e.g. for baseline, boundary, monitoring, and quantifying the amount of *GHGs* that are reduced, avoided, reduced, destroyed or removed from the atmosphere due to the project implementation compared to the *baseline scenario*. Copyright law protects original works of authorship fixed in a tangible medium of expression, like a published methodology. However, it does not protect ideas, procedures, methods, or systems, even if they are included a methodology. Therefore, applying or referencing processes, methods, and procedures in a methodology typically does not violate its copyright (if it exists). Processes, methods, or procedures may be eligible for protection under different forms of intellectual property, including patents. Nevertheless, the ICR does not have any records of *GHG programs* or methodologies developed under *GHG programs* being protected under patent law. Should a methodology's processes be patented, the methodology documentation should explicitly mention this information and any application of such methodology shall disclose such intellectual property rights. ICR, however, respects the associated cost of developing methodologies. Where a methodology has been developed partially or entirely by third parties (other than a *GHG program*) approved and published by other *GHG programs* and is applied in all significant aspects, as a *good practice guidance*, to demonstrate conformity to *ISO 14064-2* and *ICR requirements*, the methodology developer(s) may be eligible to receive royalties from project proponents applying the methodology for developing and registering projects under the *ICR program*. Where ICR deems a methodology has been applied, developers may apply for entitlement of royalties according to the ICR fee schedule as a compensation for their contribution. ICR determines eligibility on a case-by-case basis. Methodology fees are collectible for 12 months from first transfers of ICCs applying the respective methodology. If not collected, ICR will deposit the methodology fee to amethodology development fund. ICR acknowledges and makes explicit the copyrights of approved methodologies (or other methodologies). ICR respects and preserves the existing trademarks and logos in the published materials (methodologies from other *GHG programs*). ### Project concept A project concept refers to the basic outline and description of an initiative to reduce, avoid or destroy *GHG emissions* or sequester carbon dioxide from the atmosphere. Project proponents may submit a project concept in the *ICR registry* where they have not completed the project documentation according to the ICR requirement document and procedures. For *stakeholders*, viewing project concepts, they should be aware that there's no certainty that the project will be implemented or *issue* ICCs in the future. Projects listed as a "Project concept" are not considered pre-registered or registered. Information needed to be eligible for listing a project concept is submitting a project concept description. If the *project proponent* intends to develop a methodology, he may submit a methodology concept note (see ICR methodology requirements and ICR methodology approval process). **Information to complete in the registry platform for project concept:** 1. Descriptive project name 2. Short descriptive summary of project activities 3. Website 4. Estimated start date 5. Sector 6. Estimation of additionality levels 7. Other SDGs 8. *Project type* 9. Location of the project **Documentation:** 1. A project concept note 2. A methodology concept note (optional) Projects may be listed as a project concept for up to 6 months. If the project concept status has not been updated to "under development" and has been pre-registered after six months, the concept listing will be redacted from the public registry. After the *project proponent* has submitted the project concept for review, ICR shall respond within two weeks from submission of the project concept. When ICR has no further observations of the information provided or the documentation, ICR approves the project concept 2 week after the proponent has responded to findings raised by ICR. Where a project requesting a listing of a project concept has not followed the instructions, suspects that the information and documentation submitted are false or misleading or ICR consider is spam, ICR reserves the right to reject the listing request without providing any findings to the proponent. ![](https://2441265052-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfIdoGcZZdvap67xjb5h1%2Fuploads%2FYyGEI3tE4R9ejg8g83YK%2F11.png?alt=media) *Figure 10: Project concept listing* ### Pre-registration The *ICR registry* features a project pipeline that showcases projects before their official registration. Projects can be pre-registered during initial development stages, identified as "under development," or "under validation" when prepared to initiate the *validation* process. Project proponents applying for *pre-registration* in the *ICR registry* can do so at any time before or during the implementation of the actual project and its implementation. *Pre-registration* may be to showcase projects in implementation for potential off-takers or investors or to increase awareness of prominent climate actions being developed. *Pre-registration* of a project does not constitute a *validation* or approval by the ICR of the project or its eligibility for final registration. *Pre-registration* solely constitutes is a preliminary review by ICR of project information provided by the proponent to the ICR. It is not a final determination of the project's eligibility or validation, nor does it guarantee the *issuance* of ICCs. When validating or verifying the project activities, the *VVB* shall check the project's status in the *ICR registry*. If the project has not been pre-registered with the ICR, the *VVB* shall advise the proponent to do so. When the *VVB* has been contracted for validation/*verification*, he shall be identified as the *VVB* for the project along with the *criteria* for validation/*verification*. The validation/*verification* team shall have access to all documentation submitted to the ICR and shall be added as an auditor of the project on the *ICR registry*. See further in the ICR *validation* and *verification* specifications. ### Process 1. !\[A diagram of a diagram Description automatically generated]\() 2. *Figure 12: Pre-registration* When the *project proponent* has completed a draft PDD, an *admin* initiates *registration* of a new project from the *ICR registry* platform's organizational *account*. An *editor user* can modify information. See the ICR user guide for details of *pre-registration* items. The *project proponent* appoints an individual(s) or an entity responsible for communication with ICR throughout the *crediting period* of the project activities depicted in the PDD as an "*Authorized representative*." The appointment is done in a *representation deed***\[4]**, only users identified as *authorized representatives* shall be added as an *admin* for the project. Others shall be *editor users* or viewers, (or auditors). If the individual is not already holding a user ID, the *organization* provides the individual authorization to be associated with the project with a user ID with admin rights for the project during the completion of the registration form. See details in the ICR user guide. The *admin* can invite other users to edit and modify information about the project. They are added as *editor users* to the project. *Note: editor users may edit information about the project, upload documentation, and share insights, but admins are also permitted to submit projects for review by the ICR and request issuances.* #### Under development !\[A diagram of a project Description automatically generated]\() *Figure 11: Pre-registration process under development* Projects eligible for *pre-registration* shall submit the following documentation and approve terms and conditions applicable for projects in the registry platform ("*project agreement*"): * 1. Proof of ownership (private document) 2. A draft PDD (or PDDMR) with the following sections completed\[5] (public/private document): 1. 1.1 - 1.17 2. 2.1 – 2.4 3. 4.1 – 4.4 (if applicable) 3. A draft ICR environmental and socio-economic safeguards. 4. *Representation deed* (private document) All documents regarding the project shall be submitted in electronic format. The *project proponent* uploads all relevant documents to the *ICR registry*. The *project proponent* shall use information from the project documents to complete the registration form in the *ICR registry*. All documents uploaded should be posted publicly, except for commercially sensitive information and proof of contracting. When the registration form has been completed and all documentation uploaded, the *admin* submits the project for *pre-registration* in the *ICR registry* platform as "under development", for review. The *project proponent* pays all relevant outstanding fees according to applicable terms and conditions and the fee schedule. When fees have been received, ICR reviews submitted documents and information provided in the registry platform for completion and consistency. If the submitted documentation are insufficient, the proponent is informed of corrections/improvements needed. The project status is confirmed by ICR as "under development" subject to review of the documentation and confirmation by ICR. \- All submitted documents and records are kept for at least seven years after the last *retirement* of the *instrument* issued and activated resulting from the project activities. If the project that has been pre-registered fails to complete *registration* (retracted) and no ICCs are issued, documents and records are kept for at least seven years. All information about a project that is registered on-chain can't be removed\[6]. If a project has been pre-registered and does not complete *validation* within 12 months. from initial *pre-registration*, the project is identified as "Inactive." Subject to objective evidence of ongoing implementation, the status is updated or reverted. Pre-registered projects shall complete *validation* and *registration* within 24 months from initial *pre-registration* date. If projects do not complete *validation* and *registration* within 24 months, they're retracted from the *ICR registry*. If ICR suspects that information and documentation submitted are false or misleading, ICR reserves all rights to retract the project and disclose the occasion. When the project has been pre-registered on the *ICR registry* and relevant documentation made available on the *ICR registry* platform, *stakeholders* may comment on the project and its public documentation. Comments on the project activities shall be submitted to with information, e.g. name, organization, address, and email address of the disclosing party. Comments received are shared with the *project proponent* and the *VVB* for consideration. Where the project requesting *pre-registration* has not followed the instructions and ICR believes it is spam, ICR reserves the right to reject the *pre-registration* request without providing any findings to the proponent. When ICR determines that the project does not meet eligibility *criteria* of the *ICR program*, ICR will reject the *pre-registration* request. After the proponent has requested a review by the ICR for *pre-registration* and all fees paid, the ICR shall respond with findings within two weeks. When the proponent has resolved all outstanding issues raised by ICR, ICR shall complete the *pre-registration* within one week. When a project has not updated the status to “under validation” within 12 months, the project is identified as inactive. #### Under validation !\[A diagram of a project Description automatically generated]\() Figure 2: Pre-registration process under validation For projects initially pre-registered as under development, the status shall be updated to "under validation" before the *validation* starts, providing all necessary documentation listed for projects "under validation" and selecting the *VVB* contracted to conduct the *validation* (and *verification*) and the criteria, from the registry platform. The proponent shall further add the *validation* team members as *auditor users* of the project. To update the *registration* of the project as "under validation," the following documentation shall be submitted or updated as relevant: 1. Proof of ownership (private document) 2. Completed PDD (or PDDMR) with all sections completed (public document) 3. ICR environmental and socio-economic safeguards template (public document) 4. Proof of contracting a *VVB*, proof of contracting can be in the form of a legal agreement, letter of intent/memorandum of understanding (private document) 5. *Validation* plan (or *validation* and *verification* plan for PDDMR) 6. *Representation deed* (private document) The proponent shall further update all information about the project on the registry and maintain consistency in information provided in the project documentation and on the registry. The proponent shall identify the relevant *criteria* for *validation* and *verification* in the registry platform. See the ICR user guide. The difference between under development and under *validation* represents the status of implementation and the contractual relationship with a *VVB* and ongoing *validation* or *validation* and *verification*. Those under *validation* are projects that have completed the PDD or PDDMR and contracted a *VVB* for *validation* (and *verification* for joint *validation* and *verification* engagements), while projects "under development" have not. When a project has not updated the status to “validated” within 12 months, the project is identified as inactive. ### Validation Before a project may be registered, it needs to be validated by an *approved VVB*. A list of *approved VVBs* may be found on ICR's website and the registry platform. All documentation uploaded to the registry shall be accessible for the *VVB* to conduct its assessment. !\[A diagram of a project Description automatically generated]\() *Figure 13: Validation and registration process* #### Project design description for validation When projects have been pre-registered, and the PDD (or PDDMR) has been completed, projects can undergo validation\[7]. 1. Before initiating the validation, the PDD (or PDDMR) shall be completed and submitted to ICR as it is submitted to the *VVB* for assessment (same version). 2. The *project proponent* shall use all applicable templates from ICR for the documentation and follow all outlined instructions. 3. If the project includes other environmental or social benefits subject to validation, the proponent shall inform the *VVB* and add it as *criteria* for validation, and necessary documentation shall be made available for the *VVB* for validation. ICR allows for additional labelling of other certifications or other benefits, such as the SDGs. 4. Other benefits shall be described in the PDD (or PDDMR) and on the project *registration* page. 5. For *validation* to be completed, the PDD (or PDDMR) shall meet the *validation* criteria, i.e., conform to all requirements of *ISO 14064-2*, the ICR requirement document, and, where relevant, the applied methodology. Note that the minimum *criteria* for *validation* are the ICR requirement document and *ISO 14064-2*. The *project proponent* may decide to have an approved methodology as an added criterion for *validation* (see section 7.1). 6. The *project proponent* shall adhere to and demonstrate conformity to all applicable requirements. 7. All documents regarding the project shall be submitted to the *VVB* in electronic format or a format requested by the *VVB*. The proponent shall not request to change the *registration* status to "Validated" until it has completed validation, received the ValR, and the *VVB* has uploaded the ValR to the registry platform and submitted the report to ICR. #### Validation of projects The *validation* process shall be completed for projects to be eligible for *registration* and *issuance* of ICCs. With limitations, projects are eligible to *issue ex-ante ICCs* post *validation* (prior to *monitoring* and *verification*). See section 5.4 in the ICR requirement document. If project proponents *issue ex-ante ICCs* after *validation* of projects, they are inactive and, as such, can't be retired by organizations holding them or used to support any offsetting *claim*. *Ex-ante ICCs* can, however, be transferred. *Issuance* of *ex-post ICCs* is subject to *verification* of *GHG emission mitigations* by the *VVB*. Note that *issuance* of ICCs ex-ante does not guarantee them becoming *ex-post ICCs*, as discussed under section 8.2.1 but safeguards are in place to guaranteeing compensation of any non-performance of projects issuing *ex-ante ICCs*, see section 8.5.1.1. *Criteria* for validation, including requirements for *VVB*, are set out in the ICR requirement document. Further guidance and specifications on *validation* and *verification* may be found in ICR *validation* and *verification* specifications. Projects shall complete *validation* before requesting *registration* and *issuance* of ICCs. The process for requesting *issuance* of ICCs is discussed under section 8. The *VVB* shall review if the information in the project *registration* aligns with the documentation. Further, any images or posts the *project proponent* has shared relate to the project activities. Project proponents shall submit documentation to the *VVB* according to requests by the *VVB*. The *VVB* assesses the documentation and accompanying evidence of conformity to *ISO 14064-2* requirements, the ICR requirement document, and, where applicable, the applied methodology or other criteria. The *VVB* submits findings to the *project proponent* with findings and requests for *corrective actions* as applicable. If applicable, the *project proponent* responds to the requests for *corrective actions*, and the *VVB* assesses the measures taken. The *VVB* submits the final ValR or VVR with findings to the *project proponent* and uploads it to the registry platform. The *project proponent* shall review that all relevant and necessary documentation has been uploaded to the registry and that relevant documents are available for public access. 1. PDD or PDDMR, 2. ValR or VVR, 3. Methodology specific documentation, 4. Environmental and socio-economic safeguards assessment, 5. Documentation relating to other criteria, 6. *Representation deed*. 7. *Validation* plan or *validation* and *verification* plan, 8. *Validation* agreement or *validation* and *verification* agreement, 9. Ownership proof. 10. Statement of no *double issuance* and counting. 11. Letter of attestation and authorization (if applicable) When the proponent has confirmed that all documentation necessary for the *registration* has been uploaded, the project status may be changed to "Validated." A *project proponent admin* shall request a review of the project for *registration* from the registry platform. ICR reviews the documentation and ValR (or VVR) for completeness, findings, and opinion. If the ValR (or VVR) or supporting and required documents are insufficient or need clarification, ICR advises the *VVB* and/or the project proponent, respectively. ### ICR review and registration The *project proponent* initiates the final *registration* process from the ICR platform. The project review process is initiated when relevant documentation for *registration* or renewal of the *crediting period* is submitted to ICR via the registry platform. The process initiates no sooner than when all necessary documentation has been submitted to ICR and a request has been submitted by an *authorized representative* (admin) from the *ICR registry* platform by changing the status of the project to “Validated”. The project review process consists of a documentation review. !\[A diagram of a document Description automatically generated]\() *Figure 14: Registration process* *Registration* is possible when the project has been validated, the proponent has resolved all non-conformities raised by the *VVB*, and the *VVB* has submitted the ValR (or VVR) to the ICR. The project review fee shall be paid before ICR completes the project review and the project is registered in the registry. When a project is registered, relevant documents shall be made available in the registry platform as follows and are disclosed publicly\[8]: 1. PDD or PDDMR, 2. ValR or VVR, 3. Environmental and socio-economic safeguards assessment, 4. Methodology specific documentation, 5. Documentation relating to conformity to other criteria, 6. letter of attestation and authorization (if applicable) The following documents shall be provided to the ICR and are not disclosed publicly: 1. *Representation deed*. 2. *Validation* plan or *validation* and *verification* plan, 3. *Validation* agreement or *validation* and *verification* plan, 4. Ownership proof. Project proponents shall advise ICR before disclosure, if any documentation is subject to non-disclosure or confidentiality. The purpose of ICR review is to ensure that all applicable documents are complete and signed where necessary. When an *approved VVB* has completed the *validation* and/or *verification*, *GHG emission mitigations* have not been issued as instruments under another *GHG program* (or been cancelled as appropriate), appropriate information has been used to complete all project documents, the *VVB* holds required accreditation, and the competence of the audit team is appropriate. Further, check if the newest versions of methodologies or tools have been applied and if all information provided in the registry platform is consistent with the project documentation. Further to guarantee consistency in the documentation from the proponent and from the *VVB* and overall quality of the documentation. If information is missing, incorrect or inconsistent, ICR will request that project documentation be updated, or information be revised on the registry platform. Any findings from the review shall be addressed before the *registration* or *issuance* request for instruments can be completed. Both the *project proponent* and the *VVB* conducting the *validation* (and *verification*) will receive a review report issued by the ICR disclosing the findings from the review. The ICR review report will be publicly disclosed. If the *project proponent* or *VVB* fails to address findings from the ICR, the ICR informs the *VVB* and/or the *project proponent* that the project has failed to demonstrate conformity to the *ICR program* requirements and is ineligible for *registration* or *issuance*. Note that documentation review is also applicable for all *issuance*s of ICCs ex-post. See section 8.4. The registry stores all project documents in its record-keeping system for at least seven years from the *retirement* date of the last ICC to which the project documents relate.\[9] When the project has completed both *validation* and *verification*, the sections below are also applicable, but *monitoring reporting* shall be included in a PDDMR. ![](https://2441265052-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfIdoGcZZdvap67xjb5h1%2Fuploads%2FeLpkgkaUfbolGv5gsjFT%2F17.png?alt=media) *Figure 15: Review process* After the proponent has requested a review by the ICR for registration, the ICR shall respond with findings within four weeks after all fees have been paid. When the proponent (or *VVB*) has responded to findings raised or resolved all outstanding issues raised by ICR, ICR shall complete a review of responses and/or the *registration* within two weeks. After *validation* and final step in the *registration* process of a climate project, ICR publishes publicly the validated estimation of *GHG emission mitigations* for the *crediting period* as an estimated supply for each *vintage* of the project on chain. This involves no-*issuance* event but merely a transparent public disclosure of validated projected *GHG emission mitigations*, which may be compared later to actual *GHG emission mitigations* of the project. !\[A diagram of a diagram Description automatically generated]\() *Figure 16: Project review timelines* ### Monitoring During the project's operation, the *GHG emission mitigations* shall be monitored according to the *monitoring* plan and reported in a MR. Any deviations from the *monitoring* plan shall be addressed and justified in the MR. If a deviation has been made to the PDD (or PDDMR), a revised PDD shall be issued and validated by the *VVB* and uploaded to the registry as a public document, along with the updated ValR. When a *VVB* has been contracted, the *project proponent* shall submit a *verification* agreement and *verification* plan to the registry. Further, the proponent shall select the contracted *VVB* from the registry platform and add the *verification* team members as *auditor users* of the project. Proponents shall select the *monitoring* period and monitored *GHG emission mitigations* when they submit MR. An *admin* shall upload the MR to the registry. See further section 8.3 for ex-post ICC *issuances*. ### Verification After monitoring, the *GHG emission mitigations* shall be verified by an *approved VVB* to be eligible for *issuance* of *ex-post ICCs*. If *ex-ante ICCs* have been issued, *verification* is mandatory to convert *ex-ante ICCs* to *ex-post ICCs*. !\[A screenshot of a diagram Description automatically generated]\() *Figure 17: Submitting monitoring and verification reports* When *GHG emission mitigations* have been monitored according to the *monitoring* plan and verified by the *VVB*, *ex-post ICCs* may be issued, and/or *ex-ante ICCs* converted to *ex-post ICCs*; see section 8.2.1 and 8.3. *Criteria* for *verification*, including requirements for *VVB*, are set out in the ICR requirement document. Further guidance and specifications on *validation* and *verification* may be found in ICR *validation* and *verification* specifications. Projects shall complete *verification* before requesting *issuance* of *ex-post ICCs*. The process for requesting *issuance* of *ex-post ICCs* post-*monitoring* is discussed under sections 8.2.1 and 8.3. The proponent shall identify the relevant *criteria* for *verification* in the registry platform. See the ICR user guide. When the proponent has contracted a *VVB* for *verification*, the *VVB* is selected in the registry platform that will conduct the *verification* of the *GHG emission mitigations* along with the *criteria* for *verification*. When the *VVB* has been selected, the *verification* team shall have access to all information relevant to the project on the registry platform. See further in the ICR user guide. The *VVB* shall review if the information in the project *registration* aligns with the documentation. Further, assess any images, videos or insights the *project proponent* publicly has shared and confirm that they relate to the project activities. Project proponents shall submit documentation to the *VVB* according to *VVB*'s request. The *VVB* assesses the *monitoring* and accompanying evidence of conformity to the *verification* criteria. The *VVB* submits findings to the *project proponent* with findings and requests for *corrective actions* as applicable. If applicable, the *project proponent* responds to the requests for *corrective actions*, and the *VVB* assesses any measures taken. The *VVB* submits the final VerR or VVR with findings to the *project proponent* and uploads it to the registry platform. The *project proponent* shall indicate the *monitoring* period in the registry and review that all relevant and necessary documentation has been uploaded to the registry and that relevant documents are available for public access. 1. Updated PDD (if applicable), 2. New *ValR* (if applicable), 3. *Monitoring report*, 4. *Verification report,* 5. Statement of no *double issuance* and counting for the *monitoring* period, and the following documents are private 1. *Validation* plan (if applicable) 2. *Verification* plan 3. *Verification* agreement. ICR reviews the request to ensure all documents are complete and signed where necessary. An *approved VVB* has conducted the *verification*, instruments have not been issued under another *GHG program* (or been cancelled as appropriate) for the same *GHG emission mitigations*, and appropriate information is included in all documentation. The *VVB* holds the necessary accreditation, and the competence of the *verification* team is appropriate. Further, to check if the newest versions of methodologies or tools have been applied and all information provided in the registry platform is consistent with the project documentation. The *project proponent* may *issue ex-post ICCs* according to *monitoring* and *verification* findings as stated in the MR and VerR or VVR, see section 8.3. When the *verification* has been confirmed, ICCs are issued and delivered to the proponent (subject to any deduction due to ICR *adjustment account* deposits, see section 8.5). The supply of verified *ex-post ICCs* for the *monitoring* period is provided on-chain. *Ex-ante ICCs* issued are converted to *ex-post ICCs* !\[A diagram of a flowchart Description automatically generated]\() *Figure 18: Verification review* ### Crediting period renewal If the *crediting period* has been renewed, a revised PDD and new ValR and *validation* agreement and *validation* plan shall be provided to ICR. If the *crediting period* has been renewed, the following documents shall be uploaded to the registry as public documents. 1. Revised PDD 2. Methodology specific documentation 3. Environmental and socio-economic safeguards assessment 4. New ValR 5. Letter of attestation and authorization (if applicable) and the following documents are private 1. *Validation* agreement 2. *Validation* plan 3. Ownership proof. 4. *Representation deed*. For renewal, the proponent shall follow section 7.4. If the *crediting period* is not renewed or expires the project is identified as “Closed”. ### Issuance Issuing *carbon credits* on a *blockchain* offers several advantages in terms of transparency and security compared to traditional databases. *Blockchain* operates on a decentralized network of computers, which means that the data is not stored in a single location; see section 5.4 further. This enhances transparency, as every transaction on the *blockchain* is recorded on a public ledger accessible and auditable by anyone. This means that all ICC transactions, e.g., *issuances*, transfers, and retirements, are publicly visible, making it easier to track their origin and ensure they are not double-counted. Once a transaction is recorded on a blockchain, it cannot be altered or deleted. This immutability provides a high level of security against tampering and fraud. This ensures that the records are accurate and remain unaltered, thereby maintaining the integrity of the credits. *Ex-ante* and *ex-post ICCs* differ primarily in terms of the timing of the realization of the *GHG emission mitigations* activities they represent: * ***Ex-ante ICCs*** are issued based on projected or expected *GHG emission mitigations* that will occur in the future. They are issued before the actual *GHG emission mitigations*, based on predictive calculations or models of the project's expected impact. *Ex-ante ICCs* are converted to *ex-post ICCs* subject to successful *verification* of *GHG emission mitigations*. * ***Ex-post ICCs*** are issued after the *GHG emission mitigations* have occurred and have been verified. *Ex-post ICCs* represent real, measurable *GHG emission mitigations* that have been achieved and verified, confirming the project's actual *GHG emission mitigations*. *Figure 19: Ex-post vs. ex-ante.* *Issuance* of ICCs, either *ex-ante ICCs* or *ex-post ICCs* may generally be described according to the following diagram. *Figure 20: Ex-ante ICC issuance.* *Figure 21: Ex-post ICC issuance.* | | ***Ex-ante ICCs*** | ***Ex-post ICCs*** | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | **Definition** | ICCs that have been issued in the *ICR registry* from a registered project that an *approved VVB* has validated. *Ex-ante ICCs* can’t be retired. | ICCs that have been verified that *GHG emission mitigations* are real and can be used for offsetting emissions or for other environmental *claims*. | | **Issued on carbonregistry.com** | Yes – after validation, subject to limitations and safeguards | Yes – after *verification* | | **Transferrable** | Yes – can be transferred to buyers *account* on the *ICR registry*. | Yes – can be transferred to buyers *account* on the *ICR registry*. | | **Retirable** | No | Yes | | **Cancellable** | Yes – if ex-ante ICCs have not been transferred from proponent | Yes | | **Convertable** | Yes – subject to *verification* *ex-ante ICCs* are converted to *ex-post ICCs*. | No | *Ex-ante ICC* *issuance* refers to the *issuance* of ICCs before *GHG emission mitigations*, and *ex-post ICC* *issuance* refers to *issuance* after *verification* of real *GHG emission mitigations*. At *issuance* *ex-ante ICCs* have vintages in the future, while ex-post vintages in the past. *Issuances* are either pre-*monitoring* (*ex-ante*) or post-*verification* (ex-post). The *ICR registry* displays the status of every ICC that has been issued. ICR allows projects that have been validated to *issue ex-ante ICCs*. ICCs may have a different status that represents the attribute of the credit. ICCs may be inactive (*ex-ante ICC*), *active* (*ex-post ICC*), retired, or cancelled. Please refer to ICR definitions for detailed definitions on different statuses. The *project proponent* may request partial or complete *issuance* of ICCs in the registry, subject to limitations. When a proponent requests partial *issuance* of *ex-ante ICCs*, it shall be no less than 10.000 t *CO2-e* for each *issuance* unless validated *GHG emission mitigations* are less than 10.000 t *CO2-e*. No limitations apply for *ex-post ICC* *issuances* as they’re all issued after MR or PDDMR and VerR or VVR have been reviewed and confirmed. When *registration* and *issuance* coincide, the documentation review is completed in parallel. ### Serialization Serial numbers play an important role in ensuring the integrity and traceability of *carbon credits.* Even though the tokenization of credits on chain ensures the uniqueness of a project and a credit, a credit serial number further serves as a consistent unique identifier assigned to each *vintage* of each project, representing a reduction, avoidance, destruction sequestration or removal of *CO2-e*. The serial number ensures that each credit is distinct and traceable. Relying on serial numbers helps prevent *double counting* and fraud. It ensures that a specific *carbon credit* can be tracked throughout its lifecycle, from *issuance* to retirement, which is essential for maintaining credibility. The serialization of ICCs helps to see the credits' attributes and compare projects easily. ICR serialization structure is provided below. | **Component** | **Order** | **Type** | **Length** | **Range** | **Comment** | | ----------------------------- | --------- | -------- | ---------- | ---------- | --------------------------------------------------------------------------------------- | | Credit identifier | 1 | Letter | 3 | Text | Fixed value. Unique registry identifier. (ICC, FCC) | | Project country | 2 | Letter | 3 | ISO 3166-1 | Three-letter country code for the project (e.g., Iceland is ISL). | | Project country dialling code | 3 | Numeric | 3 | 1-999 | Three-digit country code for the project (e.g., Iceland is 354). | | Project ID | 4 | Numeric | 4 | 1-9999 | Registry assigned identifier for the project, unique in the registry. | | Sector | 5 | Numeric | 2 | 1-16 | Primary sector | | Type | 6 | Letter | 1 | A, R, H | Avoidance, Removal, Hybrid | | *Host country* attestation | 7 | Numeric | 1 | 1;0 | 1 = Yes, 0 = No attestation | | *Vintage* (Year) | 8 | Numeric | 4 | 0-9999 | The *vintage* year of the credits. | | *Multiple project activities* | 9 | Numeric | 3 | 0-999 | ID of a sub-project. If not *multiple project activities*, this identifier is not used. | *Example: ICC-ISL-354-33-13-A-0-2022* ***GHG program:** International Carbon Registry* ***Project Country**: Iceland* ***Dialling code:** 354* ***Project ID:** 33* ***Sector:** Waste handling and disposal* ***Type:** Avoidance* ***Host country attestation:** No approval for ITMO transfer.* ***Vintage**: 2022* ***Multiple project activities:** Not a multiple project activity.* ### Ex-ante ICCs ICR acknowledges the importance of early funding projects to cover associated costs, access to funding, and the possibility of quickly scaling climate methodologies/projects. Transparency of such funding is important for sake of reporting and trust. Therefore, project proponents can *issue ex-ante ICCs* after projects have been validated and before *GHG emission mitigations* have been verified, subject to limitations, as further discussed in the ICR requirement document. This may ease funding efforts, facilitate climate actions, scale climate actions, and provide market visibility and credibility to *climate projects*. Note that *ex-ante ICCs* are issued based on validated estimation of *GHG emission mitigations*. *Ex-ante ICCs* do not represent real *GHG emission mitigations* by definition and thus cannot be retired until verified and converted to *ex-post ICCs*. Any terms of transactions with *ex-ante ICCs* should clearly define compensation mechanisms for non-performance events. This could involve risk-sharing arrangements where all parties involved in the transaction proportionally share the risk, or other specified options. If no specific terms of delivery have been agreed upon out in the agreement section 8.5.1 applies. *Ex-ante ICC issuance* is allowed for projects if they meet additionality level 4b or have insurance cover or warranty to compensate for any non-performance of the projects. Meeting level 4b allows issuing up to 50% of validated *GHG emission mitigations* for each *vintage* for the crediting period, notwithstanding *ex-ante ICCs* demarcated for *adjustment account(s)*. Projects with insurance cover or warranty may *issue ex-ante ICCs* up to 100% of the validated *GHG emission mitigations*, see requirements relating to insurance requirements in Appendix II in the ICR requirement document. Further see Appendix II on examples for *ex-ante ICCs* conversion to *ex-post ICCs* and compensations for non-performance events. *Figure 22: Ex-ante issuance.* When *ex-ante ICCs* are issued, the project shall either: 1. Meet additionality level 4b, or 2. Have insurance cover for non-performance events. Project meeting additionality level 4b issuing *ex-ante ICCs* shall deposit minimum of 2% to a non-performance *adjustment account*, the percentage is determined by a non-performance risk assessment. The non-performance *adjustment account* is to rectify issued *ex-ante ICCs* that fail to result in real *GHG emission mitigations*.\[10] See section 8.5.1.1 on compensation mechanism on non-performance events. After the request for *issuance* ICR performs the risk assessment for *non-performance* for *non-performance adjustment account* contribution. Projects are allowed to *issue* up to 50% of validated *GHG emission mitigations* of each *vintage* for the crediting period, notwithstanding ICCs demarcated for non-performance *adjustment account*, if the meet additionality level 4b, see section 4.4. Projects with insurance cover for non-performance may *issue* up to 100% of validated *GHG emission mitigations* of each *vintage* for the crediting period. The insured entity shall publicly disclose that the project has insurance coverage. Please see Appendix II in the ICR requirement document for *insurance eligibility criteria*. All *ex-ante ICCs* have not been verified for real *GHG emission mitigations* and are inactive. As such, they can't be retired and used by organizations to offset emissions. When an *approved VVB* has verified *GHG emission mitigations*, *ex-ante ICCs* are converted to *ex-post ICCs* that can be retired and used for offsetting or for other *claims* (see section 4.2.1). Vintages are ICCs based on validated estimates in the PDD and ValR for ex-ante ICC *issuance*.\[11] Requests for *issuance* of *ex-ante ICCs* are made by an *admin* from the *registration* platform. See the ICR user guide for further information. *Ex-ante ICCs* are delivered to the proponents *account* upon all fees received by ICR. Please see below ICR's eligibility requirements for suitable insurance coverage, including safeguards to ensure fungibility when the insurance claim is paid in-kind. ICR only approves insurance products that meet the *insurance eligibility criteria* as a basis for ex-ante ICC *issuance*. #### Ex-ante post verification This process relates to *verification* submission when projects have issued *ex-ante ICCs*. For each verified *monitoring* period, the *project proponent* shall submit a MR and a VerR and request the conversion of *ex-ante ICCs* to *ex-post ICCs*. *Figure 23: Ex-ante post verification* When *monitoring* and *verification* have been completed, the proponent shall submit the MR and the *VVB* the VerR from the registry and request review. When ICR has completed the review, ICR converts the corresponding number of *ex-ante ICCs* to *ex-post ICCs*. 1. If verified *GHG emission mitigations* are greater than issued *ex-ante ICCs*, *ex-post ICCs* are delivered directly to current holders of the *ex-ante ICCs*, and *ex-ante ICCs* are converted to *ex-post ICCs*, subject to confirmation by ICR. 2. If verified *GHG emission mitigations* are less than issued *ex-ante ICCs* and the *monitoring* period for the respective *vintage* has not been closed, *ex-post ICCs* (according to the verified *GHG emission mitigations*) are delivered to the *ICR escrow account*. The *ex-post ICCs* remain on the *ICR escrow account* until the *monitoring* for the respective *vintage* has been completed and verified. The *project proponent* shall complete *verification* of the respective *vintage* within 12 months. 3. If, after the completion of the *verification* of the *monitoring* period, verified *GHG emission mitigations* are greater than issued *ex-ante ICCs*, *ex-post ICCs* are delivered from the *ICR escrow account*, to the current holders of *ex-ante ICCs* replacing the *ex-ante ICCs* and any excess *ex-post ICCs* may be issued according to the VerR. 4. If, after verifying the *monitoring* period, verified *GHG emission mitigations* are still less than issued *ex-ante ICCs*, 3. applies. 5. If *monitoring* for a *monitoring* period, where a *vintage* has been completed, and *verification* confirms fewer *GHG emission mitigations* than the number of issued *ex-ante ICCs* for the respective *monitoring* period (vintage), the *project proponent* is responsible for compensating for excess *ex-ante ICCs* issued. If insurance or warranty is in place to cover non-performance of the project, then that insurance or warranty cover shall be called upon, as outlined in the insurance / warranty policy. See details in section 4.4.1.1 If the *VVB* has verified that *GHG emission mitigations* are more than issued *ex-ante ICCs*, the *project proponent* may *issue* the *ex-post ICCs* not eligible for *ex-ante ICC* *issuance* at registration, see section 4.3. Further, if *monitoring* confirms fewer/more mitigations than estimated in the PDD and verified by *VVB*, additional *issuance* can be made accordingly for the respective vintage. ### Ex-post For each *monitoring* period that has been verified, the *ex-post ICCs* may be issued, subject to ICR review and confirmation. *Figure 24: Ex-post issuance.* When ICCs are issued for a *monitoring* period, relevant documents shall be provided to ICR that are disclosed publicly: 1. MR or PDDMR, 2. VerR or VVR\[12], 3. Methodology specific documentation, 4. Documentation relating to conformity to other criteria, 5. Documentation regarding *cancellation* of *GHG* credits under another *GHG program* (if applicable) or 6. Statement of no *double issuance* and counting. 7. Letter of attestation and authorization (if applicable) Further, the following documents shall be provided to the ICR and are not disclosed publicly: 1. *Verification* plan, 2. *Verification* agreement 3. Other documents relevant subject to confidentiality. If *material* deviation to the PDD has been applied during implementation and a revised PDD has been issued, the new version of the PDD shall be provided to the *VVB* for *validation* and submitted to ICR, accompanied by a new/updated ValR. The new version of the ValR and the previous version are publicly available. Project proponents shall advise ICR before disclosure if any documentation is subject to non-disclosure or confidentiality. The proponent shall identify which documents are private or public. After *issuance*, ICCs are deposited to the proponent’s registry *account* unless other means for delivery has been requested by the *authorized representative*. ICR only invoices *issuance* of ICCs after the ICCs has been transferred from the delivery *account*.\[13] See further information about transfers, retirements and cancellations under section 9 and the *ICR registry* user guide. All documentation shall be submitted to ICR via electronic means. ### ICR review and issuance ICR reviews the MR and VerR (or PDDMR and VVR) for completeness, findings, and opinion and *issuance* of ICCs is subject to a successful documentation review. The purpose of documentation review is to ensure that all applicable documents are complete and signed where necessary. When an *approved VVB* has completed the *verification*, *GHG emission mitigations* have not been issued as instruments under another *GHG program* (or been cancelled as appropriate), appropriate information has been used to complete all project documents, the *VVB* holds required accreditation, and the competence of the audit team is appropriate. Further, check if the newest versions of methodologies or tools have been applied and if all information provided in the registry platform is consistent with the project documentation. Further to guarantee consistency in the documentation from the proponent and from the *VVB* and overall quality of the documentation. If information is missing, incorrect or inconsistent, ICR will request that project documentation are updated, or information be revised on the registry platform. Any findings from the documentation review shall be addressed before the *issuance* request for ICCs can be completed. Both the *project proponent* and the *VVB* conducting the *verification* will receive a review report from the ICR disclosing the findings of the review. If the VerR, supporting and/or required documents are insufficient, ICR advises the *VVB* and/or the project proponent, respectively. The ICR review report will be publicly disclosed. ### Adjustments ICR addresses the risk associated with project activities' *non-permanence*, non-performance of estimated *GHG emission mitigations* or non-corresponding adjustment of host countries by requiring the *project proponent* to set aside non-tradable *adjustment ICCs* to *adjustment account*s or presenting an *insurance policy* covering the respective risk. This is to cover unforeseen losses in carbon stocks, unforeseen obstacles in the operations of projects and any double *claim* under international transfers (see ICR Article 6.2 procedures). * **Non-performance:** Adjustment *ex-post ICCs* are cancelled if projects fail to produce real *GHG emission mitigations*. * **Non-permanence:** Adjustment *ex-post ICCs* are cancelled upon a *non-permanence* (*reversal*) event of carbon stocks. * **Non-corresponding adjustment:** Adjustment *Article 6.2 ICCs* are cancelled upon a non-corresponding adjustment event. Deposits to *adjustment account*s are completed during *issuance* of ICCs. When *ex-ante ICCs* are issued which are subject to *non-permanence* risk, the *non-permanence* adjustment is also applicable for the *ex-ante ICCs*. In time during *monitoring* and *verification* of respective vintages *ex-ante ICCs* are converted to *ex-post ICCs*. For risk associated with project activities' *non-permanence*, non-performance of estimated *GHG emission mitigations* or non-corresponding adjustment of host countries, ICR performs a risk assessment considering the respective risk. Before any *issuances* of ICCs (*ex-ante* or ex-post), ICR conducts the applicable risk assessment. The risk assessment is publicly available. ICR manages risk on ICR’s *adjustment account*s to proactively identify, manage and mitigate risks via upfront insurance-driven risk assessment of projects, liquidity management and transparent reporting. This includes: 1. Risk assessment, permanence scoring and scenario analyses across the entirety of the ICR project portfolio to ensure projects can be compared on a ‘like for like’ basis. 2. *Risk adjusted contribution* per project, utilizing insurance quality underwriting criteria to assess level of adjustment contribution. Risk assessment factors shall include counterparty, country and project specific risk that could result in lead to under-performance and/or *reversal*, leading to *non-permanence*. Factors include but are not limited to: 1. track record of the *project proponent* and/or developer; 2. financial and KYC/B assessment of the *project proponent* and developer and any implementation partners; 3. natural catastrophe risk modelling; 4. supply chain disruptions; 5. country risk, including land ownership rights, community engagement and benefit sharing, fraud and corruption indices, and wider political and regulatory risk considerations, for example across expropriation, confiscation, export license cancellation, contract frustration (including those leading to issues like revocation of *corresponding adjustments*), war/terror/civil unrest; and 6. technical risks which will vary by *project type*. 3. Ongoing portfolio management and reporting on liquidity and risk in-line with financial industry standards. This includes regular reporting on *adjustment account* performance, systemic risk factors, adjustment depletion scenario analyzes to ensure adjustment depletion risks are mitigated and transparent reporting on results that can be made publicly available. 4. Analysis on where further incorporation of insurance could be beneficial for ICR and/or its *stakeholders*. ICR may work with an *external risk advisor(s)* to perform ongoing *monitoring* and consulting of its *adjustment account*s to enable regular reporting on *adjustment account* performance, systemic risk factors, and *adjustment account* depletion scenario analyses to ensure adjustment depletion risks are mitigated and transparent reporting on results that can be made publicly available. #### Non-performance *Figure 26: non-performance account allocation.* Project proponents issuing *ex-ante ICCs* (when not insured) shall deposit non-performance adjustment *ex-ante ICCs* into the ICR non-performance *adjustment account*, following. 1. The number of *ex-ante ICCs* to be deposited to the non-performance *adjustment account* is based on non-performance risk assessment but never lower than 2% of issued *ex-ante ICCs*, irrespective of the timing of *issuance* prior to *verification*. Maximum number of *ex-ante ICCs* deposited to the non-performance *adjustment account* is never higher than 10%. 2. Non-performance adjustment *ex-post ICCs* are only eligible for compensation for non-performance events. Non-performance adjustment *ex-ante ICCs* are not subject to any *issuance* fees, same applies at *verification* and conversion to *ex-post ICCs*. 3. At *verification* events, *ex-ante ICCs* are converted to *ex-post ICCs* and eligible to compensate for non-performance. Upon *verification* *ex-ante ICCs*, on the ICR non-performance *adjustment account* have priority for conversion to *ex-post ICCs* over any other outstanding *ex-ante ICCs*. 4. At the end of each project crediting period, the *project proponent* may apply for reimbursement of deposits of adjustment *ex-ante ICCs* that have been converted to *ex-post ICCs*. They are reimbursed by ICR's sole discretion and with respect to the status of the ICR non-performance *adjustment account* and cancellations made by the ICR due to non-performance events and consideration of depletion risk. **Non-performance events** In the event of a non-performance of a project, the *project proponent* shall notify ICR within 30 days of discovering non-performance event. If there have been any previous *issuances* of *ex-ante ICCs*, a report shall be prepared and submitted to the ICR. The proponent is responsible for compensating for the *non-performance event* irrespective of any non-performance *adjustment account* deposits, according to the following: 1. For the *non-performance event* the proponent shall use the ICR non-performance event report template. It shall contain a conservative estimation of the impacts on previously validated *GHG emission mitigations* due to the non-performance of the project based on monitoring. 2. The *non-performance event report* shall be submitted to the ICR within six months from the discovery date of non-performance of the project. Failure to submit the non-performance report within this timeframe may result in sanctions towards further *issuances* of ICCs. The non-performance report shall be publicly available. 3. The ICR will temporarily withhold *ex-post ICCs* from the non-performance *adjustment account* and deposit to *ICR escrow account*, equivalent to the estimated difference stated in the non-performance report affecting any *ex-ante ICC* holders.\[14] 4. The proponent shall account and report for the *non-performance event* in the next *monitoring report* and the *VVB* in the following *verification report*. 1. If the net *GHG emission mitigations* verified are less than issued *ex-ante ICCs* for the *monitoring* period in the following order: 1. the *project proponent* shall compensate for the difference; and/or 2. notify the insurer of non-performance and exercise the insurance or warranty policy. 3. If the proponent can't compensate for the *non-performance event* or is not covered by an insurance or warranty policy, *ex-post ICCs* are cancelled from the *ICR escrow account*, and any remaining non-performance *adjustment ICCs* are released from the escrow account to the non-performance *adjustment account*. 2. If the *GHG emission mitigations* are greater than issued *ex-ante* credits, the *ex-ante ICCs* are converted to *ex-post ICCs*, and the allocated *ex-post ICCs* from 3 will be released to the non-performance *adjustment account*. The proponent can *issue ex-post ICCs* for the remaining *GHG emission mitigations* verified after the *ex-ante ICC* to *ex-post ICC* conversion. 5. The following applies for compensation according to 4 a) i. by the proponent: 6. Within 30 days from the submission of the VerR the *project proponent* shall deposit *ex-post ICCs* of earlier *vintage* to the *ICR escrow account*. ICCs shall be owned by the project proponent. Excess *ex-post ICCs* shall be deposited from the project proponent's registry *account* and shall not have been retired or cancelled. Such *ex-post ICCs* deposited to the *ICR escrow account* shall be delivered to the current holders of *ex-ante ICCs* with *ex-post ICCs* issued for the respective *vintage* subject to the non-performance event, proportionally. 7. The proponent can also deposit of issued *ex-post ICCs* from subsequent vintages of *ex-post ICCs* to the *ICR escrow account* following the same requirements as in i. If the *project proponent* has insufficient holdings on the *account* for i and ii, any remaining deposit shall follow iii. 8. Purchase by the *project proponent* of an equivalent number of replacement *ex-post ICCs* or equivalent ex-post *carbon credits* issued by at minimum ICROA-endorsed *GHG program* for the same *project type*, sector, and vintage, determined by the ICR. Such *ex-post ICCs* shall be deposited to the *ICR escrow account*. Other ex-post *carbon credits* shall be cancelled for the same amount and confirmed by ICR. The deposit or *cancellation* shall be completed within 60 *business days* of receiving formal notification of such required action from ICR. *Ex-post ICCs* deposited or remaining on the *ICR escrow account* shall be delivered to the affected holders of *ex-ante* with *ex-post ICCs* issued for the respective *vintage* subject to non-performance proportionally. When other ex-post *carbon credits* have been cancelled, confirmation from the ICR of such *cancellation* shall be delivered to the affected *ex-ante* holders. 9. The following applies for compensation according to 4 a) ii. When insurance or warranty covers part or total non-performance, the insurance or warranty policy shall compensate for the non-performance of the *ex-ante* *ICC* *issuances* according to the policy terms. The policy shall be according to Appendix II of the ICR requirement document. 10. The following applies for compensation in cases where the project proponents fail to compensate for the *non-performance event* in part or full. ICR will deliver *ex-post ICCs* from the non-performance *adjustment account* to the *ICR escrow account* according to 3 above. Such *ex-post ICCs* deposited to the *ICR escrow account* shall be delivered to the current holders of *ex-ante*, proportionally for the respective *vintage* subject to the non-performance event. 11. Following the compensation according to 7 the proponent shall reinstate any deductions from the non-performance *adjustment account* after subsequent *monitoring* and *verification*. Where the *project proponent* fails to compensate for non-performance event, ICR may act against the project proponent, including applying sanctions with respect to its registry *account* activities and/or suspend any *issuances* of ICCs until the *non-performance event* has been compensated for according to 8. #### Non-permanence *Figure 25: non-permanence account allocation.* Project proponents issuing *ex-ante* or *ex-post ICCs* (when not insured) shall deposit *non-permanence* *adjustment ICCs* into the ICR *non-permanence* *adjustment account*, following: 1. The number of *ex-ante* or *ex-post ICCs* depo*site*d to the *non-permanence* *adjustment account* is based on *non-permanence* risk assessment conducted by ICR but never lower than 10% of issued *ex-ante* or *ex-post ICCs*, irrespective of the timing of *issuance*, prior to or post *verification*. 2. *Non-permanence* adjustment *ex-post ICCs* are only eligible for compensation for *non-permanence events*. *Non-permanence* adjustment *ex-ante* or *ex-post ICCs* are not subject to *issuance* fees. At *issuance* of *ex-ante* or *ex-post ICCs*, ICR allocates the *non-permanence* ICCs to the ICR *non-permanence* *adjustment account* based on risk assessment for *non-permanence*. *Ex-post ICCs* within the pooled *non-permanence* *adjustment account* from different projects are functionally distinct, although managed in one pooled *account* in the *ICR registry*. Therefore, *ex-post ICCs* from the same *project type*s can compensate for *non-permanence events* for the same or similar *project type* or durability. ICR will retire *ex-post ICCs* from the *non-permanence* *adjustment account* to compensate for *non-permanence events* on a first-in, first-out rule after identifying which *ex-post ICCs* meet the *criteria* above for *non-permanence* compensation. ICR performs an ongoing risk assessment and reporting of against required permanence *criteria* with transparent reporting. Any *ex-ante ICCs* issued, subject to *non-permanence* risk, deposited to the *non-permanence* *adjustment account* are converted to *ex-post ICCs* subject to *monitoring* and *verification*. **Non-permanence events** The *project proponent* shall notify ICR within 30 days of discovering an actual or potential *non-permanence* (*reversal*) *event*. If there have been previous *issuances* of *ex-ante* or *ex-post ICCs*, the report shall be prepared and submitted to ICR, following these guidelines: 1. The *non-permanence event* *report* shall use the ICR *non-permanence event report* template. Based on *monitoring* the entire affected area and/or locations, it shall contain a conservative estimation of the *reversal* of previously verified *GHG emission mitigations* due to decreases in carbon stocks from the event. 2. The *non-permanence event report* shall be submitted to the ICR within 6 months from the discovery date of the event. Failure to submit the report within this timeframe may result in sanctions towards further *issuances* of ICCs or transactions with ICCs from the project proponent’s *account*. 3. ICR will temporarily allocate *non-permanence* adjustment *ex-post ICCs* from the ICR *non-permanence* *adjustment account* to the *ICR escrow account*, equivalent to the estimated *reversal* stated in the report. 4. The *project proponent* shall account for the *reversal* in the following MR and the *VVB* in its VerR after the event. 1. If the verified net *GHG emission mitigations* are net-negative compared to issued *ex-post ICCs*, the allocated *ICR escrow account* *non-permanence* adjustment *ex-post ICCs* shall be cancelled, and any remaining *ex-post ICCs* released. 2. If the *reversal* is greater than stated in the initial *reversal* event report, an equivalent number of *non-permanence* adjustment *ex-post ICCs* allocated to the *ICR escrow account* is updated and the equivalent number of *ex-post ICCs* cancelled to meet the *non-permanence event*. 3. If the *GHG emission mitigations* are positive, the allocated *non-permanence* adjustment *ex-post ICCs* are released from the *ICR escrow account* and returned to the *non-permanence* *adjustment account*. 5. If the proponent has in place an insurance for meeting *non-permanence events*, and the policy is according to ICR’s insurance eligibility requirements, the proponent, ICR and the insurance company shall resolve how the *non-permanence event* is compensated for and responsibility of each party. If the *non-permanence event* has not been resolved between the parties within 90 days, *ex-post ICCs* from the *ICR escrow account* are cancelled and ICR shall become the beneficiary of the *insurance policy*. 6. When *non-permanence* adjustment *ex-post ICCs* are cancelled, the *non-permanence event* initiating the *cancellation* is disclosed as the reason for the cancelation. 7. ICR *non-permanence* *event report* shall be publicly available. #### Non-corresponding adjustment *Figure 26: Non-corresponding adjustment account allocation.* Project proponents issuing *Article 6.2 ICCs* (when not insured) shall deposit adjustment *Article 6.2 ICCs* to the ICR Article 6.2 *adjustment account* following: 1. The number of *Article 6.2 ICCs* to be deposited to the Article 6.2 *adjustment account* is based on ICR’s risk assessment for non-corresponding adjustment by the *host country*. 2. Deposits to ICR Article 6.2 *adjustment account* are irrespective of the estimated time of CA by the *host country*. 3. Non-corresponding adjustment *Article 6.2 ICCs* are only eligible for compensation for non-corresponding adjustment events. Non-corresponding adjustment *Article 6.2 ICCs* are not subject to any *issuance* fees, unless released to the proponent after a *corresponding adjustment* has been confirmed. **Non-corresponding adjustment events** See section V in ICR Article 6.2 procedures. ### Adjustment account management ICR manages ICCs deposited to any *adjustment account*s, based *project type*s and type of adjustment, i.e. non-performance, *non-permanence* and non-corresponding adjustment risks. ICR manages risk in relation to its *adjustment account* management in relation to *double claiming* risk, non-performance risk and *non-permanence* risk proactively identify, manage and mitigate risks via upfront risk assessment, liquidity management and transparent reporting. Key elements of the risk management include: 1. Risk assessment, permanence scoring and scenario analyses across the entirety of the ICR project portfolio to ensure projects can be compared on a ‘like for like’ basis. 2. *Risk adjusted contribution* per project, utilizing high-quality underwriting criteria to assess level of buffer contribution. In relation to the Article 6.2 account, political and regulatory risk scoring tools to determine contributions to the Article 6.2 account. 3. Ongoing portfolio management and reporting on liquidity and risk in-line with financial industry standards including regular reporting on performance, systemic risk factors, Article 6.2 account depletion scenario analyzes to ensure depletion risks are mitigated and transparent reporting on results that can be made publicly available. 4. Advice on where further incorporation of insurance and/or guarantee could be beneficial for ICR and/or its *stakeholders*, including ongoing best practice advice in relation to section (1) above. ICR may contract a third-party *external risk advisor* to support ICR in its *adjustment account* risk management. The role of the *external risk advisor* is to support ICR in risk management for non-performance risks, *non-permanence* risk, *double claiming* risks, helping ICR proactively identify, manage and mitigate risks via upfront risk assessment, liquidity management and transparent reporting. ### Transfer, retirements, and cancellations Transfers, retirements, and cancellations have specific meanings. A *transfer* meanstransferring an *instrument* from one *account* to another, representing a *transfer* of *beneficial ownership* of *GHG emission mitigations* entitlements. *Retirement* means permanently removing an *ex-post ICC* from circulation in the registry system, representing of one metric tonne of CO2 equivalent (*CO2-e*) due to a *claim*. *Cancellation* means permanently removing an ICC from circulation in the registry system for purposes other than *retirement* (e.g., converting ICCs into another form of *GHG* credit, compensating for excess ICC *issuance*, expiry, etc.). See further in ICR definitions. The ICR user guide provides details about transfers, retirements, cancellations, and other credit actions. ### Transfers Transfers involve transferring a set number of ICCs from one registry *account* to another. This process includes changing *beneficial ownership* of *GHG emission mitigations* they represent as defined in ICR definitions. *ICR registry* functionality always guarantees *instrument* delivery, and buyers can always expect to have ICCs delivered. Each *transfer* and related information, including the address of each ICC, is traceable in the platform or through the *blockchain* ledger. Historical *transfer* can be accessed on the platform and public *blockchain* ledger. From a registry *account*, an *authorized representative* (admin) initiates a transfer. There are two instances of transfers. 1. *Transfer* to organizations or individuals that have accounts with within the registry 2. *Transfer* to organizations or individuals that don't have an *account* within the registry *Figure 27: Transfers* #### Transfer to existing accounts. From the registry *account*, an *admin* either searches for the name of the *organization* receiving the ICCs or provides an *account* number of the *organization* registry *account*. The project, vintage, and number of ICCs to be transferred are provided, and then the *transfer* is completed and confirmed. Both entities receive a notification and confirmation of the *transfer* with an email and within the registry platform to *account* admins. #### Transfers to new organizations or individuals If the receiving entity has not established an *account* with ICR yet, the transferring *organization* needs to collect information about it to deliver the ICCs. Information required is. 1. Name (max 100 characters) 2. Email of contact By providing this information, the transferring *organization* can complete the transfer. When completing the transfer, the transferring *organization* may choose to provide a comment to the receiving *organization* and, if the credits will be transferred in a retired state (only applicable for *ex-post ICCs*), and a *retirement* reason (max 500 characters). When transferring *ex-post ICCs* in a retired state, the receiving *organization* is the beneficiary of the retirement, and the transferring *organization* shall provide a reason and comment for the retirement. After the transferring *organization* has confirmed the transfer, the contact receives an email invitation to claim his/hers *user account* and is provided with login details to access the ICCs in the *ICR registry*, where he/she can complete onboarding an *organization* receiving the ICCs, view inventory of ICCs and downloads certificates of retirement. By default, the organizational *account* created is private, with no public disclosure of inventory of ICCs or details of the organization. See further section 6.2 and 6.3 and the *ICR registry* user guide. Beneficiaries, comments and reason for retirements of retired ICCs are always public. ### Retirement The process of retiring ICCs in the registry is set out below. 1. An *organization account* *admin* needs to initiate a *retirement* from his respective user account and selecting the *organization* holding the ICCs. 2. Details of all retirements are stored on-chain on a public ledger, also shown in the *ICR registry* platform. 3. The *admin* selects the respective *ex-post ICCs*, vintage, and the number of *ex-post ICCs* for retirement. 4. The *admin* provides information about the reason and comment for retirement. 5. *Ex-post ICCs* are retired from the registry *account holder's* ICC holdings (i.e. when the holder requests *ex-post ICC* *retirement* of a part of its holdings). 6. A *retirement* certificate can be downloaded from the platform when the *retirement* has been completed. *Figure 28: Retirement process* ### Cancellation A *cancellation* of ICCs is initiated by the registry *account holder*, the other *GHG program* in which the registry *account holder* may participate, or ICR. Note that the initiator and recipient of an ICC *cancellation* request depend on the circumstances of cancellations (e.g., whether ICCs are being converted into another form of *GHG* credit). The *cancellation* request may be submitted to ICR by the other *GHG program* in which the registry *account holder* participates. An *admin* for a registry account initiates a cancelation from his user account. The *account holder* may execute a *cancellation* through its *ICR registry* *account*. Details of all cancellations are recorded on the *blockchain* and mirrored in the registry platform. The registry *account holder* may be asked to confirm the details of the request for ICC cancellation. *Ex-post ICCs* with a *vintage* T – 10 years, issued T – 3 years, and are cancelled by the *ICR* and are ineligible for retirement. ICR will not reimbursement any *issuance* fees due to such cancellations. *Ex-ante ICCs* may be cancelled, only if they have not been transferred from the proponent’s *account*. If the proponent requests cancellations of *ex-ante ICCs*, e.g. due to withdrawal from the ICR (section 11) shall demonstrate that all current holders of affected *ex-ante ICCs* have been compensated with *ex-post ICCs* or *carbon credit* from at minimum ICROA endorsed *GHG program*. ### Transfer from other GHG programs Projects registered under a *GHG program* may *transfer* their registration, renew the *crediting period* or also register their projects with the ICR. In such cases, the documentation required for the project *registration* process is the same as required for projects registering under the *ICR requirements* only, but noting the following: 1. Reference to the project in the other *GHG program* registry. For dual registration, confirmation from the other *GHG program*. 2. The latest version of the PDD and MR from the other *GHG program* and the latest version of ValR and VerR shall be uploaded to the *ICR registry*. 3. Submission of the reason for transfer, renewal of *crediting period* or dual *registration* with ICR. The reason for *transfer* shall be in a formal letter and will become public document. 4. The proponent shall further complete the ICR PDD template by providing information in the following sections in addition to the cover page. * 1.1 - 1.12 * 2.1 – 2.2 * 4.1 – 4.4 5. During the next *verification* event, the *VVB* shall complete *validation* on conformity to the *ICR program* criteria, i.e., ICR requirement document and *ISO 14064-2*, and if the project follows a methodology that is listed under the ICR approved methodologies the applied methodology 6. If the project remains registered with another *GHG program* and has completed *monitoring* and *verification* which the proponent intends to split up the *GHG emission mitigations* between the *ICR program* and the *approved GHG program*. The proponent shall provide evidence that any *GHG emission mitigations* presented for *ex-post ICCs* *issuance* have not been and will not be issued as an *instrument* under another *GHG program* or scheme or if such instruments have been issued under the *GHG program* or scheme that they have been cancelled. The *project proponent* shall also sign and submit to ICR a formal letter of conversion to *ex-post ICCs* and provide evidence of *cancellation* and follow section 5.8 of the ICR requirement document. 7. Projects subject to *non-permanence* risk are subject to section 8.5.2 above and 6.8.2 in the ICR requirement document. A risk assessment determines the *non-permanence* deposit and shall be applied to the *ex-post ICCs* to be issued under the *ICR program* and deposited to the *non-permanence* *adjustment account*. 8. When a project, previously registered with another *GHG program*, seeks a renewal of the *crediting period* with the ICR, the PDD shall be updated using the ICR PDD template with relevant sections complete, as set out in the ICR requirement document and following instructions in the ICR PDD template. The *criteria* for *validation* shall be according to the *ICR program*. For the renewed crediting period, the ICR *crediting period* applies, and the project shall conform to *ICR requirements*. Further, the project shall follow section 7 of the project cycle. 9. If projects have created another form of *GHG*-related environmental instruments, such as renewable energy certificates, evidence shall be provided to ICR demonstrating that the *GHG emission mitigations* presented for *ex-post ICCs* *issuance* have not also been recognized as another *GHG*-related environmental *instrument* or that any such *instrument* has not been used and have been cancelled under the relevant program. Especially considering section 5.8 of the ICR requirement document. ### Withdrawal If a *project proponent* wishes to withdraw a project from *ICR program* (e.g. to transfer the project to another *GHG program*), the following applies: 1. The *project proponent* shall request formally that the project requests to be withdrawn from ICR. The letter shall, for a minimum, include the following: 1. Project name 2. Project ID 3. Reason for withdrawal 4. Signature of the *authorized representative* of the project. 2. ICR reviews the request and may request further information, e.g., outstanding fees payable or outstanding *ex-ante ICCs* have been transferred and not been converted to *ex-post ICCs* or *ex-post ICCs* have been transferred and not retired. 3. If *ex-ante ICCs* have been transferred and have not been converted to *ex-post ICCs*, ICR may reject the request or require the *project proponent* to compensate for any *ex-ante ICCs* that have not been converted to *ex-post ICCs*. 4. Upon approval of the request, the project's status is updated to "Withdrawn" in the *ICR registry*, and details of the withdrawn project remain publicly available. The letter of withdrawal will by publicly availably along with ICR confirmation for withdrawal. 5. The confirmation may be subject to conditions, e.g. limits to certain vintages, deductions, or public announcement of withdrawal. 6. Any ICCs deposited to *adjustment account*s cannot be reimbursed for the withdrawn project. 7. The process shall, from the time of submission of withdrawal, not exceed four weeks, subject to responses from the proponents to ICR clarification requests. *Figure 29: Project withdrawal.* 1. Withdrawn projects may rejoin the ICR subject to a formal letter requesting re-*registration* and updated documentation. 1. PDD or PDDMR 2. New Valr or VVR 3. any methodology-specific documentation or other applicable documentation. 4. Other documentation as per section 7.5 2. ICR reviews the documentation according to section 7.5 and determines if the project is eligible for re-registration. ICR reserves all right to deny re-registration. If the project is accepted, its status is updated accordingly and all relevant information becomes public, i.e. request to rejoin, PDD/PDDMR, ValR/VVR, other documentation. ### Validation and verification bodies All projects are subject to *validation* of projects and mitigations are subject to *verification*. *Validation*/*verification* bodies (*VVBs*) assess projects for conformity to ICRs requirements, *ISO 14064-2*. *VVBs* are qualified, independent third parties that ICR approves for *validation* and *verification* based on their accreditation. *Validation* and *verification* bodies are eligible to provide *validation* and *verification* services under the ICR if they have signed an agreement with ICR and are accredited under an ICR *approved GHG program* and/or accredited under *ISO 14065* by an accreditation body that is a member of the International Accreditation Forum (IAF). ### Approval process *Figure 30: VVB approval* *VVBs* meeting the *criteria* may apply to be approved as a *VVB* under the *ICR program* following: #### Application An *authorized representative* of the *VVB* completes an application form available on ICR's documentation page and submits it to ICR along with supporting evidence of accreditation. #### Application review ICR confirms receipt of the application within 24 hours, reviews the application for completeness, and further requests the *VVB* to sign up for the *ICR registry* and create a registry *account* and complete KYC and KYB. If improvements are needed, the applicant is informed. The process continues when KYC and KYB have been completed. #### Approval meeting ICR suggests an introductory meeting for ICR to introduce the *ICR program*, the program documentation, registry platform, and the role of *VVBs* and responds to questions from the *VVB*. After the meeting ICR shares a standard *VVB* agreement for review. #### VVB agreement signing If both parties agree upon the terms of the *VVB* agreement, it is electronically signed by both parties, formalizing the contractual relationship between the parties and disclosing the terms and conditions of the relationship. #### Information ICR will provide the details of the *VVB* on its registry *account*, *sectoral scope* of accreditation, and other relevant information. The *authorized representative* will be assigned an *admin* role for the *account*. Further, the *VVB* is added to the project *registration* form in the *ICR registry* as an option for *VVB*. #### Status of approval If the *VVB* does not comply with the terms and conditions of the *VVB* agreement, ICR may suspend or terminate the agreement. In such cases, ICR will change the status of approval and remove from the project registration form as *approved VVB.* ### Validation Details about *validation* is outlined in ICR *validation* and *verification* specifications. *VVBs* validating projects and *ex-ante* estimation of *GHG emission mitigations* and requesting *registration* with the ICR shall follow ICR *validation* and *verification* specifications in addition to *ISO 14064-3* when validating projects intending to register with the ICR. ### Verification Details about *verification* is outlined in ICR *validation* and *verification* specifications. *VVBs* verifying *monitoring reports* and ex-post *GHG emission mitigations* shall follow ICR *validation* and *verification* specifications in addition to *ISO 14064-3* when verifying projects' *GHG emission mitigations* and intending to *issue* *ex-post ICCs* with the ICR. ### Assessment of conformity The project registration, *issuance*, activation, or project *crediting period* renewal request process may be subject to an assessment of conformity by ICR. An assessment may be initiated at ICR's sole discretion. ### Routine assessment ICR may, at its discretion, undertake an assessment of registration, *issuance*, activation, or project *crediting period* renewal request, to safeguard conformity to the principles and *ICR program* requirements. If ICR undertakes such an assessment, ICR informs the *project proponent* and the *VVB* before any inspection is conducted. Any findings raised during the assessment shall be addressed before further actions are completed in relation to the project. The assessment may include sampling of *ICR requirements* conformity or a detailed assessment where all relevant *ICR program* requirements are assessed relating to the project activities and *VVB* assessment. If no issues are raised during the assessment, ICR informs the *project proponent* and the *VVB* thereof and no further actions are needed. ICR may, at its sole discretion, decide to outsource the assessment. Where the assessment of conformity is initiated due to routine operation or internal audit ICR bears the cost of the assessment. #### Non-conformities If non-conformities are identified during the assessment, the *project proponent* and/or the *VVB* shall respond to the non-conformities raised by ICR. All communications shall be in writing by electronic means. Where significant non-conformities are identified during the assessment, ICR informs the *project proponent* and/or the *VVB* and requests *corrective action* and/or clarification. 1. The *project proponent* and/or the *VVB* shall provide a written response to each *non-conformity,* undertake, or ensure that the *project proponent* undertakes, as appropriate, improvements to the documentation or other measures if necessary and submit all revised documents to ICR. Follow-up actions of the *VVB* and/or *project proponent* shall include as applicable: 2. Detailed response to the findings raised. 3. Root cause analysis. 4. *VVB* or project proponent, as appropriate, shall revise project documents and implement *corrective actions.* 5. The *project proponent* and the *VVB* upload revised project documentation to the registry. 6. If the *project proponent* and/or the *VVB* fails to address findings within 60 *business days*, ICR reserves the right to assume that the proponent does not intend to pursue further actions. If ICR determines this to be the case, requests are not accepted, and ICR notifies the *project proponent* and the *VVB*. 7. If findings are significant and not corrected to the satisfaction of ICR, ICR may conclude that the project has failed to demonstrate conformity to the principles, *ICR program* requirements, and/or applied methodology, and further registration, *issuances*, or activations are suspended until further notice or entirely withdrawn. ICR notifies the *project proponent* and the *VVB*. ### Integrity assessment At its discretion, ICR may review registered projects, issued ICCs (*ex-ante* and/or ex-post) if ICR has concerns about project conformity to the principles, *ICR requirements*, and/or the applied methodology. Any of the following may initiate a review: 1. *VVB* identifies an error or quality *issue* in a previous *validation* or *verification* (see section 10 of ICR *validation* and *verification* specifications and *ISO 14064-3*. 2. A *project proponent* identifies an error or quality *issue* after registration, *issuance*, or activation. 3. *Interested party* has concerns about a registered project. 4. ICR identifies error(s) or quality issues as part of routine operations or internal auditing. 5. Other applicable concerns. The assessment may include focusing of areas of concerns raised or a detailed assessment where all relevant *ICR program* requirements are assessed relating to the project activities and the *VVB* assessment. If an assessment of conformity is initiated, ICR informs the *project proponent* and the *VVB* of the review and may impose temporary sanctions on ICC transfers from the registry *account* and/or postpone further *issuance*/*activation* while the assessment is performed. Any findings raised during the assessment shall be addressed before further actions are completed in relation to the project. If no issues are raised during the assessment, ICR informs the *project proponent* and the *VVB* thereof and no further actions are performed, and sanctions lifted. ICR may, at its sole discretion, decide to outsource the assessment. The *project proponent* pays all costs associated with the assessment of conformity when it relates integrity assessment. #### Non-conformities If non-conformities are identified during the assessment, the *project proponent* and/or the *VVB* shall respond to the non-conformities raised by ICR. All communications shall be in writing by electronic means. Where significant non-conformities are identified during the assessment, ICR informs the *project proponent* and/or the *VVB* and requests *corrective action* and/or clarification. 1. The *project proponent* and/or the *VVB* shall provide a written response to each *non-conformity*, undertake, or ensure that the *project proponent* undertakes, as appropriate, improvements to the documentation or other measures if necessary and submit all revised documents to ICR. Follow-up actions of the *VVB* and/or *project proponent* shall include as applicable: 2. Detailed response to the findings raised. 3. Root cause analysis. 4. *VVB* or project proponent, as appropriate, shall revise project documents and implement *corrective actions*. 5. The *project proponent* and the *VVB* upload revised project documentation to the registry. 6. If the *project proponent* and/or the *VVB* fails to address findings within 60 *business days*, ICR reserves the right to assume that the proponent does not intend to pursue further actions. If ICR determines this to be the case, requests are not accepted, and ICR notifies the *project proponent* and the *VVB*. 7. If findings are significant and not corrected to the satisfaction of ICR, ICR may conclude that the project has failed to demonstrate conformity to the principles, *ICR program* requirements, and/or applied methodology, and further registration, *issuances*, activations or transfers are suspended until further notice or entirely withdrawn. ICR notifies the *project proponent* and the *VVB*. ### Further actions When severe issues are ongoing and *non-conformity* to the principles, *ICR program* requirements, and/or, where relevant, applied methodology exists, ICR may suspend future *issuances* of ICCs and/or *registration* and impose sanctions to transfers of any affected ICCs. If ICR determines that ICCs have been issued in excess of the actual *GHG emission mitigations*, the following applies: 1. The *project proponent* shall deposit ICCs on ICR's escrow account. 1. Where excess ICCs remain in the project proponent's registry *account*, and it can be demonstrated that they have not been used for compensation purposes, immediate deposit to *ICR escrow account* and *cancellation* of the ICCs. 2. Replacement of ICCs through immediate cancelation from subsequent *issuances* of ICCs from the project. If the *project proponent* has no holding on its registry *account*, deductions shall transfer to the subsequent *issuances* of ICCs. 3. Purchase by the *project proponent* of an equivalent number of replacement *ex-post ICCs* or instruments determined to be equivalent to the affected ICCs and *cancellation* of the same within 60 *business days* of receiving formal ICR notification of such required action. 2. Where the *project proponent* fails to compensate for excess *issuance*, ICR may act against it, including applying sanctions with respect to its registry *account* activities until such time as the excess *issuance* has been compensated. ICR will, if applicable, inform the relevant accreditation body of its findings. If the assessment of conformity relates to *validation* and/or *verification*, the *project proponent* shall not bear the cost of any additional assessment. ### Miscellaneous ### Representation All project proponents need to submit a *representation deed* to the ICR. The purpose of a *representation deed* is to establish an authorized representation for a project by appointing a focal. This representative is selected by the project proponent(s) to serve as their focal in matters concerning a project and/or the organizational *account*(s). Templates for *representation deed*s are available on the ICR documentation page. Where multiple project proponents are involved, they all need to sign the *representation deed*, which is then submitted to the ICR and the registry platform. The focal can either be a third party or selected from among the project proponents themselves. A communications agreement can also be used to appoint representation authority for projects with a single proponent. To revoke the authority of representation, the sole *project proponent* (in single proponent projects) or all the proponents (in multi-proponent projects) shall provide a signed written notice of this termination to ICR. Following this, the project proponent(s) need to adhere to the stipulations above to create a new *representation deed*, as applicable. The new *representation deed* overrides any previous (terminated) representation of the project. At any given time, a project may only have one designated focal, as determined through the *representation deed*. The focal shall appoint individual users from the registry platform who are allowed to act as *authorized representatives* for the project. The *authorized representatives* are identified as "admin" in the registry platform of each project. ### Monitoring and reporting Project details may be updated regularly by the project proponent, and as necessary, further information on reasons may be provided. Any changes to the validated PDD shall be documented and submitted as soon as they occur. An updated PDD shall be uploaded to the registry, along with an updated ValR as applicable. Project proponents shall respectfully submit MR and VerR following the *monitoring* and *verification* plans. If the *project proponent* fails to submit a MR and/or VerR to the registry within six months according to the *monitoring* plan and *verification* plan, the following applies: 1. ICR requests evidence from the *project proponent* showing that the project is still active. 2. The *project proponent* shall submit reason for the delay and objective evidence of ongoing operations within 60 days of receiving the request. If the *project proponent* fails to confirm continuing implementation/operation, ICR may act against the proponent, including applying sanctions regarding its registry account activities until continuing implementation/operation has been confirmed. When a project has not submitted a MR and VerR for 12 months according to the *monitoring* and *verification* plan, the project is identified as inactive. ### Media Project proponents may upload media to the registry platform. Allowed form of media are images, videos or presentations. The *project proponent* shall guarantee that all media shared relate directly to the project and should be connected to any information that are available in the project documentation. If the media doesn’t relate to the project or its activities ICR reserves all right to delete the media from the registry platform. Where a project or a proponent has repeatedly shared media unrelated to the project or its activities ICR may remove all media shared on the project profile and prevent further sharing of media. ### Insights Project proponents may use the insights feature in the registry platform to share information about project activities. Note that insights shall be used conservatively, and when sharing insights about a project, they shall relate to that particular project. Images and videos shared shall directly relate to the project and include geo-location in the image or video file. If ICR discovers that the insights and media don’t relate to the project ICR reserves all right to delete the insight from the registry. Where a project or a proponent has repeatedly shared insights unrelated to the project or its activities ICR may remove all media and insights shared on the project profile and prevent further sharing of insights. Project proponents, developers, *VVBs*, or other organizations may use the insights feature to share insights about their *organization* unrelated to specific projects. When doing so, they shall choose that the insight is posted on behalf of the organization, not a project. ### Public comments *Stakeholders* may submit comments about any project activities. Such comments shall be submitted to . Comments may also be submitted via the projects page on the registry platform. Only users that are verified (have completed KYC) may comment on the live project page. Comments received are shared with the project proponent, and the *VVB* performing *validation*/*verification*. Where the *VVB* has not been contracted, ICR shares comments received with the project proponent, and he shall provide the comments and any actions taken or comments responses to the *validation*/*verification* body. Any comments received shall be addressed at the current or subsequent *validation* or *verification* unless ICR determines that an assessment of conformity is required, as described in section 13 above. ### Exemptions Proponents or *VVBs* may apply for exemptions from the stipulations in the ICR requirement document, ICR process requirements or ICR *validation* and *verification* specifications where the project can’t conform to the requirements stated or the *validation*/*verification* procedures prescribed can’t be met. Exemption shall be submitted in a formal letter and submitted to the ICR to . When considering exemptions, ICR takes due account that the exemption doesn’t affect the principles stated in section 4, should affect compliance to *ISO 14064-2*, *ISO 14064-3* and *ISO 14065* or sets a precedent that affects the overall integrity of the *ICR program*. All exemptions are public for the relevant project granted such an exemption. ### Appendix – Document history | Version | Date | Comment | | ------- | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 2.0 | 11.8.2021 | Initial version under version 2.0. | | 3.0 | 6.1.2022 |

Main changes:

  • Transition requirements from other GHG programs amended
  • Definitions amended, consistency referring to defined terms

Flowcharts improved for clarity

| | 4.0 | 14.10.2022 | Alignment with revision of ICR requirements document and ICR methodology requirements in October 2022. | | 4.1 | 28.2.2023 | Update due to new platform | | 5.0 | 6.2.2023 | Alignment with of ICR requirement document v.5.0 and ICR *validation* and *verification* specifications v1.0. Better alignment with *ICR registry* platform, processes to address *reversal* events and non-performance. | | 6.0 | 15.10.2024 |

Process for applications for exemptions from ICR requirements.

Reversal replaced with non-permanence. Adjustment account allocations details, Corresponding adjustment account allocation. Better alignment with structure of other ICR documentation. Procedures updated with revision to ICR requirement document and other relevant documentation.

After public consultation language made clearer especially relating to ex-ante ICC issuance and conversion to ex-post ICCs, post verification and compensation mechanisms for non-performance and non-permanence events. Diagrams updated.

Appendix added for examples for compensation for non-performance events.

| ### Appendix II – Ex-ante ICCs conversion to ex-post ICCs A project with start date 1.6.2023 will generate 150,000 t *CO2-e* over the *crediting period* of 15 years. *Verification* will be yearly. Joint *validation* and *verification* are conducted for the *monitoring* period 1.6.2023 – 1.1.2025. Assume that the project has not been insured for non-performance and thus only eligible to *issue* 50% of the validated estimation and no permanence risk. Table AII1: *Issuances* at *validation* and *verification*. | **Year** | **Validated** | **Ex- ante ICCs issued** | **Non-performance adjustment deposit** | **Delivered to proponent** | ***Ex-post ICCs*** | | --------------- | ------------- | ------------------------ | -------------------------------------- | -------------------------- | ------------------ | | 2023 (6 months) | 5,000 | - | - | - | 5,000 | | 2024 | 10,000 | - | - | - | 10,000 | | 2025 | 10,000 | 5,000 | 100 | 4,900 | - | | 2026 | 10,000 | 5,000 | 100 | 4,900 | - | | 2027 | 10,000 | 5,000 | 100 | 4,900 | - | | 2028 | 10,000 | 5,000 | 100 | 4,900 | - | | 2029 | 10,000 | 5,000 | 100 | 4,900 | - | | 2030 | 10,000 | 5,000 | 100 | 4,900 | - | | 2031 | 10,000 | 5,000 | 100 | 4,900 | - | | 2032 | 10,000 | 5,000 | 100 | 4,900 | - | | 2033 | 10,000 | 5,000 | 100 | 4,900 | - | | 2034 | 10,000 | 5,000 | 100 | 4,900 | - | | 2035 | 10,000 | 5,000 | 100 | 4,900 | - | | 2036 | 10,000 | 5,000 | 100 | 4,900 | - | | 2037 | 10,000 | 5,000 | 100 | 4,900 | - | | 2038 (6 months) | 5,000 | 2,500 | 50 | 2,450 | - | After 5 years the project has been verified yearly, confirming the following *GHG emission mitigations*: Table AII2: *Verification* and conversion to *ex-post ICCs*. | **Year** | **Verified** | **A: Ex- ante issued** | **Difference (*****ex-post ICC*** ***issuances*****)** | ***Ex-ante***** -> *****ex-post ICC*** | ***Ex-post ICCs***** post *****verification*** | | --------------- | ------------ | ---------------------- | ------------------------------------------------------ | ------------------------------------------------ | -------------------------------------------------------- | | 2023 (6 months) | 5,000 | 0 | 0 | 0 | 5,000 | | 2024 | 10,000 | 0 | 0 | 0 | 10,000 | | 2025 | 11,000 | 5,000 | 6,000 | 5,000 | 11,000 | | 2026 | 9,000 | 5,000 | 4,000 | 5,000 | 9,000 | | 2027 | 12,000 | 5,000 | 7,000 | 5,000 | 12,000 | | 2028 | 5,000 | 5,000 | 0 | 5,000 | 5,000 | | 2029 | 4,500 | 5,000 | -500 | 4,500 | 4,500 | Further the non-performance *adjustment account* has benefited from the *ex-ante* ICC to *ex-post ICC* conversion. Table AII3: Non-performance *adjustment account* inventory in year 2029 | **Year** | **Non-performance *****adjustment account***** inventory (*****ex-ante ICCs*****)** | **Non-performance *****adjustment account***** inventory (*****ex-post ICCs*****)** | | --------------- | --------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | 2023 (6 months) | 0 | 0 | | 2024 | 0 | 0 | | 2025 | 0 | 100 | | 2026 | 0 | 100 | | 2027 | 0 | 100 | | 2028 | 0 | 100 | | 2029 | 0 | 100 | | 2030 | 100 | 0 | | 2031 | 100 | 0 | | 2032 | 100 | 0 | | 2033 | 100 | 0 | | 2034 | 100 | 0 | | 2035 | 100 | 0 | | 2036 | 100 | 0 | | 2037 | 100 | 0 | | 2038 (6 months) | 50 | 0 | | **Total** | **850** | **500** | Yearly the following happens Table AII4: Actions for vintages | **Year** | **Actions needed** | ***Ex-post ICCs***** post *****verification*** | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------- | | 2023 (6 months) | No actions applicable (no *ex-ante ICCs* issued) | 5,000 | | 2024 | No actions applicable (no *ex-ante ICCs* issued) | 10,000 | | 2025 | No actions needed verified *GHG emission mitigations* greater that issued *ex-ante ICCs*. Proponent can *issue* 6,000 *ex-post ICCs* after ex-ante ICC to *ex-post ICC* conversion | 11,000 | | 2026 | No actions needed verified *GHG emission mitigations* greater that issued *ex-ante ICCs*. Proponent can *issue* 4,000 *ex-post ICCs* after ex-ante ICC to *ex-post ICC* conversion | 9,000 | | 2027 | No actions needed verified *GHG emission mitigations* greater that issued *ex-ante ICCs*. Proponent can *issue* 7,000 *ex-post ICCs* after ex-ante ICC to *ex-post ICC* conversion | 12,000 | | 2028 | No actions needed verified *GHG emission mitigations* equal to issued *ex-ante ICCs*. Proponent can’t *issue* additional *ex-post ICCs* after ex-ante ICC to *ex-post ICC* conversion | 5,000 | | 2029 | Compensation mechanism initiated as issued *ex-ante ICCs* are greater than verified *GHG emission mitigations*. | 4,500 | For the year 2029 there needs to be a compensation done for excess *issuances* of *ex-ante ICCs*. For this the section 8.5.1.1 applies for the compensation. Figure 3: Compensation hierarchy of non-performance events 1. *VVBs*, ratings agencies, insurance companies and some *stakeholder* types are also identified specifically, but identification is administered by the ICR. ↑ 2. Temporary Organizational *account* may be created during retirements or transfers of ICCs, see section 5.1.2. ↑ 3. Users may also be invited to join projects, see further in section 7 and in the ICR user guide. ↑ 4. NOTE: Authorized representatives may be others than defined as admins to the organization ↑ 5. Note that the draft rationale does not have to include evidence of conformity at this stage and does not need to be publicly available. ↑ 6. Private documentation and confidential information are never published on-chain. ↑ 7. Projects may complete *validation* and *verification* jointly if they have been implemented completed *monitoring* for a monitoring period and completed a PDDMR. ↑ 8. For joint *validation* and *verification* refer to section 7.6 and 7.7 for documentation for *verification* and *issuances* of *Ex-post ICCs* ↑ 9. Information stored on-chain can‘t be removed. No private data or confidential information are disclosed on-chain. ↑ 10. Deposits to adjustment accounts are always made during the *issuance* of ICCs, e.g. if a *project proponent* issues 50% of estimated mitigation outcomes, he shall deposit 2% of the *issuance*, i.e. 2%\*50%=0,1% of the total validated *GHG emission mitigations*. ↑ 11. Additional credits can be added to each *vintage* based on findings in MR and VerR. ↑ 12. *Validation* and *verification* can be reported in a *validation* and *verification report*. ↑ 13. For example: *Verification report* confirms 100.000 t *CO2-e* of *GHG emission mitigations*. 100.000 ICCs are issued and delivered to the proponent’s registry account. The proponent transfers 10.000 ICCs to another *account* or retires on behalf of third party. The proponent is invoiced for *issuance* 10.000 \* Ex-post *issuance* fee at transfer event. ↑ 14. Example: *Non-performance event* is expected to result in 40% of the validated estimated *GHG emission mitigations* for affected vintage. The proponent issued 50% of the validated estimation as *ex-ante ICCs* and transferred 45% to buyers. *Ex-post ICCs* from the non-performance amount to 5%. ↑