Table of Contents​Foreword												4Executive Summary										5Framework												6Framework Components									7		Framework Component Relationships								14Artifact Details											16Framework Process Flow									22Quality Standard to Digital MRV Mapping							25Attestations											25
		Reputation											26Confidentiality in Attributes & Asset Generation
27
		
Reference Example										27Co-benefits & Modular Benefits

28

Moving Forward			 								29Appendix												30Tagging Example										30		Contributors											34Foreword
The first version of the Digital Measurement, Reporting & Verification (dMRV) Framework was publishedin late 2021. Since that time, the membership of the InterWork Alliance (IWA) and Global Blockchain
Business Council (GBBC) have shared the framework broadly throughout the sustainability ecosystemand put it through its paces to find missing elements, refine definitions, and strive to establish common
ground to help unify the way ecological and environmental products like voluntary carbon credits are
manufactured or originated.
This document will replace its predecessor in its entirety due to the hard work and collaboration of its
contributors. But we are not done. There are still improvements to be made and refinements to bediscovered as we all set forth to implement these specifications and commit to returning the lessons
learned back for the next version of this specification in the future.
We invite you to join us on this journey to help scale these markets by shoring up its foundations bycreating consistent, comparable, interoperable, and hopefully higher-quality digital ecological assets to
help all of us achieve our personal, organizational, and global goals.
DISCLAIMER: This document is intended as an introduction and basis for further dialogue andcooperation with all relevant stakeholders. Neither the individual taskforce members nor theirorganizations have agreed to or adopted this document in its entirety. The following is an incomplete,pioneering work in progress intended to cultivate further cooperative effort on the keystone elements
and best practices with the intention to align around a common governance set of standards,
specifications, and classification systems. We encourage participation and collaboration with otherorganizations and actors within the industry as well as regulators and welcome their feedback andcommentary for the next version. The taskforce members do not presently endorse any specificregulatory treatment, and do not formally endorse or ratify any particular independent efforts to develop
market governance frameworks.
We encourage those that can join us in the GBBC/IWA, or are already members not currently active in
our group, to reach out and engage with us.

4Executive Summary
To scale environmental markets we need to digitize the origination, or manufacturing, process
and products. This new digital approach will enable the creation of standardized, comparable, anddifferentiated products from a wide variety of sources and lower their creation costs to make them moreaccessible and trustworthy.
The Digital MRV Framework defines the terminology, roles, process workflows, generic evidence
packaging, and attestations that digital MRV solutions should follow to originate these next generation
digital assets. The framework defines a generic roles-based process along with an extensible data model
to facilitate a consistent taxonomy across infrastructure and asset classes and allow for customization of
the diverse array of activities that can produce these new assets.
The framework can better enable investments in, and generation of, high-quality, well-documented
ecological assets at scale. This framework defines the variables that enable the application of a wide
variety of standards, protocols, and technologies that can be used in combination to create high-quality
projects and claims, ready for validation and verification.
A harmonized, standardized framework agreed upon by market participants will enable investors,
buyers, and other participants in global environmental markets to ensure the credibility and integrityof outcomes while maintaining the rigor and the requisite documented evidence to indisputably track
impacts. Additionally, the MRV framework, when implemented, can ensure that double-counting anddouble-crediting do not occur – safeguarding market integrity. Tokenization alone will not and does notprevent double-counting, only tokens with corresponding, cryptographically-linked MRV audit trails havethe opportunity to prove, on a public ledger, a lack of double-counting.
While this paper is focused on the business aspects of the framework, the InterWork Alliance has also
produced a technical specification that delves deeper into the details for those implementing solutions
based on the framework. This specification can be found at:https://interworkalliance.github.io/TokenTaxonomyFramework/dmrv/spec/index.html

5

Framework
The Digital MRV Framework provides the high-level, implementation-neutral, specification for creating
a solution that creates standardized claims into an open ecosystem for validation, verification, andcrediting. This framework builds off the “Voluntary Ecological Markets Overview Version 2” standard1 thatwas previously published by the InterWork Alliance to enhance global agreement on terms, definitions,and basic understanding of the process for creating ecological or environmental assets like carbon
credits.
This framework brings Process, Data, and interchangeable science-based Quality Standards together
that can operate under a governance framework to facilitate adjustments and create an inclusive and fairplaying field for all participants.

Figure 1: Governance

The modular Quality Standard is specific to the type of activity being implemented and the sourceof beneficial claims. These Quality Standards are typically modular in themselves and combine a“methodology” or “protocol” that is specific for the activity being measured or monitored, a generic
program or process, and options for implementation that enable optimal methods for measuring andqualifying project claims (e.g., additionality, permanence, etc.). Quality Standards define steps to establish
a valid project and detail the required evidence and calculations used to quantify the benefit of the
project’s activity (e.g., mtCO2e removed).
The Quality Standard that a project follows will set the guidelines for what data collection requirements
exist for a digital MRV solution. For instance, the Quality Standard will specify the evidence that should
be collected, from which sources the evidence should be gathered, and what cadence the evidence will
be reported. The Process and Common Data Standard remain the same across Accountable Impact
Organizations.
Traditionally, Quality Standards have been governed by accredited registries (e.g., by ICROA) as options
that project developers can choose from. However, recent advancements and innovation have led tothe development of new “methodologies” and “protocols” by consortia, start-ups, and academia that are
accelerating time to market and issuing credits using non-traditional techniques. This is likely a symptomof the traditional market infrastructure being unable to scale to meet the advancements and governanceof new techniques. As Quality Standards and market participants become digitized and optimized, it islikely that the future form factor of environmental markets will resemble a convergence of traditional andinnovative solutions.
1

https://gbbcouncil.org/wp-content/uploads/2022/09/Voluntary-Ecological-Markets-Version-2-InterWork-Alliance.pdf

6Framework Components
The framework defines components that represent roles, process artifacts, and subsystems that work
together to package evidence in a claim that can be independently verified in standard processes. Each ofthese components provides a placeholder or variable that can be replaced with a specific actor, artifact orsubsystem, allowing the framework to be generic and support a wide and diverse set of implementations.
For example, solutions using the framework for soil carbon sequestration through agricultural practices
would have different standards and sources of evidence than a direct air capture program, but eachsolution would create a standard claim that plugs into a standard process.

