DEV Community: Ekong Jemimah

Building a Bitcoin Education Platform, Contributing to Open Source, and Surviving a Hackathon

Ekong Jemimah — Sat, 13 Jun 2026 18:46:16 +0000

A few months ago, I didn't expect that I'd be spending my days debugging authentication flows, opening pull requests, analyzing backend architectures, and building a Bitcoin education platform during a hackathon.

Yet here we are.

What started as curiosity about Bitcoin turned into one of the most intense learning experiences I've had as a builder, and honestly, I wouldn't trade it for anything.

This is the story of how I joined Hack4Freedom Lagos 2026, helped build BitPath, contributed to open source, discovered OpenCode, and learned that software engineering is often just solving one problem after another until things somehow start working.

How I Ended Up Building in Bitcoin

My interest in Bitcoin didn't start from price charts or trading.

What attracted me was the builder ecosystem around it.

I've contributed to open source before, so I already appreciated the value of collaborative software development. But what stood out about Bitcoin was how deeply open source is woven into the culture.

In many ecosystems, open source feels like an option.

In Bitcoin, it feels like a foundation.

Everywhere I looked, people were building in public, contributing to projects, improving documentation, reviewing code, and helping newcomers find their footing.

That environment made me want to participate more deeply.

When the opportunity came to join the Hack4Freedom Lagos 2026 hackathon, I said yes.

The Project: BitPath

Our team worked on BitPath, an AI-powered learn-and-earn platform designed to make Bitcoin education more accessible.

The idea was simple:

Instead of overwhelming learners with technical concepts, BitPath uses conversational learning experiences, AI tutoring, quizzes, progress tracking, and rewards to help users learn Bitcoin and financial literacy in a more engaging way.

Our stack looked something like this:

Frontend

Next.js
TypeScript
Tailwind CSS
Zustand

Backend

NestJS
PostgreSQL
Redis
Queue processing

Additional Services

Google OAuth
OpenAI APIs
Lightning Network integrations

At least that's what it looked like on paper.

In reality, there was a lot more chaos involved. 😅

Frontend Meets Backend (And Everything Breaks)

One of the biggest learning experiences during the hackathon was frontend-backend integration.

If you've never experienced it before, imagine spending hours building a beautiful UI only to discover that the API contract changed while you were working.

Now multiply that by several days.

There were moments when authentication worked perfectly.

Then suddenly it didn't.

There were API responses that looked correct until they weren't.

There were environment variables that seemed fine until they quietly caused issues.

And there were enough network errors to make me question my entire setup.

One of the most memorable moments involved Google OAuth.

Everything appeared configured correctly.

Then I started getting:

Error 401: invalid_client

At that point, I learned a valuable lesson:

When authentication breaks, the error message is rarely as helpful as you want it to be.

Eventually, after digging through environment variables, OAuth settings, callback URLs, and backend configurations, we figured it out.

But the journey there was definitely educational.

Discovering OpenCode

One unexpected highlight of this experience was OpenCode.

I started using it as a coding assistant, but quickly realized it could be much more than that.

Whenever I encountered unfamiliar repositories, backend services, API contracts, or open-source issues, I'd use OpenCode to help analyze the codebase and break down the problem.

Some examples included:

Understanding backend API structures
Analyzing repository architectures
Generating implementation plans
Reviewing issue descriptions
Preparing pull requests
Understanding integration requirements

The most valuable part wasn't that it wrote code.

It was that it accelerated understanding.

I could move from confusion to clarity much faster.

And as any developer knows, understanding the problem is usually half the battle.

Contributing to Open Source Along the Way

The hackathon wasn't the only thing I worked on.

During the same period, I continued contributing to open-source projects.

One thing I love about open source is that every contribution teaches you something different.

Sometimes you're fixing a bug.

Sometimes you're cleaning up technical debt.

Sometimes you're improving performance.

And sometimes you're simply helping reduce confusion for future contributors.

One issue involved removing incomplete database migration artifacts that suggested a migration was underway when the application still relied on JSON storage.

Another involved implementing in-memory caching to reduce redundant disk reads.

Each contribution required reading unfamiliar code, understanding existing architecture, and making changes without breaking functionality.

That process never gets old.

The Reality of Building

One thing I've learned is that software engineering rarely looks like the polished screenshots people share online.

Most of the time it looks more like:

Reading documentation
Debugging errors
Testing assumptions
Asking questions
Breaking things accidentally
Fixing what you broke
Repeating the cycle

And honestly?

That's okay.

Because every bug fixed is knowledge gained.

Every pull request teaches something.

Every deployment reveals a new lesson.

What Bitcoin Taught Me About Open Source

