Written by Sulaiman Aminu Barkindo

For the past few weeks, I’ve been trying to understand the quantum computer risk and the options Bitcoin has at a technical level. I’ve gone through various sources, from reading post-quantum cryptography articles to following the bitcoin-dev mailing list and Delving Bitcoin.

This article is my way of stating what I’ve learned, where we are right now, what options exist, and why finding the right path forward isn’t as simple as it might first appear.

How Bitcoin's Cryptography Works and Where It Breaks

To understand the struggle for a solution, understanding the problem is very important. Bitcoin's cryptographic foundation has held for over 17 years. The Elliptic Curve Discrete Logarithm Problem (ECDLP) which is the security base for Elliptic Curve Digital Signature Algorithm (ECDSA) that Bitcoin originally uses, and the Schnorr signatures introduced in Taproot, are computationally infeasible to break with classical hardware — the best known attack, called square-root attack, would require computational effort on the order of 2^n/2 operations, which in the case of Bitcoin is 2^256/2 lying far beyond the reach of any general or special (not quantum) purpose computer that could realistically be built. Math is not the problem.

The problem is what happens when the math stops being the hard part.

Bitcoin uses ECDSA, which, unlike RSA that depends on Integer factorisation, ECDSA depends on ECDLP. Even more devastating, quantum computers were estimated to be able to break ECDSA with the same level of security as RSA faster, as it requires fewer qubits.

To mathematically represent the problem, say we have a public key P and a known generator point G on the curve:

With k being the private key scalar, recovering k from P and G is computationally infeasible. Because, for elliptic curve points, there is no division like there is in normal arithmetic. 

The best known attack on ECDLP known as square-root attack, with algorithms such as Pollard's rho and Baby-step Giant-step (BSGS) algorithms that both run in O(√n) complexity, which for Bitcoin's secp256k1 curve means roughly 2√256 which is 2^256/2 operations. Practically infeasible on any current hardware.

However, with Shor's algorithm, ECDLP can be solved in polynomial time. Given a public key P, a quantum computer recovers a private key k directly.

The threat does not target both symmetric and asymmetric crypto algorithms equally. In terms of symmetric algorithms like AES, the quantum threat halves the difficulty of breaking the algorithm, so what needs to be done as a countermeasure is to just increase the key size. For example, AES key size >= 256 should be what is used going forward. 

Looking at asymmetric algorithms, which fall broadly into three categories: integer factorization as used in RSA, the discrete logarithm problem (DLP) over finite fields, and the elliptic curve discrete logarithm problem (ECDLP) which is itself a special case of DLP over elliptic curve groups. Quantum computers' effect is devastating on these, and we need completely different algorithms that are resistant to quantum computing threats, which are called post-quantum cryptography algorithms.

The threat is not unique to ECDLP, For example, RSA, which secures most banking systems and the internet at large, relies on the integer factorization problem. Say n is a large public modulus, computed by multiplying two large primes p and q. 

It is easy to compute but computationally infeasible to reverse. In other words, recovering p and q from n is the hard problem. That is, n is publicly available for all to see, but factoring it to get the two primes that were multiplied to get n is computationally infeasible. The best classical algorithm, the General Number Field Sieve, runs in sub-exponential time but is practically infeasible for very large n.

What if factoring is no longer hard? Once an attacker recovers p and q, Euler's totient (ϕ) can be calculated using the formula:

And from the parameters ϕ(n) and the public exponent e, the decryption key d is easily recovered using modular inverse with the help of Extended Euclidean Algorithm (EEA):

This means, once the integer factorization is solved, the security of RSA collapses.

Interesting to note throughout this discussion is that the method for proving the security of cryptographic schemes is by making them public and having enough smart researchers, cryptanalysts, and organizations to try and fail at breaking them many times and for a long time. Because the assumptions are made public and well-defined, it can be monitored. The moment a meaningful break is discovered and disclosed, what has broken will be known immediately and what needs replacing. So making it public is both a feature and foundation.

What Quantum Computers Do Differently

Unlike classical computers that work with bits (0 or 1), Quantum computers work with quantum bits (qubits), which are capable of representing information in 0, 1, or both at the same time through superposition. It uses interference that manipulates the probability amplitudes of quantum states (superpositions) to amplify correct solutions and cancel out incorrect ones.

This does not mean quantum computers are universally faster. It only means quantum computers are exceptionally faster at solving specific mathematical structures. But for most tasks you will want to use normal classical hardware, as quantum computers are like special-purpose computers that are really good, particularly at breaking mathematical functions underlying integer factorization and discrete logarithm problems.

Why the Threat is Real Before the Machine Exists

A Cryptographically Relevant Quantum Computer (CRQC) that can execute Shor's algorithm at scale does not exist today. Opinions as to the timeline for its existence are divided; some believe it may be available within a decade, others two decades. The point of agreement is that we are traveling at a pace towards its existence.

Bitcoin transactions are public, and a large amount of bitcoin is secured using P2PK with visible public keys on-chain. Also, even with other kinds of outputs that are behind a hash, p2pkh address reuse can make them vulnerable. Because when Bitcoin is spent, the public key is revealed, and if the same address is reused to receive Bitcoin, either through change or external output, the public key for that was known from the first spend, and the Bitcoin in those addresses will be vulnerable to attack. This means the public keys can be collected, stored, and broken once quantum capability arrives. This is also called harvest now, decrypt later.

Major work has been ongoing in regard to standardization and discussions around migration and choice of signature scheme. As most cryptography students know, most of the current cryptographic schemes were standardized by NIST and this threat of quantum computing is no different, as NIST has been working on standardizing post-quantum cryptographic schemes since 2016, and after almost a decade, in 2024, it finalized two signature schemes. One lattice-based published as FIPS 204 and the other hash-based published as FIPS 205. 

The Bitcoin development community is also now more alert about the quantum computing risk and what it will take to perform migration. It is rare to receive an alert from engagements and discussions among developers and cryptographers in Bitcoin forums such as the bitcoin-dev mailing list and devlingbitcoin that does not involve quantum. The engagements have moved from theoretical to active engineering. See bip360 and bip361.

However, Bitcoin has some specific needs, which makes the answer to which scheme Bitcoin should adopt more complicated than it first appears.

What Bitcoin Actually Needs From a Signature Scheme

For us to evaluate any post-quantum scheme, we need to list out the needs of Bitcoin from a signature scheme so that we can evaluate each against these needs. Apart from being mathematically sound, any post-quantum candidate to be adopted by Bitcoin should satisfy the following:

Signature Size

The size of a signature is very important in Bitcoin, as every signature lives on-chain. This means a significant increase in the size of signatures will affect the number of transactions that can be fit in a block; affecting the number of transactions in a block will affect the efficiency of transactions. Since you can only fit in a small number of transactions, then more transactions will have to wait for the block to be confirmed before they are picked next. Currently, this is, on average, after 10 minutes, which is already a bit slow.

With the block only fitting a smaller number of transactions than it currently does, block space will become more expensive as demand for it will be higher. which will affect usage of the blockchain by ordinary users.

Lastly, full nodes will also be affected by demanding more node storage, making it more difficult for ordinary users to run full nodes and be independent.

Signing and Verification Speed

Verification of every transaction in every block is being done by each full node. A significant decrease in speed will affect node performance and create centralization where only highly resourced nodes can do well. This will go against Bitcoin's security model.

In regard to signing speed, it matters a lot, especially for payment channels like in the Lightning Network, which require quick state updates. If the speed decreases, we will experience higher latency in a flow that was built to be almost real-time.

Security Assumptions and Cryptanalytic Maturity

Bitcoin has over a trillion-dollar market cap. Therefore, it makes absolute sense to be conservative in changing anything that, if done wrong, can affect the savings of people that believe in it. This is how changes have been happening in Bitcoin with careful review, well-understood demands, and clear constructions.

Therefore, it is of high importance to ensure the signature scheme being adopted is battle-hardened and has gone through rigorous public scrutiny, and cryptanalysts have had as much time as they need to try and break the scheme, as trust in cryptographic schemes is built through failed attacks over time.

NIST has selected two signature scheme finalists, which means they are credible. The process ran from 2016 to 2024 and went through rigorous public attacks. A lot of early submissions were broken during that process. But we should still be conservative, as Bitcoin, holding over a trillion dollars in value, should be handled carefully.

Constant-Time Implementation

Constant time implementation is a security measure to prevent timing attacks, which are one of the side channel attacks where a system is exploited by measuring how long it takes to perform operations on different inputs.

A constant-time implementation of a post-quantum signature scheme is important, as Bitcoin's signing infrastructure may operate in an adversarial environment, and if the duration of a signing operation leaks information about the private key or even a few bits of the private key, hence the full private key can be recovered through statistical analysis, then the signature scheme being mathematically sound may not be as useful as it should have been. Also nowadays compilers are very smart and silently undo constant-time codes.

The Evaluation Criteria

As we will see, none of the two NIST finalist signature schemes satisfies all six cleanly.

The Candidates: ML-DSA and SLH-DSA

With Bitcoin currently having signature sizes between 64 and 73 bytes and 32 bytes public keys, both NIST signature scheme finalists have some drawbacks compared to Bitcoin's current scheme. The question is which tradeoffs Bitcoin is willing to accept.

ML-DSA (Dilithium)

This is built based on Module Learning With Errors (MLWE) which is a lattice-based assumption considered to be more conservative than NTRU style lattices. It also has a nice feature (rejection sampling over integers), which makes it easier to write constant-time code that protects against side-channel attacks. But the rejection sampling over integers does not mean developers should not be careful in implementation, because the rejection process itself may end up leaking information.

While ML-DSA has nice implementation security, it has a significant drawback in terms of signature size. With approximately 2,420 bytes, it's roughly 38 times larger than a Schnorr signature. Therefore, integrating it as it is on Bitcoin would affect the network's throughput; transaction fees would go up, and hardware requirements for running a full node would increase significantly. This means it may require rethinking Bitcoin's scaling roadmap entirely. 

SLH-DSA (SPHINCS+)

This was standardized by NIST in case of an emergency where some mathematician suddenly identifies a weakness with a lattice-based signature scheme. In that scenario, SLH-DSA will serve as a fallback. It carries the highest cryptanalytic maturity because its security relies entirely on hash functions like SHA-256 or SHAKE, which are some of the oldest primitives in cryptography. Furthermore, due to it being essentially just a massive tree of hashes, achieving constant-time execution is straightforward as there are well-vetted libraries.

With all the nice features and being an old primitive, it's still catastrophic when it comes to signature size, as the SLH-DSA signatures are massive, ranging from approximately 8,000 bytes to over 49,000 bytes. This means a single signature at the small end may be 126 times larger than Schnorr, which shows this is practically incompatible to be used as it is with Bitcoin's current architecture.

Why Neither Candidate Fits Bitcoin as It Stands

When we look at the two finalists together, a clear (maybe fortunate in a way that will make us innovate some more better ways for Bitcoin) pattern shows for Bitcoin: one scheme offers reliable implementation security, and the other offers a very strong mathematical foundation, but they are both destructive to the block size of Bitcoin and other resource constraints we have mentioned.

This is not a failure in research by the cryptography community. It shows the cost that comes with quantum resistance. The mathematical structures used by these schemes produce more massive signatures than classical signature schemes. Bitcoin will need to engineer around that and not expect a direct replace-in scheme.

