There are few moments in open source that feel as rewarding as seeing your first pull request merged.

For many contributors, it marks the end of days, weeks, or even months spent navigating an unfamiliar codebase, responding to review comments, revising changes, and wondering if their contribution will eventually be accepted. When the merge notification finally appears, it brings a sense of accomplishment. The effort has paid off, the contribution has been accepted, and your work has become part of a project that thousands of people rely on.

It is a milestone almost every contributor remembers. What happens afterwards, however, receives far less attention.

Some contributors submit another pull request almost immediately. Others become active members of the communities surrounding the projects they contribute to. Some eventually become reviewers, maintainers, and mentors. Others quietly stop contributing after their first merge.

What separates those paths?

To explore that question, we spoke with Kelvin Isievwore, Head of Engineering at Btrust, alongside Btrust Developer Grantees Abubakar Sadiq and Enigbe Ochekliye. Their experiences suggest that while your first merged PR is worth celebrating, it is rarely the moment that defines your journey. What matters most is what you do afterwards.

The First Merge Changes the Work

Kelvin still remembers his first merged pull request. In 2023, he found a bug that had been unresolved for more than a year. It had gradually become a bottleneck for new contributors. Before writing code, Kelvin spoke with the project maintainer to understand what others had tried and why those attempts had failed.

Those conversations shaped nearly two months of investigation before he eventually found a solution.

Looking back, the experience meant much more than fixing one bug.

That was the moment I realized this would become my routine, solving hard problems. It was also the moment I knew I wasn't going to stop contributing anytime soon.

Today, Kelvin reviews contributions and mentors developers across the Bitcoin ecosystem. He has noticed that many new contributors misunderstand what their first merge really means.

Many people think it gets easier after the first merged PR, but it's actually the opposite. Now you're expected to keep learning, improve your technical skills, communicate more effectively, help other contributors, and become better at receiving and acting on feedback. In many ways, the real work begins after that first merge.

A merged pull request does more than add code to a repository. It begins to build trust. Maintainers have seen you respond to feedback, collaborate during review, and carry an idea through to completion. That trust can lead to more opportunities and responsibility. But it also comes with an expectation: keep learning.

The Work Continues

Abubakar Sadiq experienced this almost immediately. His first contribution improved a functional test he found while reading through a project’s codebase. Once it was merged, reviewers suggested a follow-up fix that would apply the same improvement in other places.

After the PR was merged, reviewers suggested a follow-up fix to use the new improvement in other places.

For Abubakar, the merge was not the end of the task. It opened the door to the next contribution.

Sometimes, that next step can come even earlier. While the first PR is still under review, you may notice a related issue, find another small improvement, or receive feedback that points to a separate piece of work. Starting a second PR before the first one merges is completely normal, as long as the changes are independent and you can manage the review process.

The review process itself also challenged Abubakar’s expectations.

I was surprised by how thorough and lengthy the review process was, even for a test PR.

For someone contributing to a mature open-source project for the first time, that level of scrutiny can feel intimidating. But it reflects the care these projects require. Reviews are not just about finding mistakes; they are part of the collaborative process that helps contributors improve.

Abubakar’s advice to new contributors is simple:

If there are suggested follow-up review comments, see them through by opening a new PR that addresses them.

It is straightforward advice, but it reflects an important mindset. Open-source progress is rarely about one contribution. It is about returning, improving, and building on what you have already learned.

Curiosity Is What Keeps Contributors Growing

For Enigbe, the biggest lesson from her first merged pull request was discovering how much more she had to learn.

Her contribution involved Rust, a language she already felt comfortable using. The challenge came after she made her changes: the full build refused to compile because she had gaps in her understanding of the Foreign Function Interface, or FFI.

The experience was frustrating, but it became one of the most valuable lessons of her early open-source journey.

It was a deeply humbling experience. It showed me the importance of understanding the broader system rather than focusing only on the part you're directly modifying.

That lesson continues to shape the way she approaches open source today.

Rather than viewing a merged pull request as proof that she had mastered a project, she left with a deeper appreciation for the context required to contribute meaningfully to mature codebases. High-quality contributions, she says, demand patience, attention to detail, and an understanding of how different parts of a system fit together.

Those expectations have only strengthened her curiosity.

Every contribution answered one question, uncovering several more, and that curiosity has kept me engaged.

That curiosity has taken her beyond writing code alone. Wanting to better understand Bitcoin and distributed systems, Enigbe started a small book club with fellow Bitcoin enthusiasts and software developers. Together, they study Bitcoin and computer science fundamentals to build a stronger understanding of the systems they contribute to.

Her experience reflects something that came up throughout these conversations: contributors who stay engaged are rarely motivated only by a growing list of merged PRs. They stay because every contribution teaches them something new, raises new questions, and gives them another reason to learn.

The Contributors Who Keep Showing Up

After years of reviewing contributions and mentoring developers, Kelvin has noticed that a first merged PR is not always a good predictor of who will become a long-term contributor.

The difference, he says, is rarely technical skill alone.

Consistency, the ability to learn quickly from mistakes, and persistence make all the difference.

He has seen contributors whose PRs were closed because the work was no longer a project priority. Others waited weeks for a review or had to rethink their approach after extensive feedback.

The people who kept going were often the ones who learned to ask better questions, understand what the project actually needed, and focus their energy there.

Contributing consistently is also about more than writing code. Kelvin encourages people to become active in the communities around the projects they care about. Join Slack or Discord conversations, attend project meetings, read open pull requests, review code when you can, and engage with maintainers.

These small actions help you understand the project better while building trust within its community.

Enigbe shares a similar view. She believes one of the best ways to keep growing is by reviewing pull requests.

Code review lets contributors explore unfamiliar parts of a codebase, see different engineering choices, and offer thoughtful feedback that helps move the project forward. It is a reminder that meaningful contribution is not only about the PRs you merge yourself.

More Than a Milestone

Your first merged pull request is easy to celebrate because it is visible. It appears on GitHub, earns congratulations from peers, and gives you proof that your work has become part of a real project.

But the more important changes often happen quietly. They show up in the confidence to ask better questions, the patience to work through several rounds of review, the curiosity to understand parts of a codebase beyond the task in front of you, and the willingness to keep showing up after the excitement of that first merge fades.

These qualities cannot be measured by a GitHub profile or a list of merged PRs. They grow over time through consistent participation, thoughtful feedback, and a genuine desire to keep learning.

That was the strongest thread running through every conversation for this article.

Kelvin found himself returning to harder problems after his first merge. Abubakar learned that one contribution can naturally lead to another, sometimes even before the first one is fully merged. Enigbe gained a deeper appreciation for the systems she was working in and developed a curiosity that still shapes how she learns today.

None of them described their first merged PR as the moment they had finally “made it”. They described it as the moment they realised there was still so much more to learn. Perhaps that is what really happens after your first merged PR.

You stop thinking only about making your first contribution and start thinking about how you can make the next one.

As Kelvin puts it:

Congratulations! Your Bitcoin open-source journey officially begins.

Africa, July 13, 2026 - We’re excited to announce the Q2 2026 Btrust developer grant recipients. Last quarter, seven Bitcoin open-source developers were awarded grants, including three starter grant recipients and four long-term open-source cohort members.

This cohort continues our mission to decentralize Bitcoin open-source development by supporting talented contributors from the Global Majority. Their work spans wallet infrastructure, Bitcoin Core testing, developer tools, privacy-preserving payments, peer-to-peer exchange infrastructure, cryptography, and user-facing bitcoin applications.

The quarter also marked an important first for us: for the first time, we supported a grantee working on peer-to-peer exchange infrastructure. This expands the scope of our grant program into tools that can help people access Bitcoin in places where traditional onramps are limited or unavailable.

Another defining theme of this cohort is community. All but one of the recipients have been through the Btrust Builders program, showing how structured learning, mentorship, and hands-on open-source experience can help developers grow into long-term Bitcoin contributors. Many of the recipients also help organize or participate in local BitDevs communities across Africa, including in Lagos, Kampala, Kaduna, Malawi, and Nairobi.

Starter Grants

The Btrust starter grant supports software engineers who are ready to contribute full-time to open-source Bitcoin development. It gives recipients the time, mentorship, and financial support they need to explore a focused area of Bitcoin open source, make meaningful contributions, and grow into long-term contributors.

Starter Grant Recipients

Jemimah Nagasha

Nagasha is a software engineer based in Kampala, Uganda. She has experience building web and mobile applications and brings a strong systems-oriented approach from her background in civil engineering and software development.

Her Bitcoin development journey began through the Btrust Builders Fellowship, where she gained hands-on experience with Bitcoin internals, Lightning Network tooling, and open-source collaboration.

Since then, Nagasha has been contributing to Polar, an open-source desktop application used by Bitcoin and Lightning developers to create local testing environments. It helps developers safely test Bitcoin and Lightning applications on their own computers before building for real users.

Her work so far has focused on making Polar easier and more reliable to use. She has helped add the ability to rename nodes, improved the manual block-mining workflow, contributed to Tor support for nodes, and participated in pull request reviews and issue discussions.

With the starter grant, Nagasha will work full-time on improving Polar’s usability, reliability, and developer experience. Her planned work includes adding better support for Core Lightning on Windows, improving wallet locking and unlocking workflows, adding seed phrase and backup management tools, and fixing bugs that affect developer testing.

She also helps grow the local Bitcoin developer community by organizing BitDevs Kampala, creating a space for developers in Uganda to learn, discuss, and contribute to Bitcoin.

Oyindamola Oladapo

Oyindamola is a software engineer based in Kaduna, Nigeria, with experience building and maintaining reliable software systems. He was part of the inaugural Btrust Builders’ Rust for Bitcoiners pathway, where he deepened his understanding of Rust and Bitcoin development and graduated as the top student.

He has since become an active contributor to privacy-focused Bitcoin tools, especially Rust-Payjoin and related Payjoin projects.

Payjoin is a privacy technique that helps make bitcoin transactions harder to analyze from the outside. Instead of a transaction clearly looking like it came from one person paying another, Payjoin allows both sides to collaborate in a way that makes ownership patterns less obvious. This helps protect user privacy without changing Bitcoin’s base protocol.

Oyindamola’s contributions have included privacy-safe logging, code audits, spendable coin checks, documentation improvements, and work on simulations for multiparty Payjoin. Multiparty Payjoin is an extension of this idea, allowing more than two participants to collaborate in a transaction and strengthen privacy further.

With the starter grant, Oyindamola will focus on advancing multiparty Payjoin research and implementation. His work will include helping refine the protocol design, improving simulations, contributing to the Payjoin Development Kit, writing tests, improving documentation, and working closely with maintainers to make the system safer and easier for wallet developers to use.

Beyond code, Oyindamola co-hosts BitDevs Kaduna and has supported local bitcoin education efforts, including mentoring and judging at the Hack4Freedom Hackathon in Kaduna.

Yankho Ngolleka

Yankho is a Bitcoin developer and community builder based in Lilongwe, Malawi. His technical journey began at Btrust Builders, where he received the Top Student Award among an international cohort of Bitcoin developers.

He has experience with Bitcoin Core tools, the Nostr protocol, and Lightning Network concepts such as hold invoices and payment retries.

Yankho contributes to MostroP2P, a peer-to-peer bitcoin exchange system built on Nostr and the Lightning Network. Mostro helps people buy and sell bitcoin directly with each other, without relying on a centralized exchange. This kind of infrastructure can be especially important in countries and communities where formal bitcoin onramps are limited, unreliable, or unavailable.

This makes Yankho’s grant especially notable as he is Btrust’s first grantee focused on peer-to-peer exchange infrastructure.

His contributions to the Mostro ecosystem include test coverage, error handling improvements, user experience improvements in the command-line tool, website fixes, code reviews, and work related to the reliability of the Mostro daemon.

With the starter grant, Yankho will work full-time on improving MostroP2P’s reliability and usability. His planned work includes strengthening error handling, expanding mutation testing, investigating bugs that could affect real trades, improving the Mostro command-line experience, and running a live Mostro node in Malawi.

He also plans to grow the Malawian Bitcoin developer community through BitDevs Malawi, using the live Mostro node as a practical example of how open-source Bitcoin infrastructure can serve local needs.

Long-Term Grants

The Btrust Open-Source Cohort provides long-term support to established Bitcoin open-source contributors. Members receive funding, mentorship, and peer support so they can continue working on important Bitcoin projects over a longer period.

These grants are designed to help contributors build deep expertise, maintain critical open-source software, and make lasting contributions to the Bitcoin ecosystem.

Long-Term Grant Recipients

Abiodun Awoyemi

Abiodun is a software engineer and Bitcoin open-source contributor based in Lagos, Nigeria. His work focuses on wallet infrastructure in the Bitcoin Dev Kit ecosystem.

Bitcoin Dev Kit (BDK) is a set of tools that helps developers build bitcoin wallets. Instead of every wallet developer having to solve the same difficult problems from scratch, BDK provides reusable building blocks for transaction construction, wallet state, signing, and other core wallet features.

Abiodun is a secondary maintainer of bdk-tx, a transaction-building library in the BDK ecosystem. His role includes reviewing pull requests, guiding technical discussions, and helping maintain code quality.

His contributions have covered many areas that directly affect wallet safety and reliability, including fee calculation fixes, anti-fee-sniping support, Payjoin examples, CPFP fee-bumping support, locktime handling, BIP353 payment support reviews, PSBT creation, BIP322 message signing, and continuous integration improvements.

With the long-term grant, Abiodun will continue strengthening BDK and BDK-TX. His work will focus on making Bitcoin transaction construction safer, more predictable, and easier for developers to use. Planned areas include better fee handling, clearer errors, improved transaction ordering, policy-aware transaction building, timelock correctness, and foreign function interface support so that BDK-TX can be used more easily outside the Rust ecosystem.

Abiodun also contributes to local developer education as a co-organizer of BitDevs Lagos, helping create space for technical Bitcoin discussion and contributor growth in Nigeria.

Emmanuel Ojok

Ojok is a software engineer based in Kampala, Uganda. He has experience building web and mobile applications using JavaScript, TypeScript, React, React Native, and Node.js. He is also 

His Bitcoin development journey began through Btrust Builders programs, including the BOSS cohort, Learn Bitcoin from the Command Line, and the Open Source Bootcamp. Over the past grant period, he has worked full-time on BlueWallet, a self-custodial bitcoin and lightning wallet for iOS and Android.

BlueWallet is used by people around the world to hold and manage their own bitcoin. Work on a wallet like BlueWallet directly affects user safety, privacy, reliability, and ease of use.

During his previous grant period, Ojok contributed to several important improvements. He helped migrate parts of the codebase from Buffer to Uint8Array, worked on converting JavaScript code to TypeScript, contributed to Silent Payments-related code, improved user interface screens, reviewed wallet features, and worked on removing or replacing dependencies that are not ideal for an open-source wallet.

He has also been working on reproducible builds. Reproducible builds help users and developers verify that the app they install matches the open-source code. This strengthens trust and aligns with bitcoin’s culture of verification.

With the long-term grant, Ojok will continue improving BlueWallet. His planned work includes Android 16KB page size compliance, finalizing reproducible builds, modernizing Gradle, improving interoperability with hardware and external wallets, expanding end-to-end test coverage, and exploring a Taproot CLTV savings wallet feature.

His work will help make BlueWallet more reliable, easier to maintain, and more trustworthy for users who depend on self-custodial bitcoin tools.

Ojok also contributes to local Bitcoin developer education as a co-organizer of BitDevs Kampala, helping create a space for developers in Uganda to learn, discuss Bitcoin technical topics, and connect with open-source contribution opportunities.

Jamal ERRAKIBI

Jamal is a software engineer from Morocco with several years of professional engineering experience and more than two years of active Bitcoin open-source contribution. He is also active in bitcoin education and has built learning resources such as BTCillustrated and an interactive SHA-256 explainer.

Jamal’s work focuses on the lower-level libraries that many Bitcoin projects depend on. These libraries are not always visible to everyday users, but they are part of the foundation that makes Bitcoin software secure, fast, and reliable.

During his previous grant period, Jamal made significant contributions across the rust-bitcoin ecosystem. He opened and reviewed many pull requests and issues, worked on the hashes crate, added SHA256 ARM hardware acceleration, improved benchmarking, added test vectors, helped fix hashing-related issues, and contributed to the consensus encoding crate.

Some of this work improves performance. Some improve safety. Some reduce the risk of bugs in code that many bitcoin applications rely on.

With the long-term grant, Jamal will continue working on performance and cryptographic foundations in the Rust Bitcoin ecosystem. His planned work includes optimizing double-SHA256, adding SIMD implementations for different processor architectures, benchmarking Bitcoin-related Rust crates, deepening work on rust-secp256k1, reviewing Silent Payments support, and writing educational material for the Btrust blog.

He also plans to explore quantum-computing-related topics relevant to Bitcoin and continue mentoring Btrust Builders students and starter grantees.

Brandon Odiwuor

Brandon is a Bitcoin Core contributor based in Kenya whose work focuses on build systems, testing, continuous integration, functional tests, documentation, RPC improvements, GUI work, and code review.

During his previous grant period, he contributed across many parts of Bitcoin Core. His work included build-system improvements, functional test enhancements, Signet configuration support, RPC coverage fixes, offline signing documentation, GUI improvements, and extensive review of CI and build-related pull requests.

Bitcoin Core is the reference implementation of the Bitcoin protocol. Because of this, its testing and build systems are extremely important. When developers make changes to Bitcoin Core, continuous integration systems help check that those changes do not break important functionality.

Brandon’s long-term project focuses on improving Bitcoin Core’s CI pipeline using CTest and CDash. In simple terms, CTest can help standardize how tests are run, while CDash can provide clearer dashboards for tracking test results, failures, and trends over time.

This work aims to make Bitcoin Core testing easier to understand, easier to debug, and more consistent across different operating systems and environments.

With the long-term grant, Brandon will prototype CTest integration for Bitcoin Core tests, help set up and improve a CDash dashboard, update CI workflows, support sanitizer and coverage reporting, review CI and build-related changes, and continue mentoring new contributors.

He also helps grow the Bitcoin developer community through BitDevs Nairobi, where he leads Socratic seminars and supports technical discussions around Bitcoin Core development.

Btrust Builders Alumni