MRV Network
A shared set of infrastructure where the Data and Process
standards are implemented that provides storage, compute,ledgering, and other capabilities for all participants.
A Data standard includes the generic data elements that all
activities should generate as well as specific “Quality Standard” data
properties required by the standard.
A Process standard includes the generic “lifecycle” of originatingclaims and workflow elements to enable automation.

Accountable Impact Organization (AIO)
The identity and metadata about a program or project that will behosting or sponsoring one or more Activity Impact Modules (AIMs).
The AIO is a way to group multiple modular projects logically tosupport different business models. Each AIO has one or more“owners” that references the accountable identity, i.e., individual ororganization.
For example, an AIO can represent a single farm that will want tohave a project that makes carbon removal claims and anotherthat will make water claims. Each claim type is associated with adifferent Quality Standard and will result in different credit types
being issued, but are managed by a single organization.
Or an AIO can represent an organization that will host multiple
AIMs in different geographic locations, like solar deployments indifferent countries or states.
Examples:••A farm that will have one or more AIMs for each Quality
Standard it will implement for its location.
A solar company that will have an AIM for each solar
deployment they will make renewable energy claims from.

7

Activity Impact Module (AIM)An AIM is a “child” of an AIO and is a unique combination of alocation, land area or facility, and a Quality Standard that will befollowed for the location. The AIM is a party to the Verification
Process Agreement where the Quality Standard is identified as wellas the verifier(s) and issuing registry.
Each AIM can have one or more “developers” and “sponsors”
that references the individual(s) or organization(s) in these roles.
A “developer represents the part performing the activity and a“sponsor” could be a separate financier of the activity.
AIMs are the source for the claims process and is where theevidence is provided for creating one or more claims about
beneficial impact, such as a claim of carbon removal.
For example, an AIO may want to create claims for carbon removal
and water for the same location, thus having an AIM for each. An
AIM must be validated before it can begin submitting claims forverification.

Project Design Document (PDD)
An Activity Impact Module needs to be validated or approved by anappropriate authority, i.e., the validation body or issuing registry,
before the claims verification process can begin. This is when aproject’s baseline is established and the activities of the project willbe tracked and reported. This traditionally has been done in a PDD,
a word processing document that follows a template provided by
the issuing registry.

Accounting & Ecological Claims Registry
An organization that maintains and governs a portfolio of protocols
or methodologies which certifies Validation and Verification
Bodies (VVBs) to validate projects and verify their claims based on
the protocol or methodology and then issue credits from thesevalidated and verified claims.

8Certification Standards Body
An organization that creates and certifies science-based standards,
e.g., protocols and methodologies, for measuring environmental
impacts and benefits. This may be an industry consortium,
academic partnerships, or a single organization.

Quality Standard
Requirements for measuring outcomes, based on approved
methodologies or protocols, that result in high-quality credits being
issued. A Quality Standard can encompass a Standard Protocol
or Methodology, a crediting program, measurement tools, andcertification requirements for a VVB.

Standard Protocol (Methodology)
A science-based standard, often called a methodology, that isincorporated in a Quality Standard for making a claim that a specificactivity leads to an quantifiable environmental impact, for example,
that a project activity caused the removal of a specified quantityof carbon over a certain period. A protocol is specific to the typeof activity and can vary based on its location, time, duration, etc.
It defines the kind, amount, and frequency of evidence collectedfrom required source(s) and formulae for using the evidence todetermine the values of the claim. For example, determining theamount of carbon removal as well as other attributes like durability,
additionality, co-benefits, etc.
Validation & Verification Body (VVB)
An organization that is certified to validate and verify claims, basedon a standard, to ensure that the protocols and methodologies
were followed and that the evidence collected supports the claims.
The VVB first validates the AIO’s plan against the Quality Standard
being followed; once completed, the claims verification process canbegin. In conjunction with the Verification Automations, VVB’s work
can be scaled or enhanced.

Verification Automations
Solutions, platforms, services, etc., designed to accelerate theverification of claims. Depending on the Quality Standard, it may
be able, with appropriate audit requirements, to perform fullverification of claims issuance of impact credits. For other Quality
Standards, these platforms or services may automate and prepare
findings data that are evaluated by a VVB in order to speed up andsupport a continuous verification process.

9

Project Validation
Before an Activity Impact Module can begin creating claims forverification, the project must be validated, against the Quality
Standard being followed, by a certified VVB. This process can vary,
but usually includes several steps and requires the production of
documents like a Project Design Document (PDD) and may also
include legal documents to be submitted like proof of ownership,
title, lease, etc.

Verification Process Agreement
An agreement between the Activity Impact Module, Standard(registry) and the VVB for the claims process. Here the terms
and conditions of the verification process are agreed to anddocumented. All artifacts in the claim process are linked to thisagreement. The AIM may choose to switch standards or VVB andcreate a new agreement for verification.

Impact Claim
Made by an Activity Impact Module in accordance with its validated
Project Design Document (PDD). The PDD follows the requirementsof a quality standard, an applicable methodology, and protocols
required to generate the necessary evidence for validation of theclaim.
A completed claim output is similar to a Monitoring Report, exceptthat it is primarily intended to be machine readable, whereasa Monitoring Report is designed to be human readable. Somesolutions may generate both machine and human readable output.

Claim Source
A registered source of claim data that can be raw source datafrom a device/sensor or a device/user/application and 3rd party
reference data like satellite images or remote sensing. Thesesources are registered with the Impact Claim as valid sources ofevidence.

Claim Checkpoint
A submission of prescribed evidence data made towards an impact
claim based on a cadence or schedule required by the standard
methodology or protocol being followed. An impact claim is madeof a collection of checkpoints.

10

MRV Extension
An MRV Extension is an extensible JSON object that contains the
MRV data that is specific to the Quality Standard/Methodology. MRVExtensions can be defined by the methodology developers or theverifier, or Verification Automations, to include attributes or datathat are helpful to have on the ledger.
A Quality Standard can define multiple MRV Extensions that can be
attached to the dMRV process and data types to collect contextspecific data points from appropriate sources.
The components defined are common or generic to allow for
maximum re-use, but the framework will need to support Quality
Standard (methodology/protocol) extensions to allow for themonitoring, reporting, and verification of data that is specific to the
Quality Standard being followed. As such, Quality Standards candefine MRV Extensions that are specific for their methodology andadd them to Activity Impact Modules, Claims, Checkpoints, etc.
These extensions can be a collection of simple name/value pairs orschema-based, versioned, and optionally provide documentation
so that the extensions get reused by many projects following thesame Quality Standard.

