CDOP v1-v2 NON-Technical migration infographic
CDOP v2: A Schema Upgrade, Not a New Protocol
CDOP defines the shared data model by which carbon market actors structure their carbon data. Version 2 is a deliberate, breaking revision to CDOP's Version 1 schema — upgrading to broader coverage, a more consistent structure, and more forward compatible.
Where CDOP sits: when every carbon market actor — project developers, registries, and data providers — validates against the same schema, downstream systems can consume their data without source-specific mapping logic. The upgrade from Version 1 to Version 2 changes schema meaningfully enough to be treated as a breaking version, not a small patch — which is why it comes with a migration path rather than a silent swap.
Wider lifecycle coverage
Version 1 covered 4 core components of the carbon project lifecycle. Version 2 adds several more, including crediting period, estimations/forecasts, co‑benefits, durability & permanence, and project finance as first‑class domains — making real progress in completing the full lifecycle picture.
A standardized entity model
In Version 1, related data used to be grouped inconsistently depending on which document you were looking at. Version 2 organizes every schema around the same fixed set of entities — project, stakeholder, registry, issuance — so the data transfers across the while schema instead of resetting each time.
Forward-compatible by design
Version 1 was a closed schema — anything it didn't explicitly define was rejected, which made incremental extension brittle for adopters. Version 2 tightens structural validation — consistent nesting, enforced value lists — while loosening how it treats unrecognized fields, so schema evolution is less likely to break existing integrations.
State history, not a snapshot
Project status used to be a single field, overwritten on every change. Version 2 models it as a versioned collection with a current-record flag — an auditable timeline instead of one mutable value.
Less source-specific reconciliation — data from different registries and providers maps to the same structure, reducing custom integration logic downstream.
Lower coupling risk — because the schema now tolerates unrecognized fields, extending CDOP going forward is less likely to break existing consumers.
Cleaner domain separation — actuals and forecasts live in separate schemas instead of one overloaded document, reducing ambiguity about data provenance.
Built-in auditability — status changes are tracked as a history rather than overwritten, supporting lineage and after-the-fact review.
Wider addressable surface — six new schema domains mean CDOP can represent more of a credit's lifecycle without ad hoc, one-off extensions.
A documented, low-blast-radius migration path — adopters front a translation layer rather than re-architecting internal data models.
Map & transform
Build a translation layer between your existing internal data model and the new schema. Internal systems don't need to be re-architected — only the integration boundary that exports to CDOP.
Validate
Run transformed payloads through schema validation to confirm structural conformance before any production traffic depends on it.
Cut over
Once validation is clean, point live integrations at the new schema and retire the legacy version on your own timeline.
