- Published on
Advancements in Developer Libraries
- Authors
- Name
- OpenSats
- Name
- Arvin
- @arvin
Reliable, well-audited developer libraries are the hidden plumbing of bitcoin. They abstract away the heavy lifting—key generation, transaction building, network rules—so wallet creators, node operators, and application developers can focus on user experience. When these libraries mature, they do more than save engineering hours; they embed security best practices, prevent subtle bugs from propagating across projects, and allow new ideas to spread quickly through the ecosystem.
OpenSats funding enables these library developers and maintainers to do all of their high-impact work in public repositories, where every commit and code review is fully transparent, audit-ready, and immediately reusable across the wider Bitcoin ecosystem.
This impact report highlights seven key library initiatives:
These initiatives have collectively stabilized core APIs, enhanced cryptographic security, improved privacy features, and enabled advanced functionalities like on-chain derivatives, collaborative payments, protocol testing, and dynamic Lightning channels, resulting in widespread adoption across wallets, nodes, and services that make Bitcoin development more accessible, reliable, and innovative for builders of this ecosystem.
Let's take a closer look at how these developer library initiatives are making an impact.
Bitcoin Dev Kit
OpenSats has supported a series of efforts to strengthen the Bitcoin Development Kit (BDK), a modular Rust library for building Bitcoin wallets across platforms. BDK plays a key role in improving wallet reliability, onboarding, and user privacy—especially in environments where security, platform reach, and flexible trust models are critical.
The BDK team developed a full-scale redesign of their library, capping it off with the BDK Wallet 1.0.0 release in December 2024, bringing a stable API tied to semantic versioning, offering developers a solid base for smoother upgrades moving forward. Alongside that full‑scale redesign, the team refreshed its Swift, Kotlin and Python bindings so they track the new 1.0 API feature‑for‑feature, giving mobile and desktop apps async‑ready access to BDK.
The BDK library was carved into bite-sized modules, allowing developers to pick and choose for specialized needs, like custom transaction builders or slimmed-down hardware. Syncing was enhanced with async options that don't lock up the application, as well as improved storage handling and adjustments for embedded gear and WebAssembly. BDK also released the Book of BDK, containing straightforward guides, upgrade paths from older versions, and real-world reusable code snippets that save developers time.
The mission of the BDK team is to provide the best FOSS libraries for building secure, modern bitcoin apps and services. With the 1.0+ releases now in the hands of thousands of users through projects like Bitkey and ProtonWallet, we have begun to achieve this mission. Moreover, with projects like AnchorWatch, FrostSnap, Cove, and Bitcoin Safe, we continue to support innovative new layer one wallets. Looking forward, we also see BDK playing a strong supporting role for layer two projects like ldk-node and Second's bark. If there is a bitcoin project you want to see in the world, BDK will help you build it.
—Steve Myers, BDK director/core contributor
Another OpenSats-supported project, Tor Support for BDK, enhanced its privacy and security, which involved patching the rust-electrum-client library upstream. Secure links to self-hosted Electrum servers have become possible using self-signed TLS certificates, removing vulnerable unencrypted backups. This means users can depend on their own setups, including onion-routed ones, without data spills. In rust-esplora-client, this removed a troublesome dependency, reviving builds for WebAssembly and mobile. A follow-up draft added a swappable HTTP layer for Tor with less effort. These fixes don't just protect IP addresses; they extend out to other Rust tools, letting wallets function in places where non-Tor traffic is blocked.
OpenSats support also enabled developer Robert Netzke (rustaceanrob) to advance BDK's Kyoto light‑client backend, which implements BIP 157/158 compact‑filter syncing. His work unlocked direct reads of indexed blocks—ideal for bandwidth‑conscious mobile usage and privacy tools like silent payments—then added Testnet4 support for safe protocol experiments and a CI harness that spins up bitcoind to catch sync errors early. Kyoto was also bridged to mobile via BDK‑FFI, opening doors for iOS and Android developers, while audit‑flagged issues in BDK's core were also resolved.
BDK's recent upgrades, including stable APIs, Tor-ready networking, and a compact-filter light client, have solidified the library as a core building block for the Bitcoin ecosystem. From hardware devices to layer-two research, development teams can now reach for BDK first because it keeps pace with features like Silent Payments and Testnet4 while maintaining strong security and developer ergonomics. OpenSats' support helped to accelerate this progress; going forward, the broader contributor community is well-positioned to carry BDK's momentum into the next wave of sovereign Bitcoin tools.
Rust-Bitcoin
The rust‑bitcoin library is a toolkit for building Bitcoin software in Rust, offering the core building blocks—transactions, scripts, blocks, and network rules—that higher‑level libraries such as BDK, LDK, and many Rust‑based hardware‑wallet firmwares rely on. Because these building blocks feed directly into wallets, nodes, and other critical apps, even small mistakes can create transactions that won't relay or trigger arithmetic errors that put funds at risk. OpenSats has supported multiple maintainers who have transformed Rust‑Bitcoin's once‑monolithic code into a modular, well‑tested stack; added policy updates to keep pace with Bitcoin Core; and enabled cross‑project coordination—delivering a safer, easier‑to‑upgrade base for the entire ecosystem.
The push was highlighted by the first release‑candidate of bitcoin‑units 1.0.0-rc.0, a step toward long‑term API stability, and by modernizing FeeRate to use milli‑vbytes (mvB), aligning fee logic with Bitcoin Core.
Tobin Harding guided the structural improvements of the Bitcoin-Rust library. He coordinated a v0.32 release wave across the stack—updating code packages (crates) like base58ck for address encoding and secp256k1 for elliptic curve cryptography—while requiring a newer version of the Rust compiler and removing outdated compatibility layers for resource-constrained environments. A key step was launching bitcoin-primitives 0.101.0, which pulls out basic data types like addresses and amounts into their own crate, breaking the chain of forced simultaneous upgrades that used to hold back entire projects.
New standalone crates came next: rust-psbt for full support of PSBT v2 (partially signed Bitcoin transactions, for collaborative or hardware-based signing), bitcoin-units for handling Bitcoin amounts safely, bitcoin-io for basic input/output operations, and the corepc RPC suite for structured calls to Bitcoin Core nodes across different versions, including built-in tools for reliable testing. These changes make the library more flexible, so developers can mix and match only the parts they need.
Harding also improved safety in bitcoin-units by enforcing bitcoin's maximum money supply limit (MAX_MONEY) and introducing a NumOpResult type—a simple wrapper that checks for errors like arithmetic overflows during calculations. The locktime module was also updated, with easier-to-use constructors and corrections for subtle off-by-one errors in height-based checks, making it simpler to create transactions that unlock only after a specific block or time.
My job is to provide libraries so other devs can create software that users love. If no one ever mentions rust-bitcoin while simultaneously using it every day, then we win.
—Tobin Harding
In parallel, Jamil Lambert focused on making the rust-bitcoin codebase more reliable through better testing and safeguards. He added weekly mutation testing—a method that changes the code on purpose to ensure the tests are catching it—and eliminated every surviving mutant in bitcoin-units and hex-conservative by writing precise, targeted tests. In bitcoin-primitives::block, he raised test coverage from 13% to 100%, strengthening one of the most critical parts of the library.
Lambert also restored a compile-time check in BufEncoder that prevents hex-encoding crashes during signing and hashing. Behind the scenes, he fixed broken fuzz tests and updated GitHub Actions to keep automated checks running smoothly, helping ensure safety across the entire rust-bitcoin stack.
Testing is an important part of software development, which isn't always treated as such. There are often poorly written tests that are hard to read, and some don't test what they set out to... Writing and improving tests for all of the missed mutants requires an understanding of what the code being tested does, which has been a good way to learn about the software while also doing something useful.
—Jamil Lambert
Additionally, OpenSats grantee Robert Netzke (rustaceanrob) implemented policy-level changes by merging upstream fixes directly into the library. He adjusted the OP_RETURN size limit—a rule for embedding data in transactions—to exactly match Bitcoin Core's 80-byte cap, including the space for instructions (push opcodes), which helps prevent transactions from being rejected by the network. He also introduced a FeeRate::from_sat_per_kvb helper function to express fees in the same units as Bitcoin Core's feefilter message (satoshis per kilovirtualbyte), making it easier for tools to set and check transaction costs accurately.
Rustaceanrob also added Transaction Version 3 (BIP 431) support to Rust‑Bitcoin, preparing the library for covenant‑style spending rules while preserving full compatibility with existing transactions. Together with his other policy fixes, this keeps Rust‑Bitcoin aligned with Bitcoin Core and lets developers build applications that stay reliable as the protocol evolves.
Community alignment tied these efforts together. Tobin Harding hosted the inaugural Rust Bitcoin Summit in Nashville in 2024, uniting 30 developers from BDK, LDK, Fedimint, and others to synchronize on primitives and PSBT plans. Shared maintainer tools, like reusable CI scripts in a dedicated repo, streamlined reviews, while active mentorship onboarded new contributors and merged external PRs, ultimately broadening participation.
These advancements have collectively made rust-bitcoin a more reliable base for Bitcoin tools, shortening development time and reducing risks in dependent projects. By enabling modular dependencies, comprehensive testing, and forward-compatible policies, the library now better serves the ecosystem's needs for secure, efficient building blocks.
Secp256k1
The secp256k1 elliptic curve secures every Bitcoin signature, but Swift developers have several challenges integrating the curve because the only audited implementation was written in C—forcing them to manage unsafe pointers, complex project build setups, and minimal documentation. With OpenSats' support, the 21-DOT-DEV collective transformed swift-secp256k1 into a polished, Swift-native toolkit for Bitcoin, Cashu, and nostr apps.
The version v0.18.0 release introduced MuSig2, a multi-signature upgrade that lets several participants merge their Schnorr signatures into one—improving privacy while saving space—so apps can enable it with just a few lines of code. In practice, this allows developers to more easily integrate with cooperative flows used by non-custodial swap protocols—such as refunds where an app co-signs the time-locked transaction with a single aggregated key when needed.
In a following release, the team began shipping a XCFramework which extends the distribution of swift-secp256k1 to CocoaPods (which can be used by cross-platform toolchains like React Native and Flutter). These prebuilt binaries make consumer app builds faster, continuous integration pipelines more deterministic, and enable module-stable Swift interfaces that won't break with Xcode updates.
The v0.21.0 release added a new UInt256 that matches the 32-byte sizes used commonly across Bitcoin keys, so developers no longer need to pass critical values around as Strings or raw Data. Backed by StaticBigInt, it accepts true 256-bit literals and plugs into Swift’s numeric protocols, letting the compiler enforce width and range at build-time—catching size/format mistakes before they ship. The result is easier adoption and cleaner APIs: developers work with a single, fixed-width integer that serializes cleanly to 32-byte buffers and drops into generic math without glue code, improving robustness and integration speed.
To spread these gains beyond a single library, they've introduced swift-plugin-tuist—a SwiftPM plugin that invokes Tuist directly (no separate install) so any package can generate reproducible, easier-to-manage Xcode projects with a single command. By treating the project as code, development teams see fewer merge conflicts and less '.pbxproj' drift, and CI spins up identical workspaces on demand. They also publish source-of-truth API docs powered by DocC on every tagged release, providing instant, deep-linked symbol pages that take developers straight from an API to its usage.
Today, the package lives under the 21.dev GitHub organization, with plans to formalize 21.dev as a nonprofit entity—signaling long-term stewardship, clear governance, and alignment with OpenSats' mission for open, transparent infrastructure.
Together, these upgrades turn swift-secp256k1 from just being a niche wrapper into a dependable foundation that helps teams ship faster—with prebuilt binaries, cleaner types, and clear docs—while making privacy the default through aggregated signatures that keep collaborative flows discreet on-chain. The result is less time spent on plumbing and more time delivering features users feel, sooner. If you’re building a wallet, node companion, or privacy tool using Swift, explore the docs and try it out to see how quickly you can go from idea to release.
DLC Dev Kit
Discreet Log Contracts (DLCs) allow parties to create conditional bitcoin transactions that settle based on external oracle data without ongoing trust in intermediaries and without revealing contract details on-chain until closure. The model works for derivatives, options, hedging, and prediction markets directly on bitcoin. Traditionally, bringing DLCs to production has required deep cryptography expertise and robust peer-to-peer architecture.
The DLC Dev Kit is a Rust library from Benny Hodl that builds on rust-dlc and Bitcoin Dev Kit, turning that work into simpler, reusable tooling.
With OpenSats' support, the project incorporated DLC messaging into the nostr protocol, allowing contracts to move through relays rather than depend on public IPs or Tor onion services. This shift makes DLCs easier to run on mobile apps and embedded devices. The first big step was an Oracle Announcement Marketplace that lets apps discover oracle events. It then launched nostr Transport v1 for basic back-and-forth messaging, followed by v1.1, which adds delayed replies and larger payloads. A nostr oracle client now lets software pull attestations straight from relays.
For higher-volume services, the DLC Manager underwent a refactor that replaced global locks with a multi-producer, single-consumer queue, enabling non-blocking tasks such as adaptor-signature generation, proving useful for exchanges and gateways handling many contracts.
The DLC Dev Kit is now modular. Developers can toggle storage, transport, and oracle components with feature flags, keeping WebAssembly and mobile builds small. The kit also comes with an asynchronous SQLx storage layer for PostgreSQL and SQLite, plus Docker-based tests, giving production servers durable and easily queried contract data.
Developers also receive the ddk-payouts crate, which supplies ready-made builders for European options (contracts that can be exercised only at expiration) and for custom payout curves, so no one has to calculate outcomes by hand.
Infrastructure work continues on the Kormir oracle, which now relies on event IDs as its primary key for cleaner APIs while remaining a reference point for spec-compliant testing. To show the DLC Dev Kit in action, the team also maintains the Ernest Money demo stack where Squawk Box handles encrypted DLC messaging over nostr, Ernest Oracle publishes bitcoin hashrate and fee data over nostr, and City Tavern forwards DLC traffic for clients without inbound connectivity using the Lightning Network protocol in a peer-to-peer framework.
All of these improvements lower the barrier to adding DLCs to open-source bitcoin tools, giving developers stable, verifiable libraries for trust-minimized hedging, payments, and derivatives, without a centralized middleman.
Payjoin Dev Kit
Payjoin is a protocol for batching bitcoin transactions that improves on-chain privacy by breaking the common-input-ownership heuristic while reducing fees. The Payjoin Dev Kit, a Rust-based library led by developer Dan Gould, addresses adoption barriers by providing a modular, developer-friendly toolkit to integrate into wallets, nodes, and payment applications.
Earlier versions of Payjoin struggled to scale primarily due to the receiver having to keep a public server running, often behind Tor and wrapped in TLS encryption and the requirement for both sender and receiver to be online at the same time. Mobile wallets and most merchants found that setup impractical. With support from OpenSats, Payjoin Dev Kit cleared those hurdles. Maintainer Dan Gould introduced advancements in Async Payjoin (merged as BIP 77), letting the sender and the receiver exchange transaction details over encrypted messages on agreed upon mailboxes, allowing parties to fetch and post messages while the other is offline, like email.
The specification was born from iterations of working code. The Rust payjoin crate jumped from version 0.11 to 0.24, gaining a simpler interface, implemented HPKE-encrypted Oblivious HTTP to help protect data without heavy Tor or TLS dependencies, and recently introduced a session-event log, creating a standard way for implementors to display transaction history in apps and throw errors. It now records more than twenty thousand downloads. The payjoin-cli matured into a stable tool that talks to Bitcoin Core and restarts interrupted async sessions automatically, giving developers an easy way to test Payjoin flows. To keep network details private, the team published the ohttp-relay crate, and community operators such as Cake Wallet and BOB Space now run OHTTP relays.
Payjoin Dev Kit now extends beyond Rust. The payjoin-ffi crate builds bindings on a framework that now ships Python and Dart. Android, iOS, and desktop apps can use the same well-tested core. By designing tools to bind from this framework, like the new one for dart, adding new languages is easy, and the rest of the rust-bitcoin ecosystem can re-use the same pattern to have compatible dev kits across many languages.
Adoption keeps ramping up: Bull Bitcoin Mobile has been able to both send and receive it since December 2024, and Cake Wallet added Payjoin V2 sending and receiving support in May 2025. Many implementations making use of the advanced "cut-through" batching features are in progress with Liana, Galoy's Bria, Boltz, and for Lightning channel funding currently being tested in LDK-Node.
In just over a year, Payjoin Dev Kit has transformed from experimental concept to a production standard protocol and toolkit, with live infrastructure, language bindings, and command-line tools. Developers can include this default, privacy-preserving behavior into wallets, nodes, and batching services, lowering fees and improving privacy characteristics for the whole Bitcoin network without running Tor or their own dedicated servers.
LN Proto Test
Lnprototest is a Lightning protocol test framework that checks whether every implementation interprets the BOLT consistently. Advancements in lnprototest, driven by support from OpenSats, has progressed from a Core Lightning utility to a cross-implementation suite used in continuous-integration pipelines across Rust, Python, and other software stacks.
A Unix-socket runner now drives the Rust-based Lampo node directly, proving the framework can test codebases outside Core Lightning without requiring patches. A community contribution soon followed, integrating an LDK sample node into the harness so any rust-lightning application can enable full protocol tests with minimal configuration.
Internal refactors have removed the TryAll abstraction and streamlined handshake scenarios, trimming execution time and shortening feedback loops for developers who add new test cases. Parallel work on a strongly typed message layer, generated from Rust-Lightning structures through FFI, replaces ad-hoc parsing and lays the groundwork for language-neutral bindings.
Community involvement has grown as well. Outreach at recent summits attracted new maintainers, expanding the reviewer pool and accelerating issue turnaround. These contributors are already planning a second major version that will further modularise the core while preserving the stable interface used today.
This improved toolset has already prevented real-world issues. During a routine Core Lightning upgrade, the suite caught a funding-signature mismatch that would have broken channel establishment across nodes, avoiding a mainnet incident and underscoring the value of continuous protocol testing.
To coordinate broader efforts, the maintainers created the Lightning Interoperability Initiative, a public working group that documents meeting notes, drafts specifications, and aligns cross-project priorities. By funding these refactors, new runners, and organized community processes, OpenSats has played a part in positioning lnprototest as the standard safeguard for Lightning interoperability before code reaches users.
Splicing in LDK
Lightning channels need ways to add or remove funds without closing them entirely. Closing a channel means paying on-chain fees twice and losing liquidity during the process. Splicing lets users resize channels with a single on-chain transaction while the channel stays open and payments continue.
OpenSats supported advancements in splicing, enabling its addition to both Core Lightning and Lightning Development Kit, and to ensure the feature behaves the same across other implementations such as Eclair. The effort included protocol integration, interactive funding refactors, extensive testing, and ongoing contributions to the protocol specifications.
In Core Lightning, developer Dusty Daemon merged a series of commits that produced the first successful splice between Core Lightning and Eclair. A later clean-up merge addressed the remaining edge cases, so full cross-implementation interoperability is now available on the main branch.
The same development cycle introduced Splice Script, a compact text format that lets operators describe multiple channel edits in one statement, which the node then translates into machine-readable instructions. Reliability improved through a restart fuzz harness that repeatedly crashes the channel daemon to surface rare socket and file descriptor bugs.
Additional patches now publish funding output indexes and record multi-transaction closes to improve audit trails. Smaller protocol adjustments accept commitment signature batches in any order, aligning channel reestablishment logic with Eclair, and add sanity checks that prevent phantom confirmations.
On the Rust side, contributor optout21 refactored the Lightning Development Kit around the draft splice_locked handshake and interactive dual funding. Foundational changes such as shared output negotiation, new signature fields, a dedicated splicing feature flag, and a refreshed message set have already been implemented on the main branch.
A recent patch rotates funding keys after each splice for added safety. A working prototype flows through ldk node, allowing wallet teams to test pay-after-splice and splice-after-pay flows. Weekly splice sync calls feed lessons learned from these tests back into the specification process.
Interoperability has been proven, script-driven workflows are live, and fuzz tests guard stability. With compliant code shipping in Core Lightning and Lightning Development Kit, splicing is ready for wallet adoption and final specification review. The feature lowers on-chain costs, preserves channel uptime, and enables automated liquidity management across the Lightning network.
Reliable developer libraries form the foundation for secure and resilient Bitcoin software. The seven initiatives detailed in this report—Bitcoin Dev Kit, rust-bitcoin, Secp256k1, DLC Dev Kit, Payjoin Dev Kit, LN Proto Test, and Splicing in LDK—show how targeted open-source work speeds adoption and raises the security bar across the ecosystem. Stable APIs replace fragile forks, cryptographic upgrades become drop-in imports, and protocol tests catch incompatibilities before they reach users.
These projects are part of more than 300 OpenSats grants awarded to date, each compounding value as modular code gets reused, vulnerabilities are prevented at scale, and privacy and interoperability features become standard practice.
OpenSats remains committed to funding the maintainers and developers who strengthen Bitcoin's core infrastructure, fostering a more accessible, secure, and decentralized network. To support projects like these and others, please consider making a recurring donation to the General Fund.
If you're a developer advancing free and open-source software that helps Bitcoin flourish, we encourage you to apply for funding.