BiCRS methodology

This methodology covers projects that transform and store biomass into a permanent carbon removal solution, also called biomass carbon removal and storage (BiCRS). This methodology is composed of modules, which give more specific requirements and instructions for different parts of project operations. This methodology document provides general requirements and instructions that are relevant for all BiCRS projects, regardless of the specific modules they use.

Methodology name	Biomass carbon removal and storage (BiCRS)
Version	1.0
Methodology ID	RIV-BICRS-GEN-V1.0
Release date	December 4th, 2024
Status	In use

See more details on how modules are organized in the BiCRS home page.

How to use this module

Introduction

It is widely acknowledged that in addition to reducing global greenhouse gas (GHG) emissions, and permanently sequestered. One way to do this is through , which involves a range of technologies that use plant biomass to remove carbon dioxide (CO$_2$) from the atmosphere and store that CO$_2$ underground or in long-lived products.

This methodology document outlines the general requirements for BiCRS projects certified under the Riverse Standard Rules. These projects are eligible for removal Riverse Carbon Credits (RCCs) related to their carbon removals, and avoidance RCCs as a result of generating valuable co-products. Further details for specific technologies are available in module documents.

Eligible activities

All projects certified under this methodology must convert biomass into permanent carbon storage solutions.

Avoidance Riverse Carbon Credits (RCCs) may be issued for eligible project activities, such as energy production.

Any share of removals coming from non-biogenic carbon are not eligible for removal RCCs under this methodology.

Carbon removals shall be ensured for at least 100 years, according to the Riverse Standard Rules permanence criteria. Each project shall transparently disclose their permanence horizon of 100 or 1000+ years.

Technologies that are not detailed in a module, but that meet the general requirements of the present methodology, may be considered on a case by case basis.

Project scope

The default project scope shall be defined in the Carbon storage modules.

Eligibility criteria

The eligibility criteria requirements that are applicable to all projects under this methodology are detailed in the sections below. Other eligibility criteria requirements shall be taken from the accompanying modules and Riverse Standard Rules:

BiCRS methodology

• Additionality

• No double counting

• ESDNH

• Targets alignment

Other modules

• Permanence

• Substitution

• Co-benefits

• No double counting

• ESDNH

Riverse Standard Rules

• Measurability

• Real

• TRL

• Minimum impact

Additionality

To demonstrate additionality, Project Developers shall perform regulatory surplus analysis, plus either investment or barrier analysis, using the Riverse Additionality Template.

Regulatory surplus analysis

Regulatory surplus analysis shall demonstrate that there are no regulations that require or mandate project activities (for removal and avoidance activities). It is acceptable if regulations promote or set targets for these activities, because the resulting increase in activities shall be accounted for in the baseline scenario.

At the European Union level, projects automatically pass the regulatory surplus analysis, which has been conducted by the Riverse Climate Team. Project Developers are only required to provide a country-level regulatory surplus analysis.

Investment analysis

Investment analysis may be used to prove that revenue from carbon finance is necessary to make the project investment a financially viable and interesting option. The investment may cover:

• The creation and launching of new sites

• Expansion of capacity of existing activities

• Expansion by installing new processes

Business plans shall be provided as initial proof for investment analysis. During verification, audited financial statements shall be used to demonstrate that the initial estimates from the business plan were reasonable, and that carbon finance was used as initially described for the expected investment.

For launching brand new sites, additionality can be simply demonstrated if the business plan shows that carbon finance is expected to make up at least 80% of the company’s revenue, as detailed in the Riverse Additionality Template.

Note that for investments in expansion, only the additional carbon reductions enabled by the expansion shall be eligible for Riverse Carbon Credits.

Barrier analysis

Barrier analysis may be used to prove that the project faces financial, institutional, or technological barriers to ongoing operations that can only be overcome using carbon finance. Examples include but are not limited to:

• Financial barrier: financial analysis demonstrating that the project is not financially viable, evidenced by net cash being lower than the working capital requirements, or proof that the project is not meeting the projected financial targets in the business plans and loan documents, and that carbon finance would make it financially viable.

• Institutional barrier: description of new regulation that the project must make costly changes to comply with, financial analysis showing that the project cannot fund the changes on their own, and carbon finance is necessary to make it viable.

For any type of barrier analysis, audited financial statements must be provided as proof. These documents should either demonstrate the financial status to prove financial barriers, or show that the project could not independently fund solutions to overcome institutional or technological barriers.

No double counting