Where the Research Is Pointing

Hope is not lost as the Bitcoin developer community has been discussing how to use those signature schemes with small to no devastating effect on the Bitcoin network itself. Currently the most promising path seems to be the Zero-Knowledge Proofs (STARKs) to compress the data. A block's worth of post-quantum signatures could be aggregated by miners into a single compact proof. This way, full nodes will not experience a lot of impact, as they will not need to download thousands of multi-kilobyte signatures. Combining this approach with output types like P2MR and the hash-based accumulator Utreexo would enable verifying post-quantum signatures without significantly affecting the block space.

This means also the weight of these signatures might eventually be moved off-chain or into some cryptographic summaries and still preserve Bitcoin's decentralization.

Conclusion

Cryptographically Relevant Quantum Computers do not exist yet. However, there has been a lot of progress in research towards ensuring its existence, and with the harvest now a decrypt-later attack, it becomes important to start working towards approaches and proposals for migrating existing systems that depend on asymmetric cryptographic assumptions of ECDLP and integer factorization. Bitcoin's security depends on the ECDLP which makes it vulnerable to quantum computer attack. Therefore, the question is no longer whether the Bitcoin community should think about post-quantum migration but when and how the migration can happen. 

However, migration of Bitcoin to a post-quantum signature scheme is not straightforward due to Bitcoin's strict limitations on signature size and computation resources. While the two NIST finalists, ML-DSA and SLH-DSA offer resistance to quantum threats, their large size would significantly affect the network under current architecture. 

Current discussions show there is light at the end of the tunnel. With STARK-based aggregation, P2MR and careful protocol upgrades can help reduce the overhead of the post-quantum signature schemes without sacrificing decentralization. The conservative approach to upgrading Bitcoin that kept the network secure for over 17 years should still be observed in updating its cryptographic foundation deliberately, publicly, and before the threat arrives.

References

Shor, P.W. (1994). Algorithms for Quantum Computation: Discrete Logarithms and Factoring. 35th Annual Symposium on Foundations of Computer Science, IEEE. https://arxiv.org/abs/quant-ph/9508027

Brumley, D. & Boneh, D. (2005). Remote Timing Attacks are Practical. Computer Networks, 48(5). https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf

Jancar, J. et al. (2020). Minerva: The Curse of ECDSA Nonces. IACR Transactions on Cryptographic Hardware and Embedded Systems. https://eprint.iacr.org/2020/728

Moghimi, D. et al. (2020). TPM-FAIL: TPM Meets Timing and Lattice Attacks. USENIX Security 2020. https://eprint.iacr.org/2019/1275

NIST (2024). FIPS 204 — ML-DSA, FIPS 205 — SLH-DSA, FIPS 206 Draft — FN-DSA. https://csrc.nist.gov/projects/post-quantum-cryptography

Wuille, P. et al. (2020). BIP-340: Schnorr Signatures, BIP-341: Taproot. https://github.com/bitcoin/bips

BIP-360: Pay to Quantum Resistant Hash (2024), BIP-361: Quantum-Resistant Migration Plan (2025). https://github.com/bitcoin/bips

Osuntokun, O. (2026). Post-Quantum BIP-86 Recovery via zk-STARK Proof of BIP-32 Seed Knowledge. Bitcoin-Dev Mailing List, April 2026. https://groups.google.com/g/bitcoindev/c/Q06piCEJhkI/m/Ly9J23FlAwAJ

Chaincode Labs (2024). Bitcoin and Quantum Computing: Current Status and Future Directions. https://chaincode.com/bitcoin-post-quantum.pdf

The BOSS Challenge may be over, but for this year’s finalists, the work has not stopped.

They are still opening pull requests, responding to reviews and building tools for Bitcoin and the Lightning Network. Some are improving the projects they started during the challenge. Others have moved into new repositories, found new problems to work on or started helping the next group of developers find their way into the ecosystem.

Together, their stories show that the most valuable part of a program like BOSS is not simply finishing a project, but leaving with the confidence, skills and community to keep going.

First, What is the BOSS Challenge?

Created by Chaincode Labs, the ₿OSS Challenge is a global program for developers who want to begin a career in Bitcoin open-source software. It is also one of the most technical and demanding programs of its kind.

Participants do not just watch lectures or follow tutorials. They write code, read Bitcoin specifications, debug failed implementations and work through exercises that require a real understanding of how Bitcoin works. They are expected to explore unfamiliar codebases, ask good questions and learn how to find answers on their own.

The program begins with a fully guided month of coding exercises and technical learning, with support from active Bitcoin contributors. After that first month, top performers are invited to continue for two more months of advanced mentorship with Chaincode Labs. During this stage, they work on proof-of-concept and portfolio projects and begin collaborating with established Bitcoin and Lightning projects.

The rest of the cohort moves into partner-supported activities, including Btrust Builders pathways, where they can continue developing their skills and engaging with the wider open-source community.

This year, we partnered with Chaincode Labs again to support developers from our talent pipeline and learning pathways who wanted to take part in BOSS.

Of the 623 developers who applied to the program through our pipeline, this feature follows eleven participants whose journeys stood out across the challenge, from portfolio builders and technical performers to developers who continued contributing after the program.

We had already seen what could happen after BOSS. Last year, alumni from the program went on to receive open-source funding from Btrust and the Human Rights Foundation. So we partnered with Chaincode Labs again, hoping to help another group of developers move from learning about Bitcoin to actively contributing to it. That is already happening.

Their Journeys Started Long Before BOSS

Although BOSS was a major step for these developers, it was rarely their first one.

Many arrived after taking part in programs such as Btrust Builders, Hack4Freedom, Chaincode seminars, Dada Devs, Africa Free Routing bootcamps, and GitHub’s All In Africa program. Some had studied Mastering Bitcoin. Others had learned to work with Bitcoin Core through the command line or developed their Python and Rust skills through structured language pathways.

Sharon Nkatha, for example, completed the 2025 Mastering Bitcoin Cohort by Dada Devs. She later went through the Btrust Builders Language Clubs cohort, where she focused on Python, before joining BOSS.

These programs did not make BOSS easy. What they did was give the developers a foundation to build on. They became more comfortable using GitHub, reading technical material, writing code and discussing difficult Bitcoin concepts with other people.

Just as importantly, they found communities that helped them stay on course.

Participants spoke about support from BitDevs Lagos, BitDevs Nairobi and BitDevs Kaduna. They mentioned mentors who pointed them towards the right materials, friends who helped them debug and peers who kept checking in when the workload became difficult.

That support mattered. Many of them were balancing BOSS with school, full-time work, exams, mentoring responsibilities and everyday life. The program required more than technical skill. It required discipline, patience and a willingness to keep going when the code did not work.

Learning That You Do Not Need to Know Everything

Before joining BOSS, several finalists thought they needed to understand every part of Bitcoin before they could contribute.

Abdullateef Mubarak was one of them.

Initially, I thought I had to understand absolutely everything about Bitcoin before I could even think about contributing. The BOSS Challenge completely changed that mindset.

He came to understand that Bitcoin is simply too broad for one person to master every part of it. Instead, a developer can choose an area, such as transaction formats, opcodes, wallets or the Lightning Network, and build useful knowledge there.

Abraham Ujah experienced a similar change.

The BOSS Challenge helped me realise there wasn’t even a facade at all. It helped me understand that Bitcoin open source is accessible to anyone willing to contribute and do meaningful work.

For Sharon, the change became real when she learned how to navigate repositories, open pull requests and respond to reviewers.

It transformed how I see it, from something intimidating and distant to something I can actively contribute to. I now know how to open PRs, respond to reviewers, and identify issues. Bitcoin open-source development feels like my space too.

That shift in confidence appears across the group, and is also visible in what they have done since the programme ended.

Where They Are Building Now

Abraham Ujah

Abraham came into BOSS with experience from Chaincode’s Bitcoin and Lightning seminars, the Africa Free Routing Lightning Developer Bootcamp, Rust for Bitcoiners and Bitcoin Core Principles. He had also contributed to Apache SedonaDB, where he learned how to turn written technical specifications into working code.

During the challenge, he built two Rust projects. Secure Fountain explores how Luby Transform fountain codes could reduce the storage demands of running a Bitcoin node. Memq is a high-performance bitcoin mempool query engine designed to support real-time fee estimation through gRPC and shared memory.

Abraham is now contributing to rust-bitcoin and rust-lightning. He is also on a path towards getting a grant. His goal is to make Bitcoin open source development his career.

Jolade Okunlade

Jolade stood out not only because of what she built, but because she kept showing up. She remained closely involved with her portfolio project, responded quickly to feedback and stayed active in the community throughout the programme.

Her BOSS project, dust-cleaner, is a Rust command-line tool that connects directly to Bitcoin Core and helps wallet users identify suspicious dust UTXOs. Dust attacks can weaken a user’s privacy if tiny outputs are later spent alongside other funds, allowing blockchain observers to connect addresses that may belong to the same person.

Dust-cleaner scans a wallet, identifies suspicious outputs and creates PSBTs that users can review, sign and broadcast themselves. The tool does not handle private keys or automatically broadcast transactions.

After BOSS, Jolade built GhostKey, which won first place at the 2026 Hack4Freedom hackathon in Lagos.

GhostKey is a non-custodial bitcoin inheritance tool built around a dead man’s switch. A holder can name an heir and set a check-in period while keeping control of the funds during their lifetime. If the holder stops checking in, the heir receives a way to claim the bitcoin directly.

Jolade is also building BitPilot, an interactive Bitcoin education platform, and contributing to the Lightning Dev Kit ecosystem.

Winterrdog

Winterrdog entered BOSS with general open-source experience but no earlier Bitcoin training program. He described the challenge as “DIY with no training wheels”, which suited the way he likes to learn; by entering difficult problems and creating structure for himself.

During the program, he often worked at night, setting aside several quiet hours to read, plan, implement and debug his solutions. Although he did not complete every exercise before time ran out, the experience gave him enough confidence to take on work that had previously seemed beyond him.

He contributed a backend stability fix to Saving Satoshi, helping the service handle periods of heavy demand more reliably. The patch was later merged.

He then began participating in the Bitcoin Core review process. In one review, his feedback helped improve the decision logic for a fix related to low file-descriptor limits on Unix systems, and he was credited as a co-author on the resulting change. He has since taken part in reviews across several Bitcoin Core pull requests and opened a pull request of his own.

Btrust also supported his travel and accommodation for Bitcoin++ Nairobi, helping him connect more closely with contributors in the wider ecosystem.

Abdullateef Mubarak

Abdullateef is completing his final year of university in Abuja while building a deeper understanding of Bitcoin infrastructure in Go.

His project focuses on PSBT v2 support for btcd. Partially Signed Bitcoin Transactions allow wallets, hardware signers and multisig coordinators to exchange the information needed to build and sign a transaction without sharing private keys. Abdullateef’s work supports both BIP 174’s PSBT v0 format and the newer PSBT v2 format described in BIP 370.

He designed the core parser, compact-size integer utilities and multi-version validation logic. He then brought the work into the btcd ecosystem through a pull request that is awaiting review.

Abdullateef has also been studying LND and reviewing pull requests to understand how the codebase fits together. He is expected to graduate in June 2026 and is preparing himself for deeper mentorship and a possible future open-source grant opportunity.

