Machine-Ready: The API and Data Product Layer Behind Every QET

For developers, ERP integrators, ESG-software engineers, and customer technical teams, machine-readable emissions data is the difference between a registry-grade attestation that flows through the buyer’s existing systems and one that requires manual reconciliation at every step. Machine-Ready is the API and data product layer that makes Greentruth’s Quantified Emissions Tokens (QETs) consumable programmatically — REST endpoints, webhook events, schema-first attributes, DID-compliant identifiers, and the EarnDLT registry’s Hedera Hashgraph anchoring all exposed cleanly.

Machine-Ready, in one paragraph. Machine-Ready is Greentruth’s developer surface, built on the EarnDLT blockchain infrastructure that anchors every QET on Hedera Hashgraph. It exposes the full QET lifecycle — mint, discover, acquire, retire — as REST endpoints with webhook events on every state change. The data product layer publishes a schema-first attribute model with DID-compliant identifiers, so the same record an ESG-software platform consumes is the same record an autonomous procurement agent reasons over. The architecture is designed for both the carbon accounting stack reporters use today and the agentic-AI consumption patterns the industry is converging on.

What a QET is in the first place

Machine-Ready is the integration surface that sits between Greentruth’s application layer (where buyers discover QETs, run the GasTrace workflow, and retire tokens against reporting claims) and EarnDLT’s registry infrastructure (where the underlying tokens are minted, transferred, and retired on Hedera Hashgraph).

Practically, three things sit inside Machine-Ready:

• The API. A REST surface covering every step of the QET lifecycle — mint, discover, acquire, retire — plus the framework-aligned exports each retirement produces.
• The event stream. Webhook events on every QET state change, so an integrated platform stays current without polling. Mint events, transfer events, retirement events all stream out.
• The schema. A versioned, schema-first attribute model that defines exactly what attributes every QET carries, in what shape, with what data types. The schema is the contract integrators build against.

For developers, the practical effect is that Greentruth’s registry-grade attestation flows through the buyer’s existing accounting platform, ERP, or sustainability software without manual reconciliation steps that introduce error and slow disclosure cycles.

The Machine-Ready API exposes the four marketplace lifecycle stages as parallel resource surfaces. The same authentication, the same schema, and the same versioning apply across all four.

• Minting. Producers (and Measurement Partners on their behalf) submit primary data, the methodology runs, the accredited third-party verifier signs off under ISO 14064-3 reasonable assurance, and the token issues on-chain. Minting endpoints expose the producer-side mint pipeline as REST operations.
• Discovery. Buyers search the live registry by attribute — geography, MRV tier, methodology version, regulatory eligibility (LCFS, EU Methane Regulation, GHG Protocol Scope 2 market-based). Discovery endpoints expose the search as a queryable REST surface, with saved searches and watchlist support.
• Acquisition. Buyers acquire QETs via on-chain transfer. The transfer is recorded on Hedera Hashgraph; the token lands in the buyer’s wallet. Acquisition endpoints handle the order, payment, and on-chain transfer.
• Retirement. Buyers retire QETs to anchor specific reporting claims. The retirement is irrevocable on-chain. Retirement endpoints write the claim record and produce framework-aligned exports (GHG Protocol Scope 1/2/3, SBTi-aligned, CSRD ESRS E1, IFRS S2, SB 253, TCR GRP) on a single retirement transaction.

Minting · Discovery · Acquire · Retirement

For how the four lifecycle stages connect

Polling is the wrong primitive for a registry where state changes are the meaningful events. Machine-Ready publishes webhook events on every state change in the QET lifecycle:

• Mint events. A new QET has been issued on the registry, with all its attributes attached. Useful for buyer-side platforms running saved searches that match the new token.
• Transfer events. A QET has moved from one wallet to another. Useful for marketplace participants tracking inventory.
• Retirement events. A QET has been retired against a specific claim. Useful for the buyer’s disclosure platform consuming the framework-aligned export at retirement.
• Methodology version events. When a methodology version pin changes (annual R&D GREET 2025 refresh, a CNZS version transition, a CARB rulemaking update), the methodology event stream surfaces it so integrated platforms can stay current.

The architecture is designed so an integrated platform stays in sync with the registry without polling, and so an autonomous procurement agent reasoning over QETs can subscribe to the lifecycle changes that affect a specific portfolio.

The schema is what makes machine-readable emissions data more than just an API call. Every QET on the registry exposes a versioned, schema-first attribute set, with required fields, explicit references, and version pinning. This satisfies the ISO 14064-3 verifier-side expectation that verification criteria be “relevant, complete, reliable, and understandable” and “available to the intended user” — a JSON schema delivers exactly that at the structural level.

The universal attributes every QET exposes:

