• 

  Cover Picture

Track: Carbon Markets & Emissions Transparency

Inspiration

I got interested in blockchain because of one idea: a record that nobody can quietly rewrite. Corruption usually works that way. Someone with access edits a number, adds a missing entry, or counts the same thing twice, and nobody can check.

Carbon credits have this problem. Clean cookstove projects earn credits, often on the assumption that a stove handed out is a stove used. I wanted to build something where the proof is hard to fake and no single person controls the record. That became EmberLedger.

What it does

EmberLedger makes sure carbon credits for clean cookstoves are paid only when a stove was really used.

How it works, step by step

1. A sensor seals the data. Each stove has a temperature sensor. At the end of the day it signs that day's readings with its own key. If anyone changes the readings later, the signature no longer matches.
2. AI finds the cooking. An ML model reads the temperature pattern and marks the cooking sessions. SHAP shows why the model flagged a day.
3. Sanity checks filter fakes. A session must reach a realistic peak temperature, last long enough, and show natural heat fluctuation. Copied traces are rejected too.
4. The smart contract decides. It checks the sensor's signature, links the day to the previous record, and issues one credit. If anything is wrong, it rejects the day and gives a reason.
5. Households get paid. Payment is held in escrow for a waiting period. An auditor can cancel a bad claim during that time, and the operator loses part of a deposit. After the wait, the payment is split between the households automatically.

What the contract enforces

• Only the stove's own sensor can seal its data
• Every day links to the one before it, so history cannot be rewritten
• One credit per stove-day
• Each cooking session counts only once
• At most 2 sessions per day

What makes it different

• The blockchain is the decision maker. The AI only proposes. In our live demo, a corrupt official injects a fake cooking trace and the AI accepts it. The contract still rejects it, because the data does not match what the sensor signed.
• 6 of 6 attack tests blocked. Claiming a day twice, replaying an old event, using an old record, claiming 3 events in one day, signing with a fake key, and editing data after signing.
• Real data. Built and tested on real stove sensor data from Rwanda, with held-out households the model never saw. All 10 true usage days were caught.
• A climate number, not just a claim. Under the Gold Standard cookstove method, the 12 verified days cover about 45 kg CO2e. Crediting every logged day would have claimed 120.6 kg, which is 167% more than was proven.
• Anyone can check it. Each credit is a transaction with its own ID, so buyers, auditors and households can verify the record.

Who it is for

• Carbon credit buyers get credits backed by proof of use.
• Project operators get a trusted record that raises the value of their credits.
• Households get paid automatically for real use.
• Auditors and regulators get a record that cannot be edited.

What I learned

I started this project new to blockchain and Solidity. What I learned:

• A blockchain is a shared record where every new entry is linked to the one before it by a hash. Changing an old entry breaks every link after it.
• A smart contract is code on that chain that enforces rules. Nobody can bypass it, including the person who submits the data.
• A digital signature proves who created data. If the data changes after signing, the signature no longer matches.
• ML alone is not enough. My AI accepted a fake heating curve. Only the contract's signature check stopped it. That showed me why the blockchain has to be central and not an add-on.

How I built it

• Data: Stove-use data from Rwanda (Phase 2, 6 files with clean clocks). 4 households for training and 2 held out for testing.
• ML: LightGBM with causal features finds cooking events. Validation is leave-one-household-out. SHAP explains each decision.
• Checks: A sanity check on peak temperature, duration and heat fluctuation, plus a duplicate check for copied traces.
• Smart contract: ProofOfUse.sol in Solidity. It checks the sensor's signature, links each day to the previous record, allows one credit per day and at most 2 events per day, holds payment in escrow, and lets an auditor penalize a bad claim.
• Sensor signing: Each stove has a simulated sensor key that signs the day's raw data.
• Climate number: Gold Standard SMEC V4.0 default baseline, applied per household-day.
• Demo: A Streamlit app with a local blockchain through web3.py. It includes a live tamper scene where a corrupt official edits data and the contract blocks it.

Challenges

• Refining the project. My first version was ML only. It was not convincing, because the AI could be fooled. I reworked it so the contract makes the final decision, then added sensor signing so edited data fails on-chain.
• Data collection. Most of the raw files were unusable. All Phase 1 files had broken clocks and thousands of error rows. I screened every file and kept only the 6 clean ones instead of stretching weak data.
• Results. The labels come from a rule, so the scores only measure agreement with that rule. I kept that honest and focused on the held-out households and the fraud tests.
• Tuning the model and the checks. The duplicate check went through three versions. The sanity check thresholds had to catch fakes without rejecting real days. I tested several levels and kept the one that still verified all real days.
• Making the blockchain robust. I tested 6 attacks against the contract: claiming a day twice, replaying an event, using an old record, claiming 3 events in one day, signing with a fake key, and editing data after signing. All 6 are blocked.

What's next

Deploy to a public testnet, use real sensor hardware for signing, and test on more households.

Built With

• blockchain
• lightgbm
• python
• shap
• streamlit