Project Developers shall sign the Riverse MRV & Registry Terms & Conditions, committing to follow the requirements outlined in the Riverse Standard Rules, including not double using or double issuing carbon credits.

BiCRS projects have a risk of double issuance of credits if the user of the removal solution and/or operator of the storage site also seeks credit issuance. Project Developers shall:

• Identify all direct downstream users/buyers/actors in their supply chain, providing the company/organization name, name of an individual contact person at the company/organization, and their contact information (email address at minimum).

• Provide proof that measures have been taken to avoid double issuance with those actors, such as through signed agreements, packaging/marketing material stating carbon credits have already been issued, and/or sales contract clauses.

If the Project Developer proves that the removal solution stays within the project scope all the way through storage, and it is never sold or transferred, then the requirements above may be disregarded.

At the validation stage for projects under development, this information may not be determined yet. In this case, upon validation Project Developers shall describe any information available on the expected buyers, and provide signed agreements committing to provide the necessary information upon verification. During the verification stage, Project Developers shall provide the information described above in order to issue RCCs.

Environmental and social do no harm

ESDNH risk evaluation

Project Developers shall fill in the General BiCRS risk evaluation, in addition to all module-specific risk evaluations, to evaluate the identified environmental and social risks of projects. The General BiCRS risk evaluation contains the Minimum ESDNH risks defined in the Riverse Standard Rules.

Project Developers shall assign a likelihood and severity score of each risk, and provide an explanation of their choices. The VVB and Riverse’s Certification team shall evaluate the assessment and may recommend changes to the assigned scores.

All risks with a high or very high risk score are subject to a Risk Mitigation Plan, which outlines how Project Developers will mitigate, monitor, report, and if necessary, compensate for any environmental and/or social harms.

Additional proof may be required for certain high risk environmental and social problems.

The Project Developer, the Riverse Certification team, or the VVB may suggest additional risks to be considered for a specific project.

Note that the life-cycle GHG reduction calculations account for the climate change impacts of most environmental risks. Nonetheless, Project Developers shall transparently describe any identified GHG emission risks in the risk evaluation template.

All risk assessments must also address the Minimum ESDNH risks defined in the Riverse Standard Rules.

Targets alignment

BiCRS projects that issue avoidance RCCs must prove that they lead to at least the following GHG emission reductions compared to the baseline scenario, which are aligned with the European Union’s 2040 Climate target and described in the Riverse Standard Rules.

• Biochar use in concrete: 73%

• Biochar replacement of peat or horticultural products: 58%

• Energy co-products: 45%

The scope of the reduction is the system boundary used in GHG quantification, described in the Baseline scenario and Project scenario sections below.

This shall be proven using the GHG reduction quantification method described below and in the relevant modules.

This eligibility criteria may be disregarded for projects that only issue removal RCCs.

GHG quantification

General GHG quantification rules can be found in the Riverse Standard Rules.

Process-specific GHG quantification rules can be found in the accompanying BiCRS carbon capture, transformation, and carbon storage modules.

The net removals for a project shall be calculated by summing the emissions and removals of each module used by that project.

Calculations of GHG emissions for the baseline and project scenarios shall follow a robust, recognized method and good practice guidance. The overall methodological approach is a comparative life cycle assessment (LCA) at the project-scale, based on .

BiCRS projects may be eligible for removal and avoidance Riverse Carbon Credits. Removal and avoidance RCCs are calculated and issued according to two completely separate accounting mechanisms, described below. This conservative approach results in double counting the project's induced emissions, and avoids the need for allocation of emissions/removals.

GHG quantifications shall be completed either for each batch (batches are defined in the relevant carbon storage modules), or for each calendar year. Carbon storage module documents may provide specific requirements.

Functional unit

The functional unit shall be 1 tonne of carbon storage solution (e.g. 1 tonne of biochar spread on soils, 1 tonne of biomass buried...).

Co-product allocation

BiCRS projects may result in multiple products in addition to the primary carbon storage component. Emissions from multifunctional processes shared among co-products may be allocated across the respective products. However, emissions from processes exclusive to a single product (e.g., dedicated delivery of carbon storage products) must be fully attributed to that product.

If the co-product is a nonvaluable waste, then no allocation is required and all GHG emissions are allocated to the main product.

If the co-product is valuable and eligible for avoidance RCCs, then no allocation is performed, and process emissions are counted towards both the avoidance GHG accounting and the removal GHG accounting. This is a conservative approach to separately handling removal and avoidance accounting schemes.