A major theme of the quarter’s cohort is the role of Btrust Builders in helping developers move from learning to meaningful open-source contribution.

All but one of the recipients in this cohort have participated in Btrust Builders or related Btrust learning pathways. These programs provide structured education, technical mentorship, and practical open-source experience. They help developers understand Bitcoin deeply, build confidence, and begin contributing to real projects used by the wider ecosystem.

This progression from Builders participants to funded grantees reflects Btrust’s long-term approach to identify talented developers, support their learning, provide mentorship, and help them build sustainable careers in Bitcoin open source.

Btrust Builders pathway applications are open all year round. If you are interested in learning Bitcoin development and joining a future cohort, we encourage you to apply.

You can also check the program calendar to see when the 2026 Btrust Builders pathways are scheduled next.

Strengthening BitDevs Communities Across Africa

This cohort also shows the importance of local developer communities. Several recipients organize or support BitDevs meetups in their cities, including Lagos, Kampala, Kaduna, Malawi, and Nairobi. These communities create spaces where developers can discuss Bitcoin technical topics, review new developments, learn from each other, and find pathways into open-source contributions.

Btrust supports the largest network of BitDevs communities in Africa, helping strengthen local Bitcoin developer ecosystems across the continent.

The work of these grantees is not limited to code. By organizing meetups, mentoring newer contributors, and creating learning opportunities, they are helping build the next generation of Bitcoin open-source developers.

If there is a BitDevs community near you, we encourage you to participate, attend a meetup, and connect with other developers learning and contributing to Bitcoin open source. If there isn’t one in your city, you can check out the BitDevs Playbook to learn how to build a sustainable community, and apply for Btrust support to help get it started.

Applications for Btrust Developer Grants

Btrust developer grant applications are open all year round, with new recipients announced quarterly.

If you are already contributing to Bitcoin open-source software, or you are ready to begin contributing full-time, we encourage you to learn more and apply.

You can learn more about Btrust developer grants and explore other Btrust grant opportunities on our website.

About Btrust

Btrust is a non-profit organization with a mission to decentralize the development of Bitcoin open-source software. We focus on supporting developer talent from the Global Majority and strengthening the free and open-source Bitcoin ecosystem.

Through grants, education, mentorship, and community support, Btrust helps developers contribute to the tools, infrastructure, and applications that make bitcoin more resilient, accessible, and decentralized.

In Q1 2026, Btrust Builders ran two learning pathways in parallel: Mastering Bitcoin and Learn Bitcoin from the Command Line. Each pathway had two tracks: a live cohort with weekly sessions, chaperones, structured assignments, and formal graduation requirements; and a self-paced track for developers who wanted to study the same material independently.

We recently celebrated the live cohort graduations. This post focuses on the other side of that same quarter: the self-paced learners.

The self-paced tracks were designed for developers balancing learning with work, school, exams, family, and other responsibilities. They received the same core materials as the live cohorts, along with learner guides, weekly prompts, Discord check-ins, moderator support, and open office hour sessions. What they did not have was the fixed structure of weekly attendance or live cohort grading.

Instead, completion was recognised through a written self-assessment: a published article or reflection documenting what the learner studied, where they struggled, what changed in their understanding, and what they plan to build next.

By the end of Q1, 13 developers submitted written reflections: 10 from Mastering Bitcoin and 3 from Learn Bitcoin from the Command Line. Together, these submissions represent the first self-paced completion pool for potential recognition, grant shortlisting, and deeper program engagement.

Below is what they wrote.

Mastering Bitcoin Track

The Mastering Bitcoin self-paced track gave learners the opportunity to study Mastering Bitcoin: Programming the Open Blockchain independently. The track focused on Bitcoin fundamentals: transactions, wallets, keys, mining, consensus, fees, scripts, Taproot, privacy, and the design choices that make bitcoin work.

For many learners, the pathway revealed a gap between being able to talk about Bitcoin and truly understanding it at the protocol level.

Hussein 

Hussein came into the pathway confident. He had explained bitcoin to people and knew the talking points. However, the seven weeks of close reading revealed the gap between being able to talk about something and actually understanding it.

The fees chapter was where it got embarrassing. "I thought about how many times I had explained fees as a small charge. That framing completely hides the truth. It's not a charge. It's a bid. Every transaction is competing with thousands of others for space in the next block. I rewrote my mental model of fees from scratch that week."

Mining hit harder. "I used to explain mining like this: miners solve a puzzle and new bitcoin gets created. Bitcoin isn't issued because miners solve puzzles. Miners solve puzzles because that's the only known way to get thousands of strangers, with no reason to trust each other, to agree on one shared version of history. The new bitcoin is just an incentive. The real product is consensus."

Hussein is now building Bitcoin Lasgidi, a Bitcoin developer community at his campus in Lagos. 

Read more here - I Thought I Understood Bitcoin. I Was Wrong

Ebube Miracle Ukpai

Ebube had developer experience and enough bitcoin familiarity to feel comfortable in most conversations. He knew about Taproot, had heard of Lightning, understood HD wallets at a surface level. What he was missing was the connective tissue behind the design decisions, the tradeoffs that shaped the protocol, the mental models that make everything else make sense.

The UTXO model was the concept that changed the most for him. In his words, "That reframe changes everything. It changes how you think about privacy; address reuse links your UTXOs together publicly. It changes how you think about fees , they're the implied difference between inputs and outputs, never explicitly stated. It changes how you think about wallet design, transaction construction, and even the economics of small payments."

The hardest part was not cryptography, as he expected, but Schnorr multisig and the key cancellation attack. Working through it required sitting with the discomfort of not immediately understanding something. He is now planning to build a Bitcoin wallet from scratch and contribute to Bitcoin Core, rust-bitcoin, and BDK.

Read more here - From Bitcoin User to Bitcoin Developer: What Six Weeks of Mastering Bitcoin Actually Taught Me

Kamogelo Aphane 

Kamogelo describes completing the pathway as gaining a new set of eyes. What began as curiosity about digital gold became, over eight weeks, a rigorous study of distributed systems, cryptography, and game theory.

What surprised her most were the incentives. "The difficulty adjustment algorithm is perhaps the most underrated piece of engineering in the 21st century, the heartbeat of the network, ensuring that no matter how much hash power enters or leaves, the block interval remains constant."

By the end, she had three projects mapped out: A non-custodial Lightning wallet that prioritizes user sovereignty, an exploration of Onion Messages for metadata-free peer-to-peer coordination, and a DLC-based weather insurance product for small-scale farmers. She wants to build a decentralised, oracle-based weather insurance tool, and a trustless safety net without a centralised middleman."

Read more here -  A Deep Dive Into the Protocol: Reflecting on the Btrust Mastering Bitcoin Journey

Timothy Chimbiv 

Timothy came in as a Stacks developer writing smart contracts in Clarity, and the pathway rebuilt the foundation he had been building on. In his words, "A bitcoin wallet doesn't hold bitcoin. It holds your keys. The bitcoin lives on the blockchain, your keys just prove you can spend it. That reframing changed how I think about custody and security entirely." This was an insight that landed the most for him. 

He is now going deeper into Lightning and building on Stacks with more intentionality about staying within bitcoin's decentralized security model.

Read more here - My Journey Through Mastering Bitcoin: What I Learned, What Challenged Me, and What's Next

Collins Mwanga

Collins came in thinking of bitcoin as magic internet money. Bitcoin Script was his hardest chapter. In his words, "Reading scripts felt like learning a tiny programming language. I had to go through examples multiple times before understanding how transaction conditions are verified. What helped most was slowing down, drawing diagrams, and experimenting with small code snippets." 

He plans to focus on Bitcoin infrastructure, privacy tools, and making technical bitcoin education more accessible across Africa.

Read more here — My Journey Through Mastering Bitcoin

Goodness Bakinde 

Goodness worked through all 14 chapters and describes Taproot as his standout: "Schnorr's linearity enables powerful features like scriptless multisignatures, making complex multi-party setups indistinguishable from simple single-signature transactions on-chain. This leap in privacy and efficiency was eye-opening." 

He is now moved into the Bitcoin CLI pathway.

Read more here - My Mastering Bitcoin Journey

Jonjay 

 Jonjay came to the pathway with no technical background in Bitcoin.

 "I used to think bitcoin was just 'that coin' for rich people on X. I never really understood what was happening underneath." By the end, his frame had shifted entirely: "It is economics. It is game theory. It is freedom. It is coordination at a global scale without trust." 

He made his first open-source contribution, to BTCPay Server, during the pathway.

Read more here -  How the Mastering Bitcoin Pathway Changed the Way I See Bitcoin

Khalid Yusuf 

Khalid went in expecting a technical overview and found, he writes, "a blend of computer science, economics, and philosophy that challenged my assumptions about money and trust in digital systems." 

His view of bitcoin shifted from investment to infrastructure. He is now experimenting with testnet transactions and plans to go deeper into Lightning.

Read more here -  The Bitcoin Journey at Btrust

Clerence 

Clerence's starting point was familiar: he thought a wallet stores coins. Learning about hierarchical deterministic wallets and derivation paths dismantled that entirely. 

"Understanding HD wallets and derivation paths changed my mental model completely. A single seed phrase can generate many addresses, all controlled by the same cryptographic root. This forced me to move away from thinking in terms of accounts and toward thinking in terms of key ownership."

The Byzantine Generals Problem was the concept that gave him the deepest appreciation for bitcoin's design. Understanding why reaching agreement in a decentralised system with untrusting participants is so hard, and how proof-of-work solves it, made the protocol feel less like a technology and more like a carefully reasoned argument.

He is now exploring node infrastructure, scalability constraints, and building systems that can operate in resource-limited environments.

Read more here - From Bitcoin User to Bitcoin Student: My Journey Through Mastering Bitcoin

Abdulmajid Yunus 

Abdulmajid came in with a goal to understand bitcoin well enough to explain it in non-technical terms. What he ended up doing was considerably more.

He ran a node on his machine, performed a testnet transaction in Sparrow Wallet, created SegWit, Taproot, and multisig wallets, and connected Sparrow to his local node. When CompactSize encoding in transaction hex stumped him, he built a tx-decoder, an educational tool for parsing the binary structure of Bitcoin transactions, to work through it properly.

He has already made contributions to rust-bitcoin and rust-payjoin, and is actively looking to go deeper into both projects. "When I come back to this in a year, I should be able to see my name, in multiple Bitcoin open-source projects."

Read more here - Btrust Mastering Bitcoin

Learn Bitcoin from the Command Line Track

The Learn Bitcoin from the Command Line self-paced track focused on practical, hands-on interaction with Bitcoin Core. Learners worked through command-line usage, node configuration, raw transactions, scripts, multisig, PSBTs, RBF, CPFP, and other low-level Bitcoin operations.

While Mastering Bitcoin helped learners strengthen their conceptual foundation, the CLI pathway pushed them to interact directly with the protocol.

Muhammad Ademola 

Muhammad's submission walks through configuring Bitcoin Core, building raw transactions, testing RBF and CPFP hands-on, and working through multisig and PSBT. The most significant work happened alongside the curriculum.

He investigated a security vulnerability in BDK Wallet, traced it across multiple dependency layers, and found the real blocker upstream in two libraries without stable releases. The lead maintainer reviewed his issue and added it to the official Wallet 4.0.0 milestone. He contributed PRs to Cove and Floresta in parallel and is monitoring upstream libraries for the next fix.

His contributions this quarter span five PRs and issues across BDK Wallet, Cove, and Floresta.

Read more here - From Zero to Scripts: My Bitcoin CLI Learning Journey

Usman Umar Garba 

Usman came in with a longer Bitcoin arc behind him. In 2025, his team built BitTicket, a decentralised ticketing platform using Bitcoin transactions, through the African FreeRouting Lightning Bootcamp. The CLI pathway shifted how he engaged with the protocol at its base layer. "Before this pathway, I mostly interacted with bitcoin through wallets and high-level explanations. Using bitcoin-cli forced me to work directly with the protocol itself."

His BOSS Challenge project, a Rust-based Lightning UTXO and Anchor Manager for Lightning node operators, was featured on the BOSS Challenge portfolio. He is now building SatsFor, a Lightning-based mobile tipping application in Flutter and Rust. 

In his words, "A creator in Lagos should be able to receive sats instantly from someone anywhere in the world without depending on traditional payment systems, delays, or high fees."

Read more here - From Learning Bitcoin to Building on It: My Journey Through Btrust, Lightning, and Open Source

Ogunseye Oluwajuwon Michael 

Ogunseye completed the CLI pathway for the second time, this time alongside AI engineering final exams. The self-paced format made that possible. 

He built a multisig wallet in Python, worked through PSBT and RPC commands, and describes where he landed: "I still consider myself early in the journey, but I now feel much closer to the direction I want to grow in."

Read more here -   My Second Journey Through Bitcoin via Command Line

What the Self-Paced Reflections Show

Across both pathways, the reflections reveal a few clear patterns.

First, the self-paced format did not reduce the depth of learning. Learners were not simply consuming material passively. They were revising mental models, building tools, running nodes, creating wallets, testing transactions, contributing to open-source projects, and forming clearer technical goals.

Second, written reflection proved to be a useful completion signal. It gave learners a way to demonstrate understanding in their own words while also documenting their growth publicly. For some, the article itself became a bridge into the next phase of their Bitcoin development journey.

Third, self-paced learning widened access. Several learners were studying around exams, jobs, or other responsibilities. The ability to move at their own pace made it possible for them to continue without being excluded by the structure of a live cohort.

Finally, the reflections point toward the next stage of the self-paced framework. Written self-assessments are a strong first signal, but the program is now working toward adding more outcome-based indicators, including pull requests, code contributions, technical projects, and open-source participation.

If you are working through the Btrust Builders pathways, or considering starting, these are the people ahead of you on that path. The material is the same and the pathway is open. If you are ready to begin, you can apply to the Btrust Builders program here.

Bitcoin has always carried a powerful promise: that money can be open, neutral, and fair. Regardless of where you are from, what you look like, who you know, or the kind of background you have should not decide whether you can access the global financial system.

That promise is one of the reasons many people are drawn to Bitcoin. But Bitcoin is not only shaped by code. It is shaped by the people who write the code, review it, maintain it, teach it, and make it easier for others to understand.

And across Africa and the Global Majority, more women are becoming part of that work. They are not just learning about Bitcoin from a distance. They are contributing to real open-source projects, leading communities, mentoring others, and helping build the tools that make the network stronger.

For a long time, open-source Bitcoin development has not reflected the full range of people Bitcoin is meant to serve. In a 2019 report by Decrypt, fewer than 5% of open-source crypto developers were recorded as women. That gap was never about ability. It was about access: access to learning paths, technical communities, mentors, funding, and people who make the journey feel possible.

Since 2021, Btrust has been working to help close that gap. Through grants, mentorship, and education programs for developers from Africa and the Global Majority, Btrust is creating clearer paths into serious Bitcoin open-source work. In our just-concluded Q1 2026 Mastering Bitcoin cohort, 34% of participants were women, one of the highest levels of female participation in any Btrust Builders cohort so far, and a striking contrast to an ecosystem where women make up less than 5% of open-source contributors overall.

That number matters because it shows what can happen when people get the right support. More women are finding their way into Bitcoin development, and many are staying, contributing, and helping others come in after them. Across the African Bitcoin open-source ecosystem, Btrust has become an important touchpoint for many women contributors, whether through Builders resources, cohorts, mentorship, or community programs. It is one sign that access, when made intentional, can change who gets to build and who gets to lead.

In this article, we are spotlighting three Btrust grantees whose work shows what that future can look like. Rita Anene is building Lightning infrastructure full-time. Jemimah Nagasha moved from public infrastructure into Bitcoin infrastructure. Enigbe Ochekliye is contributing to the Lightning Dev Kit ecosystem through engineering and research.

Three women. Three different paths. One shared commitment to building.

Rita Anene: Building Lightning Infrastructure Full-Time

Rita had spent over three years working as a software developer when she began to feel that she wanted something deeper. She was good at her job, but she wanted to work on technology that felt more foundational. She wanted to build something that could change how people relate to money, not just how a product works.

She first heard about Bitcoin in 2018. At the time, she understood it the way many people do at first: as internet money. She did not think too much about it and moved on. But in 2024, she discovered the development ecosystem behind Bitcoin. She found people maintaining the infrastructure, debating design choices, reviewing code, and building tools that support real-world use. That discovery changed everything.

It led her to Btrust, and then to the BOSS program, run in partnership with Chaincode Labs. The program was demanding, and Rita was still working a full-time job while taking part in it. But she stayed committed. She read Bitcoin chapters on her commute, used her weekends to study, and coded late into the night after work.

She later joked that she became a “vampire coder”, but what really stood out was her focus. She kept showing up because the work had become meaningful to her.

By Week 4 of the program, the Lightning Network clicked. Its design captured her attention, and the Lightning challenges quickly became the ones she solved fastest.

Her first contribution was integrating Circuit Breaker into Warnet, a Bitcoin and Lightning network simulator. She still remembers how nervous she felt when she forked the repositories. Her hands were shaking. But she opened the pull request, went through several rounds of review, and eventually, it was merged.

From there, Rita found her technical home in LDK Node, a Lightning implementation in Rust.

By January 2025, she started attending BitDevs Lagos, and by June, she was hosting sessions. In Q3 2025, she received the Btrust Starter Grant and moved into full-time open-source Bitcoin development.

Today, Rita works on LDK Node full-time. One of her recent contributions rebuilt payment store synchronization into an event-driven architecture. She then used that foundation to implement fee-bumping for unconfirmed transactions. It is careful, important work that helps shape how Lightning nodes behave for the people and applications that depend on them.

Read more about her here.

Jemimah Nagasha: From Public Infrastructure to Bitcoin Infrastructure

Nagasha was managing public infrastructure projects in Uganda when she started learning frontend development on the side. She wanted more flexibility, but she also enjoyed building things people could actually use.

As she learned more, her curiosity grew. She wanted to understand systems more deeply. How do they scale? How do they fail? How can they give people more control over their lives?

That curiosity led her to the first BitDevs Kampala event. There, Bitcoin began to feel different. It was no longer just something she had heard about. It became a serious technical system she wanted to understand.