Span Data Package (SDP)
Contains evidence data from one or more registered sources thatis used to create a claim checkpoint over a specific time span.
Sources may be 1st party, automated, application/device data, orreference data. The SDP is immutably stored, and its cryptographic
fingerprint is recorded in the claim checkpoint.

Span Data Package (SDP) Manifest
A JSON file in the root of the SDP that contains metadata about thecontents of the SDP. This includes identifiers like the Accountable
Impact Organization, the Activity Impact Module, and the Claim the
SDP is for as well as extensible MRV and Quality Standard metadatathat is defined by the participants and stored on the MRV network.
It can include digital signatures of claim sources.

11Digital MRV Solution
An implementation of this framework that follows a protocol using
a combination of technical devices, services, data sources, andapplications to automate as much of the claim creation process as
possible.
A digital MRV solution is comprised of 2 parts:••

A Digital Measurement and Reporting Solution that an
Accountable Impact Organization uses to create Impact
Claims by checking evidence in via checkpoints.
A Verification solution that the VVB uses to verify Impact
Claims created by the Accountable Impact Organization via
the Digital Measurement and Reporting Solution.

These 2 solutions integrate and communicate with each otherusing MRV transactions and extensions, messages, and events.

Long Term Monitoring Solution
A solution that monitors AIMs that have had credits issued thatlooks for events that would impact those issued credits, e.g., areversal event.
For example, a Monitoring Solution may use geospatial data andanalysis to detect a forest fire, early harvest or disease that causesa significant decrease or reversal of an issued carbon credit’s
durability and quantity.

Processed Claim
Once an impact claim is open for verification, the verifier (VVB) will
begin processing the Impact Claim it is verifying and will open a
Processed Claim once verification begins. To support continuousverification, an AIM developer(s) can continue submitting
checkpoints throughout the claim period and the VVB can add
Checkpoint Results as they are verified. Once the processed claim
is completed, the platform and/or VVB finalizes the Impact Claimand provides the necessary data in the request for issuance for theissuing registry to consider. The data review process is captured in
the Processed Claim and recorded in the Checkpoint Result.

12Checkpoint Result
To support continuous verification, a VVB may create a Checkpoint
Result for each Checkpoint that is verified. This checkpoint
result may contain communications between the VVB and the
Accountable Impact Organization about the data contained in the
checkpoint, such as a request for clarification. The Checkpoint
Result should contain a verified link to a package of verification
data, similar to the Span Data Package.

Impact Token: Carbon Removal Unit (Example Unit)
An issued digital asset, from a processed claim, that represents one
metric tonne of CO2e (for example) of carbon removal or reduction.
These credits are issued by an issuing authority and, once issued,
the Processed Claim is finalized. This credit is cryptographicallylinked to its processed impact claim sources for full transparency.

13

Framework Component Relationships
Framework components have relationships with other components. For example, an Activity Impact
Module (AIM) is dependent on the Standard Protocol chosen in which to base its claims on. The VVB
selected must be certified to verify claims for the Standard the AIM is using.
Of note, Carbon Credits and other Impact Benefit products are used to offset, or remove in this case,carbon to net effective emissions downward. The action of using a credit is commonly referred to as
retirement. In this framework, the credit is derived from an impact claim and its progression through thevalidation and verification process. As a claim progresses through its lifecycle and moves on to the nextstage, it is finalized, which means it is made permanently read-only and linked to its successor.
The framework relationship map:
AIO -> AIM
The AIM is a child entity of its parent Accountable Impact Organization (AIO).
AIM -> Quality Standard
The AIM is bound, or contracted, to follow a standard in which to form and create its impact claims.
VVB -> Quality Standard
The VVB must be certified to validate claims for the Quality Standard bound to the AIM.
Quality Standard -> MRV Extensions
A Quality Standard can define MRV Extensions.
AIM -> Quality Standard -> Impact Claim
The Impact Claim is a child of its parent AIM and is based on the Standard Protocol in the Quality
Standard.
AIM -> VVB -> Quality Standard -> Verification Process Agreement
A Verification Process Agreement has signatories representing the AIM, VVB and Quality Standard
participating in the claims process.
AIM -> Claim Source(s)Claim sources are registered with the AIM they are providing evidence for. These sources can be devices,
applications or reference data.
AIM -> MRV Extension(s)AIMs can have one or more attached MRV Extensions.
AIM -> Validations
An AIM will have at least one validation before verification can begin which contains the validation
artifacts created between the Accountable Impact Organization and the VVB.
Claim Source -> MRV Extension(s)A Claim Source can have one or more attached MRV Extensions.

14Claim Source -> Impact Claim
Sources of evidence collected are registered with the Impact Claim.
Claim Checkpoint -> Impact Claim
Claim Checkpoints are children of an Impact Claim which maintains a collection of checkpoints andsources.
Claim Sources -> Span Data Package
Only registered claim sources are allowed to have their data included in the Span Data Package.
Span Data Package -> Manifest
Each SDP contains a manifest.json file in the root of the package that contains metadata about its
contents.
Span Data Package -> MRV Extension(s)A Span Data Package can have one or more attached MRV Extensions.
Span Data Package (SDP) -> Claim Checkpoint
The SDP is the input to create a Claim Checkpoint.
Impact Claim -> VVB
Once notified, verification of the Impact Claim by the VVB or Verification Automations can begin.
Impact Claim -> MRV Extension(s)A Claim can have one or more attached MRV Extensions.
VVB -> Processed Claim
Once verification of an Impact Claim begins, the Processed Claim is created by the VVB and Checkpoint
Results are created as Checkpoints are processed. The Processed Claim, along with its checkpoint results,
allow for continuous verification progress to be demonstrated and monitored.
Processed Claim -> Impact Claim
When the Impact Claim is open for verification, the Processed Claim is created and the two claim states
become cryptographically linked.
Processed Claim -> MRV Extension(s)A Processed Claim can have one or more attached MRV Extensions.
Processed Claim -> Standard (Registry)
The Standard (Registry) is notified when the Processed Claim is finalized.
Standard (Registry) -> Carbon Removal Unit (example unit)
The Standard (Registry) conducts a final quality check on the Processed Claim and then issues a Carbon
Removal Unit and finalizes the Processed Claim.
Carbon Removal Unit (example unit) -> Processed Claim
The Carbon Removal Unit is cryptographically linked to the finalized Processed Claim.

