# Credit Issuance, Transfer, Retirement ## Credit Issuance {% hint style="warning" %} **The Data Verification Process is covered in much more depth in "**[**Third-Party Validation and Verification: Verification**](/ocp-handbook/projects/third-party-validation-and-verification.md)**"** {% endhint %}
The Credit Issuance process depends on the [**Verification Pathway**](/ocp-handbook/projects/third-party-validation-and-verification.md#selecting-from-the-3-verification-pathways) selected during [**Project Proposal**](/ocp-handbook/projects/project-proposal-process.md). * ***For project where data verification is done in tandem with project validation***: monitored data is submitted with the Project Proposal form. Third-party data verification is done at the same time as project validation. If approved, the project is registered on the OCP and credits are immediately issued to the PD * ***For projects where data verification is done per issuance***: project validation is completed before project registration. On a monitoring event, which are set during project proposal, monitored data is requested from the PD. This data is verified by an independent VVB/Auditor, and checked by the OCP team, before the credit is issued. This process repeats on each monitoring event, up to a frequency of once per year. * ***For projects where a dMRV process is pre-verified***: project validation and dMRV pre-verification is completed before project registration. On a monitoring events, which are set during project proposal, monitored data is requested from the dMRV partner. This data is checked by the OCP team before the credit is issued. This process repeats on each monitoring event, up to a frequency of once per year. Credits are issued **ex-post** i.e. after a monitoring event has taken place, and **all data must be verified** before issuance. #### Credit Information Each credit has the associated information assigned to it: * **Credit Unit ID and Batch ID:** each credit within a batch is fungible if they have (a) the same issuance event, (b) the same ownership/transfer history, and (c) the same status * **Issuance ID** * **Issuance Date**, and corresponding **Vintage** * **Project Information**: * Project ID * Project Name * Project Developer * Project Dates * Location * Methodology version * Reduction or Removal * Sector + Sub-Sector * URL Link to Project Page * **Account Owner** * We require all account owners to have [a KYB account](/ocp-handbook/governance/know-your-business-kyb-anti-money-laundering-aml-anti-bribery-and-corruption-abc.md). * If different, **Beneficial Owner** is also displayed * **History**: tracking from issuance event, all transfers and final retirement/cancellation * **Status:** * Active (after a credit has been validated and issued and is available for transfer) * [Retired](/ocp-handbook/registry/credit-issuance-transfer-retirement.md#credit-retirement) (after a credit has been retired; no further action can be taken) * [Cancelled](/ocp-handbook/registry/credit-cancellation.md) (permanent removal of a carbon credit from the OCP Registry without claiming the associated benefit of the reduction/removal for any voluntary or mandatory target.)
A credit can be traced throughout its lifecycle via the ['](https://pilot.ocp.earth/registry)[Activity' tab on the OCP Registry](https://pilot.ocp.earth/registry). This includes full ownership history, and information on issuances, retirements and cancellations. ## Credit Transfer
* Any Registry User (completed KYB) with carbon credits in their inventory can transfer those carbon credits to another account by requesting a transfer on the OCP platform. * If the requested Buyer does not have an OCP account, they will be invited to sign-up. They will have to go through [KYB](/ocp-handbook/governance/know-your-business-kyb-anti-money-laundering-aml-anti-bribery-and-corruption-abc.md) before they can receive credits. * The PD or Buyer sets the quantity to transfer and the contracted price of the credits upon requesting a transfer. * The first transfer of credit is subject to a transaction fee based on the credit transfer quantity and price sold - see '[Fees and Business Model](/ocp-handbook/governance/fees-and-business-model.md)'. This fee must be paid to the OCP before the credit is transferred to the new inventory. * These credits will be given the status 'on hold' during the transfer process, and cannot be transferred or retired until the process is completed. * Once the Buyer has received the credits, they can transfer to other accounts or retire the credits. ## Credit Retirement
* Any Registry User (completed KYB) with carbon credits in their inventory can retire those credits. * Retiring credits refers to sending credits/tokens to an immutable wallet **from which they can not be retrieved**. This means they can no longer be sent to anyone else, and the benefit is tied to the recorded beneficial owner. * The Registry User submits the following information: * **Retirement Purpose** * *Options*: Corporate Climate Target, Compliance / Regulatory, Insetting, Discretionary, Voluntary Action, and Other * **Beneficial Owner** - optional * If a beneficial owner is not submitted, the Registry User is the beneficial owner. * Beneficial owners will undergo KYB. * All associated retirement information (i.e., beneficiary, credit quantity, and any additional ownership transfers) are made publicly available in the registry, in the 'Retirements' Activity tab, as well as on the associated project page. * [In the event that credits are found to be erroneous, either by grievance submission or during an annual audit, retired credits will be replaced by either the Buffer Pool or Insurance](broken://pages/sXzbmdk3NTxvmCPu9AfB). --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://open-carbon-protocol.gitbook.io/ocp-handbook/registry/credit-issuance-transfer-retirement.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.