At that same event, she heard about the Btrust Builders Program from an alumnus. She applied, and that decision opened a new path for her.

The program took her from Bitcoin fundamentals into the Btrust Builders Fellowship. She began decoding transactions, creating Lightning channels, and studying open-source projects to understand the problems they were trying to solve. She also started contributing to Polar, a tool that helps developers run Bitcoin and Lightning nodes locally. Her work helped improve the experience for other developers who need a simpler way to build and test.

And she was doing all of this while still working full-time as a civil engineer.

What started with attending BitDevs Kampala soon became organising it. By 2025, Jemimah was leading the community. She also joined the Btrust Builders faculty, where she began mentoring the next cohort and sharing the same kind of support that had helped her grow.

In April 2026, she received the Btrust Starter Grant and made the full transition into Bitcoin open-source development. She no longer had to split her time between construction drawings and Bitcoin code.

“This journey has given me more than technical skills,” she wrote. “It has given me a community, a sense of purpose, and the chance to build tools that make Bitcoin more accessible.”

Learn more about her story here.

Enigbe Ochekliye: Strengthening Bitcoin Through Research and Engineering

Enigbe is a Lightning developer based in Nigeria. Her work focuses on Lightning Network infrastructure and research, especially within the Lightning Dev Kit ecosystem.

Her path into this work is grounded in both engineering and systems thinking. She holds a Master’s in Energy from the University of Auckland, where she completed graduate-level coursework in multivariable control systems. She also holds a Bachelor’s in Mechanical Engineering from Ahmadu Bello University.

That background gives her a unique lens for thinking about Lightning. The network is not just software. It is a live system, with many moving parts, many actors, and constant changes in liquidity, routing, and reliability. Enigbe’s work sits at the place where practical engineering and deeper research meet.

Over the past couple of years, she has contributed to the LDK ecosystem through code development, reviews, and technical research. Her work includes improvements to logging infrastructure, chain synchronization features, and infrastructure reliability across LDK components. These are the kinds of contributions that help developers and node operators run more dependable systems.

Enigbe is currently pursuing research into distributed control systems for Lightning Network liquidity management. In simple terms, she is studying how Lightning can be understood as a network of independent actors that still need to coordinate with one another. Her work models Lightning as a multi-agent dynamical system and explores how decentralized controllers can help coordinate liquidity distribution across the network.

This research will combine theory with practice. Part of the work will happen through academic exploration, and part of it will be implemented inside ldk-node and simulation environments. The goal is to contribute not only new ideas, but also open-source engineering improvements that can be tested, reviewed, and built on by others.

Enigbe is also the first member of the Btrust Open Source Cohort to focus on research. That matters because it expands what contribution can look like within the program. Open-source work is not only about writing code. It is also about asking hard questions, testing ideas, studying systems, and turning research into tools that make the ecosystem stronger.

Building the Future, Together

Rita, Jemimah, and Enigbe are part of the future Btrust is investing in: a future where more women across Africa and the Global Majority have the support, funding, mentorship, and community they need to become serious contributors to the Bitcoin open-source ecosystem.

Their stories are not about waiting for permission. They are about choosing to learn, staying with difficult problems, contributing to important tools, leading communities, and making the path clearer for others.

That last part matters more than it might seem. For many developers, the journey into Bitcoin does not begin with a grant or a formal program. It begins in a room, at a local BitDevs meetup, where people are asking questions, discussing technical ideas, and slowly making Bitcoin feel less abstract. Btrust supports the largest network of BitDevs chapters in Africa, with more than 13 communities across the continent. Several of these chapters are led by women, which makes them even more powerful as entry points. When women lead technical spaces, other women can walk in and see that they belong not only as learners, but as contributors and leaders too.

And Btrust is not the only organisation building this pipeline. Initiatives like Hack4Freedom, Dada Devs and Africa Free Routing’s Lightning Bootcamps are also creating pathways for women in the Bitcoin ecosystem. They are training developers, building communities, and helping expand who gets to take part in this work.

And that matters because the movement is bigger than one organisation. It is a growing network of people making Bitcoin development more open, more accessible, and more representative of the world it hopes to serve.

If you are a developer watching from the outside, or someone who is simply curious but unsure where to begin, there is room for you here. You do not need to already know Rust. You do not need a computer science degree. You do not need to have everything figured out before you start.

Curiosity is enough for the first step. Consistency will carry you further. And with the right community around you, the things that feel difficult now can begin to make sense.

Bitcoin’s future will be stronger when more people can help build it. Rita, Jemimah, Enigbe, and many others are already showing what that future can look like.

The bitcoin++ Open Source Edition Hackathon brought together 90 builders from across Africa and beyond for two intense days of hacking, collaboration, learning, and open-source innovation.

From June 17th, participants built projects spanning Bitcoin, Lightning, Nostr, developer tooling, financial inclusion, open-source infrastructure, and real-world applications. The result was an impressive showcase of what can happen when talented builders are given the space, community, and challenge to create.

As proud sponsors of two challenge tracks, Best Contribution to Open Source and Solve Open Source Contribution Spam, we were excited to support projects addressing some of the most pressing challenges facing open-source development today.

Btrust Challenge Winners

Best Contribution to Open Source

UTXOracle BTC Calculator by Parrish: A bitcoin price calculator powered entirely by a self-hosted bitcoin node using UTXOracle, demonstrating how useful services can be built without relying on centralized exchanges or third-party APIs. The project also included a meaningful contribution back to the ecosystem through a pull request to integrate UTXOracle into nix-bitcoin.

Solve Open Source Contribution Spam (Joint Winners)

Filter by John Osezele: A GitHub app that helps maintainers identify low-quality and AI-generated pull request spam through transparent, configurable, and explainable rules.

Core-Gate by Aisha Omar Farah and Mary Wangui: A GitHub Actions workflow designed to automatically triage Bitcoin Core pull requests before maintainers spend valuable time reviewing them, helping reduce contributor noise while improving review efficiency.

Congratulations to all three teams for building tools that strengthen the open-source ecosystem and support the maintainers who make it possible.

Overall Winners

1st Overall - WestToEast

Built by Mamadou Diop, WestToEast enables cross-border payments between West African currencies (XOF, XAF, and GNF) and Kenyan Shillings through Bitcoin, Lightning, LNURL, and Tando. The project demonstrates how Bitcoin infrastructure can help bridge fragmented mobile money ecosystems across Africa.

2nd Overall - Robin

Built by Fidel Otieno and Chris Oketch, Robin is an AI-powered guide for aspiring Bitcoin open-source contributors. Rather than encouraging low-context contributions, it helps builders understand where they can contribute meaningfully and directs them toward projects that best match their skills and experience.

3rd Overall - nairobi2

nairobi2 is a permissionless ride-sharing platform that combines market-based price discovery with Bitcoin-based Sybil resistance, exploring new models for decentralized coordination.

Category Winners

Best Beginner Hack

Hodlr by Paul Eke: A bitcoin savings application that leverages timelocks to help users commit to long-term saving strategies by removing the temptation of early withdrawals.

Best Use of Soapbox

Dishi Fresh by Thomas Cadra and Colly Sindani: A platform that connects users to local recipes, ingredient vendors, and delivery services, simplifying meal planning while supporting local businesses.

Best Tool for Mobile Money Brokers/Agents Using Bitcoin

LNpesa by Denver Mtange, Kelly Gakii, and Kendi Litala: A USSD-powered bitcoin agent platform that allows feature phone users to participate in bitcoin-enabled mobile money services without requiring smartphones or internet access.

Best Use of Pontmore

Pontswap by Wesley Nyamu and Cynthia Muemi: A Nostr-native coordination layer for bitcoin-to-fiat swaps that combines transparency, privacy, and verifiable state transitions using open protocols.

Honorable Mentions

Several projects also stood out for their creativity, technical execution, and potential impact.

PoWR

Built by Shannon Kioko, Lucy Kamau, Anne Mahonga, and Salma Adam, PoWR creates verifiable proof-of-work profiles for developers by analyzing meaningful open-source contributions and anchoring reputation data on-chain.

Zaptip

Built by Rita Anene, Zaptip is a Chrome extension that enables bitcoin tipping directly on GitHub profiles and repositories using Lightning addresses.

SiriScore

Built by Susan Githaiga, Nkatha Kaburu, Rose Jane, and Nelly Nakhero, SiriScore is a pre-broadcast bitcoin transaction privacy analyzer that helps users identify privacy leaks before signing and broadcasting transactions, giving them actionable insights to improve on-chain privacy.

MindfulSats

Built by Tony Nakamoto, MindfulSats combines accountability, goal-setting, and financial commitment to encourage positive habits and long-term personal growth.

Tando's Ark

Built by Shamsudeen Adedokun and Matthew Vuk, Tando's Ark integrates Ark technology into Tando, creating a pathway toward more efficient and potentially fee-free bitcoin-to-M-PESA payments.

Recognizing the People Behind the Event

A special thank you goes to Alex Lewin, and the bitcoin++ team for creating an environment where builders could learn, collaborate, experiment, and ship. From organizing the hackathon and coordinating logistics to supporting participants throughout the event, their efforts helped create an experience that will continue to impact builders long after the final presentations concluded.

We would also like to thank the judges who dedicated their time, expertise, and attention to evaluating submissions across a wide range of categories:

• Nifty, Base58
• Jodom, Minmo
• Alex Gleason, Soapbox
• Fabian Jahr, Brink
• Sy, Stratum V2
• Judy Imasuen, Human Rights Foundation
• Kelvin Isievwore, Btrust
• Mikey, Cashu
• Mark Kamau, Designing Africa
• Hadi Alamdar, Block
• Marvin Charles, Block

Judging a hackathon involves far more than selecting winners. It requires reviewing technical implementations, understanding project impact, evaluating creativity and feasibility, providing constructive feedback, and recognizing excellence across very different categories. We are grateful for the time and thoughtfulness they brought to the process.

The Future Is Being Built in the Open

What stood out most throughout the hackathon was not just the quality of the projects, but the creativity, collaboration, and willingness to build in public.

The projects ranged from developer tooling and contribution workflows to financial infrastructure, cross-border payments, decentralized coordination systems, and mobile-money integrations. Together, they showcased the breadth of innovation emerging from African builders and the global Bitcoin open-source community.

The quality of submissions was a reminder that builders are not waiting for permission. They are solving real problems, contributing to open source, experimenting with new ideas, and building the future of Bitcoin.

Congratulations to all category winners, honorable mentions, finalists, and every team that shipped a project during the hackathon. Building something meaningful in less than 48 hours is no small feat.

To everyone who participated, submitted a project, mentored, volunteered, judged, or simply showed up and learned something new: thank you. Keep building. Keep contributing. Keep shipping.

Written by Jemimah Nagasha

If you had told me a few years ago that I would leave my civil engineering job to work full-time in Bitcoin open source, I probably would have smiled politely and gone back to reviewing construction drawings.

At the time, my life followed a fairly structured path. I was a civil engineer managing public infrastructure and maintenance projects. But on the side, I had started exploring technology.

I picked up frontend development as a side hustle, partly because I wanted more flexibility, and partly because I enjoyed building things that people could actually use and interact with.

But even then, something felt incomplete. I wasn’t just interested in writing code. I wanted to understand systems, how they work, how they scale, how they fail, and most importantly, how they can give people more freedom and control. That curiosity is what eventually led me to Bitcoin.

The First Spark

My real entry point into Bitcoin was a conversation. A friend invited me to the very first BitDevs Kampala event. I didn’t fully know what to expect, but I decided to show up anyway.

That room changed everything for me. For the first time, I saw Bitcoin not as speculation, hype, or headlines, but as a technical system. A system that people were actively building, questioning, improving, and defending.

Even more importantly, I met people who deeply cared about the idea of freedom money and permissionless systems. There was something powerful about being in a room with people who were not just talking about Bitcoin, but working to understand it and contribute to it.

At that same event, I heard about the Btrust Builders Program from an alumnus, Rukundo. He described it as a structured, rigorous, and community-driven pathway into Bitcoin open-source development.

It sounded exactly like the kind of opportunity I had been looking for so I applied.

The Btrust Builders Program

When I got accepted into Btrust Builders, I was so excited. The first six weeks focused on understanding the foundations of Bitcoin: how it works, why it exists, and the principles behind it. We learned about Bitcoin as a monetary system, a technical system, and a tool for individual freedom.

This phase was highly engaging, especially because of the weekly collaborative calls with other participants. We shared what we were learning, asked questions, and worked through difficult concepts together.

During that time, I began to understand Bitcoin’s broader mission more clearly. It is not just about technology for technology’s sake. It is about addressing real problems in traditional money systems and giving people more control over their financial lives. Coming from a context where financial systems do not always work in people’s favour, that idea felt very real to me.

After the initial phase, I was accepted into the Btrust Builders Fellowship, where we went much deeper into the technical side of Bitcoin.

We wrote programs to decode transactions, created Lightning channels, worked on group projects to build Bitcoin applications, and also explored existing Bitcoin open-source projects and the problems they were trying to solve. It was intense, demanding, and exactly the kind of structure my curiosity had been missing.

The fellowship also changed the way I approached learning. I became more comfortable with not knowing everything right away. I learned how to read code I didn’t fully understand yet. I learned how to ask better questions. And slowly, I gained both the technical foundation and the confidence to start contributing to open source.

From Learning to Contributing

Because of the fellowship, I started contributing to Polar, a tool that makes it easier for developers to run Bitcoin and Lightning nodes locally. It was the perfect entry point for me because it's practical, useful, and directly connected to improving the developer experience.

My first pull request was a huge learning experience. It was exciting, but also humbling. I had to read the codebase, understand the contribution process, ask questions, make changes, and respond to feedback. But each contribution made the next one a little easier.

Over time, the codebase started to feel less foreign. It became something I could understand, work with, and eventually help shape.

Around the same time, I became more involved in the local Bitcoin community. What started as attending BitDevs Kampala slowly turned into helping organise it, and eventually leading it in 2025.

I also joined the Btrust Builders faculty, where I got the chance to share what I had learned with future cohorts. That experience meant a lot to me because it felt like I was passing the knowledge forward and helping create the same kind of supportive path that had helped me.

Through all of this, I met like-minded people, learned from their experiences, and realised that I was not alone in this journey.

Building a space where developers could learn together, whether they were completely new or already experienced, reinforced something I now believe deeply: Education and open source are closely connected. In many ways, they are part of the same work.

The Btrust Starter Grant

All of this was happening while I was still working full-time as a civil engineer. Balancing both worlds was one of the hardest things I have done. There were lots of late nights, early mornings, and weekends spent writing code after long workdays. I loved what I was learning and building, but it was not easy to keep both paths going at the same time.

Then I applied for the Btrust Starter Grant to work on Polar, and in April 2026, I was awarded the grant. That moment meant a lot to me because it gave me the opportunity to transition into full-time Bitcoin open-source development. I no longer had to squeeze contributions into evenings and weekends, nor wait until after work hours to focus on the thing I cared about deeply. I could finally give it my full attention.

Building the Future I Care About

Today, I work full-time on Bitcoin open source, focusing on improving the developer experience, making it easier for others to build, test, and experiment with Bitcoin and the Lightning Network.

This journey wasn't linear, nor was it planned. It was a series of small decisions: showing up to one event, applying to one program, making one contribution, and saying yes to one opportunity. Each step built on the last, but none of them felt obvious or inevitable at the time.

This journey has given me more than technical skills. It has given me a community, a sense of purpose, and the chance to build tools that make Bitcoin more accessible.

I hope sharing my story motivates more people, especially those who, like me, didn't start in traditional computer science paths. You don't need to have it all figured out. What you need is curiosity, consistency, and a willingness to learn.

Bitcoin has room for people from many backgrounds, each bringing their own skills and perspective. That is part of what makes it stronger and more resilient.

Global, May 19, 2026 - Btrust today announced the appointment of its new Board of Directors, marking the completion of a planned governance transition and the beginning of its next chapter.

Following a global, open call and a rigorous selection process, Janet Maingi, Bruno Garcia, and Laurence Aderemi have assumed full governance responsibilities. The process was guided by Btrust’s Genesis Principles, with a focus on transparency, fairness, and mission alignment.

This transition fulfills the mandate set in 2021, when Btrust was established with a 500 BTC endowment from Jack Dorsey and Jay-Z. The inaugural board, Obi Nwosu, Ojoma Ochai, Carla Kirk-Cohen, and Abubakar Nur Khalil, was tasked with building the organisation’s foundation and enabling a structured handover to a successor board.

Over a multi-week transition period concluding April 30, 2026, incoming and outgoing boards worked closely to ensure continuity across governance, financial oversight, and operations. This included budget reviews, documentation consolidation, and the initiation of an independent audit to strengthen accountability.

The new board brings deep expertise across Bitcoin infrastructure, energy systems, and open-source development. Together, they will guide Btrust’s mission to decentralise Bitcoin development and expand access to opportunities across the Global South.

“Today marks an important milestone for Btrust,” said CEO Abubakar Nur Khalil. “We are confident the new board will strengthen our impact and safeguard our long-term mission.”

Btrust moves forward with strong governance, operational continuity, and renewed stewardship.

About Btrust

Btrust is a non-profit organisation focused on decentralising the development of Bitcoin open-source software. It supports developer talent across the Global South and works to ensure the Bitcoin ecosystem remains open, inclusive, and resilient.

Learn more: https://btrust.tech

The first pathways of 2026 at Btrust Builders officially concluded recently. Between March and April 2026, developers from across Africa and beyond participated in two learning pathways: Mastering Bitcoin and Learn Bitcoin from the Command Line.

Each pathway ran in two formats: a structured live cohort and an open self‑paced track, allowing developers to participate either through scheduled weekly discussions or by progressing independently while engaging with moderators and the wider community.

Across both pathways, 265 developers from 24 countries took part in the program. By the end of the cohorts, 37 developers successfully graduated from the live tracks after meeting the technical and participation requirements.

The live cohorts were also among the most geographically and gender‑diverse groups in the Builders pathways to date, bringing together developers from across Africa as well as participants from outside the continent.

These pathways are part of Btrust Builders’ broader developer education strategy: a structured progression that helps developers move from learning Bitcoin fundamentals to contributing meaningfully to open-source projects.

Mastering Bitcoin