If the co-product is valuable and eligible for removal RCCs, then emissions may be allocated to between the co-products. It is best practice to perform allocation based on an underlying characteristic that best represents the main function of the products. Here the main function is carbon removal, so allocation shall be based on the proportion of carbon removal of the two products, in tonnes of carbon.

For example, if a project's main function is to produce biochar via pyrolysis, they may generate syngas and/or bio-oil co-products.

Syngas example

The syngas could be used to produce and export electricity to the grid and be issued avoidance RCCs. Syngas and biochar production share processes such as feedstock production and transport, feedstock shredding, and starting the pyrolyzer. Emissions from these processes would be included in both the removal RCC quantification and avoidance RCC quantification. However, emissions from biochar transport to a farm for spreading would not be accounted for in the syngas avoidance quantification, because it is not a shared process.

---

Bio-oil example

The bio-oil could be used for carbon removal and be issued removal RCCs. If the total carbon storage from bio-oil is 400 tonnes CO$_2$eq and from biochar is 600 tonnes CO$_2$eq, then 40% of the GHGs from shared processes would be allocated to bio-oil, and 60% would be allocated to biochar.

Baseline scenario

A baseline scenario must be included for any project that issues avoidance RCCs. The baseline scenario represents the GHG emissions from the product or activity that is avoided by the project activity, i.e. the GHG emissions that would have occurred in the absence of the project.

Baseline scenarios may be included for projects that issue only removal RCCs, for example from biomass feedstock carbon capture. The baseline scenario represents the permanent carbon removals that would have occurred anyway, without the project intervention.

Specific instructions for definition and modeling of baseline scenarios are available in the relevant module documents.

The baseline scenario structure remains valid for the entire crediting period but may be significantly revised earlier if:

• The Project Developer notifies Riverse of a substantial change in project operations or baseline conditions, and/or

• The methodology is revised, affecting the baseline scenario.

The specific values within the baseline scenario will be updated annually, using project data to accurately reflect the equivalent of the project’s annual operations.

Project scenario

Modules include specific instructions on calculating GHG emissions and removals for the relevant processes.

Each project must use at least one module from the following categories: carbon capture, transformation and carbon storage.

Calculations - Removals

$\textbf{(Eq.1)}\ Net\ R = \Sigma{R}_{P, Storage} - \Sigma{R}_{B,\ Capture}-\Sigma{E}_{P,\ Capture} - \Sigma{E}_{P,\ Transformation}- \Sigma{E}_{P, Storage}$

where,

• $Net R$ represents the net removals from the project during the verification period, in tonnes of CO$_2$eq.
• $R_{P,\ Storage}$ represents the project's GHG removals from the storage module(s) used by the project.
• $R_{B,\ Capture}$ represents any baseline GHG removals from the capture module(s), representing permanent storage that would have occurred in the absence of the project.
• $E_{P,\ Capture}$ represents the project's GHG emissions from the capture module(s) used by the project.
• $E_{P,\ Transformation}$ represents the project's GHG emissions from the transformation module(s) used by the project.
• ${E}_{P, Storage}$ represents the project's GHG emissions from the storage module(s) used by the project.

Calculations - Avoidance

$\textbf{(Eq.2)}\ E_{project} = \Sigma{E}_{P,\ Capture} + \Sigma{E}_{P,\ Transformation} + \Sigma{E}_{P,\ Storage}$

where,

• $E_{project}$ represents the induced GHG emissions from the project during the verification period, in tonnes of CO$_2$eq. It does not account for any carbon removals in the storage modules.
• $E_{P,\ Capture}$, $E_{P,\ Transformation}$ and ${E}_{P, Storage}$ were described in Equation 1.

$\textbf{(Eq.3)}\ E_{baseline} = \Sigma{E}_{B,\ Capture} + \Sigma{E}_{B,\ Transformation} + \Sigma{E}_{B,\ Storage}$

where,

• $E_{baseline}$ represents the GHG emissions from the baseline scenario during the verification period, in tonnes of CO$_2$eq.
• $E_{B,\ Capture}$, $E_{B,\ Transformation}$ and ${E}_{B, Storage}$ represent GHG emissions from any baseline scenario created in the respective modules.

$\textbf{(Eq.4)}\ E_{avoided} = E_{baseline} - E_{project}$

where,

• $E_{avoided}$ represents the avoided GHG emissions from the project scenario, in tonnes of CO$_2$eq.
• $E_{baseline}$ was calculated in Equation 3.
• $E_{project}$ was calculated in Equation 4.

Risk evaluation template

👉 Download the template here