CoolRoof Commons

Existing cool roof programs pay on invoice. We pay on measured outcome.

Comment

CoolRoof Commons

Existing cool roof programs pay on invoice. We pay on measured outcome.

A results-based climate finance prototype for Climate Data & Environmental Monitoring. The demo uses simulated before/after measurements and photos; no physical coating experiment was performed. The intended system: a sponsor's money is locked in a smart contract and released only when a reflective roof coating is verified against weather-normalized temperature and photo-coverage checks.

Track alignment

Climate Data & Environmental Monitoring. The track's challenge statement is that environmental data is fragmented and difficult to verify, and it calls for climate-data verification platforms, IoT environmental monitoring, and tools for research and insight.

We build the verification platform the track asks for, then go one step further: we bind a financial decision to the verified data. The data is not just shown, it is acted on. A smart contract pays a contractor only once backend-signed, weather-normalized evidence clears a set of thresholds it re-checks itself.

Inspiration

Climate money is paid for the activity, not for the outcome. Louisville's Cool Roof program pays $1 per square foot on proof of installation. France's repair bonus pays a flat €10–45 per device against the invoice. In both cases, the payment trigger is a document, not a measured result. Results-based climate finance exists as a concept — pay after independently verified outcomes — but its known bottleneck is that monitoring and verification can be prohibitively expensive. We wanted to attack that bottleneck directly: can verification be made cheap enough that a smart contract can safely act on it?

What it does