The Mastering Bitcoin pathway is an 8‑week foundational program designed to help developers understand how Bitcoin works from the ground up.

Participants study Mastering Bitcoin: Programming the Open Blockchain (3rd Edition) by Andreas Antonopoulos, exploring topics ranging from transactions and wallets to mining, consensus, and the deeper mechanics of the protocol. The pathway emphasizes technical reading, critical thinking, and collaborative discussion, preparing developers to engage seriously with Bitcoin development and open‑source work.

Live Cohort

The first live cohort brought together 74 developers from 18 countries, supported by 13 chaperones and teaching assistants who facilitated weekly study sessions.

One of the cohort’s highlights was its strong diversity: 34% of participants were women, one of the highest levels of female participation across any Btrust Builders cohort to date. The group also included developers from countries appearing in the program for the first time, including Burundi, Namibia, and Mozambique.

Over eight weeks, participants worked through the book chapter by chapter, preparing answers to Socratic questions, discussing concepts with partners, and joining weekly 90‑minute group study sessions where learners unpacked complex ideas together.

By the end of the program, 18 developers from nine countries graduated, meeting the pathway’s requirements for participation, preparation, and understanding.

Learners consistently highlighted the community and collaborative environment as one of the most valuable aspects of the experience.

"I wanted to get in‑depth knowledge about Bitcoin. The Mastering Bitcoin cohort didn't just provide that, it provided a community too," said Carita Ndibe from Nigeria.

Self‑Paced Track

Alongside the live cohort, 100 developers joined the self‑paced Mastering Bitcoin track, studying the same material independently while engaging with moderators and the community on Discord.

The track provides structure without fixed schedules, offering learners suggested weekly pacing, engagement prompts, progress milestones, and community discussions to support independent learning.

Moderators supported learners throughout the program and hosted an open office hour session where they explored different topics.

Learners were encouraged to progress at their own pace. Those who completed the program have been invited to share their takeaways, provide feedback on the pathway, and explore next steps such as upcoming Builders pathways.

The Discord space remains active so participants can continue discussing ideas, asking questions, and supporting others working through the material.

Learn Bitcoin from the Command Line

While Mastering Bitcoin focuses on conceptual foundations, Learn Bitcoin from the Command Line focuses on hands‑on interaction with Bitcoin software.

This 7‑week pathway teaches developers how to work directly with Bitcoin Core using the command‑line interface, following the book Learning Bitcoin from the Command Line by Christopher Allen and Shannon Appelcline.

Instead of just reading about Bitcoin’s mechanics, learners run commands, spin up nodes, construct transactions, inspect scripts, and explore the protocol by interacting with it directly.

Live Cohort

The first CLI cohort brought together 61 developers from 16 countries, supported by 14 chaperones and teaching assistants.

The group included participants from across Africa as well as developers from India and the United States, expanding the global reach of the program.

Throughout the seven weeks, learners worked through progressively challenging exercises, experimenting with Bitcoin Core commands, analyzing blockchain data, and building practical understanding of how the system works under the hood.

The pathway concluded with a capstone project, where participants applied what they had learned in a practical scenario.

By the end of the program, 19 developers graduated, representing seven countries.

"This cohort changed what I think is possible for me in Bitcoin development. I leave with the confidence to keep going, to contribute, to build, and to understand Bitcoin at a level I couldn't have imagined a few months ago," said Nkatha Sharon from Kenya.

Another participant reflected on how the pathway deepened their technical understanding:

"I already understood Bitcoin at a high level, but the bitcoin-cli pathway helped me understand it much better. If you want to really learn how Bitcoin works, this kind of training is a great way to get your hands dirty with the low-level details," added Tuedon Tuoyo from Nigeria.

Self‑Paced Track

Alongside the live cohort, 30 developers joined the self‑paced CLI track, progressing through the same material independently while engaging with moderators on Discord.

Moderators supported learners and hosted an open office hour session where participants shared projects they had built during the pathway, including a multi‑signature wallet in Python and a dust cleaner application.

What We Learned

Across the pathways, peer discussion emerged as one of the most powerful drivers of learning.

Learners consistently rated the weekly discussions, breakout rooms, and collaborative problem solving as the most valuable parts of the experience. The pathways also brought together developers from a wide range of backgrounds and countries, helping build a growing community of Bitcoin developers connected through shared learning.

Participants also shared thoughtful suggestions which will help shape the next iteration of the pathways.

What’s Next?

Many graduates are continuing their journey through the Btrust Builders ecosystem. Several participants plan to move on to upcoming Q2 pathways; Rust for Bitcoiners or the Language Clubs. Those who prefer to join future cohorts can also join the waitlist for upcoming pathway cohorts, as listed in the Pathway Calendar.

A number of learners have begun publishing technical write‑ups, sharing their knowledge in local developer communities, and exploring opportunities to contribute to Bitcoin open‑source Bitcoin projects.

Beyond structured learning, graduates are also encouraged to immerse themselves in the broader Bitcoin developer ecosystem by participating in developer communities such as BitDevs, as well as meetups, hackathons, and other Bitcoin-focused events. Staying connected to the community is one of the most effective ways to keep learning, find collaborators, and gradually move toward meaningful open‑source contributions.

Thank You to the Builders Community

These cohorts were made possible by the dedication of our faculty and the broader Builders community who supported learners throughout the journey.

To everyone who showed up each week, asked questions, helped their peers, and pushed themselves to understand Bitcoin more deeply, thank you for being part of this learning community.

About Us

Btrust Builders is Btrust’s comprehensive engineering program dedicated to training and funding African software developers to contribute to Bitcoin and Lightning open-source projects. The Builders program provides technical mentorship, community support, and structured pathways to sustainable Bitcoin development careers.

Written by Abdullahi Yunus

Most people know the Lightning Network as a fast way to send Bitcoin payments. It’s a network of computers (called nodes) connected by payment channels. When someone sends a payment, it travels through several nodes, and each step of the journey is protected using something called onion encryption.

But the technology that makes Lightning payments possible can do more than move money.

Think of Lightning like a network of roads connecting many cities. Right now, those roads are mainly used to deliver packages of money (bitcoin payments). But the roads could also carry letters, instructions, or other kinds of information.

Right now, Lightning nodes can only communicate directly with their immediate peers. If a node wants to communicate with another node it isn’t directly connected to, it usually has to use something outside the Lightning Network.

For example, fetching a payment invoice often requires making an HTTP request to a web server. That works, but it introduces several problems.

First, it can leak information. The server might learn your IP address, when you’re making the request, and that you’re about to make a payment.

Second, it introduces extra infrastructure outside Lightning. If the server goes down, the process breaks.

Third, it weakens Lightning’s privacy model, which was carefully designed around onion routing.

And that leads to the question, if Lightning already has a network that can privately route payments between nodes, why not use that same network to route messages too?

That’s exactly what onion messages are.

Onion messages are defined in the BOLT 4 specification. They allow nodes to send arbitrary data through the Lightning Network, using the same onion‑routing system used for payments, but without the extra payment machinery like channels, HTLCs, or liquidity locks.

In other words, onion messages turn Lightning from a payment-only network into a private communication layer.

This isn’t just a theoretical idea. Onion messages are already being used as a foundation for new Lightning features and protocols.

In this post, we’ll explore:

• How onion messages work
• How they differ from payment routing
• How they’re implemented in LND

How Onion Routing Works for Payments

Before we look at onion messages, it helps to understand how Lightning routes payments, since onion messages build on the same idea.

Imagine you want to send a package to someone across the country. You don’t deliver it directly yourself. Instead, it travels through several post offices, each forwarding it to the next one until it reaches the destination.

Lightning payments work in a similar way.

When a node wants to send a payment, it first finds a route through the network. That route is a sequence of nodes where each pair shares a payment channel.

Once the route is found, the sender creates something called a Sphinx packet, named after the cryptographic system it uses.

The important idea here is layered encryption.

Think of the packet like a package wrapped in multiple envelopes.

Each envelope contains instructions for one stop along the route. The first node opens the outer envelope. It reads instructions telling it where to send the package next. It forwards the remaining package. The next node does the same thing, removing the next layer and forwarding the packet again.

Eventually the packet reaches the final recipient, who opens the last layer and sees the payment details.

Another way to imagine this is like a relay race. Each runner only knows who handed them the baton and who they should pass it to next. No runner knows the entire route of the race.

This design provides strong privacy.

Each intermediate node only learns three things: who sent it the packet, where to forward it next and the forwarding instructions. It cannot see the full route, the sender, or the final destination.

Alongside this routing mechanism is something called an HTLC (Hash Time‑Locked Contract). A simple way to think about HTLCs is like a secure escrow lock. Funds are temporarily locked along the route, and they are only released when the recipient reveals a secret called the payment preimage.

When the recipient reveals this secret, it travels back along the same path and unlocks the payment at each step.

This ensures that the payment either succeeds everywhere or fails everywhere.

But there’s a downside. All of this machinery exists because we’re moving money. It requires payment channels, available liquidity, HTLC contracts and updates to channel balances. That’s a lot of work if all you want to do is send a message.

So developers asked a simple question. What if we kept the private routing, but removed everything related to payments?

That’s the idea behind onion messages.

Onion Messages: What They Are and How They Differ

Traditional Lightning routing is tightly connected to payments. Every hop in a payment route requires a channel with enough liquidity and an HTLC setup.

That’s like using a full armored money truck just to deliver a simple letter.

Onion messages strip all of that away.

They keep the encrypted routing, but remove the payment parts.

An onion message is defined in BOLT 4 as a standalone message type (msg type 513). It’s essentially a packet of encrypted data that can travel across the network using the same onion‑routing design.

But there are a few key differences:

No channel and HTLC required: A payment hop requires an active payment channel between nodes. An onion message only requires a network connection. For example, Alice can forward a message to Bob as long as they are connected peers, even if they don’t have a payment channel. This means the message network can be larger than the payment network, since any peer connection can act as a relay.

One-way by default: Payments involve a round trip because the recipient must reveal a secret to complete the transaction. Onion messages are much simpler. They are one‑way packets. The sender builds the packet and sends it into the network. After that, it simply travels hop by hop until it reaches its destination. You can think of this like dropping a letter into a mailbox. Once it’s sent, you don’t necessarily know the exact path it takes to reach the recipient.

Reply paths solve the response problem: If messages are one‑way, how can the recipient respond? The sender can include something called a ReplyPath. This is like including a self‑addressed return envelope inside the message. The recipient can place their reply inside this envelope and send it back through the network. The clever part is that the reply path is also hidden using route blinding, so the recipient doesn’t learn who the original sender is.

Blinded paths add recipient privacy: Normally, when a sender builds a route, they know who the final recipient is. But onion messages introduce blinded paths. With blinded paths, the final portion of the route is hidden from the sender. Imagine sending a letter to a reception desk in a large office building. The receptionist receives it and forwards it internally to the correct office. You never see the internal routing. That’s similar to how blinded paths work. The recipient creates a hidden route starting from an introduction node. The sender only knows how to reach that introduction point. From there, the message continues along the hidden path to the final destination. This provides powerful privacy guarantees. It allows situations where the sender doesn’t know the recipient’s node ID, intermediate nodes only know the next hop, and the recipient doesn’t know the sender.

This combination of reply paths and blinded paths is what gives onion messages their privacy properties. A full exchange can happen where neither side knows the other’s node identity, with each party hiding behind blinded routes.

The Denial-of-Service (DoS) question: One concern with onion messages is spam. Payment forwarding naturally limits traffic because it requires liquidity and HTLCs. But forwarding onion messages is basically free. That means someone could try to flood the network with messages. The current approach is rate limiting. Each node limits how many onion messages it will forward per peer per second. It’s a simple solution, but it helps prevent abuse while keeping the system lightweight.

Protocol Walkthrough: Inside LND

Let’s trace what happens when a node sends an onion message through the network in LND. The implementation is split across two main PRs: #9868 introduced the wire message and basic structures, with the forwarding logic following in #10089. The architecture that emerged reveals some interesting design choices.

The Wire Message

At the lowest level, an onion message on the wire is surprisingly simple. The OnionMessage type in the lnwire package (message type 513) is just two fields:

// lnwire/onion_message.go
type OnionMessage struct {
  PathKey *btcec.PublicKey // route blinding ephemeral pubkey
  OnionBlob []byte // Sphinx onion packet (BOLT 4), blinded by default
}

The PathKey is used to derive the blinded node identity at each hop, while the OnionBlob carries the layered encrypted payloads, constructed the same way as payment, but using route blinding by default. Feature bits 38/39 (OnionMessagesRequired/OnionMessagesOptional) signal support during the init handshake.

Per-peer Actors

Rather than processing onion messages inline in the peer’s read loop, LND uses an actor-based architecture. During peer connection, after the init handshake, the LND node checks whether the remote side peer advertises feature bit 38/39 and, if so, spawns a dedicated OnionPeerActor:

// peer/brontide.go — Start()
if p.remoteFeatures.HasFeature(lnwire.OnionMessagesOptional) {
   // Start an actor primitive specifically for handling onion messages
   // for this peer.
   ref, spawnErr := p.cfg.SpawnOnionActor(p.cfg.ActorSystem, ...)
   // ...
}

When a type 513 message arrives, the read handler for the local node dispatches it directly to the actor with a fire-and-forget Tell:

// peer/brontide.go - readHandler
case *lnwire.OnionMessage:
     p.onionActorRef.WhenSome(func(ref onionmessage.OnionPeerActorRef) {
        ref.Tell(ctx, onionmessage.NewRequest(*msg))
    })

Decoding and Routing

The actor delegates the heavy lifting to processOnionMessage in hop.go. Onion messages use a separate Sphinx router initialized without replay protection since no funds are at stake:

// server.go - the onion message router uses a no-op replay log
sphinxOnionMsg := sphinx.NewRouter(nodeKeyECDH, sphinx.NewNoOpReplayLog())

The snippet below shows how LND determines action to take after it decodes the Sphinx packet and decrypts the blinded hop data using the path key. LND uses a sum type pattern to represent the result, either a forwardAction or a deliverAction, depending on whether we’re a relay or the final destination:

// onionmessage/hop.go - the routing decision
if isForwarding(packet) {    
    // For forwarding action, resolve nextNodeId either directly
    // or using a short channel Id (SCID)
    if routeData.NextNodeID.IsSome() {     
        nextNodeID = routeData.NextNodeID.UnwrapOrErr(…)   
    } else {     
        nextNodeID = resolver.RemotePubFromSCID(ctx, routeData.ShortChannelID…)   
    }
    return fn.NewLeft(forwardAction {…})
}
return fn.NewRight(deliverAction{payload: payload})

For forwards, a new OnionMessage with the updated path key and remaining onion blob is sent to the next peer via the PeerMessageSender interface. You can think of this like a postal sorting center. Each center checks the address and decides whether to forward the letter or deliver it. For deliveries, we’re the final destination, and the payload (including any ReplyPath and other TLV records) is handled.

The Opt-out Flag

LND also gives node operators the choice to opt out. It supports a `— protocol.no-onion-messages` flag. When set, the node doesn’t advertise feature bits 38/39, the actor factory is never created, and no per-peer actors are spawned; incoming onion messages are simply ignored. This lets node operators control their participation in message routing.

What Onion Messages Unlock

Onion messages, on their own, are a low-level building block, a way to get encrypted data from one node to another over the network. Their value becomes clear when you look at what can be built on top of them.

The most significant protocol development based on onion messages is BOLT 12, which introduces a native way for nodes to request and receive invoices directly over the Lightning Network, replacing the out-of-band invoice fetching we discussed earlier.

Today, if you want to pay a merchant, you usually have to fetch an invoice from a web server. That means leaving the Lightning Network and making a request over the internet. With BOLT 12, things work differently. A merchant can publish a small piece of information called an offer, which acts like a permanent payment endpoint. When a customer wants to pay, their node sends an onion message requesting an invoice. The merchant replies with the invoice using a reply path.

You can imagine this like ordering food at a restaurant using a private internal messaging system instead of calling an external phone line.

Everything happens inside the Lightning Network, improving privacy and reliability. Blinded paths and reply paths make this exchange possible while preserving privacy on both sides.

BOLT 12 is already supported in other implementations like CLN and Eclair, and its arrival in LND will be a meaningful step toward cross-implementation interoperability.

And offers are just the beginning. Onion messages provide a general-purpose transport layer that any application-level protocol can use. Node-to-node communication, custom application data, coordinated channel management, anything that currently relies on external infrastructure could potentially move onto the network itself, inheriting its privacy properties in the process.

What's most exciting about contributing to this in LND is how foundational the work is. Onion routing isn’t a feature end users interact with directly; it’s plumbing. But it’s the kind of plumbing that removes constraints. Today, building anything on Lightning that goes beyond a simple payment means reaching outside the network. Onion messages close that gap. The protocol surface area they open up is large, and we’re still early in exploring what’s possible.

Conclusion

Onion routing has always been a core part of Lightning’s privacy. Originally, it was designed specifically for payments. But onion messages extend the same idea to general communication.

By removing the payment‑specific requirements while keeping the privacy guarantees, onion messages allow nodes to exchange encrypted information across the network.

You can think of this as adding a private messaging system to Lightning’s infrastructure. Most users will never interact with it directly. But it quietly expands what the network can do.

And as developers continue experimenting with this new capability, we’re likely to see many new protocols built on top of it. In other words, Lightning may turn out to be not just a payment network, but also a private communication layer for the internet.

If you’re interested in following the progress in LND or contributing yourself, check the LND repo. The specification itself lives in BOLT 4. And if this post piqued your curiosity about how the pieces fit together, the best way to learn is to read the code.

References

• https://github.com/lightning/bolts/blob/master/04-onion-routing.md#onion-messages
• https://github.com/lightningnetwork/lnd/pull/10089
• https://github.com/lightningnetwork/lnd/pull/9868
• https://www.cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf

Global Majority, April 9, 2026 — 2025 was a pivotal year for us at Btrust, as it marked the start of what we believe will serve as the generational foundation for the organization and Btrust Builders for years to come.

Following a few years of experimentation, iteration, and learning alongside our communities, in 2025, all that work crystallized into a more wholesome, structured execution phase. We focused on strengthening our programs, partnerships, and internal systems that demonstrated the most real impact, rather than rolling out numerous new initiatives.

