Introducing CDOP Version 2.0: A More Usable, Forward-Compatible Data Standard for Carbon Markets
CDOP's Version 2.0 schema is live, extending the open-source, cross-industry carbon market data standard from its pre-issuance foundations to 11 data categories spanning the full credit lifecycle
True standardization requires widespread implementation: CDOP invites market participants — registries, project developers, ratings agencies, and platforms alike — to align their data delivery infrastructure with the updated schema
A full migration guide is available now, designed to be low-blast-radius: organizations can build a translation layer, validate against the new schema, and cut over on their own timeline
New York Climate Action Week (NYCW) 2026 is an important marker in the history of CDOP. It marks CDOP’s second anniversary as a market initiative, one borne of the recognition that the carbon market needs a common data language and fluid data exchange to achieve its common goal of channelling greater investment into real climate action. Over the last two years, CDOP has grown from 50 organizations to now over 75 members, reflecting greater market participation in the collaborative production of a common good for the market’s growth. That collaboration celebrates the first anniversary of CDOP’s schema Version 1.0, but also celebrates another milestone: the release of CDOP’s schema Version 2.0.
This post will cover reflections on CDOP Version 1.0, what has changed under Version 2.0 and why, and how to adopt or migrate to Version 2.0.
Where CDOP Version 1.0 started
At the time of CDOP’s launch in September 2024, the carbon market had long faced challenges stemming from market-wide data fragmentation. Registries, crediting programs, project developers, and raters each structured their information differently, and every organization that wanted to compare, aggregate, or report on that data had to build its own custom mapping logic to do it. CDOP was established with the recognition that this challenge needed to be addressed and set out to do so, starting work in early 2025 to establish common principles and harmonize more than 15 distinct data schemas submitted by its membership — a process that surfaced over 1,600 unique data fields.
The result of the year’s work was Version 1.0: a schema covering four foundational, pre-issuance categories — Location, Project Approach and Details, Disclosures, and Issuance — launched at NYCW 2025. More than 50 organizations spanning the private and public sectors backed CDOP at its launch in 2025, and the coalition has continued to grow since, now comprising more than 75 organizations.
Version 1.0 was an integral starting point, working its way from pre-issuance with the intent to lay the foundations for future work. That gap is where Version 2.0 builds from.
What's changing in Version 2.0
Version 2.0 expands and rearchitects the schema first introduced in Version 1.0. In practical terms, that means a data model that's easier for organizations to work with day to day, and one that's built to accommodate new data types and use cases as the market evolves. There are four key changes:
Wider lifecycle coverage. Version 1.0 covered the four core components of a project's pre-issuance lifecycle. Version 2.0 adds several more categories — including Crediting Period, Estimations and Forecasts, Co-benefits, Durability and Permanence, and Project Finance — bringing the schema's total coverage to 11 data categories.
A standardized entity model. Version 2.0 organizes everything around the same fixed set of entities — project, stakeholder, registry, and issuance — so a piece of data behaves the same way wherever it appears in the schema, instead of the structure resetting each time you move between sections.
Forward compatibility by design. Version 2.0’s upgraded structure can handle unrecognized fields while simultaneously tightening structural validation elsewhere (consistent nesting, enforced value lists, a canonical source for constrained values instead of largely unconstrained free text). The combination means the schema can continue to evolve without breaking the integrations already built on it.
State history, not a snapshot. This is arguably the most consequential change. Version 2.0 models status as a versioned collection with a current-record flag — so instead of one mutable value, you get an auditable timeline of every status change.
Why it's worth the migration effort
Each of these changes solves a specific, practical problem for anyone integrating CDOP:
Less source-specific reconciliation. Data from different registries and providers now maps to the same structure, cutting down on the custom integration logic every downstream consumer used to need.
Lower coupling risk. Because the schema now tolerates unrecognized fields, future extensions to CDOP are far less likely to break integrations that are already live.
Cleaner domain separation. Actuals and forecasts now live in separate schemas instead of one overloaded document, reducing ambiguity about where a given data point actually came from.
Built-in auditability. Status changes are tracked as history rather than overwritten, supporting lineage tracking and after-the-fact review — which matters directly for concerns like double counting and transparent accounting that initiatives like CAD Trust exist to address.
A wider addressable surface. The new schema domains mean CDOP can represent more of a credit's lifecycle without one-off, ad hoc extensions.
A documented, low-blast-radius migration path. You're not re-architecting your internal data model — you're fronting a translation layer, described below.
As with any shared standard, though, these benefits are only realized through adoption. It takes organizations building their data infrastructure from it to turn "possible" into "in practice."
Adoption already underway
That work is already happening. Several CDOP member organizations — spanning project developers, ratings agencies, registry service providers, and others — have adopted the schema and are using it to exchange project data more efficiently, with further organizations expected to adopt over the course of the year. At CDOP's most recent adoption webinar, member organization Equitable Earth walked through the practical steps it took to integrate the schema into its existing systems and the value it's already delivering.
These early movers are proof points for everyone considering the next migration: the schema works in production, not just on paper.
What migration actually looks like
CDOP Version 1.0 to Version 2.0 is a breaking change, which is exactly why it ships with a migration guide. For an overview of Version 2.0 changes and how to migrate, CDOP has created two infographics: one for technical and another for non-technical audiences.
The path itself is designed to be low-risk and incremental:
1. Map and transform. Build a translation layer between your existing internal data model and the new schema. You don't need to re-architect your internal systems — only the integration boundary that exports data to CDOP needs to change. This is also the point to decide how you'll handle historical status data: since Version 2.0 introduces versioned status history, existing records will need a one-time backfill into the new format if you want continuity in your audit trail from before the migration.
2. Validate. Run your transformed payloads through schema validation to confirm structural conformance before any production traffic depends on it. As with any schema migration, it's worth validating against a representative sample of your real data — including edge cases — rather than only the happy path, since the new enum constraints and standardized entity structure are the parts most likely to surface mismatches you weren't tracking under Version 1.0's looser rules.
3. Cut over. Once validation is clean, point your live integrations at the new schema and retire the legacy version on your own timeline. Because Version 1.0 and Version 2.0 can coexist during the transition, there's no hard deadline forcing a single cutover moment — you can migrate incrementally by data category if that fits your systems better.
Full field-level mappings, repo layout, and adapter code patterns are covered in the companion technical documentation, not this post — if you're implementing the migration yourself, start there.
Getting started
Full documentation and a step-by-step migration guide are available on GitHub: CDOP Version 2.0 Schema Documentation & Migration Guide. For questions not covered there, reach out to the CDOP team at sebastian.weeks@rmi.org.
What to look out for next
CDOP continues to progress in close, collaborative conversations with other data standardization efforts across the market, including its ongoing work with the CAD Trust's post-issuance infrastructure, and continued attention to the UNFCCC's Article 6 framework. All of it is in service of the same goal CDOP started with: scaling the carbon market through data infrastructure that's genuinely fit for use. Expect more on how these efforts converge in the months ahead.
CDOP is supported by more than 75 organizations from the private, nonprofit, and public sectors, and that number continues to grow. Building shared data infrastructure for the carbon market takes sustained participation across all three. To find out more about CDOP, become a member, or support the initiative, visit the CDOP website.