15

Artifact Details
Accountable Impact Organization
The Accountable Impact Organization establishes an organizational identity for one or more ‘child’, or‘sub’, Activity Impact Module(s) and only contains basic organizational information primarily used for
identification. Establishing a hierarchical project structure allows for organizational and benefit projects
to be arranged logically, enabling many different business scenarios.
Activity Impact Module (AIM)An Activity Impact Module, is a ‘child’ of an Accountable Impact Organization, and serves as the systemof record for the actual type of project work that generates an impact being measured. It contains
information about who the developers or workers are, the project’s geographical boundary, its link to a
Quality Standard, etc. It can have one or more “developers” and “sponsors”, where a developer is theparty performing activities and a sponsor can be financing them. AIM developers, or their automations,are responsible for submitting claim checkpoints. Activity Impact Modules are validated and are thesource of impact claims to be verified.
AIM Sources
Activity Impact Modules produce claims that contain evidence. In order for the contained evidence’s
provenance to be established, a ‘claim source’ must be registered with the AIM. Some examples of claim
sources would be:••••

A device or sensor that takes measurements
An application that runs on a mobile device that uses the devices’ sensors, GPS, etc., and theauthenticated user to collect and submit evidence
A ‘reference’ source could be a Factor Library like the US EPA, IPCC, etc. libraries and version
A ‘service’ like a geospatial or satellite provider to provide biomass estimates or other remotesensing capabilities.

Because the capabilities of these sources of evidence can vary, the method for establishing an identity
for them to register will as well. There are several techniques for identifying a source and various ways toensure evidence integrity to prove that evidence came from a registered source.
Newer methods for establishing identity and integrity of data will be more thorough and trusted, but wealso need to support older, less capable sources of evidence that can be phased out over time in favorof fully identified and validated sources.
For example, newer devices can establish an identity based on Decentralized Identities and Verifiable
Credentials1 and are able to attest to their own evidence, see Attestation. Other devices may be able
to support PKI infrastructure2 and digitally sign their evidence. And in many cases, only a device make,model and serial number are available. In this specification we provide a general framework to support
as wide a range of sources and compatibility as possible, while recommending that sources migrate overtime to higher trust capabilities.
1
2

https://www.w3.org/TR/vc-data-model/#introduction
https://www.enisa.europa.eu/topics/incident-response/glossary/public-key-infrastructure-pki#

16Verification Process Agreement
The Verification Process Agreement documents the parties, rules, policies, and procedures between the
AIM (or Accountable Impact Organization), Standard, VVB, and/or other required parties for the creation,verification, and issuance of credits for claims made under the agreement. Every artifact created in thisprocess is linked back to the Verification Process Agreement. There is the potential for the Verification
Process Agreement to be implemented as a set of smart contracts or other processes.
The details such as the Standard, Version, and Protocol are all agreed to by the signatories of theagreement. An AIM may choose to switch standards or VVBs, which would require a new Verification
Process Agreement to be executed and the old agreement archived.

Figure 2: Properties of a Verification Process Agreement

17

MRV Extensions
To allow for the Digital MRV process to be customizable for each Quality Standard (methodology, protocol,
tools, etc.), extensions can be defined and attached to Activity Impact Modules, Claims, etc.
Digital MRV Extensions should be defined by the participants, in the context of a Quality Standard, in theorigination/manufacturing process (e.g., Methodology Developer, Issuing Registry, VVB). A Digital MRV
Extension should have a type, name, version, description, and optional documentation, then can containany structure of data expressed in name/value pairs and does not need to be understood by the network,
just by the participants in the process for that protocol or methodology.
MRV Extensions are process or data type context-specific and are scoped by their type, meaning they canbe defined to be attached to a specific data type, e.g., Activity Impact Module, Claim Source, Impact Claim,
Checkpoint, Span Data Package, Processed Claim, etc. In doing so they can record context-specific data
elements that are required for that data type for the Quality Standard being followed. For example, an
AIM MRV Extension can apply additional geospatial configuration data to a project, or a Claim Source canrecord additional identifying metadata to increase its record of provenance.
MRV Extensions should be agreed upon between the project application supplying the evidence andthe Verification Automations and/or VVB in order to streamline and optimize the process. It is expectedthat the development of standardized MRV Extensions will be adopted and incorporated into solutions
digitizing Quality Standards.
See the companion specification for details:
https://interworkalliance.github.io/TokenTaxonomyFramework/dmrv/spec/index.html
Span Data Package
A span data package is a file package (.zip, etc.) that contains data from registered sources that is to be
stored as evidence for a claim. It is up to the digital MRV solution as to the actual data format(s) so long as
it is agreed to and understood by the parties involved in the verification process.
Each SDP has a “manifest.json” file in the root of the package that contains metadata about the files
included and the sources the evidence originates from. The manifest.json is extensible to allow for specificextensions for digital MRV solutions and Quality Standards.
Claim sources are registered with the Impact Claim and provided an ID, this ID is used to validate andverify that the data contained within the SDP is from the registered source. Some sources may be capableof digitally signing their evidence, in which case the source’s public key would be registered with its ID.
Example claim sources that can be registered:•••

IoT Sensors
Reference Data (Satellite, Remote Sensing, etc.)
In-person application/device/human18Figure 3: Span Data Package

The manifest.json file within the SDP file can contain methodology- or protocol-specific attributes
or properties that can be defined and values stored. This allows for each protocol or methodology
to have a customized digital MRV implementation, yet also co-exist with other digitized protocols or
methodologies.
It is expected, but not required, that an implementation would read the manifest.json file and record it in
the checkpoint so that it is stored in the ledger and the SDP file can be persisted in an appropriate datastore. This allows for the network implementation to support placing dMRV-specific data on the ledger,
without having to “understand” every Quality Standard it supports.
Claim Checkpoint
Once the digital MRV solution creates an SDP, it will need to submit it to the Impact Claim as a Claim
Checkpoint. The SDP will be securely stored and a cryptographic fingerprint for the SDP acts as areceipt embedded in the checkpoint.