We centered our year on refining how we sustainably execute our mandate to support open-source developers across Africa and the broader Global Majority by carefully threading various independent pockets of developer communities into a unified system. Including increased focus on building long-term pathways that enable developers to discover Bitcoin, contribute to its open-source infrastructure, and have a meaningful global impact.

This review highlights what we built, what we learned, and how we are positioning Btrust for the years ahead.

Table of Contents

• The Btrust Mission
• 2025 Overview
• Building Across the Global Majority
• Btrust Builders
• Btrust Grants
• Spend Overview
• Btrust Activities & Ecosystem Engagement
• Operations & Ecosystem Growth
• Btrust in 2026

The Btrust Mission

Btrust exists to decentralize Bitcoin development.

Bitcoin, as a global technology, is designed to operate without centralized control. Yet, its development has, unfortunately, historically remained concentrated in a few regions, with many of the communities that rely most on it, particularly in Africa and the broader Global Majority, featuring on the outskirts of its developer ecosystem.

Btrust exists to help address this dilemma.

Created in 2021 as a blind, irrevocable trust funded by a 500 BTC donation from Jack Dorsey and Shawn Carter (Jay‑Z), we are ushering in a new paradigm in which Bitcoin is built by open-source engineers from regions that rely on it the most—the Global Majority. We initially focused on Africa as a foundational base and have since expanded our reach to Latin America and India.

In line with our mission’s founding ethos of decentralization, our original donors have no direct operational influence over the organization’s governance or activities.

2025 Overview

2025 was a defining year in the evolution of Btrust. Central to our work was the resolute focus on our core mission of decentralizing Bitcoin open‑source development by increasing participation from Africa and the broader Global Majority.

Doing this requires building a full ecosystem for open-source developers that streamlines learning, charts a clear path to impactful contributions, and supports their growth.

Throughout the year, we worked to strengthen this developer pipeline across several layers and focused on improving each part of this pipeline, we were able to scale our reach while maintaining the quality of the programs and support structures around them. The year was also fueled by deep collaboration with organizations across the broader Bitcoin ecosystem.

Across all programs and initiatives, Btrust engaged with more than 3,800 developers globally in 2025, reflecting growing interest in Bitcoin open‑source work across Africa, Latin America, India, and other parts of the Global Majority.

Overall, 2025 was less about rapid expansion and more about building a strong, resilient foundation. Btrust is now more well-positioned to support the growing global network of Bitcoin developers while continuing to strengthen the role of the Global Majority in shaping the future of Bitcoin’s open‑source ecosystem.

Building Across the Global Majority

Over time, we aim for Btrust to serve both as a starting point and a destination for Bitcoin developers across Africa. For many engineers, their journey into Bitcoin development begins through community initiatives, study groups, or programs such as Btrust Builders, where they first encounter the technical foundations of the protocol and the open‑source ecosystem surrounding it. These entry points help developers understand how Bitcoin works, how open‑source collaboration functions, and where they can begin contributing.

As developers traverse this path, Btrust is increasingly becoming a destination where they can deepen their work through mentorship, grants, and long‑term support, contributing to Bitcoin infrastructure. In this way, we are creating a continuous pipeline that moves developers from early curiosity to meaningful open‑source contributions and, in many cases, sustainable careers working on Bitcoin.

While Africa remains a core base for our work, decentralizing Bitcoin development requires building a broader network of contributors across the Global Majority. In 2025, we expanded our engagement in Latin America and India, where strong and growing developer ecosystems are already emerging.

In Latin America, Btrust supported developer education and open‑source initiatives through programs such as Librería de Satoshi’s Bitcoin for Open Source (B4OS) and Vinteum, which play a critical role in funding and mentoring open‑source Bitcoin developers across the region. In India, we continued our support for Bitshala, a developer education initiative focused on building strong technical foundations for engineers interested in contributing to Bitcoin.

Supporting these initiatives alongside our work in Africa helps terraform an interconnected developer ecosystem across the Global Majority. As developers in these regions collaborate, share knowledge, and contribute to the same open‑source projects, they collectively expand the global base of engineers shaping Bitcoin’s future.

Btrust Builders

The Btrust Builders program continues to serve as one of the most important entry points into Bitcoin open‑source development for engineers across Africa and the Global Majority.

Throughout 2025, the program expanded both in reach and structure, introducing more developers to the technical foundations of Bitcoin and helping them progress toward real open‑source contributions.

Across the Builders ecosystem and its different learning pathways and open‑source training programs, the initiative received more than 1,800 applications, reflecting the strong growth in awareness of Bitcoin development opportunities among engineers in emerging ecosystems.

For a closer look at the program, including its curriculum, mentorship structures, and the developers who participated throughout the year, check out the full Btrust Builders 2025 year in review blog to see everything the Builders community got up to.

Btrust Grants

Supporting the Bitcoin open-source ecosystem financially remains one of the most important parts of Btrust’s mission.

Open‑source development requires pouring in time and focus, and for many engineers in emerging ecosystems, contributing to Bitcoin infrastructure full‑time can be difficult without financial support. Btrust grants are designed to address this gap by providing developers and ecosystem initiatives with the resources needed to build, mentor, and educate within the Bitcoin open‑source ecosystem.

Developer Grants

In 2025, Btrust awarded over $2 million in grants, with 39.7% of funding going directly to developers contributing to open‑source Bitcoin infrastructure.

These grants supported developers contributing to a range of open-source projects across the Bitcoin ecosystem, including Bitcoin Core, the Lightning Development Kit (LDK), BDK, Rust‑Bitcoin, Stratum V2, BTCPay Server, and other tools that form part of the technical backbone of Bitcoin.

Across the year, 18 Btrust grantees contributed to 15 open‑source projects across the Bitcoin stack. Together, their work resulted in 431 commits, 222 merged pull requests, and 475 code reviews, helping strengthen and improve the tools that developers, businesses, and users rely on throughout the Bitcoin ecosystem.

We recently published a blog that breaks down the projects they worked on, the technical contributions they made, and the broader impact their work had across the Bitcoin stack.

In line with our mission to support developers working on open-source projects within the Bitcoin ecosystem, Btrust’s impact is also reflected in the growing adoption and recognition of open‑source infrastructure supported by our grantees. Through targeted funding and developer support, Btrust grantees actively contribute to critical Bitcoin projects that are widely used across the ecosystem.

As such, Btrust was endorsed as an Associate Member of the BDK Foundation, recognizing our role in enabling contributors working on the Bitcoin Dev Kit (BDK). Similarly, Btrust is recognized as a Supporter and Funder of Stratum V2, as highlighted on the Stratum V2 website, following sustained contributions from our grantees to the protocol’s development. These recognitions highlight our broader impact across multiple layers of the Bitcoin stack, as we strengthen Global Majority representation and long‑term stewardship of Bitcoin’s core infrastructure by backing developers whose work directly advances the network's decentralization, security, and resilience.

Education Grants

Alongside developer grants, Btrust also continued supporting the broader ecosystem through education grants.

Education grants were directed toward programs that train and mentor new Bitcoin developers in regions where technical resources are limited. These initiatives help expand the pipeline of engineers entering the Bitcoin open‑source ecosystem and strengthen long‑term developer capacity across the Global Majority.

Event Grants

Event grants focus on supporting conferences, workshops, and technical gatherings that bring developers together to collaborate, share knowledge, and showcase their work.

These events play an important role in helping developers build relationships, discover open‑source opportunities, and engage more deeply with the global Bitcoin community.

Together, developer grants, education grants, and event support form a comprehensive funding approach that strengthens both individual contributors and the broader ecosystem around them.

Spend Overview

Similar to 2024, the majority of Btrust’s spending in 2025 was focused on supporting developers and strengthening the ecosystem around them, as we believe that the health of an ecosystem is tied to the strength of communities, programs, and the resilience of the infrastructure that supports developers.

We supported initiatives that helped connect developers, expand technical communities, and surface new contributors across Africa and the Global Majority. These efforts ranged from grassroots developer meetups to international conferences.

BitDevs in Africa

In 2025, Btrust supported 13 active BitDevs locations across 9 countries, spanning West Africa, East Africa, and Central Africa. These are Bitcoin meetups that follow a Socratic seminar format, where developers gather to discuss recent developments in the Bitcoin protocol, Lightning Network infrastructure, and related open‑source projects.

All 13 BitDevs communities collectively hosted more than 70 meetups, bringing together approximately 1,900 developers in person.

BitDevs provides a space where engineers can learn collaboratively, stay informed about protocol developments, and begin participating in technical discussions that mirror those happening in more established Bitcoin developer communities globally.

To support the growing demand of BitDevs communities, we developed and released the BitDevs Playbook, an open resource designed to support organizers across the Global Majority. In it we document practical lessons from several years of supporting technical meetups across Africa and provide guidance on how to organize, sustain, and grow Bitcoin developer communities while maintaining the open, collaborative spirit that defines the BitDevs model.

Representation at Global Conferences

Another key component of our ecosystem work in 2025 involved participating in major conferences and developer gatherings across the world.

Over the course of the year, Btrust was represented at sixteen conferences across Africa, Europe, Asia, and Latin America. These events ranged from highly technical developer gatherings to broader open‑source and freedom‑technology conferences.

Btrust grantees played a leading role in these engagements, attending 10 conferences and speaking at 9 of them. Through talks, workshops, and technical discussions, they shared their work with the wider Bitcoin ecosystem while building relationships with maintainers, educators, and fellow contributors.

Alongside this, members of the broader Btrust team were present across these events to amplify awareness of our programs, connect with emerging developers, and highlight pathways into Bitcoin open‑source development through initiatives like Btrust Builders and our grants.

For many developers supported by Btrust, these conferences provided valuable opportunities to present their work publicly, collaborate directly with other contributors, and deepen their involvement in Bitcoin infrastructure.

Conferences are also key discovery points where developers first encounter Bitcoin open‑source development, and where Btrust can both support existing contributors and welcome new ones into the ecosystem.

The Btrust Annual Gathering

In November 2025, we hosted the Btrust Annual Gathering, where for the first time, we brought together Btrust grantees, alumni, and contributors from across Africa, India, and Latin America for the two-day event to reflect on the past year and plan for the next.

Over the two days, we held workshops, technical discussions, and strategic conversations about developer pathways, open‑source sustainability, and opportunities for deeper collaboration across regions. These surfaced several important insights around mentorship structures, contributor support systems, and the challenges developers face when building open‑source careers in emerging ecosystems.

More broadly, the gathering reinforced the importance of building stronger connections between developers working across different parts of the Global Majority and helped shape several initiatives that will continue into the coming years.

Btrust Developer Day

In 2025, our flagship one-day developer conference returned, this time in Mauritius, where it brought together approximately 265 developers, students, and ecosystem participants for a full day of technical learning and collaboration. The event featured more than twenty technical sessions alongside lightning talks, workshops, and product demonstrations focused on Bitcoin infrastructure and open‑source development.

Topics ranged from practical development workflows and Lightning node setup to emerging privacy technologies and new tools within the Bitcoin ecosystem.

The Btrust Developer Day also served as a platform for African developers to showcase their work to a global audience, with 538 viewers tuning in live and the replay now surpassing 1.1k views. It also created opportunities to engage directly with contributors and organizations across the global Bitcoin ecosystem.

Building a Global Developer Ecosystem

Taken together, all these activities reflect Btrust’s broader approach to ecosystem development. Supporting open‑source contributors requires more than funding alone; it requires strong communities, spaces for collaboration, and opportunities for developers to engage with the global Bitcoin ecosystem.

Through initiatives such as BitDevs meetups, conference participation, developer gatherings, and community playbooks, Btrust continues working to build the infrastructure that allows Bitcoin developer communities to grow organically across Africa and the wider Global Majority.

Operations & Ecosystem Growth

In 2025, Btrust strengthened its operational and communications foundations to better support Bitcoin development across Africa and the Global Majority. Internally, we improved financial, legal, and grant systems to reduce friction while maintaining transparency, alongside appointing Abubakar Nur Khalil as CEO to ensure leadership continuity and strategic focus. Externally, we expanded our presence across platforms including X, LinkedIn, Instagram, Nostr, YouTube, and media outlets, reaching millions through content that highlighted developer work, programs, and educational resources, bringing more builders into the Bitcoin open-source ecosystem.

Btrust in 2026

The work of decentralizing Bitcoin development is a long‑term effort.

As we look ahead to 2026, in building on our structures to ensure long‑term institutional resilience, we will prioritize governance improvements and increased board transparency as we navigate our first board cycling.

We will continue to deepen collaboration and coordination with ecosystem partners through even more structured partnership frameworks that support developer mobility between education programs, grants, and open‑source contribution opportunities.

Additionally, we are focused on expanding opportunities for female Bitcoin developers and building on our success in this arena. Through mentorship programs, education pathways, and grant support, we aim to make Bitcoin development more accessible for women across the Global Majority.

In 2025, we strengthened the foundations that make our work possible. The progress we have recorder across developer education, open‑source contributions, and global ecosystem growth reinforces our belief that a more geographically distributed Bitcoin development community is already emerging.

Our role is to continue supporting it.

Onwards!

Written by Sonkeng Maldini

Bitcoin is constantly evolving, and one of the recent developments attracting attention is Silent Payments.

In this post, we provide a simplified, high‑level explanation of how Silent Payments work, their advantages over existing approaches, and how they can be used in practice. We will also walk through a practical example of receiving and scanning Silent Payment outputs using Frigate and BDK.

(And yes, make sure there’s no noise around you before we start.)

What are Silent Payments?

Silent Payments are a protocol defined in BIP352 that introduce static payment addresses to Bitcoin. Compared to previous approaches, they offer several advantages:

• No on‑chain linkability
• No need for notification transactions
• Improved privacy for both sender and receiver, which is a fundamental aspect of Bitcoin

However, these benefits come with trade‑offs that we will discuss later.

Before Silent Payments, receiving payments privately required interaction between the sender and receiver for every transaction. To preserve privacy, the receiver would need to generate a fresh address and share it with the sender each time.

While effective, this approach can create poor user experience and operational challenges. For example, if you are collecting donations for a charity, you might need to run a service such as BTCPay Server to generate a new address for every donor in order to preserve privacy.

Silent Payments solve this by allowing the receiver to publish a single static address. From this address, a fresh, unique public key is derived for every transaction that sends funds to it. Although the same address is reused, only the sender and the recipient can identify the transactions associated with it.

To achieve this, the protocol relies on several cryptographic techniques, including Elliptic Curve Diffie‑Hellman (ECDH).

Elliptic Curve Diffie‑Hellman (ECDH)

This section briefly explains the ECDH cryptographic function and assumes some familiarity with ECDSA notation and concepts.

One of the key components behind Silent Payments is the ECDH key agreement protocol, which allows two parties to generate a shared secret.

Let's set up some context to better understand how the shared secret generation works:

• Alice (the sender) has a private key/public key pair: a * G = A , where a is private key, G the generator point
• Bob (the recipient) has a private key/public key pair: b * G = B , where b is private key, G the generator point

Now in order to generate the shared secret, Alice and Bob need to exchange their public keys: A and B. Once Alice receives Bob's public key, she then computes a secret S = a * B likewise Bob computes S = b * A.

Since the shared secret computed should be the same, it meansa * B = b * A. Substituting B by b * G we get: a * (b * G) = b * A. Given the associativity of the elliptic curve scalar multiplication, we can write:  b * (a * G) = b * A , which proves the equation b * A = b * A!

Thus, both parties derive the same shared secret without revealing their private keys. This shared secret is the core mechanism used in Silent Payments.

Shared Secret Role in Locking Silent Payment Outputs

The shared secret is used to construct the public key that locks the transaction output.

Let's call the locking public key P. As defined in the BIP 352 specification, P = B + hash(a * B) * G, spotted the shared secret ? The resulting value of P is what will be put in the Taproot output of the transaction.

Notice that the locking equation has two B. Without the additional added B (means writing P = hash(a * B) * G) , coins locked by the public key (P) would still be spendable by either sender Alice (using her private key a) or recipient Bob (using his private key b).

For improved security, the protocol requires the first and the second B to be completely different values. The first one is called spend key,B_spend with its associated private key b_spend, and the second is now called scan key B_scan with it's associated private key b_scan. So the equation becomes P = B_spend + hash(a * B_scan) * G.

The reason for this is that the private key b of Bob will need to be exposed to an online device to check for incoming payments. In order to avoid any potential private key leak, the responsibilities are separated into two keys, one that's meant only for scanning and another for spending. We will see how that separation of concerns helps in the scanning section.

The combination of the spend and scan keys will now form what we call a silent payment address. An example Silent Payment address looks like this:  sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv.

This address is longer than traditional Bitcoin addresses because it encodes several components:

• A human-readable part and separator sp1
• The version 0 encoded as q
• Scanning and Spending public keys
• A checksum

There is much more to Silent Payments than what we have covered here. For a deeper technical explanation, the official BIP 352 specification provides further details.

How Silent Payments Compare to Other Approaches

• Using BIP 32 Extended Public Keys: By sharing the extended public key (xpub) of an entire bitcoin account, the sender can create new addresses on their own. This only solves the problem for single transaction partners at a time, though, because sharing a single extended public key with multiple entities would, again, be a major privacy compromise.
• BIP 47 introduces reusable payment codes that preserve privacy while removing the need for interaction for every transaction. However, sending funds requires a notification transaction to a notification address. This transaction includes additional data embedded in an OP_RETURN output, which adds complexity.

Scanning Silent Payment Outputs with Frigate Using bdk-sp (Experimental)

As mentioned earlier, the advantages of Silent Payments come with a trade‑off.

The receiver must scan the blockchain to detect payments sent to their address. This process can be expensive for lightweight clients, which may lack the resources to constantly scan the chain.

To mitigate this challenge, several approaches have been proposed in the Work In Progress index server specification for BIP 352. These include: remote scanner, Tweak server, and My Scanner (a personalized scanner).

A comparison between the different method from privacy to operational cost can be found here.

Frigate is an experimental Electrum server designed to test Silent Payment scanning using ephemeral client keys. It implements the remote scanner strategy.

Frigate builds on the traditional Electrum RPC protocol while introducing additional RPC methods that allow clients to request Silent Payment scanning data from the server. It uses efficient database indexing for fast queries and can optionally leverage GPU acceleration to reduce scanning time.

