> For the complete documentation index, see [llms.txt](https://open-carbon-protocol.gitbook.io/ocp-methodology-requirements/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://open-carbon-protocol.gitbook.io/ocp-methodology-requirements/sections/4.-additionality.md).

# 4. Additionality

### 4.1 Core Principle of Additionality

Carbon reductions or removals are only additional if they would not have happened without revenue from selling carbon credits (i.e. carbon financing).

**Each methodology must define a conservative business-as-usual (BAU) scenario representing realistic baseline conditions absent of carbon credit revenues.** Credited outcomes must demonstrably exceed this BAU scenario, and baseline assumptions must be conservative where uncertainty exists.

### 4.2 Minimum Additionality Tests

The additionality tests set out in this section represent minimum evidence requirements.

When using the methodology, project developers must be able to prove that the emission reduction/removal would not have occurred without Carbon Financing in the Baseline Scenario.  

The methodology must include detailed instructions on how developers can calculate whether their project is additional using the four additionality tests below. Some project activities may 'automatically' pass one of more of the tests and therefore specific project documentation is not required; however this must be explained in the methodology.

{% stepper %}
{% step %} <mark style="color:$success;">**Financial Additionality**</mark><mark style="color:$success;">: Are project activities financially viable and attractive without carbon revenues?</mark>

**If the project's only source of revenue is Carbon Finance:** projects are financially additional and do not have to show further analysis.

**If the project has sources of revenue other than Carbon Finance** (including government subsidies or tax credits), a project must show either:\
\
a) The project is **not financially viable without Carbon Finance** >> [FINANCIAL ADDITIONALITY ANALYSIS](#financial-additionality)\
\
b) There are **economic barriers** preventing the project activity from taking place >> [BARRIER ANALYSIS](#barrier-analysis)
{% endstep %}

{% step %} <mark style="color:$success;">**Policy & Regulatory Surplus:**</mark> <mark style="color:$success;"></mark><mark style="color:$success;">Are there regulations or incentives that enforce or encourage the project activity?</mark>

Project Developers must demonstrate that the Project is not already required by existing laws, regulation or other binding obligations. \
\
If there are relevant laws or regulations that are not being enforced, Project Developers must provide evidence or research into lack of enforcement or compliance.
{% endstep %}

{% step %} <mark style="color:$success;">**Common Practice:**</mark> <mark style="color:$success;"></mark><mark style="color:$success;">Are activities similar to those implemented by the project typical in the geography?</mark>

Project Developers must demonstrate that the Project activity is not Common Practice. Methodologies should set a scope and *Common Practice Threshold*, which Projects should assess against during Project Proposal >> [COMMON PRACTICE ANALYSIS](#common-practice)
{% endstep %}

{% step %} <mark style="color:$success;">**Economic & Other Additional Assessments**</mark>

Depending on the activity type, market context, and risk of non-additionality, methodologies are required to apply additional tools, including but not limited to barrier analysis, performance standards/benchmarks, or economic viability assessments.

[>> PERFORMANCE STANDARD ANALYSIS](#performance-standard)
{% endstep %}
{% endstepper %}

Expert reviewers will assess whether the combination of tests applied is appropriate and sufficient to demonstrate that credited outcomes exceed a conservative BAU scenario.

It is important to note that the components above do not always have obvious yes/no answers. It is up to the methodology author and expert panel to decide the ‘cut-off’, and the project validator to confirm each project is additional above what is set out in the methodology.

#### Specific Additionality Tests

{% tabs %}
{% tab title="Financial IRR" %}
If the Project activity has potential non-Carbon Finance sources of revenue (including government subsidies or tax credits), the Project Developer must submit Project financials, including a calculation of the Internal Rate of Return (IRR) of the Project. [IRR calculations must be aligned with accounting principles](https://www.accaglobal.com/gb/en/student/exam-support-resources/foundation-level-study-resources/ffm/ffm-technical-articles/the-internal-rate-of-return.html).

&#x20;The IRR for the Project without Carbon Finance must be either:

* ≤ 0
* < Cost of Capital or Return on Equity&#x20;

The Project Developer should then demonstrate that Carbon Finance can raise the profitability of project above the IRR, in a range of price and volume scenarios.&#x20;

The assessment and outcome must be documented in the 'Additionality' section of the Project Proposal Form.
{% endtab %}

{% tab title="Barrier Analysis" %}
Barrier analysis must demonstrate that there are documented barriers preventing the project activity from occurring. It must also demonstrate that Carbon Finance would overcome the identified barriers.

The assessment and outcome must be documented in the 'Additionality' section of the Project Proposal Form.
{% endtab %}

{% tab title="Common Practice" %}
When methodologies require a Common Practice test, projects must demonstrate that project activities are not typical in the project geography. Project geography is typically the country of project operations, but Project Developers can use a more specific region if they provide appropriate justification during project proposal (e.g. economic, regulatory, or environmental differences).

The methodology must **define a scope of analysis** (e.g. target market size, [Technology Readiness Level](https://ec.europa.eu/research/participants/data/ref/h2020/wp/2014_2015/annexes/h2020-wp1415-annex-g-trl_en.pdf)) including appropriate metrics, and then **calculate a Common Practice Threshold** (i.e. the point where the activity becomes 'Common Practice') using market data.&#x20;

During Project Proposal, the Project Developer **assesses whether the Common Practice Threshold has been reached in the project geography**. If has not, the project is deemed not Common Practice, and is therefore Additional.&#x20;

The assessment and outcome must be documented in the 'Additionality' section of the Project Proposal Form.
{% endtab %}

{% tab title="Performance Standard" %}
The Performance Standard approach to additionality establishes a specific benchmark to determine if the Project's activities result in emission reductions/removals exceed the Baseline Scenario.

When a performance standard is used, methodologies must provide steps to demonstrate that the Project activity would not be implemented until it outperforms other activities in a specific parameter (e.g. emissions benchmark).&#x20;

The assessment and outcome must be documented in the 'Additionality' section of the Project Proposal Form.
{% endtab %}
{% endtabs %}

[This article by Sylvera provides more details of the techniques available to measure and red flags to look for in various sectors](https://www.sylvera.com/blog/additionality-carbon-offsets).

### 4.3 Conditional Use of Positive Lists

OCP does not maintain a program-wide positive list of automatically additional project types.

Where a methodology proposes the use of a narrowly defined positive list, such designation shall be exceptional, evidence-based, and subject to heightened scrutiny. Satisfaction of common-practice or market-penetration criteria alone is necessary but not sufficient for automatic additionality.

Methodologies proposing positive lists must demonstrate, through robust and documented evidence, that the activity type would not occur at scale in the absence of carbon credit revenues, taking into account regulatory context, economic viability, deployment trends, and structural barriers where relevant.

Positive-list designations are subject to independent expert approval, periodic review, and may be revised or withdrawn if underlying conditions change.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://open-carbon-protocol.gitbook.io/ocp-methodology-requirements/sections/4.-additionality.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.