When I first pitched this project, I had a bold vision but no clear map. Reinforcement learning, blockchain, real-time oracles — on paper they sounded like a dream team for stabilising carbon markets. In reality, I wasn’t even sure how to get the three to talk to each other. I spent the first couple of weeks misreading algorithms, confusing basic concepts, and feeling like I was just spinning my wheels instead of writing real code.

Things only started moving when I stopped overthinking and began building tiny pieces. A barebones smart contract. A basic RL agent that nudged prices up or down. A fake oracle feeding in made-up data. Almost everything broke at first. Contracts deployed but didn’t trigger events. The RL agent went wild, sending prices into chaos. The oracle kept updating at the wrong time. But at least I had something real to fix, rather than just a whiteboard full of arrows.

One bug nearly drove me mad: the RL agent kept refusing to learn. After a week of digging, I discovered the reward function was scaled so badly that every action looked equally terrible — so the model simply gave up. Another time, the smart contracts ran flawlessly until prices hit certain thresholds, then quietly failed without errors. Both problems forced me to tear things apart and rebuild them properly. Painful, yes. Useful, absolutely.

Slowly, the pieces began to click. The RL agent started proposing sensible price changes. The oracle checked the data before passing it along. The blockchain stored everything transparently. The first time the entire loop ran end-to-end without crashing, I didn’t even care that the results weren’t perfect. Seeing data flow cleanly from model to chain felt like winning a small war.

By the final weeks, the system handled simulated price shocks surprisingly well. The RL agent responded with smoother, smaller interventions than the rigid rule-based system, avoiding the big, ugly price jumps that make real markets so unpredictable. It wasn’t flawless, but it proved the idea worked.

Looking back, the biggest takeaway wasn’t just technical. I learned to ask better questions, break problems into smaller chunks, and treat failed experiments as clues rather than disasters. I started the summer doubting whether I could even finish. I ended it with a working prototype — and a lot more confidence in my ability to navigate messy, open-ended research. This first summer of research taught me far more than debugging code or training models. It showed me how to stay curious when things break, how to ask better questions, and how to share both mistakes and progress honestly. I began with a system that barely held together; I finished with a prototype that worked — and a clearer sense of how to build, learn, and lead in the face of uncertainty.