He has also been thoughtful about how he uses AI while learning. Rather than allowing tools to replace his understanding, he has focused on reading specifications, tracing the code and making sure he can explain the systems he is working on.

Aaliyah Junaid

Aaliyah came into BOSS after winning the 2025 Hack4Freedom hackathon. During the challenge, she began contributing to the Bitcoin Dev Kit ecosystem through work related to BIP 329 wallet labels.

BIP 329 proposes a shared format for importing and exporting labels for Bitcoin addresses, transactions and UTXOs. Without a common standard, users can lose useful wallet information when moving between applications.

Aaliyah researched the specification and worked on an example showing how developers could use bdk_wallet with the bip329 crate. The contribution changed direction during review and did not move as quickly as she hoped, but that became part of her introduction to real open-source work. Contributions can stall, scopes can change and review can require several rounds of learning and revision.

She has continued contributing to Polar and exploring Payjoin, Bitcoin privacy and Python-based projects. Her BDK work also remains part of her ongoing learning process.

Aaliyah has since returned to Hack4Freedom as a mentor. As an alumna and first-place winner from the Kaduna edition, she joined the Lagos edition to share practical advice with participating teams.

Usman Umar Garba

Usman first participated in BOSS in 2025 and returned in 2026 determined to go further. Before joining the program again, he had taken part in the Africa Free Routing Lightning developer bootcamp and worked as a frontend developer on BitTicket. He is also a member of BitDevs Kaduna, where he has continued learning alongside people interested in Bitcoin and Lightning development.

For his portfolio work, Usman chose Rust partly because he wanted to strengthen his skills in the language. He built the Lightning UTXO & Anchor Manager, a library and command-line tool for analysing the UTXOs held by Lightning nodes that use anchor channels.

Poor UTXO management can leave a node operator with fragmented funds or without suitable outputs for emergency fee bumping. Usman’s project explored how better wallet policies could help node operators prepare for high-fee periods and keep their Lightning infrastructure reliable.

He is now continuing to learn and has explored contributions to LND, Polar and other Lightning projects. He is also developing SatsFor, a Lightning-powered mobile application for instant, borderless creator tipping.

Ikechukwu Obunadike

Chukwu was one of the strongest technical performers during the first month of the challenge.

Before BOSS, he completed the Btrust Rust for Bitcoiners pathway and studied Mastering Bitcoin independently. He also became involved with BitDevs Lagos and helped organize a cryptography study group.

One of the habits that shaped his approach was learning without over-relying on AI. He focused instead on reading BIPs, following source code and building clear mental models of Bitcoin’s basic parts.

During the broader program period, he worked on the Bitcoin Dev Kit’s Android reference wallet. His pull request added the ability to sweep funds from an external WIF private key into a user’s wallet by scanning a QR code or pasting the key.

The work required him to enter an unfamiliar repository and learn Kotlin and Android tooling. Completing the pull request showed him that he could understand a new codebase well enough to make a useful change.

He has also been exploring automatically generated Rust RPC bindings for Bitcoin Core, which could make it easier for Rust developers to build applications that communicate with a Bitcoin Core node.

Chukwu’s recent direction is less publicly visible than that of some of the other developers, but his technical depth and interest in areas such as Taproot, cryptography and coin selection make him someone worth continuing to watch.

Susan Githaiga

Susan’s BOSS project was a Lightning anchor fee-bumping service. When a Lightning channel closes unexpectedly, its commitment transaction can become stuck if network fees rise. Susan’s project uses anchor outputs and Child-Pays-for-Parent, or CPFP, to help move those transactions towards confirmation.

Building the project required her to work across React, Node.js, Docker, Bitcoin transaction libraries, the mempool.space API and lnd’s gRPC interface.

What stood out about Susan was that she did not limit herself to her portfolio project. She also looked for other places where she could contribute, including the Bitcoin Dev Project website and the BTCPay Server Plugin Builder. Her merged work has included interface improvements, plugin-version features, navigation changes and search-engine optimisation.

Through her work with BTCPay Server, she also noticed a gap relevant to her home market in Kenya: there is no BTCPay Server plugin designed around M-Pesa. She hopes to explore that idea as she continues to understand the ecosystem and the needs of local merchants.

Susan also joined Sharon Nkatha, Rose Jane and Nelly Nakhero to build SiriScore, a pre-broadcast bitcoin transaction privacy analyser. SiriScore helps users identify possible privacy leaks before they sign and broadcast a transaction and offers practical ways to improve their on-chain privacy.

The project received an honourable mention at the 2026 Bitcoin++ Open Source Edition.

Susan’s journey has involved exploration. Rather than staying inside one project, she has tried different repositories, built across Bitcoin and Lightning and looked for problems that connect open-source software with the needs of everyday users.

Sharon Nkatha

Nkatha’s path into Bitcoin development included Dada Devs, and Btrust Builders and BitDevs Nairobi.

During BOSS, she contributed to Warnet, fixing a problem that prevented its bitcoin message inspection command from handling Tor onion addresses and other external peers. She found the cause, changed the peer-resolution logic and added test coverage. Her pull request was reviewed and merged.

She also built Know Your Coin History, a self-hosted bitcoin privacy tool. It allows users to trace their transaction history, label UTXOs and identify wallet-fingerprinting patterns without sending their transaction data to third-party services.

The project uses a Flask API, a React interface, Bitcoin Core and Electrum adapters, BIP 329 labels and an interactive transaction graph. Nkatha also implemented eight wallet-fingerprinting checks.

After BOSS, she began contributing tests to SeedSigner, covering PSBT parsing cases involving multisig transactions and wallet consolidation. Not every contribution landed, but she kept exploring, responding to feedback and learning how different projects approach review.

She has since started contributing to Braidpool and is progressing through the pipeline for possible open-source grant support.

Nkatha was also one of the four developers behind SiriScore, alongside Susan Githaiga, Rose Jane and Nelly Nakhero. Their honourable mention at Bitcoin++ 2026 marked another step in her growing focus on Bitcoin privacy.

Her journey has included mistakes, redirections and difficult feedback, but that is part of what makes it valuable. She has continued experimenting and showing up, even when the path was not straightforward.

As she put it:

Go for it! It will be hard, you will doubt yourself, but you will come out on the other side having done things you once thought were out of reach.

Irene Ufia

Irene built bip353-go, a Go implementation of BIP 353 DNS Payment Instructions.

Bitcoin payments still often involve copying long addresses that are easy to get wrong. BIP 353 allows a human-readable identifier such as ₿alice@example.com to resolve to bitcoin payment instructions stored in DNS.

Irene discovered that there was no Go implementation while working on another project. Instead of waiting for someone else to build one, she decided to do it herself.

The library includes payment-resolution logic, BOLT 12 TLV decoding, BIP 352 Silent Payment address parsing, DNS-over-HTTPS, Tor support, a command-line tool and a BIP 21 URI builder.

After BOSS, Irene has contributed to mpcium, an open-source multiparty computation wallet infrastructure project. Her contribution improved the project’s security by replacing static AWS credentials with the AWS Default Credential Chain. This allows the project to use keyless OIDC and IAM role authentication.

She is also exploring Neutrino, Lightning Labs’ privacy-preserving Bitcoin light client written in Go.

Irene’s story is a good example of how open-source projects often begin. She ran into a real problem, confirmed that the tool she needed did not exist and built it.

Cecilia Orji

Cecilia worked with Irene on the Bitcoin UTXO Observatory, a command-line tool that helps users identify suspicious dust UTXOs and decide what to do with them.

The tool can scan UTXOs through mempool.space or directly from Bitcoin Core’s local data. It checks them against known dust campaigns and suggests different actions, such as freezing, donating, consolidating or using CoinJoin. It can also create BIP 174 PSBTs for hardware wallets.

Cecilia focused on testing and reliability. She wrote tests for the audit engine, privacy strategy logic, PSBT creation and verification. While doing that, she found and fixed problems in the recommendation system. One example involved the tool suggesting CoinJoin for a UTXO that was worth less than the fee required to spend it. Cecilia changed the logic so the recommendation made more sense.

She also improved support for legacy P2PKH inputs, making sure hardware wallets could receive the full previous-transaction data they needed.

Cecilia is now exploring lndhub.go, a Lightning account backend written in Go. She is also interested in contributing to btcd and Lightning Labs’ Loop project.

One of her biggest breakthroughs during the program was learning to use bitcoin-cli directly. It helped her understand what Bitcoin Core was doing without relying entirely on third-party libraries or high-level abstractions.

For Cecilia, BOSS changed Bitcoin open source from something intimidating into something she could take part in directly:

It’s not rocket science. It might look intimidating from the outside, but once you start, you realize it’s very doable.

The Biggest Change Was Not Technical

The finalists learned about PSBTs, UTXOs, Taproot, onion routing, wallet labels, fee bumping, coin selection, Lightning infrastructure and more. But when they spoke about what BOSS changed for them, most did not begin with the technology.

They talked about confidence. They became more comfortable reading difficult specifications, working without step-by-step instructions, asking maintainers questions and receiving feedback on their code. They stopped seeing failed tests as proof that they were not ready and started treating them as part of the process.

Aaliyah put it simply:

It showed me that contributing is less about already knowing everything and more about being willing to learn consistently, ask questions, and stay curious.

Jolade had a similar realization when she successfully built and broadcast a bitcoin transaction from raw bytes. Before it worked, the network rejected several attempts because of mistakes in the serialization, scripts and signature hash.

When the transaction was finally accepted, nobody needed to approve her as a developer first.

Nobody vouched for the transaction. The system accepted it purely because the math and serialization were correct.

Susan felt that shift when her first BTCPay Server pull request was merged. Sharon felt it when a reviewer responded to her first contribution. Cecilia felt it when all the GitHub Actions for her final capstone turned green.

Those moments may look small from the outside, but they often mark the point where someone stops asking, “Do I belong here?” and starts asking, “What can I work on next?”

Community Made The Difference

None of these developers got here alone. Mentors helped them understand where to look without doing the work for them. Friends answered messages when they were stuck. Peers reviewed ideas, shared resources and reminded one another that struggling with difficult material was normal.

BitDevs communities in Lagos, Nairobi and Kaduna played an important role. So did Dada Devs, Africa Free Routing, Hack4Freedom and the Btrust Builders community.

These communities helped bridge the gap between learning and contributing. They gave developers somewhere to ask questions, meet contributors and become familiar with open-source work before entering larger projects.

They also created a cycle of support. Aaliyah returned to Hack4Freedom as a mentor after once participating herself. Cecilia and Irene supported each other through their learning programmes and then built a privacy tool together.

Susan and Sharon have also gone on to serve as mentors and facilitators for Dada Devs, helping more women develop the skills and confidence to explore Bitcoin open source. Having once benefited from learning communities themselves, they are now sharing what they know, helping participants work through technical challenges and showing the next generation of female developers that there is a place for them in Bitcoin.

Their involvement matters because representation is practical. It is easier for a new developer to imagine herself contributing when she can learn directly from women who are already opening pull requests, building Bitcoin projects and participating in technical communities.

Several other finalists are also reviewing pull requests, sharing resources and helping newer developers understand how to begin. Their journeys show that contribution is not limited to writing code. Teaching, mentoring, reviewing and creating welcoming spaces for new contributors are also part of building a healthy open-source ecosystem.