19

Impact Claim
The Impact Claim is the standard foundation for digital MRV solutions to create and submit a claim on
the MRV network. It has metadata about the claim and collections of children entities such as sources,
checkpoints, and co-benefits.
The Impact Claim, once it is open for verification, notifies the VVB/Verification Automations to begin
verification. Although it is likely that only a single VVB/Verification Automation would be verifying a claim,
because claims are composed of checkpoints, it is possible for multiple VVBs/Verification Automations to
split verification across checkpoints. An AIM would support multiple VVBs/Verification Automations andwould have these parties identified as signatories to the Verification Process Agreement. Validation andverification can be conducted by separate entities.

Figure 4: Impact Claim

20

Processed Claim
The processed claim is created by the Verification Automations or VVB to record its findings during thevalidation and verification process. Once the processed claim is completed, the platform and/or VVB
finalizes the Impact Claim and provides the necessary data in the request for issuance for the issuingregistry to consider.

Figure 5: Processed Claim
Impact Benefit Token Example: Carbon Removal Unit
The IWA VEM Overview generically describes a tokenized value representing an impact benefit token. It
provides an example of a carbon reduction/removal unit:•

Carbon Removal or Reduction Unit token (CRU) – is for removals or reductions and is nonfungible with other tokens of any type.

There is another token designed for distribution or markets called a Carbon Reference Token (CRT) thatreferences CRUs; it is not covered in this framework.
The credit that is issued by the standard (registry) upon final verification of a Processed Claim finalizes
that Processed Claim. This creates a chain of lineage from the issued credit to its Processed Claim and to
the source Impact Claim.

Figure 6: Carbon Removal Unit Generation

21

Framework Process Flow
Components in the framework work together following a process that generates artifacts documenting
and attesting each step along the way. Participants in this process are actors fulfilling a role in theprocess, contributing data, verification, and attestation that is cryptographically and immutably recordedby the MRV network.
The MRV network is the system of record for the participants in the process where entities like the
Accountable Impact Organization, Activity Impact Module, and Impact Claims are recorded.
Project Validation: Step 1
Activity Impact Modules are required to be validated by a VVB according to the Quality Standard the
AIM is following. The validation of an AIM may include multiple steps that usually have associateddocumentation that is generated or supplied. For example, an AIM will usually be required to produce
a Project Design Document (PDD), which provides details about the project, what activities are to be
conducted, and how evidence about these activities and their results will be collected. Additionally, an
AIM may need to produce documents that prove land ownership or a lease to ensure that the AIM isproperly licensed by authorities to conduct the activities.
Because the validation process can vary based on the Quality Standard (e.g., one that is for a naturebased project type vs.one that is for an engineering-based project type), the process is flexible to allow
for Quality Standard-specific validation processes to fit within the generic framework.
Each AIM will have a collection of Validations that establishes the time the validation was performed,
when it expires, as well as links to all of the steps that occurred or are in progress with verified links toany documents those steps produce.
Claims Process: Step 2 - Impact Claims
1. An Accountable Impact Organization, the identity of a source project that can make different types ofclaims, establishes an Activity Impact Module for each type of claim the host project will create, e.g.,
Carbon Removal, Carbon Reduction, water, etc.
2. An Activity Impact Module selects a Quality Standard from a Standard Registry that matches theactivity they will conduct to make a claim, e.g., Direct Air Capture, Soil – Crop Rotation & Covering,Forestry, etc.
a. There is a lot of development and refinement needed for Quality Standards for Carbon
Removals and Reductions to digitize the protocols.
b. There may be scenarios where a Quality Standard is not under management of aStandard Registry, but another organization on the network would support the standard
and issue credits for it.

22

3. The Quality Standard will lay out a “protocol” that prescribes the sources and cadence of evidence thatneeds to be collected (measured/monitored).
a. Development of AIM applications that will collect and submit the prescribed evidence, and acorresponding Verification Service or Platform to help automate the verification, is expected
as quality standards digitize.
4. Activity Impact Modules begin creating Impact Claims based on this protocol.
5. An Impact Claim is made up of a collection of Checkpoints.
6. A Checkpoint is a submission of evidence as prescribed by the protocol.
a. Protocol developers are encouraged to define a regular or event-based cadence for thecreation of checkpoints so that claim progress can be tracked downstream.
7. The MRV Network stores the evidence and records its cryptographic fingerprint in the ledger(checkpoints).
8. This process defines the Digital Measurement and Reporting Solution area for MRV.
9. There can potentially be a many-to-many ratio between Quality Standard and Digital Measurement andReporting Solution, meaning that a dMRV Solution may be able to support multiple types of Quality
Standards AND a Quality Standard may be supported by multiple dMRV Solutions.
Claims Process: Step 3 - Processed Claims
1. An Impact Claim needs to be verified by a Validation & Verification Body (VVB) and may be assisted by a
Verification Automation or Service that automates verification of evidence as much as possible. A VVB iscertified by the Standard Registry that governs the selected Quality Standard for the Impact Claim.
2. Once an Impact Claim is open for verification, it will notify the Verification Automations/VVB that it isready to begin processing.
a.

The Impact Claim is verified by the Verification Automations/VVB as defined in the 		
Verification Process Agreement and should not be processed by any other party.
b. The AIM can continue to submit Checkpoints to the claim for continuous verification.
3. The Verification Automations/VVB will verify each of the Impact Claim’s checkpoints to determine thetotal benefit – e.g., how many metric tonnes of CO2e were removed or replaced. The MRV network
provides the chain of custody and cryptographic evidence to authenticity.
4. The verification process will generate a report of its findings in a Processed Claim.
a.

Once the Processed Claim is created, the Impact Claim is linked to the Processed Claimand verification can begin.

23

b.

c.

Once the reporting period and final checkpoint has been processed, the Verification
Automations and/or VVB finalizes the Impact Claim and provides the necessary data in
the request for issuance for the issuing registry to consider, containing the property
values that were verified, e.g., total tonnes, co-benefits, etc.
The Processed Claim is finalized.