For this to work, the client must provide both the scan private key (b_scan) and the spend public key (B_spend).

These keys are never stored by the server. They exist only in memory during the scanning process, making them ephemeral.

For this practical we will use the bdk-sp experimental repository. It provides a wallet with support of sending and receiving SP transactions.

Setting Up the Environment

We first need to get everything up for running. Follow these links to install podman and just, which are required dependencies to make things work.

Afterwards, clone the repository:

git clone --depth 1 https://github.com/sdmg15/bdk-sp --branch feat/frigate

Once cloned head over the file frigate_playbook.sh. This file contains the necessary commands that we will need to executed in order to create and scan for outputs.

The playbook is self explanatory and organized into stages, with each stage containing several steps.

Stage 1: Setup

Let's follow the playbook and start by creating a silent payment output. The just non_nix_init command could take several minutes to complete depending, so take a cup of coffee in the meantime…

1. Install dependencies locally and setup regtest environment
- just non_nix_init
2. Check bitcoind is running on regtest
- just cli getblockchaininfo
3. Check bdk-cli wallet was created correctly
- just regtest-bdk balance
4. Check sp-cli wallet was created correctly
- just regtest-sp balance
5. Synchronize bdk-cli wallet
- just regtest-bdk sync

Stage 2: Fund bdk-cli Wallet

6. Get a new address from bdk-cli wallet
- REGTEST_ADDRESS=$(just regtest-bdk unused_address | jq -r '.address' | tr -d '\n')
7. Mine a few more blocks to fund the wallet
- just mine 1 $REGTEST_ADDRESS
8. Mine some of them to the internal wallet to confirm the bdk-cli balance
- just mine 101
9. Synchronize bdk-cli wallet
- just regtest-bdk sync
10. Check balance
- just regtest-bdk balance

Stage 3: Create a Silent Payment Output

11. Get a silent payment code from sp-cli2 wallet
- SP_CODE=$(just regtest-sp code | jq -r '.silent_payment_code' | tr -d '\n')
12. Create a transaction spending bdk-cli wallet UTXOs to a the previous silent payment code
- RAW_TX=$ (just regtest-bdk create_sp_tx --to-sp $SP_CODE:10000 --fee_rate 5 | jq -r '.raw_tx' | tr -d '\n')
- TXID=$(just regtest-bdk broadcast --tx $RAW_TX | jq -r '.txid' | tr -d '\n')
13. Mine a new block
- just mine 1
14. Once the new transaction has been mined, synchronize bdk-cli wallet again
- just regtest-bdk sync

Stage 4: Find a Silent Payment Output with Frigate

15. Now synchronize sp-cli2 wallet using frigate ephemeral scanning
- FRIGATE_HOST="127.0.0.1:57001"
- START_HEIGHT=1
- just regtest-sp scan-frigate --url $FRIGATE_HOST --start $START_HEIGHT
16. Check balance on sp-cli2 wallet
- just regtest-sp balance
17. Check balance on bdk-cli wallet
- just regtest-bdk balance

Replaying an Output of the Commands

If you reached this point, congratulations! You have successfully created and detected a Silent Payment output.

Conclusion

Silent Payments are an exciting development in Bitcoin’s privacy landscape. They allow users to publish static addresses while still receiving payments through unique, unlinkable outputs.

Research and development around Silent Payments are still ongoing. Developers are continuously exploring ways to balance privacy, efficiency, and usability.

If this topic interests you, consider exploring the ongoing discussions, reading the relevant BIPs, and contributing to the ecosystem.

References

1- https://github.com/bitcoin/bips/blob/master/bip-0352.mediawik

2- https://github.com/silent-payments/BIP0352-index-server-specification

3- https://blog.bitbox.swiss/en/understanding-silent-payments-part-one

4- https://github.com/sparrowwallet/frigate

5- https://github.com/bitcoindevkit/bdk-sp

Africa, April 1, 2026 — We're excited to announce our largest Btrust developer grant cohort to date. Ten outstanding Bitcoin open-source developers have been awarded grants, comprising six starter grant recipients and four open-source cohort members, including two renewals and two promotions from starter to long-term grants.

This cohort also marks a couple of firsts: support for Cashu development, and the inclusion of a dedicated research proposal within the open-source cohort. This builds on our existing support across the stack, from core protocol work to wallets, privacy tools, and user-facing applications.

These developers are working across vastly different critical areas of the Bitcoin ecosystem, from Bitcoin Core and Lightning infrastructure to wallet development, privacy protocols, and payment infrastructure. Their work strengthens Bitcoin’s open‑source foundations while expanding the global community of contributors from the Global Majority.

Starter Grants

The Btrust starter grant provides support for software engineers ready to contribute full-time to open-source Bitcoin development. It allows recipients to explore areas of interest, identify a focus for long-term contributions, and engage deeply with the global Bitcoin developer community with relevant support via mentorship and without financial constraints.

Starter Grant Recipients

Michael Ariwaodo

Project: Cashu

Michael is a software developer based in Nigeria with over four years of experience building financial software systems.

After participating in the BOSS program in 2025, Michael began contributing to the Cashu ecosystem, a Chaumian ecash protocol designed to enable fast and privacy‑preserving Bitcoin‑backed payments.

As our first Cashu developer grantee, his recent work includes improvements to Cashu TS and Cashu Nutshell, the reference implementation of a Cashu mint. His contributions have focused on improving mint reliability, removing obsolete legacy APIs, improving wallet compatibility, and aligning implementations with evolving Cashu protocol specifications.

With the starter grant, Michael will continue strengthening the Cashu ecosystem by improving mint safety and operability, completing the removal of deprecated protocol behavior, and expanding compliance with newer Cashu NUT specifications.

He will also introduce protocol compliance tests, improve cross‑implementation compatibility, and research potential interoperability between Cashu and emerging protocols and technologies such as Ark and Minmo.

Frankline Omondi

Projects: Bitcoin Core, bip353-rs

Frankline is a software engineer based in Kenya with experience in systems programming and open‑source infrastructure development.

He completed the BOSS program in 2025 and has since become an active contributor to Bitcoin Core. His work focuses on fuzz testing, networking, and validation logic within consensus‑critical components.

Frankline has contributed to Bitcoin Core’s fuzz testing infrastructure and QA assets, helping improve coverage and detect potential bugs earlier in the development process. He is also the author of bip353‑rs, a Rust implementation of DNS payment instructions with DNSSEC validation.

Through the starter grant, Frankline will dedicate full‑time effort to expanding fuzz testing coverage across key Bitcoin Core subsystems including P2P networking, net processing, and validation logic.

His work will include designing new fuzz harnesses, running long‑duration fuzzing campaigns to uncover edge‑case bugs, and improving documentation and tooling so that more contributors can participate in Bitcoin’s testing infrastructure.

John Osezele

Projects: Bitcoin Dev Kit (BDK), Rust Payjoin

John is a software engineer based in Nigeria with five years of experience building mobile applications across fintech and security platforms.

He is a co‑maintainer of the bdk‑dart project within the Bitcoin Dev Kit ecosystem. The project provides Dart bindings that allow Flutter developers to build Bitcoin wallets powered by BDK’s Rust implementation.

John has already contributed several improvements to the repository and has also contributed to the Rust Payjoin project as part of his journey into Bitcoin open source.

With the starter grant, John will focus on bringing bdk‑dart to production readiness. His work will include improving the stability of the bindings, maintaining compatibility with upstream BDK releases, and strengthening testing and CI infrastructure.

He also plans to build a complete open‑source reference wallet using Flutter and bdk‑dart to demonstrate how developers can build secure non‑custodial Bitcoin wallets using the toolkit.

Victor Chabunda

Projects: rust‑payjoin, UniFFI‑Dart

Chabunda, also known as Chavic, is a developer based in Zambia with nearly a decade of experience building software across multiple platforms.

He is the author of UniFFI‑Dart and a contributor to the rust‑payjoin project, where his work focuses on improving developer experience through cross‑language bindings and tooling.

Victor has played an important role in making Rust‑based Bitcoin libraries accessible to developers working in other programming languages by building robust Foreign Function Interface tooling and SDK integrations.

Through the starter grant, Chavic will focus on building first‑class .NET and C++ bindings for rust‑payjoin, improving documentation and developer tooling, and continuing development on UniFFI‑Dart.

He will also begin work on a transaction fingerprinting analysis tool that helps wallet developers detect privacy leaks in transaction construction and improve overall wallet privacy practices.

Shehu Muhammad Aliyu

Projects: Payjoin Dev Kit (PDK), Bitcoin Dev Kit (BDK)

Shehu is a software engineer based in Nigeria. He holds a degree in Computer Engineering from Ahmadu Bello University and graduated from the 2025 Btrust Builders Rust for Bitcoiners pathway.

Shehu has been actively contributing to the Payjoin Dev Kit (PDK), a project focused on improving bitcoin transaction privacy through collaborative transaction construction. His work has focused on strengthening persistence, improving code maintainability, and addressing protocol‑level security issues.

His contributions include migrating the Payjoin CLI database from Sled to SQLite for better reliability, fixing a potential session replay vulnerability, and improving time‑handling accuracy to align with BIP‑77 specifications. He has also contributed documentation improvements and developer tooling updates that make the project easier for wallet developers to adopt.

With the starter grant, Shehu will work full‑time on expanding Payjoin adoption across Bitcoin tooling. His work will focus on integrating PDK into the Bitcoin Dev Kit CLI, implementing ASMAP‑based relay and directory selection for improved network privacy, and improving reliability through better fallback mechanisms and testing infrastructure.

Sonkeng Maldini

Project: Bitcoin Dev Kit (BDK), Bitcoin Core

Sonkeng is a software engineer based in Cameroon with more than eight years of experience building complex software systems.

His early exposure to Bitcoin development began while working with custom forks of Bitcoin written in C++. Since then, he has worked on distributed trading systems and open‑source infrastructure projects while steadily contributing to Bitcoin‑related development.

Sonkeng has contributed to several projects including the Bitcoin Development Kit, Rust‑Bitcoin, and the Bisq MuSig protocol. He has implemented multisignature wallet features for MuSig and actively participates in code reviews across multiple repositories.

Through the starter grant, Sonkeng will focus on improving developer experience and contributing to new releases within the Bitcoin Development Kit ecosystem. His work will include maintaining fuzz testing infrastructure, contributing to upcoming BDK features such as DNS payment instructions (BIP‑353), supporting silent payments work, and participating in Bitcoin Core Review Club sessions.

He’s also the lead organizer of BitDevs Yaoundé meetups to help grow Bitcoin developer communities in Cameroon.

Long-Term Grants

The Btrust Open-Source Cohort offers long-term support to established Bitcoin open-source contributors, promoting a collaborative environment for sustained development.

Members receive funding paid monthly in bitcoin, mentorship, and peer support to deepen their work on critical Bitcoin open-source projects.

The cohort model aims to build a resilient, inclusive developer ecosystem, enabling contributors from the Global Majority to make meaningful, lasting impacts on Bitcoin's open-source ecosystem.

Long Term Grant Recipients

Chuks Agbakuru

Project: Lightning Dev Kit (LDK)

Chuks is a software engineer based in Nigeria and a former Btrust starter grant recipient who has become a core contributor to the Lightning Dev Kit ecosystem.

Over the past year he has worked extensively on LDK‑Node, contributing features such as support for human‑readable names through BIP‑353 and improvements to infrastructure stability and code reviews.

With this long‑term grant, Chuks will focus on researching and implementing splice batching for the Lightning Network. This work explores how multiple channel splice operations can be coordinated into a single on‑chain transaction, reducing fees and improving scalability for Lightning service providers.

His work will involve specification research, Rust implementation in rust‑lightning, and integration into LDK‑Node APIs.

Peter Tyonum

Project: Bitcoin Dev Kit (BDK)

Peter is a software engineer and maintainer within the Bitcoin Dev Kit ecosystem. Over the past year as a starter grant recipient, he has contributed extensively to bdk‑cli and related wallet infrastructure libraries.

His contributions include implementing hardware wallet support, persistent wallet configuration, compact block filter support, and upgrades to align with the latest BDK wallet APIs.

During the long‑term grant period, Peter will focus on developing a production‑ready Bitcoin Core RPC client library for BDK. This library will serve as a unified interface for interacting with Bitcoin Core across multiple BDK components.

He will also continue maintaining and expanding bdk‑cli, including adding multipath descriptor support and improving testing and reliability across versions.

Enigbe Ochekliye

Project: Lightning Dev Kit (LDK)

Enigbe is a Lightning developer based in Nigeria whose work focuses on Lightning Network infrastructure and research. She holds a Master's in Energy from the University of Auckland, where she completed graduate-level coursework in multivariable control systems, and a Bachelor's in Mechanical Engineering from Ahmadu Bello University. 

Over the past year she has contributed to the LDK ecosystem through code development, reviews, and technical research. Her work includes improvements to logging infrastructure, chain synchronization features, and infrastructure reliability across LDK components.

Under the renewed long‑term grant, Enigbe will pursue research into distributed control systems for Lightning Network liquidity management. Her work models Lightning as a multi‑agent dynamical system and explores how decentralized controllers can coordinate liquidity distribution across the network.

The project will combine theoretical research with practical implementation inside ldk‑node and simulation environments, contributing both academic insights and open‑source engineering improvements.

Enigbe is the first member of the Open Source Cohort to focus on research, expanding the scope of contribution within the program and highlighting the growing importance of research-driven work in the ecosystem.

Chukwuleta Tobechi

Project: BTCPay Server

Tobechi is an experienced software engineer, active BTCPay Server contributor, and the lead organizer of BitDevs Lagos.

During his previous grant period, he developed several major plugins including the Shopify Plugin V2, the Satoshi Tickets event plugin, and the Mavapay Naira Checkout integration. His work has expanded BTCPay Server’s usability for merchants and businesses around the world.

Through this renewed long‑term grant, Tobechi will continue expanding BTCPay Server integrations across e‑commerce platforms and accounting systems while strengthening the plugin ecosystem.

He also plans to develop additional integrations that support African payment rails and local currencies, helping businesses across the continent accept Bitcoin payments more easily.

Btrust Builders Alumni

Most of the recipients above are alumni of the Btrust Builders program.

The structured learning tracks they completed provided a strong foundation in Bitcoin fundamentals, hands‑on open‑source experience, and sustained mentorship from seasoned contributors.

Their progression from Builders graduates to funded grantees reflects the program’s mission to cultivate high‑potential developers across the Global Majority and prepare them for long‑term, sustainable careers in Bitcoin open source. Each grantee’s journey underscores what focused guidance, community collaboration, and opportunity can achieve when paired with dedication and talent.

Learn more and apply to join the next cohort of the Btrust Builders pathways here.

Applications for Btrust Developer Grants

Btrust developer grant applications are open year-round, with new recipients announced quarterly. If you’re a developer passionate about contributing to Bitcoin open-source development, we encourage you to apply.

Learn more about our grant programs and apply through our website.

Stay updated on our initiatives and future opportunities by following us on X, Nostr, Instagram and LinkedIn.

About Us

Btrust is a non-profit organization with a dedicated mission to decentralize the development of Bitcoin Open-Source Software. Our focus is on fostering developer talent in the Global Majority and supporting the free and open-source Bitcoin ecosystem.

Written by Abiodun Awoyemi

Table of Contents

1. Introduction to BIP326
2. Locktime Fundamentals: nLockTime vs nSequence
3. Fee Sniping: The Threat That Locktime Solves
4. How LockTime Defends Against Fee Sniping
5. The Taproot Connection: How MAST works
6. HTLC vs PTLC: Why Off-Chain Protocols Leak
7. The Privacy Gap: The Problem Before BIP326
8. BIP326: The nLockTime + nSequence Strategy
9. Code Implementation & Analysis
10. Conclusion

Introduction to BIP326

Since Bitcoin’s introduction by Satoshi Nakamoto, its scripting capabilities have evolved significantly. One of the most important upgrades is Taproot, introduced in BIP341, which allows a transaction output to commit to multiple spending conditions simultaneously using a structure known as a Merkelized Alternative Script Tree (MAST).

These transaction outputs are called SegWit V1 or P2TR (Pay-to-Taproot). The P2TR locking script can be unlocked via two distinct paths: a Key Path Spend, which uses an aggregated public key, or a Script Path Spend, where the spending conditions are organised into a script tree used to compute the Merkle root. It is this Taproot architecture that BIP326 builds upon to address a specific and previously overlooked privacy gap in off-chain protocols.

BIP326 defines how wallets should behave when spending Taproot outputs by leveraging the nSequence field in place of traditional nLockTime for anti-fee-sniping protection. The primary motivation is to improve the privacy and fungibility of off-chain protocols such that when on-chain wallets adopt this behavior, a Taproot spend with an nSequence value becomes indistinguishable from an off-chain settlement transaction that uses timelock, making it impossible for a blockchain analyst to tell the two apart.

In modern Bitcoin scripting, what makes BIP326 particularly powerful is that it requires no consensus change and no protocol upgrade; it can be adopted unilaterally by wallet software. By simply mimicking the nSequence behaviour that off-chain protocols already use, on-chain wallets begin contributing to an anonymity set that grows larger with every wallet that adopts it.

Locktime Fundamentals: nLockTime vs nSequence

Bitcoin supports two types of locktimes that control when a UTXO can be spent.

1. Absolute Locktime prevents a transaction from being mined until a specific block height or Unix timestamp has been reached. It is set at the transaction level via the nLockTime field and applies to the entire transaction. Bitcoin interprets nLockTime below 500,000,000 as a block height and at or above 500,000,000 as a Unix timestamp.
2. Relative Locktime defines a delay based on when a specific output was mined, rather than a fixed date or block height. Encoded at the input level via the nSequence field, it allows for granular control over each input independently. This functionality was introduced by BIP68, which repurposed the nSequence field to enable these relative constraints. BIP68 requires transaction version 2 and interprets the lower 16 bits of nSequence as either a block-based or time-based relative delay.

The nSequence field is a 32-bit value assigned to each transaction input. Under BIP68, it is parsed as follows:

1. Bit 31 acts as the disable flag; if set, the relative locktime is ignored.

2. Bit 22 determines the unit, distinguishing between block-height (0) and time-based (1) delays.

