What Route 10 is
R10 produces thermal attributes (Renewable Thermal Certificates in North America via M-RETS, Guarantees of Origin for heating and cooling in the EU via the AIB framework) from useful heat generated by heat pumps, solar-thermal collectors, and geothermal systems. R10 also covers thermal flex: availability and dispatch payments for thermal storage (water tanks, phase-change materials, thermal energy storage) and controllable heat loads (heat-pump setpoint shifts, district-heat balancing).
Thermal attributes are the heat-side equivalent of power-side RECs and GOs. They prove that one MWh-th of useful heat came from a renewable source: directly (geothermal, solar-thermal) or indirectly (heat pumps whose electric input is renewably matched when a buyer requires that). Corporates and district-heat operators retire thermal attributes for portfolio claims, 24/7 heat matching programmes, and as supporting evidence for Scope 1 and Scope 2 reduction claims on building heat.
Thermal flex is analogous to power-side VPP and demand response (which the energy side covers under R2): the asset is paid for its capability to shift heat consumption or to dispatch stored heat during stressed periods on the wider energy system.
The market reality R10 plugs into
Heat is the largest end-use of energy globally. The IEA's heat tracking shows heat at roughly 50 percent of global final energy consumption and about 38 percent of energy-related CO2 emissions (2022 data). Industrial heat is about 53 percent of total heat demand; buildings about 44 percent. Decarbonizing heat requires electrification (heat pumps), renewable thermal generation (solar-thermal, geothermal), and thermal storage that can balance loads across the day. R10 plugs all three into the voluntary attribute markets.
District heating supplies about 17 EJ of heat annually, concentrated in China, Russia, and Europe; these regions are also where the GO-Heat framework is most active under the EU Renewable Energy Directive and the AIB hub. The Member State coverage for GO-Heat is expanding as the heating sector decarbonization picks up pace.
In North America, M-RETS operates the Renewable Thermal Certificate tracking system. The RTC scheme is the most mature thermal-attribute infrastructure in the Western Hemisphere and supports the corporate Scope 2 heat claims that increasingly appear in sustainability reporting.
Pricing reality: generic RTC and GO-Heat trades in the low single digits dollars per MWh-th. Hour-and-location-matched 24/7 thermal bundles (analogous to the 24/7 carbon-free energy programmes on the power side) can price materially higher but are buyer-specific. Thermal flex value is program-dependent: availability payments plus event dispatch payments per the local market structure.
How R10 works
After the eligibility and routing step (heat pump or solar-thermal or geothermal class confirmed, meter class confirmed, jurisdiction routed to RTC or GO-Heat scheme), R10's metering at S01 connects the certified heat meter. The metering standard is EN 1434, which specifies the requirements for useful-heat measurement: a flow meter on the heat-transfer fluid plus a temperature differential measurement between the supply and return streams. The product (mass flow rate × specific heat capacity × ΔT) is the useful heat delivered in kWh-th.
For heat pumps that claim renewable heat output rather than just delivered heat, the electric input is also metered to enable a COP audit (Coefficient of Performance, the ratio of useful heat output to electric energy input). Where buyers require renewable electric input matching (typical for the highest-integrity heat claims), the corresponding Route 2 hourly attribute retirement IDs are referenced as part of the R10 retirement claim.
At S02-S04, the protocol pattern is the standard EDMA flow: edge canonicalization of the meter readings, three-role attestor quorum (METER_OP plus utility or scheme integrator plus AUDITOR), PoV Gate evaluation against quorum, equality, and One-Claim Ledger exclusivity (keyed on asset_id plus hour plus grid_zone).
At S05, on PoV Gate pass, HTT mints to the producer's wallet at 1 HTT = 10 kWh-th. Each HTT carries the start_timestamp, end_timestamp, asset_id, fuel_class, and location as on-chain metadata.
At S06, aggregator contracts roll 100 HTT into 1 MWh-th of issuable thermal attribute. The external registry issues the RTC (M-RETS) or GO-Heat (EU AIB hub) with the Issue ID returned and anchored on Ethereum L1.
At S07, the buyer requests retirement against their Scope 2 heat claim or 24/7 heat-matching programme; the registry executes the retirement; the Retire IDs are anchored on-chain; the backing HTTs are stamped consumed and non-transferable. Thermal flex revenue (if the asset is enrolled in availability and dispatch programmes) settles on a separate stream and does not consume HTT.
The seven-stage diagram below shows the full path.
The flex side
Thermal flex is the second revenue stream R10 supports. Three types of assets are typically enrolled:
Heat-pump setpoint shifts. A heat pump can shift its operation by 30-60 minutes without affecting comfort, providing dispatch capability to the wider electric system. Availability payments compensate the asset for the option; event payments compensate for actual dispatch.
Thermal energy storage (TES). Water tanks, phase-change materials, and other thermal storage that can be charged when energy is cheap and discharged when needed. Availability plus event payments depending on the program structure.
District-heat balancing. Larger-scale flex from district-heat networks that can shift heat injection across hours.
The flex evidence is separate from the attribute evidence: telemetry on availability, event dispatch logs, and program-specific baselines. The flex revenue settles per the program rules and does not consume HTT. Flex and attributes are independent revenue streams from the same asset, the same way DR and electricity attributes stack on R2.
Stacking with other routes
R10 is compatible with Route 2 in one specific case: if a heat-pump claim requires renewable electric input matching, the Route 2 hourly attributes for the HP input hours must be retired or immobilized first; the Route 2 retirement IDs are then referenced in the R10 retirement claim.
R10 is compatible with Route 4 (additionality-grade energy-side carbon) for fuel-switch claims, but only if the overlapping thermal attributes are retired or immobilized first. A fuel-switch carbon claim says 'this heat would have come from a fossil source; it now comes from a renewable source; the carbon difference is the claim'. If the renewable thermal attribute (RTC or GO-Heat) for the same heat has been sold separately, that attribute must be retired before the carbon claim is queued.
R10 is compatible with Route 11 (methane avoidance) for waste-heat recovery from AD plants or other methane-capture operations, where the heat is monetised on R10 and the methane avoidance is monetised on R11 separately, with the overlap retired per the one-claim discipline.
R10 is compatible with Route 3 (community pool participation) on independent assets.
Where it stands
R10 is built on the same protocol-level architecture as the energy routes. The R10-specific work is in three areas:
HTT contract. The Heat Tracking Token contract, parallel to ETT but configured for the 10 kWh-th granularity and the EN 1434 evidence schema. The HTT carries the heat-specific metadata (fuel_class covers HP, solar-thermal, geothermal, etc.) and the 100-to-1 aggregation rule to MWh-th.
RTC and GO-Heat registry bridges. Attestation contracts for M-RETS (the RTC scheme in North America) and for the EU AIB GO-Heat hub. The bridges anchor the Issue and Retire IDs on Ethereum L1 and reference them from the HTT consumption records.
Heat MRV verifier panel. Independent verifiers with the specific expertise to audit EN 1434 metering, COP audits for heat pumps, and thermal-flex baselines. The panel is built jurisdiction by jurisdiction.
Thermal-flex enrollment depends on the local market structure. The protocol design supports the major program types (capacity payments, event dispatch, district-heat balancing) but the specific enrollments are jurisdiction-dependent.
For the protocol-level architecture R10 depends on, see Proof-of-Verification, One-Claim Ledger, Attestor Registry, and the sibling complex route pages: R9 Diesel-Solar Microgrids, R11 Methane Avoidance, and R12 Tech Removals.