If there's one thing that stood out throughout this journey, it's how much Bitcoin values contributors.

Not just experienced developers.

Contributors.

People who show up.

People who learn.

People who improve documentation.

People who fix bugs.

People who help others.

That culture is powerful.

It creates an environment where growth feels possible because participation matters more than perfection.

And that's something I deeply appreciate.

Lessons I'll Take Forward

Looking back, this experience taught me several things:

You don't need to know everything before you start building.
Frontend-backend integration is a skill you only learn by doing.
Open source remains one of the best ways to grow as a developer.
AI tools are most effective when paired with curiosity.
Debugging is frustrating until it becomes rewarding.
Consistency beats confidence.

Most importantly, I learned that growth often starts when you're willing to be uncomfortable.

What's Next?

This journey is far from over.

BitPath is still evolving.

There are more Bitcoin concepts to learn.

More repositories to contribute to.

More pull requests to open.

More bugs to fix.

More things to build.

And that's exactly what makes it exciting.

For now, I'll keep doing what got me here in the first place:

Showing up.

Building.

Learning.

Contributing.

And hopefully helping someone else do the same.

If you're building in Bitcoin, contributing to open source, or participating in hackathons, I'd love to hear about your experience.

What has been your biggest lesson so far?

Understanding Solidity: My Line-by-Line Explanation

Ekong Jemimah — Sun, 05 Oct 2025 20:32:54 +0000

As part of our blockchain development class, our tutor gave us an assignment through a GitHub Gist. The assignment was to study, understand, and explain a Solidity code.

This is my personal explanation and breakdown of the code, written based on how I understood each part.

// SPDX-License-Identifier: MIT
This tells us the license type. It simply means anyone can use or modify this code as long as they keep the license note. The compiler also requires it to avoid warnings.

pragma solidity ^0.8.0;
This sets the Solidity version the code should work with. It means the code will work with version 0.8.0. It helps to prevent errors from version differences.

contract UserRegistry {
Here we are declaring a new contract called UserRegistry. A contract in Solidity is like a class that contains data and functions that will run on the blockchain.

struct User {
A struct is like a container that groups related information. Here, we are defining a User structure.

uint256 id;
This holds the user’s ID number. uint256 means an unsigned integer (a number that cannot be negative).

string name;
This stores the name of the user as text.

uint256 age;
This keeps the user’s age as a number.

bool isActive;
This shows whether the user is active or not. True means active, and false means deleted or inactive.

mapping(uint256 => User) private _users;
A mapping works like a dictionary. It connects a user’s ID to their details (the User struct). The keyword private means only this contract can access it directly.

uint256 private _nextId = 1;
This is a counter that starts from 1. Each time a new user is created, this number goes up by one. That’s how new users get unique IDs.

mapping(address => uint256) private _addressToUserId;
This links a wallet address (the person creating a user) to their user ID. It helps to know who owns which user.

event UserCreated(uint256 id, string name, uint256 age, address indexed owner);
event UserUpdated(uint256 id, string name, uint256 age);
event UserDeleted(uint256 id);
Events are used to log actions on the blockchain. They make it easy for apps to track what happens.

modifier onlyUserOwner(uint256 userId) { ... }
A modifier is used to control who can use a function. This one checks if the person calling the function is the owner of that user.
Inside it, there’s a require statement that checks two things: if the user exists and if the caller is the supposed owner. If not, the function stops with the error “Not the owner.”

function createUser(string memory name, uint256 age) external { ... }
This function allows a user to create a new account. It takes in the user’s name and age.
Inside it:
~ It assigns the next available ID to the user.
~ It stores the user’s information in the _users mapping.
~ It links the creator’s address to their user ID.
~ It emits the UserCreated event to announce a new user was created.

function getUser(uint256 userId) external view returns (User memory) { ... }
This is a read-only function. It doesn’t change anything. It just returns the user’s information for a given ID. The keyword view means it only reads from the blockchain.

function updateUser(uint256 userId, string memory newName, uint256 newAge) external onlyUserOwner(userId) { ... }
This function allows a user to update their own name and age. The onlyUserOwner modifier ensures only the owner of that user profile can make changes. After updating, it emits the UserUpdated event.

function deleteUser(uint256 userId) external onlyUserOwner(userId) { ... }
This is used to deactivate a user instead of deleting them completely. It sets isActive to false and emits the UserDeleted event.

function getMyUserId() external view returns (uint256) { ... }
This is a helper function that returns the user ID linked to the caller’s wallet address. If the address has not created a user, it returns 0.

My Overall Understanding
This code allows people to create, view, update, and deactivate their user profiles on the blockchain. It uses mappings to store and connect data, events to log actions, and modifiers to control access.