Celebrating 11 African Builders Beyond the 2026 BOSS Challenge
The BOSS Challenge may be over, but for this year’s finalists, the work has not stopped.
They are still opening pull requests, responding to reviews and building tools for Bitcoin and the Lightning Network. Some are improving the projects they started during the challenge. Others have moved into new repositories, found new problems to work on or started helping the next group of developers find their way into the ecosystem.
Together, their stories show that the most valuable part of a program like BOSS is not simply finishing a project, but leaving with the confidence, skills and community to keep going.
First, What is the BOSS Challenge?
Created by Chaincode Labs, the ₿OSS Challenge is a global program for developers who want to begin a career in Bitcoin open-source software. It is also one of the most technical and demanding programs of its kind.
Participants do not just watch lectures or follow tutorials. They write code, read Bitcoin specifications, debug failed implementations and work through exercises that require a real understanding of how Bitcoin works. They are expected to explore unfamiliar codebases, ask good questions and learn how to find answers on their own.
The program begins with a fully guided month of coding exercises and technical learning, with support from active Bitcoin contributors. After that first month, top performers are invited to continue for two more months of advanced mentorship with Chaincode Labs. During this stage, they work on proof-of-concept and portfolio projects and begin collaborating with established Bitcoin and Lightning projects.
The rest of the cohort moves into partner-supported activities, including Btrust Builders pathways, where they can continue developing their skills and engaging with the wider open-source community.
This year, we partnered with Chaincode Labs again to support developers from our talent pipeline and learning pathways who wanted to take part in BOSS.
Of the 623 developers who applied to the program through our pipeline, this feature follows eleven participants whose journeys stood out across the challenge, from portfolio builders and technical performers to developers who continued contributing after the program.
We had already seen what could happen after BOSS. Last year, alumni from the program went on to receive open-source funding from Btrust and the Human Rights Foundation. So we partnered with Chaincode Labs again, hoping to help another group of developers move from learning about Bitcoin to actively contributing to it. That is already happening.
Their Journeys Started Long Before BOSS
Although BOSS was a major step for these developers, it was rarely their first one.
Many arrived after taking part in programs such as Btrust Builders, Hack4Freedom, Chaincode seminars, Dada Devs, Africa Free Routing bootcamps, and GitHub’s All In Africa program. Some had studied Mastering Bitcoin. Others had learned to work with Bitcoin Core through the command line or developed their Python and Rust skills through structured language pathways.
Sharon Nkatha, for example, completed the 2025 Mastering Bitcoin Cohort by Dada Devs. She later went through the Btrust Builders Language Clubs cohort, where she focused on Python, before joining BOSS.
These programs did not make BOSS easy. What they did was give the developers a foundation to build on. They became more comfortable using GitHub, reading technical material, writing code and discussing difficult Bitcoin concepts with other people.
Just as importantly, they found communities that helped them stay on course.
Participants spoke about support from BitDevs Lagos, BitDevs Nairobi and BitDevs Kaduna. They mentioned mentors who pointed them towards the right materials, friends who helped them debug and peers who kept checking in when the workload became difficult.
That support mattered. Many of them were balancing BOSS with school, full-time work, exams, mentoring responsibilities and everyday life. The program required more than technical skill. It required discipline, patience and a willingness to keep going when the code did not work.
Learning That You Do Not Need to Know Everything
Before joining BOSS, several finalists thought they needed to understand every part of Bitcoin before they could contribute.
Abdullateef Mubarak was one of them.
Initially, I thought I had to understand absolutely everything about Bitcoin before I could even think about contributing. The BOSS Challenge completely changed that mindset.
He came to understand that Bitcoin is simply too broad for one person to master every part of it. Instead, a developer can choose an area, such as transaction formats, opcodes, wallets or the Lightning Network, and build useful knowledge there.
Abraham Ujah experienced a similar change.
The BOSS Challenge helped me realise there wasn’t even a facade at all. It helped me understand that Bitcoin open source is accessible to anyone willing to contribute and do meaningful work.
For Sharon, the change became real when she learned how to navigate repositories, open pull requests and respond to reviewers.
It transformed how I see it, from something intimidating and distant to something I can actively contribute to. I now know how to open PRs, respond to reviewers, and identify issues. Bitcoin open-source development feels like my space too.
That shift in confidence appears across the group, and is also visible in what they have done since the programme ended.
Where They Are Building Now
Abraham Ujah
Abraham came into BOSS with experience from Chaincode’s Bitcoin and Lightning seminars, the Africa Free Routing Lightning Developer Bootcamp, Rust for Bitcoiners and Bitcoin Core Principles. He had also contributed to Apache SedonaDB, where he learned how to turn written technical specifications into working code.
During the challenge, he built two Rust projects. Secure Fountain explores how Luby Transform fountain codes could reduce the storage demands of running a Bitcoin node. Memq is a high-performance bitcoin mempool query engine designed to support real-time fee estimation through gRPC and shared memory.
Abraham is now contributing to rust-bitcoin and rust-lightning. He is also on a path towards getting a grant. His goal is to make Bitcoin open source development his career.
Jolade Okunlade
Jolade stood out not only because of what she built, but because she kept showing up. She remained closely involved with her portfolio project, responded quickly to feedback and stayed active in the community throughout the programme.
Her BOSS project, dust-cleaner, is a Rust command-line tool that connects directly to Bitcoin Core and helps wallet users identify suspicious dust UTXOs. Dust attacks can weaken a user’s privacy if tiny outputs are later spent alongside other funds, allowing blockchain observers to connect addresses that may belong to the same person.
Dust-cleaner scans a wallet, identifies suspicious outputs and creates PSBTs that users can review, sign and broadcast themselves. The tool does not handle private keys or automatically broadcast transactions.
After BOSS, Jolade built GhostKey, which won first place at the 2026 Hack4Freedom hackathon in Lagos.
GhostKey is a non-custodial bitcoin inheritance tool built around a dead man’s switch. A holder can name an heir and set a check-in period while keeping control of the funds during their lifetime. If the holder stops checking in, the heir receives a way to claim the bitcoin directly.
Jolade is also building BitPilot, an interactive Bitcoin education platform, and contributing to the Lightning Dev Kit ecosystem.
Winterrdog
Winterrdog entered BOSS with general open-source experience but no earlier Bitcoin training program. He described the challenge as “DIY with no training wheels”, which suited the way he likes to learn; by entering difficult problems and creating structure for himself.
During the program, he often worked at night, setting aside several quiet hours to read, plan, implement and debug his solutions. Although he did not complete every exercise before time ran out, the experience gave him enough confidence to take on work that had previously seemed beyond him.
He contributed a backend stability fix to Saving Satoshi, helping the service handle periods of heavy demand more reliably. The patch was later merged.
He then began participating in the Bitcoin Core review process. In one review, his feedback helped improve the decision logic for a fix related to low file-descriptor limits on Unix systems, and he was credited as a co-author on the resulting change. He has since taken part in reviews across several Bitcoin Core pull requests and opened a pull request of his own.
Btrust also supported his travel and accommodation for Bitcoin++ Nairobi, helping him connect more closely with contributors in the wider ecosystem.
Abdullateef Mubarak
Abdullateef is completing his final year of university in Abuja while building a deeper understanding of Bitcoin infrastructure in Go.
His project focuses on PSBT v2 support for btcd. Partially Signed Bitcoin Transactions allow wallets, hardware signers and multisig coordinators to exchange the information needed to build and sign a transaction without sharing private keys. Abdullateef’s work supports both BIP 174’s PSBT v0 format and the newer PSBT v2 format described in BIP 370.
He designed the core parser, compact-size integer utilities and multi-version validation logic. He then brought the work into the btcd ecosystem through a pull request that is awaiting review.
Abdullateef has also been studying LND and reviewing pull requests to understand how the codebase fits together. He is expected to graduate in June 2026 and is preparing himself for deeper mentorship and a possible future open-source grant opportunity.
He has also been thoughtful about how he uses AI while learning. Rather than allowing tools to replace his understanding, he has focused on reading specifications, tracing the code and making sure he can explain the systems he is working on.
Aaliyah Junaid
Aaliyah came into BOSS after winning the 2025 Hack4Freedom hackathon. During the challenge, she began contributing to the Bitcoin Dev Kit ecosystem through work related to BIP 329 wallet labels.
BIP 329 proposes a shared format for importing and exporting labels for Bitcoin addresses, transactions and UTXOs. Without a common standard, users can lose useful wallet information when moving between applications.
Aaliyah researched the specification and worked on an example showing how developers could use bdk_wallet with the bip329 crate. The contribution changed direction during review and did not move as quickly as she hoped, but that became part of her introduction to real open-source work. Contributions can stall, scopes can change and review can require several rounds of learning and revision.
She has continued contributing to Polar and exploring Payjoin, Bitcoin privacy and Python-based projects. Her BDK work also remains part of her ongoing learning process.
Aaliyah has since returned to Hack4Freedom as a mentor. As an alumna and first-place winner from the Kaduna edition, she joined the Lagos edition to share practical advice with participating teams.
Usman Umar Garba
Usman first participated in BOSS in 2025 and returned in 2026 determined to go further. Before joining the program again, he had taken part in the Africa Free Routing Lightning developer bootcamp and worked as a frontend developer on BitTicket. He is also a member of BitDevs Kaduna, where he has continued learning alongside people interested in Bitcoin and Lightning development.
For his portfolio work, Usman chose Rust partly because he wanted to strengthen his skills in the language. He built the Lightning UTXO & Anchor Manager, a library and command-line tool for analysing the UTXOs held by Lightning nodes that use anchor channels.
Poor UTXO management can leave a node operator with fragmented funds or without suitable outputs for emergency fee bumping. Usman’s project explored how better wallet policies could help node operators prepare for high-fee periods and keep their Lightning infrastructure reliable.
He is now continuing to learn and has explored contributions to LND, Polar and other Lightning projects. He is also developing SatsFor, a Lightning-powered mobile application for instant, borderless creator tipping.
Ikechukwu Obunadike
Chukwu was one of the strongest technical performers during the first month of the challenge.
Before BOSS, he completed the Btrust Rust for Bitcoiners pathway and studied Mastering Bitcoin independently. He also became involved with BitDevs Lagos and helped organize a cryptography study group.
One of the habits that shaped his approach was learning without over-relying on AI. He focused instead on reading BIPs, following source code and building clear mental models of Bitcoin’s basic parts.
During the broader program period, he worked on the Bitcoin Dev Kit’s Android reference wallet. His pull request added the ability to sweep funds from an external WIF private key into a user’s wallet by scanning a QR code or pasting the key.
The work required him to enter an unfamiliar repository and learn Kotlin and Android tooling. Completing the pull request showed him that he could understand a new codebase well enough to make a useful change.
He has also been exploring automatically generated Rust RPC bindings for Bitcoin Core, which could make it easier for Rust developers to build applications that communicate with a Bitcoin Core node.
Chukwu’s recent direction is less publicly visible than that of some of the other developers, but his technical depth and interest in areas such as Taproot, cryptography and coin selection make him someone worth continuing to watch.
Susan Githaiga
Susan’s BOSS project was a Lightning anchor fee-bumping service. When a Lightning channel closes unexpectedly, its commitment transaction can become stuck if network fees rise. Susan’s project uses anchor outputs and Child-Pays-for-Parent, or CPFP, to help move those transactions towards confirmation.
Building the project required her to work across React, Node.js, Docker, Bitcoin transaction libraries, the mempool.space API and lnd’s gRPC interface.
What stood out about Susan was that she did not limit herself to her portfolio project. She also looked for other places where she could contribute, including the Bitcoin Dev Project website and the BTCPay Server Plugin Builder. Her merged work has included interface improvements, plugin-version features, navigation changes and search-engine optimisation.
Through her work with BTCPay Server, she also noticed a gap relevant to her home market in Kenya: there is no BTCPay Server plugin designed around M-Pesa. She hopes to explore that idea as she continues to understand the ecosystem and the needs of local merchants.
Susan also joined Sharon Nkatha, Rose Jane and Nelly Nakhero to build SiriScore, a pre-broadcast bitcoin transaction privacy analyser. SiriScore helps users identify possible privacy leaks before they sign and broadcast a transaction and offers practical ways to improve their on-chain privacy.
The project received an honourable mention at the 2026 Bitcoin++ Open Source Edition.
Susan’s journey has involved exploration. Rather than staying inside one project, she has tried different repositories, built across Bitcoin and Lightning and looked for problems that connect open-source software with the needs of everyday users.
Sharon Nkatha
Nkatha’s path into Bitcoin development included Dada Devs, and Btrust Builders and BitDevs Nairobi.
During BOSS, she contributed to Warnet, fixing a problem that prevented its bitcoin message inspection command from handling Tor onion addresses and other external peers. She found the cause, changed the peer-resolution logic and added test coverage. Her pull request was reviewed and merged.
She also built Know Your Coin History, a self-hosted bitcoin privacy tool. It allows users to trace their transaction history, label UTXOs and identify wallet-fingerprinting patterns without sending their transaction data to third-party services.
The project uses a Flask API, a React interface, Bitcoin Core and Electrum adapters, BIP 329 labels and an interactive transaction graph. Nkatha also implemented eight wallet-fingerprinting checks.
After BOSS, she began contributing tests to SeedSigner, covering PSBT parsing cases involving multisig transactions and wallet consolidation. Not every contribution landed, but she kept exploring, responding to feedback and learning how different projects approach review.
She has since started contributing to Braidpool and is progressing through the pipeline for possible open-source grant support.
Nkatha was also one of the four developers behind SiriScore, alongside Susan Githaiga, Rose Jane and Nelly Nakhero. Their honourable mention at Bitcoin++ 2026 marked another step in her growing focus on Bitcoin privacy.
Her journey has included mistakes, redirections and difficult feedback, but that is part of what makes it valuable. She has continued experimenting and showing up, even when the path was not straightforward.
As she put it:
Go for it! It will be hard, you will doubt yourself, but you will come out on the other side having done things you once thought were out of reach.
Irene Ufia
Irene built bip353-go, a Go implementation of BIP 353 DNS Payment Instructions.
Bitcoin payments still often involve copying long addresses that are easy to get wrong. BIP 353 allows a human-readable identifier such as ₿alice@example.com to resolve to bitcoin payment instructions stored in DNS.
Irene discovered that there was no Go implementation while working on another project. Instead of waiting for someone else to build one, she decided to do it herself.
The library includes payment-resolution logic, BOLT 12 TLV decoding, BIP 352 Silent Payment address parsing, DNS-over-HTTPS, Tor support, a command-line tool and a BIP 21 URI builder.
After BOSS, Irene has contributed to mpcium, an open-source multiparty computation wallet infrastructure project. Her contribution improved the project’s security by replacing static AWS credentials with the AWS Default Credential Chain. This allows the project to use keyless OIDC and IAM role authentication.
She is also exploring Neutrino, Lightning Labs’ privacy-preserving Bitcoin light client written in Go.
Irene’s story is a good example of how open-source projects often begin. She ran into a real problem, confirmed that the tool she needed did not exist and built it.
Cecilia Orji
Cecilia worked with Irene on the Bitcoin UTXO Observatory, a command-line tool that helps users identify suspicious dust UTXOs and decide what to do with them.
The tool can scan UTXOs through mempool.space or directly from Bitcoin Core’s local data. It checks them against known dust campaigns and suggests different actions, such as freezing, donating, consolidating or using CoinJoin. It can also create BIP 174 PSBTs for hardware wallets.
Cecilia focused on testing and reliability. She wrote tests for the audit engine, privacy strategy logic, PSBT creation and verification. While doing that, she found and fixed problems in the recommendation system. One example involved the tool suggesting CoinJoin for a UTXO that was worth less than the fee required to spend it. Cecilia changed the logic so the recommendation made more sense.
She also improved support for legacy P2PKH inputs, making sure hardware wallets could receive the full previous-transaction data they needed.
Cecilia is now exploring lndhub.go, a Lightning account backend written in Go. She is also interested in contributing to btcd and Lightning Labs’ Loop project.
One of her biggest breakthroughs during the program was learning to use bitcoin-cli directly. It helped her understand what Bitcoin Core was doing without relying entirely on third-party libraries or high-level abstractions.
For Cecilia, BOSS changed Bitcoin open source from something intimidating into something she could take part in directly:
It’s not rocket science. It might look intimidating from the outside, but once you start, you realize it’s very doable.
The Biggest Change Was Not Technical
The finalists learned about PSBTs, UTXOs, Taproot, onion routing, wallet labels, fee bumping, coin selection, Lightning infrastructure and more. But when they spoke about what BOSS changed for them, most did not begin with the technology.
They talked about confidence. They became more comfortable reading difficult specifications, working without step-by-step instructions, asking maintainers questions and receiving feedback on their code. They stopped seeing failed tests as proof that they were not ready and started treating them as part of the process.
Aaliyah put it simply:
It showed me that contributing is less about already knowing everything and more about being willing to learn consistently, ask questions, and stay curious.
Jolade had a similar realization when she successfully built and broadcast a bitcoin transaction from raw bytes. Before it worked, the network rejected several attempts because of mistakes in the serialization, scripts and signature hash.
When the transaction was finally accepted, nobody needed to approve her as a developer first.
Nobody vouched for the transaction. The system accepted it purely because the math and serialization were correct.
Susan felt that shift when her first BTCPay Server pull request was merged. Sharon felt it when a reviewer responded to her first contribution. Cecilia felt it when all the GitHub Actions for her final capstone turned green.
Those moments may look small from the outside, but they often mark the point where someone stops asking, “Do I belong here?” and starts asking, “What can I work on next?”
Community Made The Difference
None of these developers got here alone. Mentors helped them understand where to look without doing the work for them. Friends answered messages when they were stuck. Peers reviewed ideas, shared resources and reminded one another that struggling with difficult material was normal.
BitDevs communities in Lagos, Nairobi and Kaduna played an important role. So did Dada Devs, Africa Free Routing, Hack4Freedom and the Btrust Builders community.
These communities helped bridge the gap between learning and contributing. They gave developers somewhere to ask questions, meet contributors and become familiar with open-source work before entering larger projects.
They also created a cycle of support. Aaliyah returned to Hack4Freedom as a mentor after once participating herself. Cecilia and Irene supported each other through their learning programmes and then built a privacy tool together.
Susan and Sharon have also gone on to serve as mentors and facilitators for Dada Devs, helping more women develop the skills and confidence to explore Bitcoin open source. Having once benefited from learning communities themselves, they are now sharing what they know, helping participants work through technical challenges and showing the next generation of female developers that there is a place for them in Bitcoin.
Their involvement matters because representation is practical. It is easier for a new developer to imagine herself contributing when she can learn directly from women who are already opening pull requests, building Bitcoin projects and participating in technical communities.
Several other finalists are also reviewing pull requests, sharing resources and helping newer developers understand how to begin. Their journeys show that contribution is not limited to writing code. Teaching, mentoring, reviewing and creating welcoming spaces for new contributors are also part of building a healthy open-source ecosystem.
This is why community is not separate from technical development, but part of what makes long-term contribution possible.
People are more likely to keep going when they know who to ask, where to find support and that other developers have faced the same doubts. The strongest communities do more than help people enter the ecosystem. They give those people a reason to return, contribute and help someone else take the next step.
To African Developers Thinking About Contributing, Start
Bitcoin needs contributors in many areas. It needs people working on wallets, Lightning infrastructure, privacy, testing, security, developer tools, documentation, design, research and education.
You do not need to understand every part of Bitcoin before you begin. No one does.
Start with one programming language. Join a local BitDevs community. Complete an introductory pathway. Read a BIP. Reproduce a bug. Improve a test. Review a pull request. Fix unclear documentation. Build a small tool around a problem you understand, then keep going.
The eleven developers in this feature did not all start from the same place. Some already had years of software experience. Others began with a single introductory program. Some worked in Rust, while others used Go, Python, Kotlin or JavaScript. Many had to learn new tools because their projects demanded it.
What they shared was the willingness to learn, ask for help and attempt work that initially felt beyond them.
BOSS gave them a demanding place to practise those habits. Btrust Builders pathways and local communities helped many of them prepare for that opportunity. What they have done since the program ended shows why those learning and community networks matter.
Their journeys are still unfolding, but they already make one thing clear: African developers are not standing at the edge of Bitcoin’s open-source ecosystem. They are writing code, reviewing contributions, improving infrastructure and helping other developers find their way in.
That is what the BOSS Challenge is ultimately meant to support, not just the completion of a program, but the beginning of a long-term contribution to Bitcoin open source.