3. Bits 0–15, the lower 16 bits store the actual duration, allowing for a maximum value of 65,535 blocks or 65,535 intervals of 512 seconds each.

Bits 16–21 and 23–30 are currently undefined and reserved under BIP68.

Off-chain protocols such as Lightning Network channels and CoinSwaps commonly use relative locktime because they allow contracts to remain open indefinitely.

Since absolute locktime are still used and still necessary, BIP326 does not propose replacing nLockTime entirely, because it is backward compatible. Instead, it proposes that Taproot wallets keep using nLockTime but also frequently use nSequence, alternating between the two with a 50% probability.

Fee Sniping: The Threat That Locktime Solves

Fee sniping refers to the process of re-mining the last block in the chain to claim the fees of both the transactions mined in that block and the new high-fee transactions that entered the mempool since it was mined. Instead of extending the current blockchain, a miner ignores the last block and secretly attempts to mine an alternative version of it. If successful, the original block is orphaned and the attacker collects all its fees, including all other high fee transactions that arrived in the mempool after the original block was confirmed.

Fee sniping threaten two fundamental properties of Bitcoin which are:

1. Settlement finality: when miners can re-mine past blocks, users can no longer trust that confirmed transactions are irreversible. A transaction with 6 confirmations today could be reversed tomorrow, which undermines the basic promise that Bitcoin’s confirmation model makes to its users.
2. Miner incentive alignment: Bitcoin’s security model is built on the assumption that miners are always incentivised to extend the longest chain. Fee sniping breaks that assumption. When re-mining a past block is more profitable than building on the current tip, the economic foundation of the entire network is compromised. In other words, miner incentive alignment is the mechanism Bitcoin relies on, and network security is what collapses when that alignment breaks.

How LockTime Defends Against Fee Sniping

Most wallets set nLockTime to the current block height, ensuring that transactions are only valid in the next block. This prevents miners from reorganizing the blockchain to include high-fee transactions from the mempool into a re-mined past block during fee sniping. By limiting transaction inclusion to the latest block, the fee sniping attack becomes economically unviable. Today, most modern wallet implementations including Bitcoin Core, BDK, and Electrum set anti-fee-sniping locktime by default.

However, while nLockTime effectively prevents fee sniping, it introduces a privacy leak by making on-chain transactions distinguishable from off-chain settlements. BIP326 addresses this by proposing that Taproot wallets alternate between nLockTime and nSequence randomly, using each with equal probability. This provides the same anti-fee-sniping protection while making on-chain and off-chain timelocked transactions indistinguishable, enhancing privacy and fungibility across the network.

The Taproot Connection: How MAST works

The Merkelized Alternative Script Tree (MAST), originally the Merkelized Abstract Syntax Tree, allows a Bitcoin output to commit to multiple spending conditions simultaneously while revealing only what is strictly necessary at spend time. It uses a Merkle tree to summarise the collection of potential spending scripts, avoiding the need to include every script in the transaction while keeping all unused conditions completely hidden on-chain

Think of MAST as a tree where each leaf represents a spending condition or script path. For example, one leaf could be “Alice can spend after 100 blocks,” another could be “Bob and Alice can spend together cooperatively,” and another could be “Bob can spend with a hash preimage”. These leaves are hashed and paired together, working upward until they produce a single Merkle root committed inside the Taproot output. When spent, only the executed leaf is revealed on-chain and all unused script paths remain completely hidden.

In off-chain protocols like Lightning Network, when a channel is force-closed via the timelock path, only that branch is revealed. However, before BIP326, the nSequence value used in that timelock settlement acted as an immediate fingerprint. Regular on-chain wallets were not using nSequence, any nSequence value was an instant indicator of off-chain activity. BIP326 addresses this by formally specifying that all Taproot wallets should randomly alternate between nLockTime and nSequence for anti-fee-sniping protection, making on-chain and off-chain Taproot spends completely indistinguishable.

HTLC vs PTLC: Why Off-Chain Protocols Leak

Hash Time-Locked Contract (HTLC) is a script-based conditional payment constructs that secure payments across multiple hops using a hash lock and a time lock. To claim the funds, the recipient must produce a secret value (the preimage) that hashes to a predetermined hash within a specified timeframe, otherwise the funds are returned to the sender. The critical privacy problem with HTLCs is that the same hash is used across every hop in a payment route, meaning any routing node can correlate the payment end-to-end simply by recognising the same hash value appearing at each step.

Point Time-Locked Contract (PTLC) perform the same function as HTLCs but provide stronger privacy using elliptic curve point operations based on Schnorr Signatures. Instead of a hash preimage, a PTLC requires the recipient to produce a scalar value corresponding to a specific elliptic curve point to claim the funds. PTLCs use a different randomised point per hop, breaking the payment correlation that HTLCs expose and making it impossible for routing nodes to link individual hops into a single payment path.

When a Lightning channel is force-closed and an HTLC must be settled on-chain, the blockchain sees a hash value and preimage. A cooperative close, by contrast, reveals none of this — both parties agree on final balances off-chain and broadcast a simple transaction that looks like any ordinary Taproot spend. When a Lightning channel closes via PTLC cooperatively, the blockchain sees only a regular Taproot script. However, a timelock path closure reveals either OP_CHECKSEQUENCEVERIFY opcode in the script itself or an nSequence ​value in the transaction input.

Note: At the time of writing, the Lightning Network still uses HTLCs. PTLCs are a planned upgrade dependent on broader Taproot and Schnorr Signature adoption across Lightning implementations. BIP326 lays the groundwork today so that when PTLCs are eventually deployed, the anonymity set will already be large enough to provide meaningful privacy.

The Privacy Gap: The Problem Before BIP326

Before BIP326, off-chain protocols such as Lightning Network relied on Hash Time-Locked Contracts (HTLCs) which is script-based conditional payment constructs that, when forced to settle on-chain, revealed recognisable fingerprints that chain analysts could trivially identify and trace.

In a Lightning Network channel, when one party broadcasts their latest commitment transaction without the agreement of the other party, the HTLC is forced to settle on-chain. The transaction reveals recognizable fingerprints which are traceable. Chain analysts could trivially identify these transactions making them simple to spot and analyze. What was intended to be private has now become public.

Privacy in Bitcoin depends on transactions being indistinguishable from one another, when there is a large pool of transactions, it becomes significantly harder to single out any one of them. HTLCs produced a distinct script pattern such as hash preimage, timelock structure and multi-path constructs, that existed almost nowhere else on-chain, making the anonymity set small and unique. At that point, even users who never broadcast their channel activity are exposed and the moment a channel is forced to close, the entire payment history off-chain can become linkable on-chain, and what was meant to be private off-chain becomes an open record on-chain.

BIP326: The nLockTime + nSequence Strategy

BIP326 proposes that Taproot wallets randomly alternate between nLockTime and nSequence for anti-fee-sniping protection, using each with a 50% probability. This random alternation is the core of the strategy. When on-chain wallets behave the same way off-chain protocols do, the nSequence value that once acted as a fingerprint becomes indistinguishable from a regular wallet transaction.

To further protect transactions that may be delayed after signing, wallets should also apply a random look back with a 10% probability, subtracting a random value between 0 and 99 from the current block height. This ensures delayed transactions blend naturally into the broader transaction landscape without standing out as anomalies.

BIP326 does not replace nLockTime, rather it acknowledges that absolute locktimes remain indispensable. There are specific scenarios where nSequence cannot be used and nLockTime must be the fallback:

1. When any input is unconfirmed
2. When any input has more than 65,535 confirmations
3. When any input is not a Taproot output
4. When RBF is not set, because nSequence needs specific values to signal RBF and cannot simultaneously encode both RBF signaling and a relative locktime

In all these cases, the wallet must use nLockTime. nLockTime remains the universal baseline, it is reliable, broadly applicable and backward compatible, while nSequence is the privacy upgrade specifically for eligible Taproot transactions.

Code Implementation & Analysis

The following implementation is written in Rust in the bdk_tx crate. It applies BIP326 anti-fee-sniping protection to a transaction by randomly alternating between nLockTime and nSequence for eligible Taproot inputs. The implementation takes a mutable transaction, a slice of inputs, the current block height, RBF flag, and a random number generator as parameters.

Before any logic runs, a guard clause checks that the transaction version is at least 2, which is a requirement of BIP68. If the version is less than 2, the function returns a CreatePsbtError::UnsupportedVersion error immediately and halts execution.

if tx.version < Version::TWO {
    return Err(CreatePsbtError::UnsupportedVersion(tx.version));
}

The implementation then filters all inputs to identify eligible Taproot inputs, specifically those whose previous output script is a Pay-to-Taproot (P2TR) script. Non-Taproot inputs are excluded entirely because BIP326 is specifically scoped to Taproot outputs only.

let taproot_inputs: Vec<(usize, &Input)> = tx
    .input
    .iter()
    .enumerate()
    .filter_map(|(vin, txin)| {
        let input = inputs
            .iter()
            .find(|input| input.prev_outpoint() == txin.previous_output)?;
        if input.prev_txout().script_pubkey.is_p2tr() {
            Some((vin, input))
        } else {
            None
        }
    })
    .collect();

Next, the function evaluates whether any input forces a fallback to nLockTime. Three conditions trigger this fallback, each for a specific reason. An unconfirmed input forces the fallback because confirmations() == 0 means nSequence cannot encode a meaningful relative delay. An input exceeding 65,535 confirmations forces the fallback because nSequence only has 16 bits for block-based delays and the value would overflow. A non-Taproot input forces the fallback because BIP326 is explicitly scoped to Taproot inputs only.

let must_use_locktime = inputs.iter().any(|input| {
    let confirmation = input.confirmations(current_height);
    confirmation == 0
        || confirmation > MAX_RELATIVE_HEIGHT
        || !input.prev_txout().script_pubkey.is_p2tr()
});

If none of these conditions are met, the function uses a 50/50 random coin flip to decide between nLockTime and nSequence. Worth noting here is the !rbf_enabled condition, which forces nLockTime when RBF is disabled. This is because using nSequence for anti-fee-sniping on a non-RBF transaction could accidentally signal RBF, since RBF is indicated by nSequence values below 0xFFFFFFFE.

let use_locktime = !rbf_enabled
    || must_use_locktime
    || taproot_inputs.is_empty()
    || random_probability(rng, FIFTY_PERCENT_PROBABILITY_RANGE);

A unique aspect of BIP326 is the 10% lookback rule, with 10% probability, the locktime is set slightly in the past (up to 99 blocks back), rather than exactly at the current block height. This preserves privacy for transactions that are signed but broadcast with a delay. For example, transactions routed through high-latency privacy networks. Without this, a transaction signed offline and broadcast later would stand out because its locktime would be noticeably behind the current chain tip.

For the nLockTime path:

if use_locktime {
    let mut locktime = current_height.to_consensus_u32();

    if random_probability(rng, TEN_PERCENT_PROBABILITY_RANGE) {
        let random_offset = random_range(rng, MAX_RANDOM_OFFSET);
        locktime = locktime.saturating_sub(random_offset);
    }

    let new_locktime = LockTime::from_height(locktime)
        .expect("must be valid Height");
    tx.lock_time = new_locktime;
}

For the nSequence path, the same 10% lookback logic applies, but with an additional .max(MIN_SEQUENCE_VALUE) guard to ensure nSequence never reaches zero, which would disable the relative locktime entirely under BIP68. The saturating_sub call prevents integer underflow when subtracting the random offset from a small confirmation value.

else {
    tx.lock_time = LockTime::ZERO;
    let random_index = random_range(rng, taproot_inputs.len() as u32);
    let (input_index, input) = taproot_inputs[random_index as usize];
    let confirmation = input.confirmations(current_height);

    let mut sequence_value = confirmation;
    if random_probability(rng, TEN_PERCENT_PROBABILITY_RANGE) {
        let random_offset = random_range(rng, MAX_RANDOM_OFFSET);
        sequence_value = sequence_value
            .saturating_sub(random_offset)
            .max(MIN_SEQUENCE_VALUE);
    }

    tx.input[input_index].sequence = Sequence(sequence_value);
}

It is also worth noting that BIP326 protection is opt-in by design. In PsbtParams, the enable_anti_fee_sniping flag defaults to false, meaning wallet implementers must explicitly enable it. This reflects two deliberate design decisions working together: it avoids silently modifying transaction behaviour for callers who have not opted in, and it preserves full backward compatibility, ensuring that existing wallets and integrations continue to behave exactly as before without any forced migration.

pub enable_anti_fee_sniping: bool,
// Defaults to false

The implementation supports both std and no-std environments through conditional compilation.

Conclusion

BIP326, though simple in its mechanism, is profound in its implications. By randomly alternating between nLockTime and nSequence for anti-fee-sniping in Taproot transactions, it closes the last remaining forensic gap that chain analysts could exploit to identify off-chain protocol settlements on-chain. The privacy impact is a network effect, every Taproot wallet that adopts BIP326 enlarges the anonymity set that off-chain protocols like Lightning Network and CoinSwap depend on, improving fungibility and security for the entire ecosystem.

What makes BIP326 significant is that it requires no consensus change, no protocol upgrade, and no coordination between nodes. It is a wallet behaviour standard that any implementation can adopt. The anonymity set BIP326 depends on only grows if wallets act before Taproot usage patterns become entrenched.

BIP326 is not just a wallet policy recommendation, it is a foundational privacy primitive that the entire Bitcoin Layer 2 ecosystem depends on, and its full impact will only be realised as Taproot adoption, PTLC deployment, and wallet implementation converge toward a more private, fungible, and scalable Bitcoin.

References

1. https://github.com/bitcoindevkit/bdk-tx 
2. https://github.com/bitcoin/bips/blob/master/bip-0326.mediawiki 
3. https://learnmeabitcoin.com/technical/upgrades/taproot 
4. https://bitcoinops.org/en/topics/htlc 
5. https://www.bydfi.com/blog/learn/glossary/merkelized-alternative-script-tree-mast 
6. https://www.wallstreetmojo.com/hashed-timelock-contract 
7. https://bitcoin.stackexchange.com/questions/120922/what-is-fee-sniping

At its core, Bitcoin is sustained by people; developers who review code, fix bugs, debate tradeoffs, and quietly maintain the software that powers a global monetary network.

In 2025, Btrust’s support of open source development efforts were guided by a belief that when developers from Africa and the Global Majority are given sustained support, they can become long‑term stewards of Bitcoin’s open‑source infrastructure.

Towards the end of 2024, we welcomed a new Engineering Lead, marking a shift from early experimentation to deliberate scaling. In 2025, this translated into stronger systems, clearer expectations, and deeper technical engagement, all designed to support developer grantee impact.

This leadership transition catalysed significant structural improvements across two key programs:

• Btrust Builders Program: Our hands-on, technical training arm that mentors new African software developers and helps them make their first contributions to Bitcoin open source development.
• Btrust Grants Program: A support system for developers actively contributing to Bitcoin open-source projects, as well as events, conferences, and educational initiatives that deepen the Bitcoin open-source contributor ecosystem.

H1 2025: Foundation And Structural Improvements

The first half of 2025 focused on improving the systems that support developer grantees, from onboarding to funding decisions.

Strengthening The Developer Pipeline

Developers need time, mentorship, and structured learning environments to meaningfully contribute to Bitcoin's open-source ecosystem.

The Btrust Builders program serves as an important entry point into that pipeline, helping aspiring developers gain the technical foundations required to eventually contribute to Bitcoin open source projects and qualify for developer grants.

In 2025, Btrust Builders supported 493 developers across our five technical pathways, with more than 1,800 applications received from across Africa and beyond.

In addition, the launch of our first Open-Source Bootcamp marked a major milestone for us, where 40 top graduates from the Mastering Bitcoin and Bitcoin CLI pathways gained hands-on experience contributing to Bitcoin open-source projects including Bitcoin Core, BDK, Polar, BlueWallet, Rust-Payjoin, and BTCPay Server.

For a deeper look at the program structure and outcomes, read the full 2025 Btrust Builders year in review blog.

Reimagining The Btrust Developer Grants Process

We also restructured our grant review process by introducing clearer requirements and establishing a dedicated sub‑committee of experienced Bitcoin open‑source contributors.

This change reduced average review time from 4 months to under 2 weeks, making it easier for developers to access timely support, and brought greater transparency, consistency, and fairness.

H2 2025: Scaling And Deepening Impact

The second half of the year focused on optimising our processes and expanding opportunities for our highest-performing grantees.

Two of our long-term grantees, both Bitcoin Core contributors, under the Btrust Pull Partnership, were invited to the 2140 office in Amsterdam to gain experience working alongside other Bitcoin Core developers. We believe collaborative partnerships like these help bridge geographic distances in open-source communities and ensure that voices from the Global Majority are part of Bitcoin’s core technical evolution.

Meanwhile, our collective grantees made their own mark, authoring over 200 PRs across 15 Bitcoin open-source projects and publishing 7 articles on our blog, covering topics ranging from personal journeys into Bitcoin open-source to Bitcoin Core protocol development.

2025 Grantee Impact By The Numbers

Program Growth And Ecosystem Expansion

2025 was a significant year of growth for the Btrust developer grantee program, both in the number of contributors supported and the Bitcoin open-source projects they contributed to. Active grantees (starter and long-term) grew from 5 to 18, representing a 260% increase over the previous year.

At the same time, the program's geographic footprint expanded beyond its strong base in Nigeria to include Kenya, Uganda, Morocco, and Egypt, reflecting a growing pool of open-source Bitcoin talent across the continent.

Alongside this growth in contributors and geography, grantees also expanded the range of projects they contribute to. In 2025, Btrust grantees were actively contributing to 15 Bitcoin open-source projects spanning multiple layers of the Bitcoin stack, including protocol development, scaling infrastructure, privacy tools, and end-user applications. These projects include:

• Protocol/Base Layer: Bitcoin Core, Rust-Bitcoin, BDK, BDK-CLI, BitcoinJ
• Scaling Solutions: LDK Node, LDK Server, LND, Stratum V2, Polar
• Privacy & Wallets: BlueWallet, Payjoin, Coinswap, BTCPay Server, VLS

Aggregate Performance Metrics

Performance across all 15 projects for the 2025 period:

High-Impact Project Spotlights

