Tomorrow’s Reserve

Checks pumping-carbon claims against the tank, refuses depleted-storage savings, and exports evidence anyone can independently replay.

Comment

Tomorrow’s Reserve Carbon savings without borrowing tomorrow’s water.

Who it is for, and a five-minute evidence route

An auditor or lender could use this to check a water utility’s pumping-carbon claim before relying on it in an emissions report or a sustainability-linked loan target. A utility analyst supplies yesterday’s hourly pumping; the contract checks the whole day and issues a receipt or refuses with a reason. This is a proposed workflow, not customer validation, a field trial or a lending approval.

  1. See a refusal. Open https://tomorrows-reserve.vercel.app/ and run “Skips the evening refill”. It appears 20.3% greener but leaves tomorrow 7,000 m³ short; the recorded local contract refuses with WaterDebt.
  2. See an acceptance. Select “Honest plan” and run its check. It restores storage and receives a receipt. Optionally select “AI-optimised plan”: the 4 February example shows 13.2% lower attributed CO₂ with the tank refilled. That is one day, not the 25-day aggregate.
  3. Download and verify. In the repository’s pumpproof/ directory, run npm ci once, then npm run verify -- accepted.json. For the refused file use npm run verify -- refused.json --expect rejected, substituting the actual downloaded filenames. This replays the exact plan on a fresh local EVM. Change a pumping value in a copy and signature verification fails. A verified refusal stays a refusal. Allow extra time for first-time installation.
  4. Read the method. Open Explore more → Method for the rule, carbon calculation, data, roles, reviewer checklist and limits.

All 50 external rule traces actually ran through the local contract: 22 accepted, 3 NoCarbonBenefit refusals and 25 WaterDebt refusals. The public website replays recorded local outcomes; run the repository locally for fresh contract execution. The 25-day aggregate results, including failed days, appear below; operating margins differ, so equal safety is not established.

Two matching 4 February rule experiments also completed on public Sepolia (chain 11155111), using separate operator and auditor keys controlled for this demonstration: WaterDebt refusal and honest acceptance. These are separate keys on a public test network, not independent organisations. A public chain does not prove a pump ran. The downloadable signed v3 bundles still describe the local EVM; the Sepolia records provide public transaction links.

The problem

20% greener on paper. Seven million litres missing from the tank.

Moving pumping into cleaner grid hours can reduce its attributed carbon footprint. But a schedule can also look greener simply by skipping the evening refill. The next day inherits the missing water and the pumping that was put off.

Tomorrow’s Reserve checks whether a carbon claim still holds when the whole day’s water balance is counted.

Track: Carbon Markets & Emissions Transparency. We address misleading emissions claims and reproducible verification, with a smart contract enforcing explicit acceptance rules.

What it does

A utility operations analyst supplies 24 hourly pumping values as CSV or JSON. The checker preserves those values, follows the tank hour by hour, and compares attributed CO₂ with the declared baseline. It does not silently repair or optimise an uploaded trace.

The local workflow has three stages:

  • Preview the exact trace, carbon comparison, hourly limits and end-of-day storage.
  • Commit the trace, attest its evidence, and let Solidity accept or refuse the claim.
  • Export a signed evidence file and readable report. A separate verifier reproduces the result on a fresh EVM without calling the optimiser.

In our 4 February 2020 simulation, skipping the refill appears to reduce attributed CO₂ by 20.3%, but the tank falls from 12,000 to 5,000 m³. The contract refuses the claim with a real reverted WaterDebt transaction. An honest plan restores storage and is accepted. The AI-supported plan for the same day shows 13.2% lower attributed CO₂ and is also accepted.

The public website runs the accounting in your browser and clearly labels its contract outcomes as recorded local runs. Clone the repository to execute new checks locally.

Why this approach

Storage restoration and carbon-aware scheduling are established ideas. Our contribution is their combination into an inspectable claim check: an unchanged external trace, explicit water requirements, an actual acceptance or refusal, and evidence another reviewer can reproduce.

Blockchain makes the agreed rules and commitment-to-decision sequence inspectable. It does not make a meter honest or prove that a physical pump ran. Both demonstration roles are controlled locally; a signed database is a credible alternative for this single-operator prototype. Duplicate protection is bounded by each experiment contract, and these commitments are retrospective.

