Make useful heat the main product, and choose a co-product with an established route to revenue. That is the economic idea behind the Heat21 approach.
Useful heat can still be expensive to use
A supermarket's refrigeration equipment, a factory or a data centre may release heat that another process could use. Why let it escape?
Because a usable heat supply needs more than a source. Temperature, distance and timing have to match demand. Pipes, heat exchangers and storage cost money. Someone must find a customer, arrange the connection and agree what happens when either business changes its operations.
Those last tasks are transaction costs: the work of organising and maintaining an exchange. They sit alongside the physical costs of recovering and delivering the heat. A research review of waste-heat recovery barriers documents both technical and commercial obstacles.
Rejecting heat can therefore be economically rational. A potentially useful by-product is not automatically a worthwhile second business.
Start with the heat customer
Heat21 reverses the starting point. We begin with a building that needs heat and ask: which heat-producing activity could help pay for meeting that demand?
The Node brings specialised computing hardware close to the heating system. A water circuit recovers heat from the hardware, and a thermal store holds it for later use. The proposed installation is designed around the building's demand, available space and operating constraints.
Find a use for the heat.
Run the computing workload, then find a suitable customer for its heat.
Find an income alongside the heat.
Start with heating demand, then use a computing workload with an established route to revenue.
Heat is local: it needs a suitable temperature, a physical connection and someone who can use it. For our chosen workload, the computing happens locally and rewards are settled over a digital network. Our design puts the harder-to-move output where it is needed.
Why compute is the co-product
The Node performs a specialised SHA-256 workload with established reward accounting and settlement through a pool. That gives this particular computing activity a route to revenue without finding a bespoke customer for every job.
That is the commercial attraction. We can focus the installation on heating rather than building a separate cloud-computing sales operation around each building.
Compute income varies, and collecting it has costs. Pool and settlement fees, equipment, connectivity and operations all matter. The sterling value of network rewards changes with market conditions. For an example of automated payments and their fees, see Braiins' payout documentation.
General-purpose computing can also produce useful heat, but it brings a different commercial task: acquiring workloads and meeting those customers' computing requirements. Our choice is to simplify that side of the model. It does not make profitability automatic.
What makes this a heat service?
For Heat21, the heat-as-a-service concept starts with the outcome the building needs. The aim is to organise the technology and its operation around useful heating and hot water, with computing revenue contributing to the economics.
- Understand the heat requirement.
Assess when warmth and hot water are needed, including cold days and periods of low demand.
- Match the equipment and storage.
Size the computing load, heat-transfer system and thermal store around heat the building can use.
- Plan when to run.
Use suitable electricity-price periods where storage and heating requirements allow. Stored heat creates room to pause the electrical load.
- Account for the whole result.
Compare electricity and operating costs, compute proceeds and useful heat delivery over the same period.
The building owner should be able to discuss heating requirements without having to commission a separate computing business. The service scope, equipment ownership, operating responsibilities and treatment of compute revenue belong in the site-specific proposal.
Our current cost illustration assumes the customer continues paying their own electricity supplier on their own tariff. This article explains the service concept; pricing and contract arrangements depend on the proposed installation.
Revenue changes the cost of heat
Computing revenue can offset part of the cost of producing heat. It does not create additional heat energy or give the system a heat pump's coefficient of performance.
Net operating cost per useful kWh =
(electricity + other operating costs − compute proceeds after pool and payout fees)
÷ useful heat delivered
The result depends on tariffs, network conditions, equipment performance, losses and whether the heat is needed. A tank that is already full limits further useful operation. Compute proceeds vary, so a sound proposal also considers periods with lower revenue.
Our compute-offset calculator explores the revenue contribution per kWh of electricity consumed. The heating-cost guide explains the additional steps needed to compare the cost of useful heat.
Explore the idea in practice
CurtailCoin explores wind curtailment and the potential computing value of unused generation. It provides context for flexible electricity demand. A low tariff alone does not prove that a particular heater is using otherwise-curtailed wind.
The GWhFI heating demonstration shows measured immersion-heater electricity use alongside Agile prices. It helps explain shifting when electricity is consumed; it does not measure the Node's compute revenue or useful heat output.
Heat21 brings these questions together around a building: what heat is needed, how much demand can move in time, and how computing proceeds affect the cost. Useful heat is the reason to run. Compute is the co-product that can help pay for it.