A sponsor locks funds in a smart contract for a specific roof. A reflective coating is applied, and before/after surface temperature is measured. The reading is normalized against real hourly weather (so a cloudy morning and a sunny afternoon can't be used to fake a result), screened for anomalies, cross-checked for coating coverage from a photo, and signed as evidence. The contract re-checks the thresholds itself before releasing money, in three time-staged tranches, and has a built-in force-majeure path so a storm doesn't penalize the contractor.

Today it does the first of two goals: proving that a specific intervention measurably worked. It is designed for a second one: as verified outcomes accumulate, they become training data for choosing which roof to fund next, so a limited budget goes where it will cool the most. That loop is on our roadmap, not built yet; roof targeting is currently a fixed, hand-weighted score from satellite properties.

Why this problem (climate impact)

Urban heat is a measurable, worsening problem, and reflective roofs are one of the cheapest interventions against it. But the money that could fund them at scale is stuck verifying paperwork, not outcomes. The sponsor can't tell if their money did anything; the building owner can't tell if the coating was worth it. That shared uncertainty is why cheap, effective interventions don't spread. The gap isn't a lack of climate ideas — it's a lack of trust in the result, and that's a data-verification problem, which is exactly this track.

Beyond the pilot: the same measure → normalize → verify → release loop applies anywhere an environmental outcome needs to be trusted before money moves — tree planting survival, insulation retrofits, water-saving irrigation. The roof is our first, narrowest case precisely so the mechanism could be built and tested end to end in the time we had.

Innovation

The innovation is not "AI for climate" or "blockchain for climate" in isolation — plenty of existing tools already do satellite-based roof targeting (Google Heat Resilience) or flat-rate climate rebates (Louisville, France). What's new is binding them into one mechanism where:

  • The payment schedule is itself evidence-driven. Money is time-staged (quality → durability → force-majeure reserve) and each stage has its own independently re-checked threshold, not a single yes/no release.
  • The contract does not trust its own oracle. Most "AI + blockchain" prototypes have a backend that decides and a contract that obeys. Ours has a contract that re-derives the pass/fail decision from the raw numbers the oracle submits, so a compromised or buggy oracle cannot push through a payment the numbers don't support.
  • We ran an actual satellite verification study as part of the build, and it failed to find a roof-level signal — and that negative result became the design justification for the ground-measurement layer, not something we hid. Most hackathon submissions show only the result that worked.
  • We implemented our own multiple-comparison correction for the satellite study rather than quoting a single raw p-value, and the one borderline-significant result we found did not survive it, so we don't claim it.

How we built it

A layered FastAPI backend (api → services → repositories → models/schemas) and a scikit-learn pipeline for weather normalization (ridge regression) and two-layer anomaly detection (rules + Isolation Forest), an OpenCV coverage estimator, a Solidity escrow contract on Hardhat/Polygon Amoy with its own threshold checks and reentrancy protection, an oracle service bridging backend and chain, and a React 19/Leaflet frontend.

Data sources: Landsat 8/9 (ST_B10 surface temperature), ECOSTRESS, Sentinel-2 (albedo derived from its bands with Liang coefficients via Google Earth Engine, not taken from the Google Heat Resilience dataset), OpenStreetMap (building footprints), Open-Meteo (hourly weather, real archive data). 726 roofs across Athens and London (723 with measured satellite data, 3 simulated demo roofs).

Technical execution

  • PostGIS-backed geospatial data for 726 real building footprints across two cities.
  • A regression-based weather normalizer that measurably does its job in simulation: the same simulated coating under 62 real weather hours has a raw delta spread of 19.1 °C, reduced to 3.87 °C after normalization (range), with the standard deviation falling from 4.07 °C to 1.26 °C (about 3.2×).
  • Two independent anomaly detectors that catch different failure modes — rules (precision 1.00, recall 0.79) catch replay attacks; Isolation Forest (precision 0.93, recall 0.14) catches physically-inconsistent combinations that stay just inside a threshold. Combined: 0.99 / 0.89.
  • A Solidity contract that independently enforces payout conditions rather than trusting a boolean from the oracle — flagged or insufficient-data results produce no transaction at all. Ordinary durability payment requires a new measurement taken after the 180-day eligibility date, and sponsor reclaim preserves a 30-day contractor claim window.
  • A reproducible multiple-comparison-corrected satellite study: 8 observational cases, Bonferroni and Benjamini–Hochberg correction implemented from scratch, 0 significant findings after correction.
  • A full test suite across backend, ML, scripts, oracle, Hardhat, and frontend, plus a Chrome end-to-end run of all three simulated scenarios against the local stack, and a schema-closed OpenAPI contract (additionalProperties: false) after we discovered our frontend had been passing 38 tests against an invented schema that didn't match the real backend.

Every number above is recomputed by a script from fixed seeds, not typed in. But the ML metrics are simulation metrics: the anomaly test set uses failure modes we designed and injected ourselves, and the normalizer is trained and evaluated on our own physical model (driven by real weather). They show the method behaves as intended; field performance is untested.

Practical usefulness & adoption

  • Who: a municipality, university, foundation, or corporate sponsor funding reflective-roof retrofits, plus the contractors who apply the coating and an independent verifier.
  • Why it's adoptable: the verification layer is built on low-cost ground sensors and free satellite/weather data by design, because verification cost is the literature's stated reason results-based climate finance hasn't scaled.
  • Why it scales beyond one city: thresholds are per-city and derived from climate data (summer irradiation ratio), not hardcoded; cities without a proprietary satellite dataset fall back to OpenStreetMap + Sentinel-2 at block level instead of building level.
  • Why it scales beyond roofs: the mechanism — stage a payment, verify an environmental outcome, release automatically, keep a public audit trail — is domain-agnostic. Tree-planting survival, insulation performance, and irrigation water savings all fit the same shape.
  • What's missing for a real pilot: device-side signing with a registered-device key (we currently use backend-signed evidence with a test key), production operations around the API keys that non-local mode already requires (TLS, key rotation), and a jurisdiction-specific review of public-sector procurement rules, since most public bodies cannot lock a budget into a smart contract without one.

Challenges we ran into

  1. Weather can fake a result if you don't correct for it. The same coating measured at different times of day looks completely different without normalization — this single problem motivated the entire ML layer.
  2. Should a storm cost the contractor money? If a storm damages the roof before the durability check, punishing the contractor is unfair, but a human adjudicating every claim defeats the point of automation. We resolved it with a three-tranche structure and a weather-threshold check, so the decision is auditable and mechanical rather than discretionary.
  3. Our satellite verification study failed, on purpose-run rigor. Across 8 cases the roof-to-pixel area ratio spans 57×, and the signal never strengthened. Rather than cherry-pick a hopeful framing, we implemented a proper multiple-comparison correction, found zero surviving results, and used that absence as the argument for why ground measurement has to exist.
  4. A contract that trusts its oracle is not actually trustless. Early in the build, the contract accepted whatever status the oracle sent. We rebuilt it so the contract independently re-derives pass/fail from the raw numbers — a materially harder but materially more honest design.

Accomplishments we're proud of

  • A smart contract that re-checks its own payout conditions instead of trusting an oracle's verdict.
  • A negative satellite result, reported rigorously (with our own multiple-comparison correction) instead of suppressed or spun.
  • Catching, mid-build, that our own frontend tests were passing against a schema that didn't match our real backend — and fixing the root cause (an open schema) rather than just the symptom.
  • A reproducible demo: a scripted round system lets the entire on-chain flow be re-run from a clean state for every rehearsal and for judging.

What we learned

If the contract is not the single source of truth, tests verify the wrong thing. We also learned that a failed measurement can be more useful than a successful one: the absence of a roof-level satellite signal is the clearest evidence we have for why automated ground verification needs to exist at all.

What's next

  • A predictive targeting model, trained on verified interventions (roof features + weather at the time + the normalized cooling actually measured), to predict expected cooling before a roof is funded — turning every completed project into a training example for the next funding decision. Today we target roofs with a fixed, hand-weighted score from static satellite properties, and nothing is learned from outcomes; the backend already stores the inputs side by side, but the model needs real pilot outcomes to train on, which three simulated demo roofs cannot provide.
  • Real device-side signing against a registered-device key, replacing the current backend-signed test-key evidence.
  • A small real-world pilot: a handful of actual roofs, real sensors, real coating, to replace the simulated before/after series with field data.
  • A fresh Amoy (or mainnet-equivalent) deployment of the current contract. The Compose override and frontend build arguments now exist; what remains is the deployment itself, its credentials, and funding projects on it.
  • Testing the satellite-for-targeting claim directly, instead of leaving it asserted but unverified.
  • Extending the same verify-then-pay mechanism to a second environmental outcome (tree-planting survival is the most natural next case) to test whether the pipeline generalizes as designed.

Limitations (full list in the repo README)

Surface temperature is not air temperature and is not CO₂ reduction; a reflective roof can increase winter heating load; blockchain records evidence but does not itself authenticate it (the oracle problem); the before/after series is simulated, not from a physical experiment; the satellite comparison is observational, not controlled; several thresholds (post-coating albedo, London's cooling threshold) are reasoned estimates, not calibrated measurements. The full, itemized list — split into methodology facts that stay true by design and gaps we would close next — is in the "Known limitations and roadmap" section of the repository README.md.

Live contract

Recorded deployment on Polygon Amoy testnet (chain ID 80002): 0xe583D50083A892DAcb0932cCA2D90dfCb22d4788 — example transaction (quality tranche released): 0x62f1f167…. The judged demo runs on a local Hardhat node for repeatability; the Amoy record documents an earlier deployment of the contract, which predates the current source's payment and reclaim protections.

Built With

Share this project:

Updates

Submission history