# Crediting timeline and process

## Crediting process overview

The process for issuing credits under this methodology is described below.

{% stepper %}
{% step %}

#### Pre-spreading pilot sampling

Before or in parallel to validation with Rainbow, Project Developers shall take pilot samples and measurements for [site characterization](https://docs.rainbowstandard.io/~/changes/215/methodologies/enhanced-rock-weathering/site-characterization) and [feedstock characterization](https://docs.rainbowstandard.io/~/changes/215/methodologies/enhanced-rock-weathering/feedstock-characterization), and propose a [sampling plan](https://docs.rainbowstandard.io/~/changes/215/methodologies/site-characterization#sampling-protocol-for-monitoring) for future MRV.
{% endstep %}

{% step %}

#### Project validation

Project Developers submit required documentation to Rainbow and the project undergoes an ex-ante validation audit. This is performed by a Rainbow-accredited VVB, and if necessary the [peer review](#peer-review-and-validation) process described below. The project documentation is made available on the[ Rainbow registry](https://registry.rainbowstandard.io/) and expected CDR volume is estimated.
{% endstep %}

{% step %}

#### Project operations and monitoring

Project Developers spread crushed rocks on eligible sites, take samples, and conduct MRV according to the [Monitoring Plan](https://docs.rainbowstandard.io/~/changes/215/methodologies/enhanced-rock-weathering/monitoring-plan).&#x20;

Monitoring in some reporting periods may show no statistically significant CDR has occurred yet, and result in no credit issuance. In that case, this step is repeated without advancing to step 4.

Project Developers may revise the Sampling Plan and/or Monitoring Plan based on initial measurement results, or as scientific knowledge and best practices evolve. Any proposed changes should be submitted to Rainbow **before** implementation. Depending on the scope of the revisions, updates may require auditing and approval by the VVB. Failure to obtain prior approval may result in measurements being rejected for credit verification and issuance, due to substantial deviations from the audited and agreed-upon Monitoring Plan.
{% endstep %}

{% step %}

#### CDR verification

By adhering to the [Monitoring Plan](https://docs.rainbowstandard.io/~/changes/215/methodologies/enhanced-rock-weathering/monitoring-plan), Project Developers prove that real ex-post CDR has occurred and document their results in a Monitoring Report, which is audited by a third-party VVB. Removal RCCs are issued on the [Rainbow registry](https://registry.rainbowstandard.io/).&#x20;

Statistical requirements for proving eligibility to issue credits for a given reporting period are detailed in the [CDR verification and credit issuance](#cdr-verification-and-credit-issuance) section below.&#x20;

Repeat steps 3 and 4 for each reporting period.
{% endstep %}

{% step %}

#### End of project

Monitoring and verification continues for the maximum crediting period duration allowed under the present methodology.
{% endstep %}

{% step %}

#### Renew the crediting period

If removals are still occurring near the end of the crediting period, the Project Developer may choose to [renew the project's crediting period](https://docs.rainbowstandard.io/~/changes/215/rainbow-standard-documents/procedures-manual/project-certification-procedure#crediting-period-renewal) to extend the monitoring plan and continue repeating steps 3 and 4.
{% endstep %}
{% endstepper %}

## Peer review and validation

ERW projects are notoriously variable, case-specific and subject to rapidly evolving knowledge and innovative measurement techniques. As a result, the present ERW methodology is intentionally not prescriptive at times, allowing project design elements to be evaluated on a case-by-case basis. Project assessments are rather individualized, sometimes relying on complex geochemical justifications, and requiring both technical expertise and a degree of professional judgment.

Therefore, if a project regularly falls outside the recommendations in this methodology, and requires extensive, complex, project-specific assessments, a **technical peer review by at least 2 experts may be recommended**.

### Peer review process

Any of the following parties may request a technical peer review: the Project Developer, the VVB or the Rainbow Certification team. The final decision on whether to initiate peer review rests with the Rainbow Certification team. The review may occur either&#x20;

1. before the validation audit by a VVB,&#x20;
2. decided on as an outcome of the validation audit, in which case it occurs after, and/or&#x20;
3. before or during a verification audit, if the project operations change substantially from the initially validated setup.&#x20;

It may be in the Project Developer's **best interest to initiate a peer review before submitting the project to a validation audit**, to identify any potential issues early and facilitate a smooth audit.

The Rainbow Certification team arranges the peer review and acts as the main intermediary between the Project Developer and reviewers. The Project Developer should remain anonymous throughout the review process to reduce potential bias. This stage is charged directly to the Project Developer, and fees may vary by project depending on the scope of the review.&#x20;

Before the review, the Project Developer and the Rainbow Certification team shall agree upon a scope of review, outlining:

* which eligibility criteria and points need to be reviewed, and which have already been validated as meeting the methodology requirements
* which points, if any, should be reviewed by the VVB if project design changes (e.g. a contingency plan)
* which underlying data must be shared to allow a sufficiently thorough technical assessment by the reviewers

The possible outcomes of a peer review include:

* **full approval**: the project is validated as-is
* **partial approval**: the project may operate as designed but certification-related aspects must be updated (e.g. increase in discount factor, changed responses to ESDNH criteria)
* **changes requested**: the project should change its planned operations, MRV and/or project design
* **refusal**: unresolvable issues mean that the project should not be certified. The Project Developer may start over with a new project application, with major changes.

The Rainbow Certification team makes the final recommendation for the project's eligibility and required changes, following the Rainbow Project validation review. Changes made as a result of the review should be directly incorporated into a revised PDD as much as possible, or where relevant, may be reflected in separate, additional project documentation. The findings of the technical peer review shall be made available on the registry along with all other project documentation.

### Eligible reviewers

The Rainbow Certification team shall review and approve eligible reviewers upon their submission of a Rainbow ERW Technical Reviewer Application form.

Through the application, reviewers shall demonstrate technical, scientific expertise in fields related to ERW, such as geochemistry, mineralogy, soil and crop science, and/or modeling and statistics. The specific reviewer chosen for a given project should have expertise in the topic/s that the project does not clearly meet from the methodology.

Reviewers may be affiliated with universities, research institutes, NGOs, consulting, freelance, or ERW companies that are not related to the project being reviewed. Two reviewers are needed per project review, and a maximum of one reviewer may come from an ERW company.

The Project Developer and the Rainbow Certification team shall select and agree upon the reviewers from the list of eligible reviewers. The Project Developer may refuse a given reviewer to preserve  confidentiality.

## CDR verification and credit issuance

Issuing credits for ERW projects is complex because there may be a time lag of months to years from when rock is spread on the soil, draws down atmospheric CO<sub>2</sub>, and this CO<sub>2</sub> is permanently stored in the ocean as bicarbonate. This methodology considers that carbon removal is:&#x20;

* **Initiated** upon feedstock dissolution.
* **Sufficiently complete to issue credits** upon alkalinity[^1] being exported from the NFZ or remaining in soil porewaters at the [depth of the NFZ](#user-content-fn-2)[^2]. This amount is adjusted for expected FFZ *losses,* which are not considered removals, because carbon is not yet permanently stored.
* **Permanent** upon arrival of DIC (notably bicarbonate) in oceans or permanent groundwater reservoirs. Losses after this point can be considered *reversals*.

To be eligible to issue credits, Project Developers must **measure a statistically significant signal of complete CDR** in treatment plots, compared to the baseline scenario/control plots, during the reporting period. One of the following requirements must be met to issue credits for a given reporting period:

* A statistically significant **increase in the export of weathering products** or the concentration of weathering products in porewaters at the depth of the NFZ, between the treatment and control plots, between the beginning and end of the reporting period. See measurement details [here](https://docs.rainbowstandard.io/~/changes/215/methodologies/ghg-quantification#dic-export).
* A statistically significant **decrease of base cation concentration in the NFZ**. This may be solid-phase measurements showing either a decrease in:
  * base cation concentration relative to an immobile tracer within the treatment plot, between the beginning and end of the reporting period, or&#x20;
  * directly measured base cation concentration between the treatment and control plot between the beginning and end of the reporting period (or, for the first reporting period, between a sample taken just after spreading and at the end of the reporting period).&#x20;
  * See measurement details [here](https://docs.rainbowstandard.io/~/changes/215/methodologies/ghg-quantification#feedstock-dissolution).

## Successive spreading events

Project Developers may perform additional rounds of feedstock spreading throughout the crediting period. They should apply for validation **before** any additional spreading round. This ensures that Rainbow, the Project Developer, and if necessary, a VVB can confirm the eligibility of the planned activities for credit issuance. This step helps avoid situations where the Project Developer completes the spreading only to discover an oversight or mistake that renders the spread ineligible.

As part of this process, Project Developers shall notify Rainbow of:

* their intention to conduct additional spreading,
* sites involved,
* timing of the activity,
* amount and source of the feedstock.

This notification may be included **proactively** during the initial validation audit, in a year prior to the successive spreading event, outlining plans for repeat spreading in later reporting periods. Alternatively, it may be provided **on an ongoing basis** throughout the crediting period.

CDR from successive spreading events shall be **cumulative**, with the total CDR considered for the entire project. For credit issuance, it is not necessary to track which removals are attributed to specific spreading events.&#x20;

Project Developers shall document and update their project induced emissions estimates and accounting timeline from successive spreading events. See below and in the [Monitoring Plan](https://docs.rainbowstandard.io/~/changes/215/methodologies/enhanced-rock-weathering/monitoring-plan) section for a full list of required information to provide/update upon a successive spreading event.

{% hint style="warning" %}
Even if CDR from successive spreading events is cumulative, and the vintage year of a spreading event does not need to be tracked to issue credits for separate years, Project Developers using NFZ Method 2: Mass balance shall describe how they plan to resolve overlapping signals of simultaneously increasing and decreasing base cation and immobile tracer concentrations from previous year's spreading events and successive spreading events.
{% endhint %}

<details>

<summary>Monitoring requirements for successive spreading event on same site, same feedstock batch</summary>

The following monitoring requirements shall be applied if the project performs new spreading events, on the **same sites** where feedstock was previously spread, **with the same** [**feedstock batch**](#user-content-fn-3)[^3] (i.e. if the feedstock was stored and covered at the project operations site between spreading events).&#x20;

* All points listed in the [Monitoring requirements for all reporting periods](#monitoring-requirements-for-each-reporting-period) section
* Feedstock application rate
* Moisture content measurements of feedstock just before spreading, and ex-post sampling description
* Updated maximum potential CDR and modeled CDR estimates for the newly spread feedstock, plus updated total project CDR estimates
* Assessment of the impact on site stratification and, if relevant, extrapolation
* Proof of adherence to [ESDNH](https://docs.rainbowstandard.io/~/changes/215/methodologies/eligibility-criteria#environmental-and-social-do-no-harm) requirements:
  * meet national and local regulations for pollutant levels and fertilizer limits
  * provide safety protocols required for feedstock application
  * model heavy metal dissolution in the environment, corresponding to heavy metal from newly spread feedstock
  * notify local stakeholders if adverse local environmental impacts are expected following application.
  * describe any potential downstream sensitive ecosystems, and plans to monitor for negative impacts resulting from rock spreading (e.g. pH shifts, contamination...).
* Updated induced emissions
  * Energy amount and type for feedstock extraction
  * Energy amount and type for feedstock processing
  * Transport data, using the [Distance based](https://docs.rainbowstandard.io/~/changes/215/modules/transportation#e8wzu6e4jkgm), [Energy amount](https://docs.rainbowstandard.io/~/changes/215/modules/transportation#ph39su917ek2-1) or [Energy efficiency](https://docs.rainbowstandard.io/~/changes/215/modules/transportation#otr9oxeftie9) data inputs from the BiCRS Transport module
  * Amount and type of other input/emissions not mentioned above
  * Description of how allocation of induced emissions and of FFZ loss will be updated to reflect updated CDR estimates
* Updated FFZ loss estimates
  * Updated calculations of CDR [loss in the FFZ](https://docs.rainbowstandard.io/~/changes/215/methodologies/ghg-quantification#project-ffz-loss), corresponding to the amount of newly spread feedstock
  * Description of how allocation of FFZ loss will be updated to reflect updated CDR estimates

</details>

### Adding new sites and feedstocks

If the spreading event occurs in **new sites** or with **new feedstocks** that weren't included in the initial validation, the Project Developer shall submit a [Site Characterization Report](https://docs.rainbowstandard.io/~/changes/215/methodologies/site-characterization#site-characterization-report) and a [Feedstock characterization report](https://docs.rainbowstandard.io/~/changes/215/methodologies/enhanced-rock-weathering/feedstock-characterization), respectively.&#x20;

Project Developers shall follow the requirements outlined in the corresponding section of the minimum requirements for a [Monitoring Plan](https://docs.rainbowstandard.io/~/changes/215/methodologies/enhanced-rock-weathering/monitoring-plan).

The Rainbow Certification team and the VVB shall decide whether a [technical peer review](#peer-review-and-validation) is required to assess the eligibility and updated project design considering the new sites and feedstock.

[^1]: cations released from feedstock that are charge balanced by DIC

[^2]: where the depth of the NFZ has been set to the depth where $$CO\_2$$ in porewater will not de-gas out into the atmosphere.

[^3]: A given amount of feedstock that comes from the same feedstock source, in the same delivery round (within 24 hours). It is assumed that all feedstock in the same batch has the same characteristics, and samples and measurements only need to be taken once per feedstock batch.