5. The Standard Registry that governs the Quality Standard used is notified of the Processed Claim.
6. The Verification solutions can be built and operated by Standard Registries or operated byindependent organizations. There will be consolidation of these solutions aligned to the types of
Quality Standards being used: e.g., Verification Automations focused on Forest Carbon, Soil Carbon,etc.
7. These solutions align to the Digital Measurement and Reporting Solutions via the Quality Standard
being followed (data formats, data sources, factors, etc.).
MRV Claims Process: Step 4 – Issuing Credits
1. The Standard Registry will reserve the Processed Claim to prevent any other registry from issuing
credits.
2. The Standard Registry may perform an additional KYC/Compliance check for the Accountable Impact
Organization to ensure that compliance has been maintained.
3. Credits are issued based on the Processed Claim’s findings/proposed credit: e.g., a Carbon Removal
Unit equal to 20mtCO2e.
a.

These credits become the property of the Accountable Impact Organization.

4. Credits may be enlisted in a Long-Term Monitoring solution (e.g., for nature-based carbon removals
like soil and forestry). This monitoring system can determine deviations in durability or permanencethat can result in the revocation and replacement of credits issued.
Following these processes, roles, and solutions - each creating, attesting, and contributing to the artifacts
along the way - will create an Impact Credit that contains a transparent link to its lifecycle data.

24

Quality Standard to Digital MRV Mapping
A Digital MRV solution needs to follow a Quality Standard and the methodology or protocol it contains
for its implementation. It would be optimal for methodology and protocol developers to be aware ofthis framework and be able to prescribe evidence collection methods and checkpoint cadence for thebuilding of Impact Claims.
For example, protocol developers can prescribe:••

A data source: a device, an application or reference data that can provide evidence to support
the claim. As these devices produce data, further considerations will need to be made on error/
exception handling and data utilization in the case of errors.
•
		
		
		
•
		
		
•
		

Specify the data source identity parameters required for the source to be 			registered to submit valid evidence. Can include device identifiers, application 		
certificate, user identifiers, geolocation and time stamps, reference data URL with 		data hash, etc.
Specify the data format for the evidence a registered source should submit, 			
including if the data should be digitally signed. This can include the data type (i.e., 		file extensions), meta-data, etc.
Specify the cadence which evidence should be included in a Span Data Package for 		
submission as a checkpoint.

•

Specify the cadence at which a device must be inspected and recalibrated for it to 		remain a registered and valid source of data.

•

Specify the data format in which the evidence of device inspection and recalibration
should be submitted.

The establishment of a cadence for claim checkpoints for building the Impact Claim over time.
These can be event-based checkpoints (e.g., agricultural events between crop rotations) ortime-based (e.g., every day/week/month).

Attestations
Attestations provide opportunities for context in MRV data. Conceptually, attestations can be the data
within the project or the commentary around the project. For project data, “Direct Data Attestations” cancome from individuals, project developers, verifiers, and/or directly from devices asserting an event thatis represented digitally on the public ledger.
Attestations, metadata, or “Tags” describing digital entities, such as actors, calculations, or theirquantifiable outcomes, allow for more context to exist about Accountable Impact Organizations within
the market, which inherently have a relationship with credit pricing and can describe overall project
effectiveness.
For these “Tags” about the project to have further meaning they need to have an understanding of thereal-world activity and the digital data model. This brings to light both “High-Definition” workflow data
in digital MRV and its relationship within data models to “Low-Definition” attributes, which form higher
order concepts that act as metrics for the market and ecological outcomes. Attributes are formed byproviding a relationship of specific schemas, data, and calculations to higher order concepts such as
Additionality, Durability, and Leakage, but can span to much broader concepts including co-benefits and
SDG-oriented statistics.

25

The level of granularity, accuracy, and the breadth of information covered, in addition to theconsistency of the information, form the basis for reputation of both the project and actors involvedin the Accountable Impact Organization. Some examples of attestations surrounding a project can be
represented in Tags as described below:
•
•
•
•
•

tags can be created by any actor with a valid ID (recommended to be a DID).
created tags should be credentialed, i.e., it should be clear who and when created or added toa particular tag.
tags can have cumulative scores, e.g., two people independently creating/assigning the same
tag to the same artifact results in both tagging actions recorded (credentialed etc.), and the ‘tagscore’ is then counted as 2.
It is possible for users to untag the item; however, this action does not remove the record oftagging in the first place, it just records the action of untagging (also credentialed) and reduces
the score by 1.
tags should be able to be associated with any identifiable entity/thing/artifact that uses and/or
produces, such as:
•
•
•
•
•
•

•
•
•

actors, including SRs (i.e. DIDs)
schemaspolicies and policy modules
VCs/VPs
tokenssmart contracts (ie. addresses)

tags can be created after the (immutable) artifacts are produced, therefore tags are external to
artifacts.
it should be possible to create and/or follow tag ontologies containing the definition or
description of tags.
tag registry[-ies] should be discoverable and usable by automated indexing systems.

An example of tags in the Hedera ecosystem can be found in the Appendix. While the IWA and theparticipants do not prescribe or endorse Hedera specifically, it is important to include a reference
implementation to demonstrate what tagging might look like.

Reputation
For reputation to take effect, based on digital MRV data and attestations, it is suggested to use acredential model that is fully traceable and contextually aware. Although reputation is often thought ofin the context of projects, companies, or individuals, reputation should be considered to be extensible
to devices, methodologies, or even specific sections of a methodology. This allows for a more complex
understanding of a project and substantive details. Although this is often price-focused, reputation canalso facilitate discourse on effectiveness of a project or any element or actor involved in a project. There
should not need to be a single data model; however, using public ledgers and associated tooling, there
should be an opportunity for reputation systems to form based on open standards and access to nonconfidential information.

26

Confidentiality in Attributes & Asset Generation
The data associated with a project that may be relevant to reputation will likely be limited as we transition
to a more digitally native format. However, there are also privacy and confidentiality considerations that
may not have been fully considered in the analog format.
To enable confidentiality in MRV data, there are multiple approaches to privacy; however, there are
specific requirements to enable this in the requirements of an MRV workflow. The below example is not
an endorsement of a specific approach, but shows an example reference based on W3C standards.

