The lifecycle of a voluntary carbon credit begins not in a registry database but in a forest. A satellite passes overhead. Microwave backscatter from synthetic aperture radar (SAR) sensors interacts with canopy structure. The resulting signal — processed through multiple stages of radiometric calibration, forest type classification, and allometric modeling — eventually becomes a number: tonnes of carbon per hectare, distributed across a project boundary polygon. From that number, and from the counterfactual baseline that defines what would have happened without the project, a credit is constructed. The registry serial number comes much later.
Understanding the steps between the SAR acquisition and the serial number matters for two reasons. First, each step introduces assumptions and uncertainty ranges that compound through the chain — errors early in the pipeline can inflate credit quantities substantially, and you can't audit the magnitude of that error without tracing back to the source. Second, each step is currently documented in a different system, by a different party, in a different format. Connecting those records is the foundational challenge of carbon credit chain-of-custody verification.
This piece walks through the full pipeline, step by step.
Step 1: Raw SAR Acquisition and Pre-Processing
Most large-scale forest carbon monitoring uses C-band or L-band SAR data. Sentinel-1 (C-band, ESA) provides 10-meter resolution imagery on a 6–12 day repeat cycle and is freely available. ALOS-2 PALSAR-2 (L-band, JAXA) penetrates deeper into canopy structure and is better suited for dense tropical forests; it's available through licensing agreements for commercial projects. For projects requiring higher spatial resolution or more frequent passes, commercial SAR providers offer sub-5-meter products.
Pre-processing involves several stages before the data is usable for biomass estimation:
- Geometric correction — orthorectification using digital elevation models to remove terrain-induced distortion, critical in topographically complex areas
- Radiometric calibration — converting raw digital numbers to sigma-naught (σ°) backscatter coefficients, normalizing for satellite geometry
- Speckle filtering — reducing the inherent noise in SAR imagery while preserving edge features; filter choice (Lee, Refined Lee, Gamma-MAP) affects sensitivity to small-scale forest structure changes
- Temporal compositing — averaging multiple acquisition dates to reduce phenological noise and increase signal-to-noise ratio for the biomass estimation step
The documentation requirement at this stage: the specific satellite product version, acquisition dates used in the composite, processing software and parameters, and the DEM source used for geometric correction. These are not always captured in project documentation. When they aren't, it's impossible to independently reproduce the backscatter values that fed into the AGB (above-ground biomass) estimation.
Step 2: Forest Type Classification and Stratification
Raw backscatter intensity is not directly proportional to biomass density across all forest types. A mature tropical moist forest and a secondary growth pine forest can produce similar C-band backscatter values despite dramatically different carbon stocks. Pre-classification of the project area into forest strata — typically using multi-spectral optical imagery (Landsat, Sentinel-2) in combination with the SAR data — is required before any biomass estimation can be accurate.
Stratification also defines the reference populations for allometric equation selection. Allometric equations relate easily measurable tree parameters (diameter at breast height, height) to biomass, and the equations validated for tropical moist forest species have substantially different coefficients from those validated for dry forest or montane forest species. Applying the wrong stratum's equations to a project area can produce above-ground biomass estimates that are off by 20–40%, with corresponding errors in the carbon stock change calculation.
Under VCS VM0042 (the Improved Forest Management methodology) and under the IPCC's 2006 Guidelines for National Greenhouse Gas Inventories (the reference framework for most REDD+ approaches), stratification methodology must be documented in sufficient detail to be reproducible. In practice, the stratification maps and the optical imagery they're derived from often exist only in the remote sensing firm's internal processing environment, not in any location where a registry or third-party verifier can access the raw inputs.
Step 3: Above-Ground Biomass Density Estimation
With pre-processed SAR backscatter and a forest type classification in hand, the next step is converting backscatter values to above-ground biomass density (Mg/ha). This is done using either an empirical SAR-biomass regression — developed using ground-truth plots within the project area — or a published algorithm calibrated for the relevant forest type and SAR sensor combination.
The critical documentation requirements here are: the allometric equations applied (including source publication and the species mix they were calibrated for), the ground-truth plot inventory (number of plots, spatial distribution, measurement protocol), the regression model parameters, and the spatial uncertainty distribution of the output AGB map. Uncertainty matters particularly at the project boundary — pixels near the edge of the forest boundary that classify inconsistently between measurement periods can create apparent carbon stock changes that are measurement artifacts rather than real forest dynamics.
Under ISO 14064-2 (the standard for quantification and reporting of greenhouse gas emission reductions at the project level), uncertainty estimation is required. The standard allows for uncertainty contributions from allometric equations to be assessed through sensitivity analysis, but the analysis must be documented and the resulting uncertainty range must be propagated through to the final tonnes estimate. Projects that report credit quantities without explicit uncertainty bounds have incomplete documentation by the standard's own terms.
Step 4: Carbon Stock Change Calculation Against Baseline
The AGB density map gives you carbon stocks at a point in time. A carbon credit requires a difference calculation: the project area's carbon stock trajectory compared to what would have happened under the baseline scenario (the counterfactual). This is where the highest-stakes assumptions enter the pipeline.
For REDD+ projects, the baseline scenario is typically defined by the historical deforestation rate in a reference region — a larger geographic area that is assumed to represent the deforestation pressure the project area would have experienced without intervention. The selection of the reference region, the time window over which historical rates are calculated, and the method for projecting that rate forward all materially affect the baseline carbon stock trajectory, and therefore the number of credits the project can claim.
VCS VM0007 (REDD+ Methodology Framework) provides detailed guidance on reference region selection criteria, including requirements for geographic proximity, similar deforestation drivers, and similar institutional context. But the application of those criteria requires judgment calls that can substantially affect outcomes. Two legitimate validators could review the same project and reach different conclusions about whether a specific reference region meets the spatial proximity requirement — and that difference in judgment could translate to a 30% difference in baseline carbon stocks and therefore in the credit volume the project is eligible to issue.
The documentation requirement: the full reference region shapefile, the deforestation data source (typically Hansen Global Forest Change or a national forest inventory), the historical rate calculation methodology, the projection approach, and a sensitivity analysis showing how the baseline credit volume changes under alternative reference region definitions. This documentation should be in a machine-readable format that allows cross-project comparison of baseline methodologies. It almost never is.
Step 5: Validation Body Technical Review
Before credits can be issued, a third-party validation and verification body (VVB) accredited by the relevant registry must review the methodology documentation, the baseline scenario, and the monitoring data. For initial project validation, this review covers the project design document (PDD) and confirms that the project's approach complies with the applicable methodology. For ongoing verification, the review covers the monitoring report and confirms the quantified removals or reductions.
VVBs are required to use consistent, documented audit procedures, but the format of their findings is not standardized across the industry. Some produce highly structured reports with tabular findings and closure records; others produce narrative documents that are difficult to parse programmatically. The key data elements that must be traceable between the VVB's review and the subsequent registry issuance include: the monitoring period covered, the specific monitoring data reviewed (which should reference the AGB maps and their acquisition parameters from steps 1–3), any material adjustments made to the project developer's claimed quantities, and the verified net quantity.
We're not saying VVBs are doing inadequate reviews — accredited validators operate under serious professional obligations and the peer review within major VVBs is rigorous. What we're saying is that the format and accessibility of VVB findings documentation creates a structural gap between the rigorous technical review that happens and the ability of downstream parties to programmatically verify that the registry issuance quantity was derived from that review's outputs.
Step 6: Registry Issuance and Serial Number Assignment
With a verified monitoring report in hand, the project developer submits a credit issuance request to the registry. The registry's operations team reviews the submission for administrative completeness, confirms the project is in active status, and assigns serial numbers from the project's issuance block. For a Verra VCS project, each serial number follows the format: VCS-[ProjectID]-[VintageYear]-[SequentialBlock]. The vintage year reflects the monitoring period in which the emissions reduction or removal occurred, not the issuance date.
The serial number record in the registry database contains: project ID, vintage year, issuance date, verified quantity, and current status (issued, transferred, cancelled, retired). What it does not contain is a direct reference to the verification report that justified the issuance, or to the monitoring data that the verification report reviewed, or to the SAR acquisitions that produced that monitoring data. The connection between the serial number and the physical measurement chain exists only in the documents, not in the data.
This is the provenance gap that a chain-of-custody layer must fill. Each serial number should carry a cryptographically verifiable reference — a hash or structured identifier — that links backward through the verification report to the monitoring data to the SAR acquisitions and processing parameters. That link doesn't require the registry to store all of that data. It requires a standardized identifier scheme that allows anyone with access to the linked documents to verify that the serial number's claimed quantity is consistent with its measurement origin.
Building that link — prospectively, at each step of the pipeline — is the technical work that turns "chain of custody" from a phrase into a verifiable property of the credit itself. The individual steps in the pipeline are well-defined by existing methodologies. What's missing is the connective tissue between them.