The impact of our grantees was felt across multiple layers of the Bitcoin stack, from protocol improvements to end-user applications and the following sections highlight the specific projects, and technical areas where these contributions had the most impact.

Bitcoin Core Contributions

Our grantees represent a significant portion of the specialized workforce contributing to Bitcoin's base layer.

Key Metrics

• 364 PR reviews performed on Bitcoin Core, directly addressing the protocol's well-known review bottleneck
• 52 PRs merged with 43 commits
• 12 PRs currently open

Contributions Breakdown

• 7 New Features
• 15 Bug Fixes
• 12 Test Improvements
• 4 Refactors
• 5 Documentation Updates

Highlights of Bitcoin Core Contributions

• Schnorr Batch Verification: Eunovo implemented batch verification of Schnorr signatures, significantly improving validation speed
• Silent Payments: Eunovo integrated Silent Payments into Core; a major advancement for on-chain privacy. Sending and receiving support now available on Bitcoin Core GUI
• Mempool-Based Fee Estimation: Abubakar Sadiq Ismail introduced new fee estimation logic to reduce overestimation during volatile market periods
• Code Review of various projects (Cluster Mempool, Libbitcoinkernel and Mining interface)
• Bug fix: Abubakar Sadiq Ismail resolved an issue in the Bitcoin Core block template assembler.
• Brandon Odiwuor fixed TestShell initialization issues caused by symlinks resolution.
• Brandon added unit test to handle case where the CLI returns an empty string, ensuring it is correctly interpreted as None in RPC tests.
• Brandon made several CI updates, including:
  • Updating the asan-lsan-ubsan-integer-no-depends-usdt workflow to use the Mold linker for faster builds.
  • Removing bash -c from the CMake invocation and replaced it with eval for cleaner command execution.

Lightning Development Kit (LDK)

• Bitcoin Core Chain Synchronization: Enigbe integrated Bitcoin Core as a chain data backend via its REST API, enabling full block-level synchronization and providing node operators with an alternative to third-party Esplora/Electrum indexers.
• Configurable Logging Infrastructure:  Enigbe built a pluggable logging system targeting different backends, and giving integrators full control over observability in deployments.
• Multi-tier Data Storage Architecture:  Enigbe implemented a tiered KVStore system that separates critical channel state, ephemeral data, and disaster-recovery backups across independent storage backends, enabling safer, more flexible deployment.
• BIP-353 Integration: Chuks integrated BIP-353 into LDK-Node. This significantly improves usability by making it possible to securely send payments to Human-Readable Names.
• Replace-By-Fee (RBF) and Event-Driven Transaction Management: Rita rebuilt payment store synchronization from full-transaction polling to BDK's wallet event stream, then leveraged this event-driven architecture to implement fee-bumping (RBF) for unconfirmed on-chain transactions and automatic background rebroadcasting with configurable attempt limits.

LND (Lightning Network Daemon)

Work on LND included contributions aimed at improving usability, reliability, and development stability. Abdullahi Yunus contributed to several improvements, including:

• UX Improvements: Added pagination to wallet transactions
• RPC Updates: Updates to RPC, including an extension to pathfinding for routes and a tracking addition to htlc forwarding events.
• Persistence: Ensured node announcement configurations persist across restarts. Added a second-layer backup for channels via archives.
• Test Flakes: Participated in hunting and addressing various CI flakes

Validating Lightning Signer (VLS)

Contributions were also made to Validating Lightning Signer (VLS), focusing on reliability, security, and operational efficiency. Sulaiman Aminu Barkindo worked on several improvements, including:

• Infrastructure and Reliability: Led critical persistence layer upgrade from Redb 1.5 to 2.2.0 with seamless automatic migration, ensuring zero-downtime upgrades for production deployments across vls-persist and LSS components.
• Security and Fund Safety: Enhanced fund recovery and security by implementing comprehensive second-level HTLC tracking, fixing sweep transaction vulnerabilities in unilateral close handling, and establishing anchor channel recovery infrastructure for zero-fee HTLC channels.
• Performance Optimization: Streamlined core operations by eliminating redundant commitment validation checks and optimizing monitoring to track only spendable HTLCs, reducing resource overhead.
• Team Collaboration: Accelerated delivery through code reviews across multiple critical PRs in a small, high-impact team.

Bitcoin Development Kit (BDK)

Peter Tyonum worked on several enhancements to BDK, including:

• Hardware Wallet Support: Added native hardware wallet support to the BDK binary crate, demonstrating how users can bridge the gap between mobile apps and cold storage
• Worked on a minimal, experimental Bitcoin Core RPC client  for the Bitcoin Dev Kit (BDK), with a focus on data emission and strict type safety, with built-in support for multiple Bitcoin versions
• Added wallet config subcommand, which allows users to persist wallet configurations to a local configuration file for ease and reuse, improving the UX of the binary crate
• Contributed to shipping versions 1 and 2 of the CLI binary crate
• Introduced --pretty flag to the CLI to transform standard JSON or raw text outputs into human-readable ASCII tables
• Introduced a descriptor generator to the binary crate to help users create valid output descriptors without having to manually string together complex scripts.

Language Bindings for BDK (BDK-FFI)

Bitcoin Dev Kit BDK-FFI received several improvements from Itoro Ukpong, including:

• Enhanced the PSBT implementation to allow easier access to inputs and outputs. This improvement enables the sign method to return a mapping of input indices to the keys used for signing.
• Improved the user interface of the BDK-FFI Android sample app by enabling users to easily copy their generated Bitcoin addresses.
• Created a script that allows Windows users to build the BDK-FFI library locally on their windows machine.
• Added public_descriptor support to the wallet implementation.
• Added a wallet setup example for JVM binding.
• Tested new library releases and provided feedback, bug reports, and fixes for identified issues.

Bitcoinj library

Itoro Ukpong made several refactors and enhancements to the Bitcoinj library, including:

• Introduced a Kotlin module to the Bitcoinj project.
• Ensured version compatibility between the Kotlin and the versions supported by Bitcoinj.
• WalletTool: Created a design document outlining the structure and functionality of WalletTool subcommands.
• Contributed to the migration of WalletTool to a subcommand-based architecture.
• Removed deprecated Guava Joiner and Splitter utilities to modernize the codebase.
• Wallet refactoring: Contributed to ongoing wallet refactoring efforts, aimed at simplifying the core wallet class and aligning it with modern Java development practices.

Rust Bitcoin

Jamal Errakibi made several refactors and enhancements to the Rust Bitcoin library, including:

• Added a feature to align with Bitcoin Core policy by reducing the minimum non-witness transaction size from 82 to 65 bytes.
• Introduced a CoinbaseTransaction newtype to clearly distinguish coinbase transactions from other transaction types.
• Standardize BIP notation across the codebase to the BIP-XXXX format.
• Consensus Encoding improvements:
  • Added a new() constructor to CompactSizeDecoder.
  • Implemented CompactSizeEncoder and refactored WitnessEncoder.
• Added functional tests for assumeUTXO in Bitcoin core.

BTCPay Server

Tobechi contributed several integrations and plugins, including:

• Shopify Integration: Developed an open-source payment gateway enabling merchants to accept Bitcoin payments directly through their Shopify stores with zero fees. While the standalone Docker image has recorded over 1,000 direct downloads, the plugin is also used by hundreds of merchants running BTCPay Server on managed infrastructure platforms like Start9 and Voltage, indicating broader real-world adoption beyond direct downloads.
• Cal.com Payment Integration: Enabled Bitcoin and Lightning payments for appointments and bookings on Cal.com, an open-source scheduling platform. The implementation supports both Bitcoin and Lightning invoice payments
• Naira Checkout Integration with Mavapay: Created a plugin allowing Nigerian customers to pay in Naira while merchants receive Bitcoin. Recently expanded to include payout functionality supporting:
  • Nigerian Naira (any Nigerian bank)
  • Kenyan Shilling (bill payment, till number, account number)
  • South African Rand (South African banks)
• Satoshi Tickets Plugin: Built a plugin enabling event organizers, conference hosts, and community managers to sell tickets and accept Bitcoin payments via BTCPay Server. The plugin has so far been known to have been used in about 3 events and conferences, processing close to a thousand tickets, with millions of sats in transaction value.
• Payroll Plugin: Built a payroll plugin that enables businesses in Africa and globally to manage payroll and salary payments using Bitcoin via BTCPay Server. The plugin is currently used by multiple organizations, including BTC Inc, to execute recurring and bulk salary payments, moving significant volumes of bitcoin and supporting real-world, non-custodial payroll operations.

Looking Ahead: 2026 Priorities

In 2026, we intend to build on the momentum created by our developer grantees last year by:

1. Scaling the Btrust Builders program and grantee pipelines to onboard more contributors.
2. Strengthening Bitcoin Core’s contributor and review capacity by supporting and growing the pool of long-term open-source contributors.
3. Deepening technical contributions while ensuring high standards of code quality and mentorship.
4. Ensuring more cross-collaboration between Global Majority developer contributors.
5. Encouraging open-source project spearheading by Global Majority developer contributors.

At Btrust Builders, our work is grounded in the belief that Bitcoin’s open‑source ecosystem only thrives when contributors are supported not just to learn, but to stay, grow, and lead over time.

As interest in Bitcoin development continues to rise, we’ve learned that access alone is not enough. Developers need structure. They need clear expectations. They need guidance that meets them where they are, and a path that doesn’t disappear once a single program ends.

That’s exactly what the 2026 Btrust Builders Program is designed to deliver.

Many of the insights that shaped this year’s design are captured in the 2025 Btrust Builders Program Report. In 2026, we are building directly on that foundation with sharper clarity, stronger systems, and a deeper commitment to long-term contribution.

Our Vision for 2026

This year, Btrust Builders is being designed as a scaled, high-quality contributor pipeline. Our goal is to absorb large applicant volumes without sacrificing rigor or care. We aim to meet developers where they are through a mix of self-paced learning and guided support, while maintaining a clear bar for excellence. We are focused on producing developers who are genuinely ready to contribute to Bitcoin open‑source projects and, over time, become strong candidates for grants and long‑term ecosystem roles.

Equally important, we are committed to delivering a consistently excellent student experience across all cohorts while protecting the sustainability of our faculty and mentors through better tooling, clearer systems, and intentional cohort sizing.

What Success Looks Like in 2026

We are measuring success differently than before. Graduation matters, but so does retention. We care about how many developers continue after BOSS through structured pathways. We care about whether there is a clear progression from graduation to fellowship, and from fellowship to grants. We care about real open‑source output, including meaningful contributions and merged pull requests. We care about whether alumni are still contributing six to twelve months later. And we care deeply about faculty satisfaction and sustainability.

The Builders program in 2026 is not optimized for short‑term wins, but is designed for durable outcomes.

The Btrust Builders Architecture

The Btrust Builders program in 2026 operates as a connected, three‑layer system.

The first layer is the on-ramp: the Btrust Builders Pathways, focused on skill-building, strong foundations, and contribution readiness. The second layer is acceleration, which happens through the Open Source Fellowship; a selective, high-touch, contribution-driven experience. The third layer is outcomes, where contributors transition into grants, continued open‑source work, ecosystem placements, and an active alumni network.

Rather than treating these as separate programs, we’ve designed them as a single, continuous journey.

How the Builders Journey Works

Developers enter Builders either through open applications or via the BOSS challenge. BOSS is a high‑bar external one‑month challenge run by Chaincode Labs, and in 2026 and continues in 2026 to serve primarily as a filter and signal generator.

Once in the pathways, developers build the technical knowledge, tooling familiarity, and contribution readiness needed to engage meaningfully with Bitcoin open-source projects. Through consistent participation and performance, top contributors are identified and invited into the Open Source Fellowship. From there, developers who demonstrate sustained impact are well positioned for grants and long-term involvement in Bitcoin open-source work, ensuring continuity beyond short-term programs and strengthening the broader ecosystem. 

The Btrust Builders Pathways

The Btrust Builders pathways form the core learning engine of the program.

Each pathway is designed to help developers build confidence, skills, and contribution readiness at different stages of their journey. All pathways use a hybrid model that combines self-paced and shared learning with live, guided support. We work in small groups, assign chaperones, and set clear weekly expectations so developers always understand what success looks like.

Mastering Bitcoin

Mastering Bitcoin is an eight‑week beginner pathway focused on theory and conceptual understanding. It runs twice in 2026. Participants study Bitcoin fundamentals using Mastering Bitcoin: Programming the Open Blockchain, Third Edition by Andreas Antonopoulos.

Learning is structured around guided readings, discussion prompts, recorded walkthroughs, and weekly live Socratic discussions led by chaperones. Developers are also placed in small buddy groups to encourage consistency and collaboration.

The goal of this pathway is to build strong Bitcoin mental models and a solid conceptual foundation.

Learn Bitcoin from the Command Line

Learn Bitcoin from the Command Line is a seven‑week intermediate pathway that also runs twice in 2026. It focuses on practical interaction with Bitcoin Core through the command‑line interface.

Participants work through GitHub-hosted exercises, set up their development environments, and gain hands-on experience interacting with nodes, transactions, and the network. Learning is supported by structured materials, weekly live review sessions, and Socratic discussions. Where possible, submissions are automatically checked to reduce overhead and speed up feedback.

The goal is practical confidence with Bitcoin Core and contributor workflows.

Rust for Bitcoiners

Rust for Bitcoiners is a six‑week intermediate-to-advanced pathway running twice in 2026.. It is designed for developers preparing to contribute to Bitcoin open‑source projects written in Rust.

The pathway mirrors existing BTCdemy and Btrust Builders practical exercises, emphasizing consistency, code quality, and real contribution patterns. Developers work in small groups per chaperone, attend weekly office hours and mentor syncs, and complete a required capstone project.

The goal is Rust proficiency tailored specifically for Bitcoin open-source work.

Language Clubs

Language Clubs are six‑week intermediate-to-advanced pathways that also run twice in 2026. They focus on other key programming languages used in Bitcoin development, beginning with Python and C++.

Learning is structured and peer‑supported, using Exercism alongside Builders‑specific practical add‑ons. Developers work in small groups, receive mentor support, and complete a capstone project. Grading is lightweight, but consistency checks are strong.

The goal is fluency in Bitcoin-relevant programming languages.

The Resource Hub

In 2026, the Btrust Builders program will be supported by the Resource Hub.

The Hub is a continuously updated, always-on knowledge base that supports developers before, during, and after every program. It serves contributors at every stage of the Builders pipeline, reduces repeated questions, lowers onboarding friction, and reinforces open-source best practices and norms.

The Hub includes contribution cheat sheets, walkthroughs, and step-by-step guides for first pull requests, issue selection, reviews, and maintainer communication. It also features curated lists of Bitcoin open-source projects organized by language, stack, and contribution readiness, alongside environment setup guides, workflows, and both technical and non-technical articles.

Across the program, the Hub is referenced weekly in pathways, serves as the primary landing resource for BOSS developers, supports fellowship contribution workflows, and remains available to alumni as a long-term learning resource.

The Open Source Fellowship

The Open Source Fellowship is the centerpiece of Builders 2026.

It is a ten-week, selective program designed for top performers across all pathways. Fellows receive stipends, work with assigned mentors, and operate within small homegroups. They contribute to pre-approved open-source projects, participate in weekly standups and contribution reviews, and produce technical writing such as articles, walkthroughs, and documentation.

The fellowship culminates in a proof-of-work database that provides public visibility and serves as a clear signal to Btrust and partner funders.

By the end of the fellowship, developers are grant-ready, have a strong public contribution record, and are positioned for sustained open-source impact.

The 2026 Program Calendar

The 2026 calendar reflects the full Builders journey across the year.

• The year begins in Q1 with the BOSS challenge running from January 12 to February 12. From February 12 onward, BOSS candidates flow directly into Btrust Builders Pathways. The first cohorts of Mastering Bitcoin and Learn Bitcoin from the Command Line run from early March through late April.
• Q2 focuses on Rust for Bitcoiners and Language Clubs, running from May 11 to June 19.
• In Q3, the second cohorts of Mastering Bitcoin and Learn Bitcoin from the Command Line run from June through July. The Open Source Fellowship runs from August 3 to October 9.
• Q4 brings the second cohorts of Rust for Bitcoiners and Language Clubs from October 12 to November 20. The year closes with program review and planning in November, and the 2027 program plan launches in December.

This calendar is intentional. It creates multiple entry points, clear progression, and a steady rhythm of learning, contribution, and outcomes throughout the year.

Systems, Faculty, and Evaluation

The 2026 Btrust Builders Program is supported by improved systems and infrastructure. The LMS hosts all pathway materials, enables self-paced learning, and reduces administrative load through progress tracking, submissions, grading rubrics, and integrations with GitHub and Discord. The website and pathways pages clearly communicate the full pipeline, timelines, and outcomes.

Our faculty model includes a Head of Program, Head of Engineering, Faculty Members, Chaperones, and Fellowship Mentors, each with clearly defined responsibilities and time commitments. Evaluation across pathways uses a shared rubric focused on consistency, technical understanding, engagement, initiative, collaboration, and communication.

Alumni and Long‑Term Outcomes

Beyond learning and graduation, 2026 places explicit emphasis on long-term contribution and leadership.

By year-end, we will maintain a live internal database of Bitcoin open-source projects to improve contributor matching. We are launching an alumni contributor network with private channels and regular calls, building a curated alumni directory to support ecosystem visibility and opportunity matching, and documenting clear post-Builders pathways into mentorship, faculty roles, BitDevs leadership, and ecosystem coordination.

We are also introducing non-financial recognition systems and tracking alumni retention and impact at six- and twelve-month intervals.

Our goal is simple. Btrust Builders should not just train developers. We should retain contributors.

Join Us

If you’d like to learn more about the Btrust Builders program, explore the pathways, or apply, you can start here: https://btrust.homerun.co/btrust-builders-application/en 

If you’re not ready to apply yet, we encourage you to explore the Btrust Builders Resource Hub. It’s always available and designed to help you start learning, make your first contributions, and understand how Bitcoin open‑source development works.

About Us

Btrust Builders is Btrust’s comprehensive engineering program dedicated to training and funding African software developers to contribute to Bitcoin and Lightning open-source projects. The Builders program provides technical mentorship, community support, and structured pathways to sustainable Bitcoin development careers.