How we built it

The application uses Node.js, strict input validation and exact integer accounting. Solidity executes on a local Ganache EVM through ethers.js. Operator and auditor signatures bind the supplied trace, pinned sources, policy, accounting and outcome.

A gradient-boosted demand forecaster and linear-programming scheduler suggest supporting plans. They do not decide whether an uploaded trace passes. Measured German water demand is paired with a historical GB grid-intensity scenario; the tank, pumps and traces are simulated.

Accounting concepts we follow

The check uses building blocks auditors already know, applied to one pumping day. It maps to these concepts; it is not a certified methodology or an accredited verification.

  • Carbon: hourly grid-average carbon intensity multiplied by pumping energy, as in the GHG Protocol Scope 2 location-based method, applied hour by hour.
  • Baseline: normal pumping, which pumps what the town uses each hour, is the baseline scenario.
  • Boundary: one tank and one day; the tank must end the day where it started.
  • Leakage: a saving created by shifting pumping into tomorrow (water debt) is refused, not counted.
  • Verification: a receipt needs the auditor’s signature first. The contract only settles against evidence recorded by the separate auditor key, so the operator cannot issue a receipt alone, and anyone can replay the evidence afterwards.

What we demonstrated

Across 25 source-complete simulated days in February 2020, gross attributed CO₂ reductions against the baseline were:

  • Forecast model: 9.44042%; 24/25 days numerically eligible.
  • Weekly persistence: 8.67546%; 23/25 eligible.
  • Honest clock/tank rule: 4.92450%; 22/25 eligible.
  • Skips evening refill: 19.36190% apparent; 0/25 eligible.

These figures include failed and negative days. The depleted rule makes the apparent reduction look 3.9 times the honest rule’s reduction, but none of its claims qualifies.

All 50 rule fixtures actually ran through the EVM: 22 honest acceptances, three honest refusals for no carbon benefit, and 25 WaterDebt refusals. Every depleted fixture was 7,000 m³ short. Model and persistence comparison rows are numerical evaluations, rather than 50 further external contract runs.

The model’s aggregate advantage over persistence is 0.76 percentage points. Its operating margins also differ, so this does not isolate an AI effect or establish equal safety. The 13.2% AI example is one day, not the aggregate.

Technical checks include 48 passing tests, HTTP smoke checks, exact-trace binding, input-change proof invalidation and independent accepted/refused bundle replay. A fresh independent code review checked integrity and publication behaviour. Public GitHub Actions passed. Changing one pumping value in an exported copy causes signature verification to fail.

Challenges and lessons

The hardest part was keeping one supplied trace bound to preview, commitment, settlement and export, including delayed responses and errors. Editing an input clears its old result and evidence link. A refused claim can still be valid evidence: independently verifying the refusal must never turn it into an accepted receipt.

The central lesson is that a persuasive carbon percentage needs a complete accounting boundary. A smaller number that restores tomorrow’s water is more useful than a larger apparent saving that does not.

Practical use and next step

A utility analyst supplies hourly pumping records; the contract checks the claim; an auditor or lender replays the evidence before deciding whether to rely on it in an emissions report or a loan target. This is a proposed workflow, not customer validation or a lending approval. The input format is small and plain, making a read-only shadow evaluation a realistic proposed first step.

That pilot has not happened. Field use would require co-located demand, pump-energy and tank measurements, calibrated equipment, agreed baselines, hydraulic validation and independently operated roles. Wider use would also need a shared registry across sites.

Limits

This is a retrospective proof of concept with no utility pilot, customer validation or measured field saving. German demand and GB grid data form a transfer scenario, not measurements from one utility. Constant pump energy intensity and idealised hourly feedback are assumptions. These are timing-based attributed CO₂ differences, not electricity saved or proven avoided emissions; peak pumping power can rise. Fresh EVM replay establishes reproducibility under declared inputs, not physical truth or the original chain’s history. No carbon credits, tokens or payments are issued.

Try it

Public recorded demo: https://tomorrows-reserve.vercel.app/ Source and local execution: https://github.com/andreajanewilliams/tomorrows-reserve

Share this project:

Updates

Submission history