I’m Omer, building Sunrova. The idea is simple: fund solar systems for schools, clinics and village water pumps, and publish every system’s daily output so anyone can check what was built and whether it still works.
How it works on Celo:
A small oracle reads each system’s meter data once a day.
It writes a daily record (energy produced, data file hash) to a Registry contract.
The raw daily file is stored openly, and the public page links each day to its on-chain record.
Where we are: the contracts and the oracle are written and tested; testnet deployment is next. We are preparing a first pilot with one school or health centre in Kenya and a local installer.
What would help us most:
Feedback on the design from anyone who has built daily on-chain records for physical assets.
Introductions to installers in Kenya with remote monitoring, or to programmes that sponsor a single system.
There is no token sale and nothing to buy; this is an early-stage project. More at sunrova.com.
Hi Omer, nice to see a project that puts the record first and the token after. I read the project paper and the Registry rules already cover a lot: days reported once, corrections as separate records, and the multisig can revoke the oracle. A few things I’d look at before testnet:
Who can post a correction? If the oracle key can, a leaked key can still rewrite history through corrections, even with write once days. I’d keep corrections behind the multisig, or at least store which oracle address posted each report, so after a revocation you can see exactly which days came from the bad key.
The plausibility check lives in the file the oracle writes, so it’s the oracle checking itself. You already store capacity in watt peak on chain, so the Registry can reject any day above something like capacity times 12 hours of full sun. That ceiling is very loose, but it catches a unit bug or a typo that adds three zeros, and nobody has to trust the oracle for it.
Silence only shows up if the oracle posts it. If the oracle is down for a week, those days don’t exist on chain yet. I’d have the public page treat any day after the install date without a report as “no report” on its own, and keep a backfilled day visibly different from one posted on time.
Thank you, this is exactly the review I was hoping for. All three points hold, and the first two are already in the Registry:
Correcting a report and registering an installation now need the admin multisig; the oracle can only post daily reports, so a leaked key cannot rewrite history or invent installations.
The Registry refuses any day above capacity × 12 hours, so the oracle no longer checks itself.
Each daily report records the oracle address that posted it, so after a revocation the days from the bad key can be filtered.
The third point goes into the public page: any day after the install date without a report will show as “no report” on its own, and late reports will be marked as late. Testnet is next; I’ll post the addresses here.
A short update: Sunrova is looking for a co-founder to lead it as CEO. I built the technology (registry, oracle, site) and want to keep building it; Sunrova needs someone who wants to lead it.
The role covers the first pilot in Kenya, sponsors and partners, and the token side if and when it comes. Ideally you have launched or run something in crypto or ReFi, and you know energy access in Africa or are keen to learn it.
How it would work: a co-founder share from day one, part of it tied to a first milestone we write down together, vesting over four years with a one-year cliff. No presale, no return promises, no salary at this stage.
If that sounds like you, or someone you know, write to omer@sunrova.com.
The Registry includes the three changes from this thread: corrections and installation registration need the admin, any day above capacity × 12 hours is rejected on-chain, and each report carries the oracle address that posted it. The installation page now also shows every day after the oracle’s last run as “no report” on its own, so silence is visible even if the oracle is down.
On the testnet one wallet holds every role so everything can be tried with one key; on mainnet the admin is a Safe multisig and the oracle a separate key. The first real installation will be registered here once the Kenya pilot is confirmed.
Nice, thanks for posting the addresses. I read the verified Registry and the vesting wallet, two things I’d look at before mainnet:
postReport accepts any past day that wasn’t reported yet, and the installation has no start date on chain. So the oracle key can still fill gaps: days before the system existed, or days the page already showed as “no report”, with any value up to the ceiling. I’d store the install day in registerInstallation and reject earlier days, and maybe cap how late the oracle can report (say 7 days), with older days going through the admin like corrections.
FounderVesting inherits Ownable from OpenZeppelin’s VestingWallet, and release() pays owner(). The schedule is fixed, but the beneficiary isn’t: transferOwnership moves the whole position to another address, and renounceOwnership would lock the 15% forever, since release would try to pay address(0). If the promise is that the founder is locked for 4 years, I’d override renounceOwnership to revert and say in the docs that the position can be transferred (OpenZeppelin notes you can’t fully block that, the founder could be a contract).
Small one: correctReport can run more than once for the same day, so the page should show the latest correction and keep the earlier ones visible.
Backfilling. registerInstallation now stores the installation’s first day, and no earlier day can be reported. The oracle can post a day at most 7 days after it; anything older goes through the admin with postLateReport and a written reason (a separate LateReport event), and the page shows it as late with that reason.
FounderVesting. renounceOwnership now reverts. As you say, the transfer cannot be fully blocked, so the paper now states that the position can be transferred with the schedule unchanged.
Corrections. The oracle now reads the correction events, and the installation page shows the latest value and lists every correction with its reason. The sample page has a corrected day (20 Sept) to show how it looks: Installation — Sunrova
Checked the new Registry and vesting wallet, all three look right to me: startDay in the shared check, the 7 day window for the oracle, LateReport behind the admin with a reason, and renounceOwnership reverting.
Two tiny things if you touch it again. postLateReport doesn’t check that the day is actually outside the oracle’s window, so the admin could post a recent day as “late” (harmless, but the label would be wrong). And a startDay of 0 by mistake would open every day back to 1970, so registerInstallation could reject it.
Thank you, and thanks for checking the new version so quickly. Both are fixed in the code now: registerInstallation refuses a startDay of 0, and postLateReport only accepts days outside the oracle’s 7-day window, so “late” is always true. Since both only matter on an admin mistake, they go out with the next deployment rather than a third address change today.