This is why community is not separate from technical development, but part of what makes long-term contribution possible.

People are more likely to keep going when they know who to ask, where to find support and that other developers have faced the same doubts. The strongest communities do more than help people enter the ecosystem. They give those people a reason to return, contribute and help someone else take the next step.

To African Developers Thinking About Contributing, Start

Bitcoin needs contributors in many areas. It needs people working on wallets, Lightning infrastructure, privacy, testing, security, developer tools, documentation, design, research and education.

You do not need to understand every part of Bitcoin before you begin. No one does.

Start with one programming language. Join a local BitDevs community. Complete an introductory pathway. Read a BIP. Reproduce a bug. Improve a test. Review a pull request. Fix unclear documentation. Build a small tool around a problem you understand, then keep going.

The eleven developers in this feature did not all start from the same place. Some already had years of software experience. Others began with a single introductory program. Some worked in Rust, while others used Go, Python, Kotlin or JavaScript. Many had to learn new tools because their projects demanded it.

What they shared was the willingness to learn, ask for help and attempt work that initially felt beyond them.

BOSS gave them a demanding place to practise those habits. Btrust Builders pathways and local communities helped many of them prepare for that opportunity. What they have done since the program ended shows why those learning and community networks matter.

Their journeys are still unfolding, but they already make one thing clear: African developers are not standing at the edge of Bitcoin’s open-source ecosystem. They are writing code, reviewing contributions, improving infrastructure and helping other developers find their way in.

That is what the BOSS Challenge is ultimately meant to support, not just the completion of a program, but the beginning of a long-term contribution to Bitcoin open source.

Walk into a BitDevs meetup for the first time and you may feel as though the conversation started before you arrived.

Someone might be discussing a recent change proposed for Bitcoin Core. A few minutes later, the group moved on to a Bitcoin Improvement Proposal, better known as a BIP, or a new idea for the Lightning Network. People ask questions, challenge assumptions, and debate the trade-offs.

There are usually no long presentations and no expectation that everyone will reach the same conclusion. Instead, the meetup is built around open discussion.

At first, it can be hard to understand what you are walking into. Is BitDevs a technical meetup, a study group, or simply a place to keep up with what is happening in Bitcoin?

In many ways, it is all three. But BitDevs is also something more: a place to learn with others, exchange ideas, meet potential collaborators, and become part of the wider Bitcoin open-source community.

And despite the name, you do not need to be a developer to attend.

How BitDevs Started

BitDevs began in New York City as a space for people interested in the technical side of Bitcoin to discuss new developments and learn from one another.

Since then, the idea has spread around the world. Independent BitDevs chapters now organize regular meetups in cities across different countries. Each community is locally run, but they share a similar goal of helping people understand and participate in the conversations shaping Bitcoin.

In Africa, BitDevs communities are now active in more than 15 cities across several countries. Btrust supports the largest network of BitDevs meetups on the continent, helping local communities create consistent spaces for learning, discussion, and collaboration.

Most chapters meet once a month, giving members a regular opportunity to reconnect, explore new topics, and keep up with developments across the Bitcoin ecosystem.

What Happens at a BitDevs Meetup?

BitDevs meetups usually follow a Socratic format. This simply means they are led by discussion rather than presentations or lectures.

The exact format may differ from one chapter to another. Some chapters focus entirely on a Socratic discussion, while others may include workshops, project demos, or beginner sessions. Each chapter adapts its meetup to the needs of its local community.

What remains the same is the core idea of BitDevs: creating an open, discussion-led space where people can explore developments in Bitcoin, ask questions, challenge ideas, and learn from one another.

Before each meetup, organizers often share an agenda containing recent topics from across the Bitcoin ecosystem. During the meetup, a facilitator introduces each topic and invites people to share what they know, ask questions, and examine the idea from different angles.

The goal is not for one person to stand at the front of the room and provide all the answers. It is for the group to think through the topic together.

That approach reflects how Bitcoin itself is developed. Open-source development rarely moves forward because one person has a perfect idea. Proposals are shared, questioned, tested, reviewed, and improved. Healthy disagreement is part of the process. BitDevs brings that process into the room.

You Don’t Have to Be Technical to Join

It is easy to assume that BitDevs is only for experienced programmers. After all, many discussions involve code, protocols, security, and other technical subjects.

But you do not need to write code, or understand every topic, to benefit from attending.

Designers, writers, researchers, educators, product managers, community organizers, students, and people who are simply curious about Bitcoin can all take part. Open-source projects need more than code. They also need clear documentation, thoughtful design, useful research, strong communities, and people who can explain complex ideas in simple ways.

A designer might learn about a usability problem in a bitcoin wallet. A writer may discover a technical idea that needs better documentation. A researcher might find an unanswered question worth exploring. A founder may meet someone interested in building a new project.

You are also allowed to attend simply to listen. Many regular BitDevs members began by sitting quietly, following the conversation, and looking up unfamiliar terms afterwards. Understanding develops over time. No one is expected to know everything before walking through the door.

Building Context Before Contributing

One of the biggest benefits of BitDevs is context. Before contributing to an open-source project, it helps to understand the problems people are trying to solve. You also need to know what has already been tried, why certain decisions were made, and what trade-offs contributors are considering.

Those details are not always easy to pick up from reading code or social media posts alone.

At BitDevs, you can hear people explain not only what is happening but also why it matters. You begin to understand how experienced contributors approach problems, evaluate proposals, and respond to disagreement.

That context is useful whether you eventually contribute to Bitcoin Core, Lightning, wallets, developer tools, research, education, design, or another part of the ecosystem.

BitDevs will not turn someone into an open-source contributor in one evening. What it can do is help build the habits that make long-term contribution possible: curiosity, careful thinking, consistent learning, and the confidence to ask better questions.

More Than Technical Learning

The conversations are important, but they are not the only reason people keep coming back. BitDevs also helps people build relationships.

At a meetup, you might:

• Debate an idea with people who see it differently
• Find someone who can help you understand a difficult topic
• Meet a partner or collaborator for a project
• Discover an open-source issue you can work on
• Get feedback on an idea you are exploring
• Learn about programs, grants, jobs, and hackathons
• Find a mentor, or eventually become one
• Become part of a community that supports your growth

Across Africa, members of BitDevs communities have gone on to join programs such as the BOSS Challenge and Btrust Builders. Some have won hackathons or started their own projects. Others have become full-time Bitcoin open-source contributors with support from organizations such as the Human Rights Foundation and Btrust.

Not everyone will follow the same path, and that is the point. A meetup can be the beginning of many different journeys.

How to Get the Most From a Meetup

Getting value from BitDevs has less to do with how much you already know and more to do with how you approach the experience.

Come Prepared, Not Perfect

Most BitDevs communities publish the agenda before each meetup. Spend a little time looking through it before you attend.

You do not need to understand every pull request, proposal, or research paper. Even reading a short summary can make the discussion easier to follow. Write down any terms or questions you want to explore.

The aim is not to arrive as an expert. It is to arrive curious.

Ask Questions

If something is unclear, there is a good chance someone else is wondering about it too.

Questions such as “What problem is this trying to solve?” or “Why is this approach controversial?” can help open up the discussion. Simple questions often bring the conversation back to the ideas that matter most.

If you are not comfortable speaking during your first meetup, that is fine too. Listen, take notes, and speak with someone afterwards.

Follow the Topics That Interest You

You probably will not understand or enjoy every discussion. Pay attention to the topics that stay with you after the meetup.

Go back to the proposal that caught your attention. Read more about the project someone mentioned. Look up the unfamiliar term you wrote down. Ask a member of the community where you can learn more. Those small moments of curiosity build knowledge over time.

Talk to People

Do not leave as soon as the final topic ends. Introduce yourself and tell people what you are interested in, even if you are still figuring that out.

You may meet someone working on a similar problem, looking for a designer, starting a study group, or preparing for a hackathon. Many useful collaborations begin with a simple conversation after a meetup.

Keep Showing Up

BitDevs makes more sense with time. The first meetup may introduce you to unfamiliar ideas. By the third or fourth, you may begin to recognize recurring debates, projects, and contributors. Eventually, you may find yourself asking questions, sharing what you have learned, helping newcomers, or working on a project of your own. You do not need to understand everything immediately. Consistency matters more.

Find a BitDevs Community Near You

BitDevs meetups take place monthly in communities around the world. Across Africa, there are chapters in more than 15 cities across several countries. Visit our website to find a community near you.

Follow your local chapter on social media and join its community channels to receive updates about upcoming meetups, discussion topics, and other opportunities.

Remember, you do not have to wait until you feel “technical enough”. Find a meetup, show up with an open mind, and start from where you are. One conversation may lead to a question, a collaborator, a project, or an entirely new direction.

At Btrust, we believe Bitcoin education is essential for a thriving open-source ecosystem.

Bitcoin open-source development grows when curious developers are given access to good learning materials, strong mentorship, projects, and the time and support to keep improving.

Btrust education grants exist to support programs that train developers, make Bitcoin knowledge more accessible, and create clear pathways into Bitcoin free and open-source software.

Through these grants, we continue to support initiatives that reduce barriers to learning and help more people in Africa, Latin America, India, and the broader Global Majority engage with Bitcoin development.

For this round, Btrust awarded $904,000 across five education programs:

• Hack4Freedom
• Summer of Bitcoin
• Bitshala
• Vinteum
• Librería de Satoshi & B4OS

These programs are different in structure, region, and audience, but they share one goal: helping more developers move from learning about Bitcoin to contributing to Bitcoin open-source projects.

Importance of Developer Education Programs

Bitcoin needs more contributors from more places. Many talented developers in the Global Majority want to work on Bitcoin but face barriers: limited local technical communities, fewer mentors, fewer opportunities to work on real open-source projects, and less access to funding that allows them to go deep.

Education programs help solve this. They create the first steps into the ecosystem. They teach technical foundations, expose developers to tools and repositories, connect them with mentors, and help them build proof of work.

The strongest programs do not stop at teaching. They create pipelines. They help learners become contributors. They help contributors become grantees, maintainers, educators, and full-time open-source developers.

That is the kind of long-term ecosystem we want to support.

Education Grant Recipients

Hack4Freedom 2026

Hack4Freedom is a female-focused Bitcoin hackathon and developer education program designed for software developers and aspiring engineers in the Global Majority.

The program started in Kaduna, Nigeria, last year, where it created a dedicated space for women developers to learn, build, and contribute to open-source Bitcoin and freedom tech projects. That first cohort showed what becomes possible when women are given the tools, mentorship, and confidence to move from learning into building.

The 2026 expansion will bring Hack4Freedom to different Global Majority cities, starting with Lagos. The edition brought together 38 women and produced 13 repo-backed open-source projects. Read more about the Lagos edition here.

Each two-week hackathon will combine expert-led workshops, mentorship, and project-based learning focused on Bitcoin, Lightning, Nostr, and eCash.

Hack4Freedom is important because it directly addresses one of the biggest gaps in the Bitcoin ecosystem: the underrepresentation of women builders, especially from regions where financial exclusion is most deeply felt. The program does not only teach participants about bitcoin. It helps them build real tools for real local problems, publish their work in the open, and begin seeing themselves as contributors to the broader Bitcoin FOSS ecosystem.

Summer of Bitcoin