Reference Example
In a reference example for generating Digital Ecological Assets, the Hedera Guardian uses the W3C
standards of Decentralized Identifiers (DIDs), Verifiable Credentials (VCs), and Verifiable Presentations(VPs) in order to capture digitally signed documents that are stored on the decentralized InterPlanetary
File System (IPFS).
Guardian uses VCs & VPs for a variety of data types - particularly:••

Monitoring, Reporting & Verification (MRV) data capturing the actual carbon reduction,
removals, or renewable energy generation.
The policies that digitize the methodology. In this context of carbon debits & credits, amethodology is a framework document that defines the rules governing the MRV process andthe criteria for minting tokens corresponding to that MRV process.

The current Guardian model publishes MRV data as a VC and creates a corresponding VP, apriori fromthat VC, and stores the VP on IPFS. The VP (and the VC within) can be retrieved from IPFS at any time andare, by default, unencrypted.
While this default transparency enables easy validation of provenance chains, it may not be acceptable toall enterprises considering using Guardian to track emissions of their manufacturing processes. While abusiness may recognize the need to be fully transparent about the amount of CO2 emissions associatedwith their business processes, they may wish to keep some details of those processes less than fully
public to protect associated intellectual property and confidentiality.
Separately, confidentiality may be required to protect an individual’s information. For instance, ahomeowner that installed solar panels may not want their street address public, but recognize that theapproximate location is important for assessing the credibility of energy production.
This sort of confidentiality can be challenging to reconcile with the desired transparency andcomposability and the fundamental choice of using a public Distributed Ledger Technology (DLT), like
Hedera, to track the provenance of Environmental, Social, and Governance (ESG) assets.
Below is an example of attestations with selective disclosure. This model enables delivery of digital MRV
generated attributes that include information which may not be publicly disclosed due to confidentiality
concern.

27

Co-benefits & Modular Benefits
Today’s voluntary carbon credits have “co-benefits” attached that map to one or more of the UN
Sustainable Development Goals (SDGs). While these attached co-benefits can provide additional
information about the project the credit is sourced from, they are not subject to the same validation andverification requirements of the actual credit that they are attached to.
This is not to say that these co-benefits are without merit, just a recognition that these co-benefits are
attributes that cannot stand or be traded on their own yet. This specification continues to recognize
these UN SDG-based co-benefits and enables projects, verifiers, and issuing registries to include them intheir processes and attach them to credits issued. We refer to this type of co-benefit to be dependent,
meaning the co-benefit is dependent on a credit in order to be traded and cannot be separated fromthe credit it is dependent on.
There are some co-benefits, and others in development, that are intended to be able to stand on
their own and be either bundled with a credit or traded separately. These Independent Co-Benefits
should follow the same process as an Activity Impact Module, meaning they are sourced from the same
Accountable Impact Organization, but are defined in their own AIM that is mapped to a Quality Standard
for the Co-benefit type, and need validation and verification of claims.
Dependent co-benefits are defined within the AIM for the credit they are dependent upon, andIndependent co-benefits are defined in their own AIM.

28

Moving Forward
Continued collaboration is required to both improve and continuously refine this framework so thatit can help establish a common understanding of the Process and Data standards needed to support
interchangeable Quality Standards. This modular approach to standardization along with a foundation
based on common terms and shared data descriptions should aid in the development of new Quality
Standards for a wide range of products in the future.
Thank you to those who have already submitted feedback on the framework. We recognize that there
are likely still areas that need to be further addressed and explored. As this guidance is implemented
in real use cases, we welcome and appreciate your continued feedback on this paper as we work tocontinue to refine the Digital MRV Framework and provide robust guidance to implementers and thoseinterested in understanding how a digital MRV solution functions.
If you have feedback you would like to provide to the IWA working group, please send that to
IWA@gbbcouncil.org so the group can consider it for future versions of the document.

29

Appendix

Tagging Example
An example of tags can be seen here regarding Energy efficiency measures in thermal applicationsof non-renewable biomass. The below example demonstrates a Hedera-based implementation ofa technology standards-based tagging architecture which can cover all public artifacts produced by
Guardian instances. This is not advocating for a specific platform for implementation, but serves as an
example of how tagging could be represented.
Methodologies (which are represented digitally as policies) can be tagged with additional contextual
information on parameters such as “Estimating biomass fuel savings (By)”.
A working paper published by the Stockholm Environment Institute (SEI) detailed several issues withcookstove methodologies such as CDM’s AMS II.G, specifically related to the following parameters:-

Estimating biomass fuel savings (By)
Fraction of nonrenewable biomass (fNRB)
Default emission factors (EFprojected_fossilfuel)Regarding Estimating biomass fuel savings (By), this parameter is calculated based on the efficiency ofold devices to be replaced and the efficiency of project devices. Under the CDM methodology AMS-II.G.:
Energy efficiency measures in thermal applications of non-renewable biomass, there are three methods thata project proponent can choose from to estimate device efficiency, the Kitchen Performance Test (KPT),
Water Boiling Test (WBT), or Controlled Cooking Test (CCT). However, there have been some considerable
criticisms and concerns related to the WBT outlined by the SEI working paper. In general, the WBT —which is performed in a lab — results do not translate well to actual performance in the field. The KPT, bycontrast, involves testing the devices by local cooks in actual households based on actual cooking tasks
to provide a more accurate efficiency test.

30

In this use case, a project proponent conducting a cookstove project, using AMS-II.G., and opting to
use the KPT method can tag the parameter ‘Efficiency of the project device i and batch j (nnew,i,j)’ to provide
additional information about how the parameter was estimated and how this impacts the parameter’svalue. Within this tag, the project proponent can have a description of the KPT and monitoring approach
implemented, and the benefits relative to the WBT option. They can also specify what the parameter’svalue (project device efficiency) would have been under the WBT method.
This tag can be discoverable and linked to the project and parameter to provide useful information forinterested stakeholders such as other project proponents seeking more accurate alternatives to the
WBT, or marketplaces and purchasers looking to identify projects that have more robust monitoring andquantification approaches.

Tag Name

Cookstove Efficiency Test and Monitoring Method

Project ID

XYZ321

Methodology

AMS-II.G.: Energy efficiency measures in thermal applications of non-renewable biomass

AssociatedParameter

Efficiency of the project device i and batch j (nnew,i,j)

MethodImplemented

Kitchen Performance Test (KPT) and Monitoring

