GHG quantification

The general GHG reduction quantification approach and components are outlined below. Detailed instructions and requirements can be found in Riverse methodologies.

General guidance

Riverse Carbon Credits shall be calculated by subtracting the GHG emissions and removals of the project scenario from the emissions and removals of a baseline scenario, or reference scenario, that would have occurred without the implementation of the project.

The difference in GHG emissions between the two scenarios (i.e. the emission reductions of the project) translates to the amount of GHG emissions avoided/removed by the project. One RCC is issued per one tonne of CO$_2$ equivalent avoided or removed.

See the Measurability criteria for more general guidance on calculations.

Functional unit

The GHG emissions and removals of both the project and baseline scenario must be normalized to a common functional unit. A functional unit is the reference value to which all impacts are normalized.

The same functional unit must be chosen for the project and baseline scenarios, to ensure functional equivalence and an appropriate comparison between the two scenarios.

Defining a functional unit is especially useful for the industrial, circular greentechs that are covered under the Riverse Standard because projects often have multiple functions, co-products and/or co-services.

Functional units shall include characteristics such as:

• Type of product/service

• Amount

Functional units may include characteristics such as:

• Performance specifications

• Geographic location

• Duration

System Boundary

The system boundary defines which GHG emissions and removals to include in a project scenario, and the equivalent processes in a baseline scenario.

The industrial, greentech projects covered under the Riverse standard are embedded in larger supply chains, with extensive upstream and downstream processes. Defining a system boundary also means delineating where the project scope ends, and which processes to exclude.

Generally, processes included in the project scope are those under direct control of the project, those affected by key decisions of the project, and those that differ between the project and baseline.

See the Project Scope section for more information.

The system boundary shall cover the project scope, and include:

• all processes under direct control of the project and

• the key upstream and downstream processes.

Processes may include raw material extraction, delivery of supplies, processing, manufacturing, distribution, use, retail, distribution, and waste treatment.

Indirect processes, such as market changes or physical displacement, shall be evaluated in the leakage criteria, and included in the GHG reduction quantification when relevant and feasible. Methodologies provide instructions on how to assess leakage and manage and, if necessary, deduct leakage emissions.

Processes with the lowest contributions to impacts, which each account for less than 1% of total impacts, may be excluded from the GHG quantification. These processes shall be transparently identified and justified.

Due to the comparative measurement approach, processes that are identical in the project and baseline scenario may be excluded, since they will not affect the comparative results.

Baseline scenario selection

The baseline scenario represents the GHG emissions and removals that would have occurred in the absence of the project.

The baseline scenario defines the GHG emissions and removals against which a project’s emission avoidance or removal is compared to determine emission reductions.

The baseline scenario should be comprehensive, and be functionally equivalent to all products and services delivered in the project scenario.

The by the World Business Council for Sustainable Development (WBCSD) shall be followed to select the baseline scenario (see figure below).

According to the from the WBCSD, average market solutions shall be assumed by default for the baseline scenario. Only when a project solution is known to substitute one specific technology (e.g. the best available technology, or a product from one specific manufacturer), may the specific technology be used as a baseline.

Conservative assumptions, values, and processes shall be chosen when selecting a baseline scenario, to avoid overestimation of GHG emission reductions. Average market solutions shall be determined based on practices in the country/region of the project, and statistically relevant historical information.

If the project activity is multifunctional, the baseline scenario shall cover all functions of the project.

When the average market solution is represented by a market mix of solutions, the market mix shall include the portion of the project solution that is already used in the market.

The duration of validity of the baseline scenario selection shall be defined in methodologies.

Input data

Project GHG emissions and removals shall be quantified using primary data from project operations for operating projects, or estimated data for planned projects. The estimated data shall be used for project validation, and shall be replaced with actual data once the project begins operations for the verification of emission reductions.

All measurements from the project must be verifiable and based on recent conditions (no more than 1 year old). These measurements include quantities (volume, mass, number) and type of products and inputs.

All background data (for example, emission factors, rates of recycling, composition of national electricity grid) shall be derived from traceable, transparent, unbiased, and reputable sources.

All assumptions and estimates shall be conservative, transparently presented and justified.

For geographic accuracy and consistency across projects, national-level background data should be prioritized. Local (region, state, city-scale) or global sources may be used if justified.

Uncertainty assessment

Uncertainty is inherent in any measurement. The purpose of uncertainty assessment is to:

• identify areas where more effort is needed to improve accuracy,

• identify areas where the most conservative approach is needed, and

• improve transparency

Qualitative estimates of uncertainty shall be justified ranging from none, low, medium, to high. A choice of “None” is only applicable for measurements of primary data that have strong, immutable sources of proof.

Project Developers shall assess uncertainty for the following areas at the project-level:

• assumptions

• selection of the specific baseline scenario

• measurements

• estimates or secondary data used for the project assessment

Methodologies shall include assessments of uncertainty for the following areas at the methodology-level:

• assumptions

• baseline scenario selection guidance

• equations and models

• estimates or secondary data used for all projects under the given methodology

All practical steps must be taken to achieve a low level of uncertainty for each area.

Areas that have high levels of uncertainty shall use the most conservative reasonable option, to avoid overestimation of GHG emission reductions.

Based on the uncertainty levels estimated for the above individual areas, Project Developers shall justify an overall uncertainty estimate of low, medium or high for the project’s GHG emission reductions.

The uncertainty estimate shall account for the sensitivity of the total GHG emission reductions to each assessed area. This way, for example, an area might have high uncertainty, but if that area has a small effect on the total GHG emission reduction calculations, then the level of uncertainty is acceptable and can be considered lower.

The overall uncertainty estimate shall be translated into the discount factor, representing the percent of credits that will not be issued, using the following:

• Low uncertainty: 3%

• Medium uncertainty: 6%

• High uncertainty: 9% or higher