Summer of Bitcoin is a global online education program that introduces university students to Bitcoin open-source development and design.

Since 2021, the program has received more than 40,000 applications from 74 countries. It has onboarded 280+ developers, with alumni now contributing to or working at bitcoin organizations and projects such as Alby, Fedi, Galoy, Vinteum, Blockstream, Zeus, BDK, and others.

The 2025 edition received 5,036 applications from 71 countries in just 15 days. From this pool, 68 interns from 9 countries were selected to work with 32 Bitcoin organizations. During the project period, interns contributed to more than 86 GitHub and GitLab repositories and submitted 413 pull requests.

The program begins with a structured Bitcoin learning bootcamp, followed by a mentored internship where students work directly on real Bitcoin open-source projects. Participants learn Bitcoin fundamentals, developer tooling, open-source workflows, and practical software engineering through direct contribution.

Summer of Bitcoin continues to be one of the largest and most consistent pipelines bringing young, globally distributed talent into Bitcoin FOSS. Its reach across India, Nigeria, Brazil, Egypt, and other Global Majority regions makes it a strong fit for Btrust’s mission of decentralizing Bitcoin development.

Bitshala

Bitshala is a Bitcoin developer education community in India focused on helping developers learn, collaborate, and contribute to Bitcoin open-source projects.

In 2025, Bitshala continued to grow as one of the most active Bitcoin technical education initiatives in India and Southeast Asia. Its work included study cohorts, weekly clubs, fellowships, starter grants, meetups, builder retreats, public conferences, and community support through Bitspace Bangalore.

Bitshala continues scaling its cohorts, fellowships, grants, meetups, and community support. Its goals include awarding more developer, design, and education fellowships; supporting starter and full-time grants; organizing more meetups; and expanding Bitspace as a hub for Bitcoin builders.

This year, Btrust approved Bitshala for long-term support. This is important because strong developer education programs need stability. Instead of spending energy every year on fundraising and reapplying, Bitshala can plan longer-term, support contributors more consistently, and focus on building India’s Bitcoin open-source developer pipeline.

Vinteum

Vinteum is a Bitcoin research and development center focused on growing open-source developer talent in Brazil and Latin America.

Its work combines education, mentorship, grants, research, and community infrastructure. Vinteum supports developers through programs such as the Bitcoin Dev Launchpad, fellowships, long-term grants, Mastering Bitcoin and Mastering Lightning seminars, technical workshops, BitDevs meetups, and Casa21, its physical Bitcoin developer hub.

Vinteum alumni are now contributing to or working with projects and organizations such as BTCPay Server, Floresta, BDK, Bitcoinfuzz, Boltz, Stratum V2, and others. The program also supports Brazil-originated open-source Bitcoin projects, including Floresta, bitcoinfuzz, and Krux.

Vinteum’s model is especially valuable because it does not rely on a single program. It creates a full ecosystem around developers: structured onboarding, technical community, physical collaboration space, fellowships, and long-term grants. This helps turn early interest into sustained contribution.

Librería de Satoshi & B4OS

Librería de Satoshi and Bitcoin for Open Source, also known as B4OS, form an integrated Spanish-speaking Bitcoin education ecosystem.

Librería de Satoshi provides foundational Bitcoin technical education, while B4OS supports more advanced developers as they move toward open-source contribution, mentorship, portfolio building, and full-time Bitcoin work.

Together, they have built one of the strongest Spanish-speaking Bitcoin developer pipelines in Latin America.

B4OS has also produced strong individual outcomes. Alumni and participants have gone on to contribute to Bitcoin Core, Mostro, BDK, SimLN, LNDK, SeedSigner, Silent Payments, and other Bitcoin-related projects. Some have received grants from organizations such as Spiral, HRF, BDK Foundation, and others, while others have moved into full-time Bitcoin roles.

The program’s model is to introduce learners to Bitcoin, help them build technical depth, move top participants into advanced open-source training, and support the strongest contributors as they transition into grants, jobs, or long-term FOSS work.

Btrust also approved Librería de Satoshi & B4OS for long-term support because the program has already shown that it can produce real contributors. With more stable funding, the team can focus less on yearly fundraising and more on scaling the pipeline, improving the platform, supporting contributors, and strengthening Spanish-speaking Bitcoin education across Latin America.

Education Grant Applications

Education grant applications are open all year round to programs that train developers and make Bitcoin technical education more accessible, especially across Africa and the Global Majority.

We support initiatives focused on Bitcoin open-source development, developer education, mentorship, and pathways that help software developers move from learning into meaningful contribution.

Programs interested in applying can find the full eligibility criteria, qualification requirements, application guidance, and submission details on the website.

Learn more and apply here.

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.

For many developers, the first step into Bitcoin is not a grant, a fellowship, or a full-time open-source role. It is a local meetup, workshop, hackathon, conference talk, or technical session where they see that Bitcoin is not only something to use, but something they can build on and contribute to.

Events help attract developer talent. They create entry points for people who are curious about Bitcoin. They give new builders access to mentors, peers, tools, and real technical conversations. They also give existing contributors a platform to share their work, find collaborators, and connect with people from different regions and communities.

Under our event grants, we support a broad spectrum of initiatives, from technical bootcamps and hands-on workshops to large-scale convenings. These gatherings help introduce new developers to Bitcoin and expand opportunities for deeper collaboration across ecosystems throughout the year and into the future.

For this first batch of 2026 event grants, we are supporting eight events:

• Adopting Bitcoin Cape Town 2026
• Africa Free Routing Lightning Developer Bootcamps
• Bitcoin++ Nairobi 2026
• Code & Chain Senegal
• The Genesis Workshop
• Dakar Bitcoin Days IV
• DevFest Kaduna 2026
• Bitcoin++ Seoul 2026

Event Grant Recipients

Adopting Bitcoin Cape Town 2026

Adopting Bitcoin Cape Town is South Africa’s leading bitcoin-only event focused on real-world adoption, circular economies, self-sovereignty, and grassroots bitcoin use in Southern Africa.

We’ve supported Adopting Bitcoin Cape Town since its inception, and in 2026 supported the event as the Honey Badger sponsor. The 2026 edition took place on January 30–31 in Cape Town. It brought together bitcoin builders, educators, developers, circular economy organizers, and adoption-focused communities from South Africa, the wider African continent, and abroad.

The event continued to serve as a regional meeting point for practical bitcoin adoption. It also created space for workshops, technical conversations, and community-led discussions around how bitcoin is being used in real life across Southern Africa.

The 2026 event also helped connect broader ecosystem activity, including bitcoin circular economy conversations, Lightning developer education, and satellite events focused on adoption.

For us, Adopting Bitcoin Cape Town remains important because it brings together the people building, teaching, using, and experimenting with bitcoin on the ground. It gives African builders a stage and helps connect local adoption work to the wider bitcoin ecosystem.

Africa Free Routing Lightning Developer Bootcamps

Africa Free Routing runs hands-on Bitcoin Lightning Developer Bootcamps across Africa. Each bootcamp is a five-day technical program where developers learn Bitcoin and Lightning fundamentals, understand channels and routing, work with Lightning infrastructure, and build Lightning-enabled applications.

We supported Africa Free Routing’s previous bootcamp series, which trained over 250 developers across eight bootcamps, seven cities, and six countries. More than 30 projects were built during the hackathon sessions, with some continuing beyond the program as active tools and businesses.

In 2026, Africa Free Routing expanded the program to reach more developers across the continent, with a goal of training over 300 new developers.

This program is important because it is deeply practical. Developers do not only learn what Lightning is. They build with it, test it, and leave with the confidence to continue working on Bitcoin and Lightning projects.

Bitcoin++ Nairobi & Seoul 2026

Bitcoin++ is the world’s leading Bitcoin developer conference series. It brings together developers, researchers, protocol engineers, educators, and open-source contributors for deeply technical events focused on specific areas of Bitcoin development.

In 2026, we are supporting bitcoin++ Nairobi and bitcoin++ Seoul.

Bitcoin++ Nairobi took place from June 17–19. It was the first bitcoin++ conference in Africa and the first-ever open source edition. For three days, developers, researchers, educators, and builders explored Bitcoin, Lightning, privacy, mining, open-source development, developer tooling, financial infrastructure, and the future of building on Bitcoin.

The event also hosted a hackathon, bringing together builders from Africa and around the world to work in public on practical Bitcoin software. The hackathon had 90 participants, 37 submitted projects, and nearly 10 million sats in prizes across the main competition and sponsor tracks.

Bitcoin++ Nairobi was especially important because it gave African developers an international stage. They were able to present their work, meet contributors from around the world, and connect with the broader Bitcoin developer ecosystem.

We are also supporting bitcoin++ Seoul, which will focus on privacy, one of bitcoin’s most important technical and social challenges. Privacy touches wallet design, transaction construction, surveillance resistance, self-custody, network behavior, and user safety.

Together, the Nairobi and Seoul editions create focused technical spaces where developers can go deep, share work, meet collaborators, and find pathways into long-term open-source contributions.

For us, supporting bitcoin++ helps connect developers from Africa and the Global Majority to global technical conversations, while also giving builders from these regions more visibility within the wider Bitcoin open-source ecosystem.

The Genesis Workshop

The Genesis Workshop is a hands-on technical workshop organized by OSGuild in collaboration with BitDevs Mauritius.

The workshop will take place in Mauritius, on July 25th and 26th, with Bitcoin open-source developers as guest facilitators.

The goal of the workshop is to help them make their first meaningful steps toward Bitcoin open-source contribution.

Participants will learn about Bitcoin development pathways, open-source contribution standards, project workflows, and how to engage with real projects. They will also be introduced to OSGuild’s contributor onboarding system, which supports mentorship, project coordination, and contribution tracking after the workshop.

The Genesis Workshop builds on the existing work of BitDevs Mauritius, which has organized recurring Bitcoin-focused technical meetups. This workshop turns that community momentum into a more structured contributor pipeline.

Code & Chain Senegal

Code & Chain is a developer-focused event series led by the Bitnob Developers Network. Its goal is to equip African developers with the skills and tools to build on Bitcoin infrastructure.

Over the past three years, the Bitnob Developers Network has hosted events across Africa, training developers through hands-on workshops, live coding sessions, hackathons, and technical talks. The network reports having trained 5,026 developers across seven African countries: Nigeria, Ghana, Uganda, Kenya, Benin Republic, Burundi, and Togo.

Btrust previously supported the Lagos edition, and we are excited to support the Senegal edition as the program continues expanding developer access to Bitcoin infrastructure across Africa.

Code & Chain helps developers move from learning to building by introducing them to practical tools for remittances, merchant payments, cross-border financial applications, developer SDKs, and open-source utilities.

DevFest Kaduna 2026

DevFest Kaduna is one of Northern Nigeria’s leading developer gatherings. For the 2026 edition, the organizers are introducing a bitcoin-only developer track focused on open-source Bitcoin development.

This track will take place ahead of DevFest Kaduna and will introduce developers to Bitcoin protocol fundamentals, Lightning development, running Bitcoin nodes, and contributing to open-source Bitcoin repositories.

By adding a bitcoin-only track to an established developer conference, the organizers can reach engineers who may not yet be part of the bitcoin ecosystem but already have the technical skills to contribute.

Dakar Bitcoin Days IV

Dakar Bitcoin Days is Senegal’s first bitcoin-only forum and one of the gatherings in French-speaking Africa.

