How Carbon3 compares with SBTi's Corporate Net-Zero Standard V2.0
The Science Based Targets initiative (SBTi) checks and approves company climate targets. It published Version 2.0 of its Corporate Net-Zero Standard on 11 June 2026. Companies can have targets checked against Version 2.0 from 1 February 2027. From 1 February 2028, Version 2.0 is the only version (Transition Guide, Table 1, p. 6).
Version 2.0 sets out what projects, market instruments, and energy attribute and commodity certificates must show before a company can use them in support of its targets. C25 applies to all three (Criteria, footnotes 33, 39, 43 and 45). C26 covers projects (p. 34 to 35), C27 covers market instruments (p. 35), and C28 covers energy attribute and commodity certificates (p. 36).
An inset credit records the outcome of a project in a company's own value chain, so C25 and C26 apply most directly. C27 applies where an inset credit is used as a market instrument. Inset credits are not energy attribute or commodity certificates, so C28 does not apply to them directly. We still use its registry tests as a benchmark, because they describe what a sound registry should do.
This page shows each requirement, where Carbon3 stands today, and what is planned.
What Carbon3 does
Carbon3 provides a registry for emissions reductions in a company's own value chain, also called insetting. Credits are issued to the project developer once a verification report is on file, and Carbon3 records them in its registry. One inset credit stands for one tonne of CO₂e of emissions reductions, checked against that report. Inset credits are not offsets.
Carbon3 does not verify reductions itself. Carbon3 asks for a verifier that is independent of the project, but the registry does not yet check who wrote the report.
When a supplier in the buyer's own chain reduces emissions, the buyer's Scope 3 goes down through lower supplier emissions data. The inset credit is the proof of that emissions reduction and who funded it, and it is not counted a second time.
This matches criterion C37.10, which says that "changes in the physical GHG inventory shall constitute the basis for any emissions reduction claims" (p. 44). Claim treatment depends on the applicable reporting framework.
The key dates
| Date | What happens | Source |
|---|---|---|
| 11 June 2026 | Version 2.0 is published. | Transition Guide, Table 1, p. 6 |
| 1 October 2026 | SBTi Services publishes its validation resources for Version 2.0. | Same |
| 1 February 2027 | Validations against Version 2.0 open. | Same |
| 31 January 2028 | Validations against the old Version 1.3.1 close. | Same |
| 1 February 2028 | Version 2.0 is mandatory for all companies that submit targets. | Same |
Requirement by requirement
The wording in the second column is quoted from the Criteria document. "Where we stand" uses three labels: Met, Partly met and Not yet. "Planned" means the work is designed but not yet approved or scheduled.
| Criterion | What SBTi requires (quoted) | Where we stand today | What is planned |
|---|---|---|---|
| C25.4 Verifiability (p. 33) | Companies shall maintain "auditable documentation supporting the outcomes of actions, sufficient to enable independent third-party assurance, where feasible." | Partly met. Credits can only be issued when a verification report is on file for the project, and the registry records which report each issuance relied on. The registry does not check who wrote the report. | Planned: store the report and the named verifier on every credit. |
| C25.5 Temporal alignment (p. 33) | Actions must correspond "to activities occurring within 12 months of the company's underlying activities," unless a longer period is justified. | Not yet. An issue date cannot be in the future, and a past issue date needs a reason and cannot be earlier than the report. Credits do not yet carry the monitoring period they cover. | Planned: add the monitoring period to each credit and check the 12-month window when a credit is retired. |
| C25.6 Unique attribution (p. 33) | "Where multiple actors within a value chain reference the same action, companies shall transparently document this and avoid over-attribution of the associated outcomes." | Partly met. One company holds each credit at a time, and a credit can be retired only once. Co-funders and their shares are not recorded. | Planned: record each co-funder and its share on the project. |
| C25.7 Double counting prevention (p. 33 to 34) | Systems must "provide unique identification (e.g., serialization) and tracking of outcomes and attributes, allowing co-claiming where appropriate." | Partly met. Every batch of credits has its own record in the registry, and a retired batch cannot be moved or retired again, even if two requests arrive at the same moment. Credits do not have public serial numbers. SBTi has not yet published its list of recognized registries (footnote 36, p. 34). | Planned: public serial numbers that stay with each credit through every split and transfer. |
| C26.2.d Excluded mechanisms (p. 34) | Not eligible: "Emissions reductions or removals that are estimated ex ante and not yet realized." | Met in the registry. Future credits, for reductions that have not happened yet, are labeled as future and cannot be retired. They keep that label when split or transferred. | Planned: a way to turn future credits into realized credits once a verification report covers the reduction. Until then, future credits cannot be retired at all. |
| C26.3 and C26.4 Proportionate and matched (p. 34) | Report outcomes "proportionate to their defined contribution to the project," and the total "does not exceed, and is proportional to, the actual physical emissions reductions or removals achieved." | Partly met. The registry will not issue more credits than the reductions recorded for the project, and realized credits cannot exceed the reductions recorded up to the issue date. Those reductions are entered by the project developer. Co-funder shares are not recorded. | Planned: co-funder shares, as for C25.6. |
| C27.1 Representative instruments (p. 35) | "Market instruments shall accurately and conservatively convey the emissions or physical attributes of the underlying activity." | Partly met. Each credit is tied to one project and one tonne, and each issuance relies on a verification report on file. The credit record does not yet carry the activity, the fuel or product, or the time period it covers. | Planned: add the activity type, the product or fuel, and the monitoring period to every credit. |
| C27.2 Volume matching (p. 35) | Companies shall ensure the volume of instruments matched to an activity "does not exceed the volume of the corresponding activity, as reflected in the company's GHG emissions inventory." | Partly met. Issuance is capped at the reductions recorded for the project, as for C26.4. The registry does not record which activity in the buyer's inventory a credit was matched to. | Planned: when a credit is retired, record the buyer's activity, reporting year and Scope 3 category. |
| C27.3 Accounting basis (p. 35) | Instruments "shall apply attributional accounting principles based on a homogeneous functional unit and be consistent with applicable GHG Protocol requirements." | Partly met. The unit is one tonne of CO₂e. The method and functional unit are not stored with each credit. | Planned: store the methodology, its version and the functional unit, such as tonne-kilometers for shipping. |
| C27.4 Attribute preservation (p. 35) | "Emissions attributes at the point of instrument generation shall be allocated in proportion to physical flows across processing stages. These attributes shall not subsequently be stacked, non-proportionally redistributed, or concentrated on a subset of products in a way that overstates the outcomes beyond what physically occurs (e.g., "carbon bank" models)." | Partly met. When a credit is split or partly transferred, the new credit keeps the project, the issuer, the issue date and the realized or future label, and the total tonnes never grow. The new credit does not yet keep a link to the credit it came from. The physical flow and each funder's share are not recorded. | Planned: a link from each split to its original credit, co-funder shares, and the physical flow, such as the volume shipped. |
| C27.5 System-level impact (p. 35) | Companies shall buy instruments "only from programs or frameworks that demonstrate decarbonization of the relevant system." | Partly met. Projects are in the buyer's own value chain. The registry does not yet describe the system for each project. | Planned: show, for each project, the system it reduces emissions in, such as a shipping lane or a supply basin. |
| C28 Tracking systems (p. 36, benchmark only) | Energy attribute and commodity certificates must be "issued, transferred, and retired through transparent, secure tracking systems that prevent double counting." | Partly met. Transfers are checked against the current holder in one step. Retirement is final: a retired credit cannot be moved or retired again. | See C28.1 and C25.7. |
| C28.1 Registry transparency (p. 36, benchmark only) | "Certificate issuance, transfer, redemption, cancellation, and retirement are recorded in a secure registry or equivalent system of records." | Partly met. Issuance, transfer, split and retirement are recorded in the registry's activity log. There is no cancelled status yet, and the log is not yet a permanent record that cannot be changed. | Planned: a cancelled status and a permanent, add-only record of every event. |
| C28.2 Assurance (p. 36, Category A companies only, benchmark only) | Conformance with the use, project, eligibility and transaction requirements (C25 to C28) "shall be verified where relevant as part of the independent third-party assurance of data and calculations substantiating target progress required under CNZS-C37." | Not yet. There is no export designed for an assurer, and the registry has not been reviewed by an outside firm. | Planned: an export for each buyer that an assurer can check. |
Not covered on this page: leakage (C26.5, p. 34), causality (C26.6, p. 34) and additionality (C26.7, p. 35). They are assessed at project level by the verifier under the methodology used. The registry does not check them. SBTi's Assurance Manual and Claims Policy are still forthcoming (Transition Guide, p. 6; Criteria, footnote 35, p. 33).