Under the CDM methodology AMS-II.G.: Energy efficiency measures in thermal applicationsof non-renewable biomass, there are three methods that a project proponent can choose
from to estimate device efficiency, the Kitchen Performance Test (KPT), Water Boiling Test
(WBT), or Controlled Cooking Test (CCT). However, there have been some considerable
criticisms and concerns related to the accuracy of the WBT. In general, laboratory tests
results do not translate well to actual performance in the field.
The KPT, by contrast, involves testing the devices by local cooks in actual households for
actual cooking tasks to provide a more accurate efficiency test.
Description

This project implements the KPT method, which is a community test (performed in actual
households); measuring fuel use in households based on normal cooking tasks over several
days.
This approach subtracts the quantity of woody biomass used by project participants (basedon a random sample) from the amount of biomass used by a representative sample ofnon participant households. Both are measured over a three-day period. Total biomass
available in the household is weighed at the start and end of each day or meal to measure
the weight of fuel used.

Parameter Value
Under the Water
Boiling Test
(WBT) Method

44%

31

Tagging Implementation example:
Tag actions can be implemented on an immutable ledger, such as Hedera, for tamper-proof, auditable
and credentialed event records such as in the following example:{“id”: “964c9e42-5483-4385-ba2f-71328f17f952”,“status”: “ISSUE”,“type”: “Tag”,“action”: “publish-tag”,“lang”: “en-US”,“uuid”: “ecd3e6b5-e5d9-4111-aadf-e9ea9d5b5763”,“name”: “Cookstove Efficiency Test and Monitoring Method”,“description”: “”,“owner”:“did:hedera:mainnet:4XjqvXeMYPes1dmPVEfMmewNgER8zedFir3ufZN2gnMP_0.0.3732665”,“target”: “1694106714.582861517”,“operation”: “Create”,“date”: “2023-09-07T17:14:01.904Z”,“entity”: “Policy”,“cid”: “bafkreiaiihlee66mncrzah2her35rjd3srr3rdjuiyzw6uzvyfhsfaejwe”,“uri”: “ipfs://bafkreiaiihlee66mncrzah2her35rjd3srr3rdjuiyzw6uzvyfhsfaejwe”}
Tags can contain or refer to extended information, secured by the cryptographic signature protecting
against tampering as the following example demonstrates:{“id”: “urn:uuid:e7916131-aa98-45fa-ab89-f1fcfceaf033”,“type”: [“VerifiableCredential”],“issuer”:“did:hedera:mainnet:4XjqvXeMYPes1dmPVEfMmewNgER8zedFir3ufZN2gnMP_0.0.3732665”,“issuanceDate”: “2023-09-07T17:14:01.930Z”,“@context”: [“https://www.w3.org/2018/credentials/v1”,“ipfs://bafkreicx6ecmje427oxss4w4ifw43mu7qezsct6ee3g6vra6fr32yrbda4”],“credentialSubject”: [{“methodology”: “AMS-II.G.: Energy efficiency measures in thermal
applications of non-renewable biomass”,“associatedParameter”: “Efficiency of the project device i and batch j(Nnew,i,j)”,“methodImplemented”: “Kitchen Performance Test (KPT) and Monitoring”,“description”: “Under the CDM methodology AMS-II.G.: Energy efficiency
measures in thermal applications of non-renewable biomass, there are three32methods that a project proponent can choose from to estimate device efficiency,
the Kitchen Performance Test (KPT), Water Boiling Test (WBT), or Controlled
Cooking Test (CCT). However, there have been some considerable criticisms
and concerns related to the accuracy of the WBT. In general, laboratory tests
results do not translate well to actual performance in the field. The KPT, bycontrast, involves testing the devices by local cooks in actual households
for actual cooking tasks to provide a more accurate efficiency test. This
project implements the KPT method, which is a community test (performed in
actual households); measuring fuel use in households based on normal cooking
tasks over several days. This approach subtracts the quantity of woody biomass
used by project participants (based on a random sample) from the amount ofbiomass used by a representative sample of nonparticipant households. Both aremeasured over a three-day period. Total biomass available in the household isweighed at the start and end of each day or meal to measure the weight of fuelused.”,“parameter”: 44,“@context”: [“ipfs://bafkreicx6ecmje427oxss4w4ifw43mu7qezsct6ee3g6vra6fr32yrbda4”],“id”:“did:hedera:mainnet:4XjqvXeMYPes1dmPVEfMmewNgER8zedFir3ufZN2gnMP_0.0.3732665”,“type”: “a9f8123a-4ec7-4cb9-a4ba-62170bcb9b08&1.0.0”}],“proof”: {“type”: “Ed25519Signature2018”,“created”: “2023-09-07T17:14:01Z”,“verificationMethod”: “did:hedera:mainnet:4XjqvXeMYPes1dmPVEfMmewNgER8zedFi
r3ufZN2gnMP_0.0.3732665#did-root-key”,“proofPurpose”: “assertionMethod”,“jws”: “eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..
QHHRxHLzT1KmpByZiyweWOPghvZ2B0E_
JNjb7rJNXrM2S0sIq3F2E2p99G7roJYBz3ZbLrgFA3Jo2CaNBx1RBA”}}
These code samples are equivalent to the tag example given earlier.

33

Contributors
Clark Thompson
Jodelle Lai
Nick Ho

Accenture

Boone Bergsma
Denis Angell
Guillermo Mondelli
Janchen Georg

Blockchain Laboratories

Andrey Brozkho
Daniel Norkin
Jason Pancis
Max Pinnola
Prernaa Agarwal

Envision Blockchain

Jackson Ross

Global Blockchain Business Council (GBBC)

Hania Othman
Jonathan Rackoff
Paul Madsen
Wes Geisenberger

HBAR Foundation

David Grimes
Miles Austin

Hyphen Global AG

Marley Gray

Microsoft

Taquin Ho

NasdaqRichard Dwelle

Rearden Digital Assets

Stan Chen

RecycleGO

Cory Levinson
Sam Bennetts

Regen Network

Cameron Prell

The dCarbon Group

Andrew Greeley
Darren Wolfberg

Triangle Systems

GLOBAL
BLOCKCHAIN
BUSINESS COUNCIL
DC Location:

1629 K St. NW, Suite 300
Washington, DC 20006

Geneva Location:

20 Rue de-Candolle
1205 Geneva