Carbon offset programs try to ensure that GHG reductions are not overestimated by requiring the use of detailed quantification methods specific to individual project types. In general, these methods prescribe:
- GHG accounting boundaries define the GHG sources and sinks that must be considered in quantifying a project’s baseline and actual GHG emissions.
- Baseline emission estimation methods that prescribe how a project’s baseline scenario is defined, including acceptable assumptions regarding baseline technologies and practices.
- Monitoring requirements that prescribe the data to be collected for predicting baseline emissions and quantifying a project’s actual emissions. These methods also specify how to conduct measurements, what kinds of estimates are acceptable, and what calculation formulas must be used.
Importantly, carbon offset programs require verification by independent, third-party verifiers, who check that projects have properly applied prescribed quantification methods (see Box below). In most cases, offset credits are only issued after GHG reductions or removals have already occurred and been verified.
Finally, offset programs also limit the crediting periods during which projects can generate creditable GHG reductions. Crediting periods are typically from 7 to 10 years, which is often shorter than the operational lifetime of a project’s equipment. Programs generally allow crediting periods to be renewed (usually one or two times, depending on project type), as long as a project remains eligible under its standard.
 Some of these sources and sinks may be treated as “leakage” effects and addressed in supplemental calculations.
 Most quantification methods prescribe a combination of project-specific data collection, along with the use of conservative defaults or estimates where data collection is impractical.
 Renewal under some programs may also involve an updated additionality determination.
 Carbon offset programs can differ in their approach to validation and verification. Some programs, like CAR, combine validation with the first verification of a project and do not make a formal distinction between the two functions. Others require validation and verification as separate steps (and some, like the CDM, require separate verifiers for each to avoid conflicts of interest – since a positive validation could lead to a more lucrative verification contract).