• Unit — the defined physical unit the token represents (1 MMBtu of natural gas, 1 MMBtu of RNG thermal energy, 1 MWh of electricity, or 1 tonne of geologically stored CO₂).
• Multi-pollutant CI in kgCO₂e/MMBtu (where applicable), with CH₄, CO₂, and N₂O converted via IPCC AR5 GWP100 (CH₄ = 28, N₂O = 265).
• Geography and pathway — basin, operator, validated pipeline pathway across EarnDLT’s 32,000-segment Lower-48 network model.
• MRV tier — where the data sits in the methodology’s hierarchy (site-specific primary → process-specific primary → peer-reviewed secondary → industry-average secondary).
• Methodology version including the R&D GREET 2025 reference dataset version.
• Verifier of record — the accredited third-party that signed off under ISO 14064-3.
• Retirement record (when applicable) — the entity, reporting period, and disclosure line the token has been retired against.

Token-specific attributes layer on within each class (producer-carried grades for QET-NG; biogenic carve-out for QET-RNG; hourly granularity for QET-ELEC; storage permanence for QET-CCS).

How the data-quality hierarchy works

How ISO 14064-3 underpins this

Independent commentary from the Payne Institute for Public Policy at the Colorado School of Mines (O’Byrne and Handler, April 2026) frames the longer arc explicitly: as the broader economy moves toward agentic AI — where autonomous reasoning models and software agents consume data at scale to make procurement, compliance, and reporting decisions — the value of tokens that embed full methodological provenance in a machine-readable structure compliant with DID (decentralized identifier) standards increases. Tokens lacking that architecture cannot be reliably consumed by systems and agents; tokens that have it become native inputs to automated decision-making.

Machine-Ready is built on that horizon, not against it. DID-compliant identifiers, JSON schema with required fields and explicit references, methodology and verifier provenance baked in — these are the structural properties an autonomous agent needs to reason over QETs without human intermediation.

A concrete example of the kind of hyperscaler-scale consumption this architecture supports: major corporate procurement programs (Google’s published T-EAC framework being one well-known public example) consume electricity-attribute data at hourly granularity, programmatically, with full methodological provenance. Citing this kind of example is not a claim of partnership, affiliation, or current use — it is an illustrative reference point for the consumption pattern Machine-Ready is built to serve. QET-ELEC carries the attribute structure those programs contemplate; Machine-Ready exposes it as API.

For QET-ELEC specifically

The infrastructure underneath Machine-Ready is the EarnDLT registry, running on Hedera Hashgraph. For technical teams evaluating registry-grade attestation, three things about that architecture matter:

• Single-mint enforcement at the registry layer. A specific physical unit produces exactly one token. The mint pipeline structurally rejects any attempt to issue a second token for the same unit.
• Irrevocable on-chain retirement. Once retired, a QET cannot be re-retired, re-used, or rolled forward. The retirement record is a permanent state change written to the Hedera ledger.
• Tamper-evident timestamping. Every mint, transfer, and retirement is recorded with cryptographic timestamping. Records and chain-of-custody are retained for at least 10 years per the ISO 14064-3 expectation.

Greentruth’s application layer (the dashboard, the GasTrace workflow, the buyer’s wallet view) sits on top of this infrastructure. The Machine-Ready API exposes the registry’s lifecycle operations as REST endpoints, so a developer working at the application layer doesn’t have to interact with raw on-chain primitives unless they specifically want to.

How double counting is structurally prevented

Most large reporters already run a carbon accounting platform — Watershed, Persefoni, Sweep, Workiva, or similar. Machine-Ready is built to integrate with that stack additively, not to replace it. The integration patterns:

• Direct REST integration. The ESG platform consumes QET data via the Machine-Ready API as a structured data source. The platform’s existing disclosure workflow stays intact; the inputs get sharper.
• Webhook-driven updates. As new QETs match the buyer’s saved criteria, as transfers happen, as retirements settle, the ESG platform receives webhook events and updates the buyer’s view without polling.
• Framework-aligned exports at retirement. When the buyer retires a QET, the ESG platform receives the framework-aligned export (SBTi, GHG Protocol Scope 1/2/3, CSRD ESRS E1, IFRS S2, SB 253, TCR GRP) and routes it into the buyer’s disclosure workflow.

For an ERP, EHS, or in-house GHG accounting system, the same integration model applies — the API is platform-agnostic, the schema is published, and the lifecycle endpoints are documented for direct integration.

For ESG teams' workflow specifically

For corporate sustainability programs

The regulatory landscape is moving rapidly toward machine-readable disclosure as a requirement, not a preference:

• CSRD ESRS E1. EU mandatory sustainability reporting requires machine-readable filings (ESEF / XBRL tagging) for in-scope entities. The data structure CSRD expects is the data structure Machine-Ready produces — methodology-versioned, verifier-stamped, with ESRS E1 line items mapped from the underlying QET attributes.
• SEC climate disclosure. Where SEC rules apply, the XBRL tagging requirement means disclosure inputs have to be machine-readable end-to-end. Machine-Ready exposes the underlying attestation data in the form an XBRL-tagging workflow can consume.
• OGMP 2.0 Level 5 interoperability. OGMP 2.0 at Level 5 (site-level reconciliation) is structurally a machine-readable framework. The underlying QET-NG data feeding it is interoperable at the schema level.

How EU Methane Regulation consumes this

How QETs align across reporting frameworks