Who I am

I am Aminu Abubakar, a smart contract developer based in Nigeria.

I don't ask “does this work?”
I ask “what does this assume, and what happens when that assumption is wrong?”

My default approach is to interrogate assumptions: what is this design relying on, and how does it fail when those assumptions break?

In smart contract systems, most critical bugs don't come from syntax mistakes. They come from overlooked interactions between components, especially around accounting and value flow.

For example:

While designing EpochVault, a yield distribution protocol, the initial approach was a single pooled accounting model for simplicity. It worked on paper, but it created a coupling problem: principal and yield lived in the same state space.

That raised a failure scenario I couldn't ignore. If yield calculations or rounding logic were incorrect, the impact wouldn't be isolated. It would propagate across all deposits.

The final design separated concerns: principal is tracked independently, yield accrues in a distinct accounting layer, and prize distribution has no direct path to depositor principal.

This increased complexity and testing overhead, but it reduced blast radius. The worst-case failure mode became a failed distribution, not loss of user funds.

That design decision came from repeatedly asking a simple question: what breaks, and who is affected when it does?

I build smart contracts with that constraint-first mindset, and I also build the interfaces that interact with them.