Btrust supported Dakar Bitcoin Days last year and is returning to support the fourth edition, planned for November 6 & 7, in Dakar, Senegal.

The event brings together developers, students, entrepreneurs, educators, and bitcoin advocates for talks, technical demos, discussions, and hackathon activity. The upcoming edition will focus on building a roadmap toward a new decentralized payment system in Africa.

Dakar Bitcoin Days plays a key role in expanding bitcoin education and technical engagement in French-speaking Africa. It helps shift the conversation away from scams and speculation toward education, practical use-cases, and open-source contribution.

Connecting Events to Developer Pathways

Our work focuses on decentralizing Bitcoin development, especially across Africa and the Global Majority. To do this well, the ecosystem needs more than one pathway. Some developers need long-term education programs. Some need fellowships or grants. Some need direct mentorship. But before all of that, many developers need a first point of contact.

Events create that first contact. They help developers discover that Bitcoin is an active technical ecosystem with real open-source projects, real engineering problems, and real opportunities to contribute. They also create the social layer that open-source needs: trust, relationships, peer learning, and community memory. Each event in this batch plays a different role.

Events can help a developer:

• Understand bitcoin beyond price and speculation
• Meet active contributors and maintainers
• Learn how to run nodes, build with Lightning, or use Bitcoin developer tools
• Make a first open-source contribution
• Join a local technical community
• Find a mentor, project, grant, or fellowship pathway
• Present their own work to a wider audience

This is especially important in regions where Bitcoin talent exists but access to global networks is limited.

Event Grant Applications

Btrust event grants are open to events, conferences, bootcamps, workshops, hackathons, and technical gatherings that help grow the Bitcoin open-source ecosystem, especially across Africa and the Global Majority.

We support events that are developer-focused, bitcoin-aligned, and designed to create meaningful pathways into Bitcoin education, open-source contribution, technical collaboration, or community building.

Programs interested in applying can find the full eligibility criteria, qualification requirements, application guidance, and submission details on the website.

Learn more and apply here.

About Us

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.

Written by Rita Anene

If you've spent time in the Bitcoin developer space, you've probably heard of LDK, (the Lightning Development Kit).

LDK gives a great deal of control. You can decide how peers connect, how channels are configured, how keys are handled, and how data is stored. That flexibility is valuable when you are building something highly specialized.

But it can also be a lot. If your goal is simply to add Lightning payments to an app, you should not need to understand every layer of the Lightning protocol before you can receive your first payment.

That is where the project I contribute to, ldk-node, comes in. LDK Node is built on top of LDK, but it makes many of the difficult decisions for you. It has a smaller API, sensible defaults, and enough structure to be useful in a real application. You still get a Lightning node, but you spend less time assembling the infrastructure around it.

This article walks you through building a working Lightning node from scratch. By the end, you'll have a node that connects to a peer, opens a channel, handles the channel-ready event, receives a BOLT11 payment, sends one, creates a BOLT12 offer and pays one, and sends a spontaneous payment without an invoice. At each step, as you run the code, you'll see exactly what the node returns, building a real mental model of what's happening under the hood.

No prior Lightning implementation experience required. Rust familiarity and a working knowledge of Bitcoin and Lightning are enough to follow along.

What LDK Node Is, and What It Is Not

LDK (the underlying library) exposes a vast array of methods. This level of control is ideal for building systems that require custom peer management, exotic channel configurations, or strict key handling. However, it’s not the right tool when you simply need to embed a node in an app.

LDK Node reduces the API surface by making concrete choices on your behalf. BDK (the Bitcoin Dev Kit) handles the on-chain wallet, while chain data comes from Esplora, Electrum, or Bitcoin Core RPC. The state is persisted to SQLite, Postgres or the filesystem. Gossip is sourced from Lightning's P2P network or Rapid Gossip Sync, and entropy is derived from raw bytes or a BIP39 mnemonic.

You trade some configurability for speed of iteration. Those defaults cover most real use cases, and if you eventually need more control, the underlying LDK is still accessible.

It’s written in Rust and ships with UniFFI-based bindings for Swift, Kotlin, and Python if you are targeting mobile.

Prerequisites

Before writing any code, you need Rust installed. If you don't have it yet, install it with rustup:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Follow the on-screen instructions, then reload your shell environment:

source ~/.cargo/env

Verify the installation worked:

rustc --version
cargo --version

For a fully interactive experience with real payments between two nodes, you'll also need Polar. Polar is a desktop app that lets you spin up a local Lightning network with one click. If you don't have it installed, grab it from the Polar website to get two nodes running. The article uses Node A (the ldk-node we build) and Node B (a Polar-managed node) to demonstrate every payment direction.

Note: LDK Server is being added to Polar (PR #1374). Once merged, you will be able to use it directly as your local node backend, since LDK Server is essentially ldk-node with an RPC interface. It will also work as an onion-message-capable peer for BOLT12 offer creation.

Note: To create BOLT12 offers, your ldk-node needs to connect to an onion-message-capable peer. In Polar, this means adding a CLN node to your network. LND does not currently support onion messages, so offer creation will fail if CLN is not present.

With that in place, create a new binary project:

cargo new ldk_node_example
cd ldk_node_example

Cargo generates this structure:

ldk_node_example/
├── Cargo.toml
└── src/
    └── main.rs

Open src/main.rs and you'll find a default "Hello, world!" program. Everything that follows replaces it.

Project Setup

Add ldk-node and tokio to your Cargo.toml:

[dependencies]
ldk-node = "0.7"
tokio = { version = "1", features = ["full"] }

The full src/main.rs will be built up function by function throughout the article. Each section adds one function and main() calls them in order. By the end, you'll have a single file that compiles and runs as a complete working node.

Helper Functions: Printing Node State

Before writing any node logic, add two helper functions at the top of src/main.rs. These get called after each meaningful action so you can see exactly what the node knows at that point: channels, payment directions, statuses, and amounts all printed in one place.

use ldk_node::payment::{PaymentDirection, PaymentStatus};

fn print_channels(node: &ldk_node::Node) {
    let channels = node.list_channels();
    if channels.is_empty() {
        println!("[channels] none");
        return;
    }
    for c in channels {
        println!(
            "[channel] id: {} | peer: {} | capacity: {} sats | ready: {}",
            c.channel_id,
            c.counterparty_node_id,
            c.channel_value_sats,
            c.is_channel_ready,
        );
    }
}

fn print_payments(node: &ldk_node::Node) {
    let payments = node.list_payments();
    if payments.is_empty() {
        println!("[payments] none");
        return;
    }
    for p in payments {
        let direction = match p.direction {
            PaymentDirection::Inbound  => "INBOUND ",
            PaymentDirection::Outbound => "OUTBOUND",
        };
        let status = match p.status {
            PaymentStatus::Pending   => "pending",
            PaymentStatus::Succeeded => "succeeded",
            PaymentStatus::Failed    => "failed",
        };
        println!(
            "[payment] {} | {:?} | {} | {} msats | id: {:?}",
            direction,
            p.kind,
            status,
            p.amount_msat.unwrap_or(0),
            p.id,
        );
    }
}

print_channels shows every open or pending channel with its capacity and whether it's ready to route payments. print_payments shows every payment the node has seen, with direction, kind (bolt11, spontaneous, or onchain), status, and amount. You'll see both grow as the article progresses.

Building the Node

The entry point into ldk-node is Builder. You configure it, call build(), and get back a Node that manages everything from that point forward.

This article uses Bitcoin Core RPC as the chain source, which is what Polar runs under the hood. Open Polar, click on the Bitcoin Core node, and find the RPC credentials in the node settings panel. You'll need the host, port, username, and password.

Add this function to src/main.rs:

use ldk_node::Builder;
use ldk_node::bitcoin::Network;

fn build_node() -> ldk_node::Node {
    let mut builder = Builder::new();

    builder.set_network(Network::Regtest);

    builder.set_chain_source_bitcoind_rpc(
        "127.0.0.1".to_string(),  // RPC host from Polar
        18443,                     // RPC port from Polar
        "polaruser".to_string(),   // RPC username from Polar
        "polarpass".to_string(),   // RPC password from Polar
    );

    builder.set_gossip_source_p2p();

    builder.build_with_fs_store().unwrap()
}

On the network: Polar runs a local Regtest network by default, so Network::Regtest is the right choice. Working against Mutinynet or another Signet instead? Swap this to Network::Signet and use an Esplora endpoint with set_chain_source_esplora(). The full list of chain sources and store options is in the ldk-node docs.

On gossip: On a local Regtest network with Polar, P2P gossip is the natural choice. Rapid Gossip Sync is better suited for connecting to the public Lightning network, where bootstrapping from a snapshot is faster than crawling peers.

On entropy: This example uses filesystem-derived entropy for brevity. In a real application, you would generate a BIP39 mnemonic once, persist it, and reload it on every subsequent start. Generating fresh entropy each run gives you a different node identity and wallet every time, which is not what you want outside of throwaway tests.

On persistence: build_with_fs_store() persists node state to the filesystem. For production, you would likely prefer build_with_sqlite_store(), build_with_postgres_store(), or build_with_vss_store() depending on your storage requirements.

Starting the Node

Add a start_node function:

use std::sync::Arc;

fn start_node(node: Arc<ldk_node::Node>) {
    node.start().unwrap();

    let node_id = node.node_id();
    let funding_address = node.onchain_payment().new_address().unwrap();

    println!("Node ID:         {}", node_id);
    println!("Funding address: {}", funding_address);

    println!("\n[channels at startup]");
    print_channels(&node);

    println!("\n[payments at startup]");
    print_payments(&node);
}

node.start() launches the background threads that handle chain sync, peer connections, and event delivery. After that call returns, the node is live.

node_id() is your node's public key, the identity other peers use to find and connect to you.

onchain_payment().new_address() derives a fresh address from the BDK wallet. In Polar, send some Regtest BTC to this address using the Bitcoin Core node before moving on.

Now add main() and run it:

#[tokio::main]
async fn main() {
    let node = Arc::new(build_node());
    start_node(Arc::clone(&node));

    println!("\nFund the address above in Polar, then press Enter...");
    let mut input = String::new();
    std::io::stdin().read_line(&mut input).unwrap();
}

Run with cargo run. You should see your node ID, a Regtest address, and empty channel and payment lists.

Opening a Channel

With funds on-chain, add an open_channel function. You'll need Node B's pubkey and listening address from Polar. Click on Node B in the Polar interface and find them in the node info panel.

use ldk_node::lightning::ln::msgs::SocketAddress;
use ldk_node::bitcoin::secp256k1::PublicKey;
use std::str::FromStr;

fn open_channel(node: Arc<ldk_node::Node>) {
    let peer_pubkey = PublicKey::from_str("NODE_B_PUBKEY_FROM_POLAR").unwrap();
    let peer_addr = SocketAddress::from_str("127.0.0.1:NODE_B_PORT").unwrap();

    node.open_channel(
        peer_pubkey,
        peer_addr,
        100_000,          // channel capacity in satoshis
        Some(50_000_000), // push amount in millisatoshis (50,000 sats to Node B)
        None,             // channel config: None uses defaults
    ).unwrap();

    println!("Channel open request sent.");

    println!("\n[channels after open request]");
    print_channels(&node);
}

The push amount is worth pausing on. It’s the balance you hand to the peer the moment the channel opens. This gives Node B inbound capacity toward Node A from the start, meaning Node B can pay Node A immediately. Without it, all the liquidity sits on Node A's side, and Node B can't route anything back until Node A has spent some first. This trips up a lot of developers building their first integrations.

After open_channel() returns, the funding transaction has been broadcast but not yet confirmed. print_channels will show the channel with ready: false. That is expected. The channel becomes usable once the funding transaction confirms, which the event loop will signal.

The Event Loop

In a real application, the event loop is purely reactive. It handles what the node surfaces and nothing else. Payment initiation, invoice generation, user interaction, all of that happens elsewhere, driven by API calls or user input. The event loop just responds.

This is exactly how the code is structured here. The event loop runs on its own spawned task, always free to process events. main() drives the interactive flow separately, prompting you at each step.

Add the event loop function:

use ldk_node::Event;

async fn run_event_loop(node: Arc<ldk_node::Node>) {
    loop {
        let event = node.next_event_async().await;

        match event {
            Event::ChannelReady { channel_id, counterparty_node_id, .. } => {
                println!(
                    "\nChannel ready: {} with peer {:?}",
                    channel_id, counterparty_node_id
                );
                println!("\n[channels after ChannelReady]");
                print_channels(&node);
                node.event_handled().unwrap();
            }

            Event::PaymentReceived { payment_id, amount_msat, .. } => {
                println!(
                    "\nPayment received: {} msats (id: {:?})",
                    amount_msat, payment_id
                );
                // Persist the payment to your database before calling
                // event_handled(). Once acknowledged, the node moves on
                // and the event will not be re-delivered after a restart.
                println!("\n[payments after receive]");
                print_payments(&node);
                node.event_handled().unwrap();
            }

            Event::PaymentSuccessful { payment_id, fee_paid_msat, .. } => {
                println!(
                    "\nPayment succeeded (id: {:?}, fee: {:?} msats)",
                    payment_id, fee_paid_msat
                );
                println!("\n[payments after success]");
                print_payments(&node);
                node.event_handled().unwrap();
            }

            Event::PaymentFailed { payment_id, reason, .. } => {
                println!(
                    "\nPayment failed (id: {:?}, reason: {:?})",
                    payment_id, reason
                );
                // reason is a PaymentFailureReason that tells you whether
                // the failure was a routing problem, invoice expiry, and so on.
                // Useful for surfacing meaningful error messages to users.
                println!("\n[payments after failure]");
                print_payments(&node);
                node.event_handled().unwrap();
            }

            Event::ChannelClosed { channel_id, reason, .. } => {
                println!("\nChannel closed: {} ({:?})", channel_id, reason);
                print_channels(&node);
                node.event_handled().unwrap();
            }

            _ => { node.event_handled().unwrap(); }
        }
    }
}

Always call node.event_handled().unwrap() after every branch, including the wildcard. The node blocks on delivering the next event until you acknowledge the current one. Missing it in any branch means the event loop silently stalls the moment that event type arrives.

Receiving a BOLT11 Payment

Add a create_invoice function:

use ldk_node::lightning_invoice::{Bolt11InvoiceDescription, Description};

fn create_invoice(node: Arc<ldk_node::Node>) {
    let invoice_description =
        Bolt11InvoiceDescription::Direct(Description::new(String::from("coffee")).unwrap()).into();

    let invoice = node
        .bolt11_payment()
        .receive(
            10_000,               // amount in millisatoshis (10 sats)
            &invoice_description,
            3600,                 // expiry in seconds
        )
        .unwrap();

    println!("\nNode A invoice generated. Take this to Polar and pay it from Node B:");
    println!("{}", invoice);
}

The amount is in millisatoshis throughout. ldk-node works at millisat precision for everything payment-related.

bolt11_payment() has more methods than just receive(). You can create variable-amount invoices with receive_variable_amount(), hold invoices pending manual release with receive_for_hash(), and more. The full API is at docs.rs/ldk-node.

Sending a BOLT11 Payment

Add a send_payment function:

use ldk_node::lightning_invoice::Bolt11Invoice;

fn send_payment(node: Arc<ldk_node::Node>, invoice_str: &str) {
    let invoice = match Bolt11Invoice::from_str(invoice_str) {
        Ok(i) => i,
        Err(e) => {
            eprintln!("\nInvalid invoice string ({e:?}). Skipping payment.");
            return;
        }
    };
    match node.bolt11_payment().send(&invoice, None) {
        Ok(payment_id) => {
            println!("\nPayment sent to Node B (id: {})", payment_id);
            println!("Waiting for result in event loop...");
        }
        Err(e) => eprintln!("\nFailed to send payment ({e:?})."),
    }
}

ldk-node handles pathfinding, fee estimation, and retry logic internally. The payment_id returned here matches what you'll see in the PaymentSuccessful or PaymentFailed event, so store it if you need to correlate the outcome back to this call.

BOLT12 Payments (Offers)

BOLT12 introduces a different payment primitive called an offer. Unlike a BOLT11 invoice, an offer is reusable and does not expire by default. The payer fetches a fresh invoice from the offer each time they want to pay, so you share it once and it keeps working.

Add a create_offer function:

use ldk_node::lightning::offers::offer::Offer;

fn create_offer(node: Arc<ldk_node::Node>) {
    match node.bolt12_payment().receive(10_000, "coffee", None, None) {
        Ok(offer) => {
            println!("\nOffer created. Share this with the payer:");
            println!("{}", offer);
        }
        Err(e) => eprintln!(
            "\nCould not create BOLT12 offer ({e:?}). Make sure your node is connected to an onion-message-capable peer."
        ),
    }
}

To pay an offer, add a send_bolt12_payment function:

fn send_bolt12_payment(node: Arc<ldk_node::Node>, offer_str: &str) {
    let offer = match Offer::from_str(offer_str) {
        Ok(o) => o,
        Err(e) => {
            eprintln!("\nInvalid offer string ({e:?}). Skipping BOLT12 payment.");
            return;
        }
    };
    match node.bolt12_payment().send(&offer, None, None, None) {
        Ok(payment_id) => {
            println!("\nBOLT12 payment sent (id: {})", payment_id);
            println!("Waiting for result in event loop...");
        }
        Err(e) => eprintln!("\nFailed to send BOLT12 payment ({e:?})."),
    }
}

The outcome arrives the same way as BOLT11, as a PaymentSuccessful or PaymentFailed event in the event loop. The full BOLT12 API including variable amount offers and offers with descriptions is at docs.rs/ldk-node.

Note: Paying a BOLT12 offer end to end through Polar's UI is not currently supported. The send_bolt12_payment function is correct and will work against any compatible BOLT12 payer outside of this regtest setup.

Spontaneous Payments (Keysend)

Not every payment needs an invoice. Keysend lets you push sats directly to a node's public key without the recipient generating anything first. It’s useful for tipping, streaming payments, or any flow where waiting for an invoice adds unnecessary friction.

Add a send_spontaneous_payment function:

fn send_spontaneous_payment(node: Arc<ldk_node::Node>, recipient_pubkey: PublicKey) {
    let payment_id = node
        .spontaneous_payment()
        .send(5_000, recipient_pubkey, None)
        .unwrap();
    println!(
        "\nSpontaneous payment sent to Node B (id: {})",
        payment_id
    );
    println!("Waiting for result in event loop...");
}

One thing to keep in mind: keysend payments are not protected by a payment hash the recipient generates, which changes the trust model slightly compared to BOLT11. The recipient can't prove they were expecting the payment, and you can't prove they agreed to receive it. For most spontaneous use cases, this does not matter, but it's worth knowing before building a product on top of it.

Putting it all Together in Main()

Now update main() to wire everything together. The event loop runs on its own spawned task, so it's always free to process events. The interactive flow runs sequentially in main(), prompting you at each step. This mirrors how a real application works: the event loop reacts, the application layer initiates.

#[tokio::main]
async fn main() {
    let node = Arc::new(build_node());
    start_node(Arc::clone(&node));

    println!("\nFund the address above in Polar, then press Enter...");
    let mut input = String::new();
    std::io::stdin().read_line(&mut input).unwrap();

    let node_b_pubkey = PublicKey::from_str("NODE_B_PUBKEY_FROM_POLAR").unwrap();

    open_channel(Arc::clone(&node));

    // Spawn the event loop on its own task so it runs independently.
    // It will print events as they arrive without blocking main().
    tokio::spawn(run_event_loop(Arc::clone(&node)));

    println!("\nMine blocks in Polar to confirm the channel.");
    println!("Press Enter once you see ChannelReady printed above...");
    let mut input = String::new();
    std::io::stdin().read_line(&mut input).unwrap();

    // Step 1: Generate an invoice for Node B to pay (inbound payment)
    create_invoice(Arc::clone(&node));
    println!("\nPay the invoice from Node B in Polar, then press Enter when done...");
    let mut input = String::new();
    std::io::stdin().read_line(&mut input).unwrap();
    // PaymentReceived will have already fired and printed on the event loop task.

    // Step 2: Send an outbound BOLT11 payment to Node B
    println!("\nGenerate an invoice on Node B in Polar.");
    println!("Paste it here, then press Enter:");
    let mut invoice_input = String::new();
    std::io::stdin().read_line(&mut invoice_input).unwrap();
    send_payment(Arc::clone(&node), invoice_input.trim());
    
    // Step 3: Create a BOLT12 offer for Node B to pay
    println!("Press enter to create a BOLT12 offer for Node B to pay (inbound payment)...");
    std::io::stdin().read_line(&mut String::new()).unwrap();
    create_offer(Arc::clone(&node));
    println!("\nPay the offer from Node B in Polar, then press Enter when done...");
    let mut input = String::new();
    std::io::stdin().read_line(&mut input).unwrap();

    // Step 4: Send a BOLT12 payment to Node B
    println!("Press enter to send a BOLT12 payment to Node B...");
    std::io::stdin().read_line(&mut String::new()).unwrap();
    println!("\nGenerate an offer on Node B in Polar.");
    println!("Paste it here, then press Enter:");
    let mut offer_input = String::new();
    std::io::stdin().read_line(&mut offer_input).unwrap();
    send_bolt12_payment(Arc::clone(&node), offer_input.trim()); 

    // Step 5: Send a spontaneous payment to Node B, no invoice needed
    println!("Press Enter to send a spontaneous payment to Node B (no invoice needed)...");
    let mut input = String::new();
    std::io::stdin().read_line(&mut input).unwrap();
    send_spontaneous_payment(Arc::clone(&node), node_b_pubkey);

    // Keep main alive so the event loop task can finish processing.
    println!("\nWaiting for remaining events...");
    tokio::time::sleep(tokio::time::Duration::from_secs(10)).await;
}

Run with cargo run. After funding and opening the channel, mine blocks in Polar to confirm it. You'll see ChannelReady print from the event loop task. From that point, each payment step is driven by your input, and the event loop prints the result as soon as the node delivers it.

The Complete Main.rs

Here is the full file for reference. Every function is in place, main() drives the interactive flow, and the event loop handles everything the node surfaces on its own task.

use ldk_node::Builder;
use ldk_node::Event;
use ldk_node::bitcoin::Network;
use ldk_node::bitcoin::secp256k1::PublicKey;
use ldk_node::lightning::ln::msgs::SocketAddress;
use ldk_node::lightning::offers::offer::Offer;
use ldk_node::lightning_invoice::Bolt11Invoice;
use ldk_node::lightning_invoice::{Bolt11InvoiceDescription, Description};
use ldk_node::payment::{PaymentDirection, PaymentStatus};
use std::str::FromStr;
use std::sync::Arc;

// --- Helpers ---

fn print_channels(node: &ldk_node::Node) {
    let channels = node.list_channels();
    if channels.is_empty() {
        println!("[channels] none");
        return;
    }
    for c in channels {
        println!(
            "[channel] id: {} | peer: {} | capacity: {} sats | ready: {}",
            c.channel_id,
            c.counterparty_node_id,
            c.channel_value_sats,
            c.is_channel_ready,
        );
    }
}

fn print_payments(node: &ldk_node::Node) {
    let payments = node.list_payments();
    if payments.is_empty() {
        println!("[payments] none");
        return;
    }
    for p in payments {
        let direction = match p.direction {
            PaymentDirection::Inbound  => "INBOUND ",
            PaymentDirection::Outbound => "OUTBOUND",
        };
        let status = match p.status {
            PaymentStatus::Pending   => "pending",
            PaymentStatus::Succeeded => "succeeded",
            PaymentStatus::Failed    => "failed",
        };
        println!(
            "[payment] {} | {:?} | {} | {} msats | id: {:?}",
            direction,
            p.kind,
            status,
            p.amount_msat.unwrap_or(0),
            p.id,
        );
    }
}

// --- Node setup ---

fn build_node() -> ldk_node::Node {
    let mut builder = Builder::new();
    builder.set_network(Network::Regtest);
    builder.set_chain_source_bitcoind_rpc(
        "127.0.0.1".to_string(),
        18443,
        "polaruser".to_string(),
        "polarpass".to_string(),
    );
    builder.set_gossip_source_p2p();
    builder.build_with_fs_store().unwrap()
}

fn start_node(node: Arc<ldk_node::Node>) {
    node.start().unwrap();
    println!("Node ID:         {}", node.node_id());
    println!("Funding address: {}", node.onchain_payment().new_address().unwrap());
    println!("\n[channels at startup]");
    print_channels(&node);
    println!("\n[payments at startup]");
    print_payments(&node);
}

// --- Channel ---

fn open_channel(node: Arc<ldk_node::Node>) {
    let peer_pubkey = PublicKey::from_str("NODE_B_PUBKEY_FROM_POLAR").unwrap();
    let peer_addr = SocketAddress::from_str("127.0.0.1:NODE_B_PORT").unwrap();
    node.open_channel(peer_pubkey, peer_addr, 100_000, Some(50_000_000), None).unwrap();
    println!("Channel open request sent.");
    println!("\n[channels after open request]");
    print_channels(&node);
}

// --- Payments ---

fn create_invoice(node: Arc<ldk_node::Node>) {
    let invoice_description =
        Bolt11InvoiceDescription::Direct(Description::new(String::from("coffee")).unwrap()).into();
    let invoice = node
        .bolt11_payment()
        .receive(10_000, &invoice_description, 3600)
        .unwrap();
    println!("\nNode A invoice generated. Pay this from Node B in Polar:");
    println!("{}", invoice);
}

fn send_payment(node: Arc<ldk_node::Node>, invoice_str: &str) {
    let invoice = match Bolt11Invoice::from_str(invoice_str) {
        Ok(i) => i,
        Err(e) => {
            eprintln!("\nInvalid invoice string ({e:?}). Skipping payment.");
            return;
        }
    };
    match node.bolt11_payment().send(&invoice, None) {
        Ok(payment_id) => {
            println!("\nPayment sent to Node B (id: {})", payment_id);
            println!("Waiting for result in event loop...");
        }
        Err(e) => eprintln!("\nFailed to send payment ({e:?})."),
    }
}

fn create_offer(node: Arc<ldk_node::Node>) {
    match node.bolt12_payment().receive(10_000, "coffee", None, None) {
        Ok(offer) => {
            println!("\nOffer created. Share this with the payer:");
            println!("{}", offer);
        }
        Err(e) => eprintln!(
            "\nCould not create BOLT12 offer ({e:?}). Make sure your node is connected to an onion-message-capable peer."
        ),
    }
}

fn send_bolt12_payment(node: Arc<ldk_node::Node>, offer_str: &str) {
    let offer = match Offer::from_str(offer_str) {
        Ok(o) => o,
        Err(e) => {
            eprintln!("\nInvalid offer string ({e:?}). Skipping BOLT12 payment.");
            return;
        }
    };
    match node.bolt12_payment().send(&offer, None, None, None) {
        Ok(payment_id) => {
            println!("\nBOLT12 payment sent (id: {})", payment_id);
            println!("Waiting for result in event loop...");
        }
        Err(e) => eprintln!("\nFailed to send BOLT12 payment ({e:?})."),
    }
}

fn send_spontaneous_payment(node: Arc<ldk_node::Node>, recipient_pubkey: PublicKey) {
    let payment_id = node
        .spontaneous_payment()
        .send(5_000, recipient_pubkey, None)
        .unwrap();
    println!("\nSpontaneous payment sent to Node B (id: {})", payment_id);
    println!("Waiting for result in event loop...");
}

// --- Event loop ---

async fn run_event_loop(node: Arc<ldk_node::Node>) {
    loop {
        let event = node.next_event_async().await;

        match event {
            Event::ChannelReady { channel_id, counterparty_node_id, .. } => {
                println!(
                    "\nChannel ready: {} with peer {:?}",
                    channel_id, counterparty_node_id
                );
                println!("\n[channels after ChannelReady]");
                print_channels(&node);
                node.event_handled().unwrap();
            }

            Event::PaymentReceived { payment_id, amount_msat, .. } => {
                println!(
                    "\nPayment received: {} msats (id: {:?})",
                    amount_msat, payment_id
                );
                println!("\n[payments after receive]");
                print_payments(&node);
                node.event_handled().unwrap();
            }

            Event::PaymentSuccessful { payment_id, fee_paid_msat, .. } => {
                println!(
                    "\nPayment succeeded (id: {:?}, fee: {:?} msats)",
                    payment_id, fee_paid_msat
                );
                println!("\n[payments after success]");
                print_payments(&node);
                node.event_handled().unwrap();
            }

            Event::PaymentFailed { payment_id, reason, .. } => {
                println!(
                    "\nPayment failed (id: {:?}, reason: {:?})",
                    payment_id, reason
                );
                println!("\n[payments after failure]");
                print_payments(&node);
                node.event_handled().unwrap();
            }

            Event::ChannelClosed { channel_id, reason, .. } => {
                println!("\nChannel closed: {} ({:?})", channel_id, reason);
                print_channels(&node);
                node.event_handled().unwrap();
            }

            _ => { node.event_handled().unwrap(); }
        }
    }
}

// --- Entry point ---

#[tokio::main]
async fn main() {
    let node = Arc::new(build_node());

    start_node(Arc::clone(&node));

    println!("\nFund the address above in Polar, then press Enter...");
    let mut input = String::new();
    std::io::stdin().read_line(&mut input).unwrap();

    let node_b_pubkey = PublicKey::from_str("NODE_B_PUBKEY_FROM_POLAR").unwrap();

    open_channel(Arc::clone(&node));

    tokio::spawn(run_event_loop(Arc::clone(&node)));

    println!("\nMine blocks in Polar to confirm the channel.");
    println!("Press Enter once you see ChannelReady printed above...");
    let mut input = String::new();
    std::io::stdin().read_line(&mut input).unwrap();

    create_invoice(Arc::clone(&node));
    println!("\nPay the invoice from Node B in Polar, then press Enter when done...");
    let mut input = String::new();
    std::io::stdin().read_line(&mut input).unwrap();

    println!("\nGenerate an invoice on Node B in Polar.");
    println!("Paste it here, then press Enter:");
    let mut invoice_input = String::new();
    std::io::stdin().read_line(&mut invoice_input).unwrap();
    send_payment(Arc::clone(&node), invoice_input.trim());
    
    println!("Press enter to create a BOLT12 offer for Node B to pay (inbound payment)...");
    std::io::stdin().read_line(&mut String::new()).unwrap();
    create_offer(Arc::clone(&node));
    println!("\nPay the offer from Node B in Polar, then press Enter when done...");
    let mut input = String::new();
    std::io::stdin().read_line(&mut input).unwrap();

    println!("Press enter to send a BOLT12 payment to Node B...");
    std::io::stdin().read_line(&mut String::new()).unwrap();
    println!("\nGenerate an offer on Node B in Polar.");
    println!("Paste it here, then press Enter:");
    let mut offer_input = String::new();
    std::io::stdin().read_line(&mut offer_input).unwrap();
    send_bolt12_payment(Arc::clone(&node), offer_input.trim());

    println!("Press Enter to send a spontaneous payment to Node B (no invoice needed)...");
    let mut input = String::new();
    std::io::stdin().read_line(&mut input).unwrap();
    send_spontaneous_payment(Arc::clone(&node), node_b_pubkey);

    println!("\nWaiting for remaining events...");
    tokio::time::sleep(tokio::time::Duration::from_secs(10)).await;
}

What You Can Build From Here

Once the basics are working, there are a few directions worth exploring.

Embedding a node in a backend service gives you Lightning payments without routing through a third-party provider. The node runs as a long-lived process alongside your application, and payments arrive through the event loop rather than webhooks.

LDK Node has first-class support for the LSPS protocols: LSPS0, LSPS1, and LSPS2, the open standards for Lightning Service Providers. Building a service that opens channels on demand for users goes through those protocols. Work in ldk-node on multi-LSP configurations makes it possible to connect to more than one LSP and discover their capabilities automatically via LSPS0 protocol negotiation.

The Swift and Kotlin bindings wrap the same Rust core, so the event loop, the Builder pattern, and the payment APIs behave identically on mobile. The mental model transfers directly.

Where To Go Next

The ldk-node GitHub repository has the source, the CHANGELOG, and the issue tracker. The PR history is genuinely useful for understanding why design decisions were made.

The API docs on docs.rs cover the full surface, including things this article did not get into: on-chain sends, channel configuration, and other chain source options.

The LDK Discord is active. The #ldk-dev channel is where contributors and users discuss implementation questions, and the maintainers are responsive. If you run into issues following this article, #ldk-help is the right place to ask.

LDK Node makes Lightning approachable without hiding what’s actually happening. The API is small enough to hold in your head, the event model maps cleanly to how the protocol works under the hood, and the escape hatch to raw LDK is there when you need it. If the protocol has felt too complex to build on before, this is the right starting point.

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.

Quien busque qué medidas comprobar en una camiseta de portero puede reducir dudas comprobando el corte de las mangas y la libertad de movimiento. Una revisión final debería incluir las instrucciones de cuidado del tejido y los estampados.

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.

Una comparación útil de camisetas de fútbol para regalo comienza por las medidas reales y el tipo de ajuste preferido. El pedido puede cerrarse después de confirmar las condiciones de cambio antes de personalizar la prenda.

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.

La elección de camisetas de fútbol para entrenar mejora al comparar la comodidad, el tejido y la frecuencia de uso. Las fotografías y la ficha del producto deberían confirmar el precio total, el plazo de entrega y las condiciones de devolución.

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