The last 3 months of Swift Bitcoin development have been intense as we advance firmly towards testnet compatibility and a stable public API.

Project Updates

Our primary goal laid out back in June was to start syncing the "testnet" blockchain. The consensus parameters for "Testnet 4" were configured #379 and all special rules of BIP94 were implemented #406.

A guide was written to facilitate running/testing out Swift Bitcoin alongside a controlled dockerized Core instance. The configuration file format and the daemon's command line arguments were improved to accept a log level and the all important chain selection (network) value #385 #403.

During the initial synchronization attempts multiple issues and missing functionality were identified and subsequently fixed. Some of the more relevant fixes are:

Missing persistent block undo data #420
Lack of headers-first IBD strategy #416
Poor support for chain reorganizations #430
Incomplete time-lock implementation #443
Incomplete implementation of BIP 130 #408
Anchor outputs and several consensus related bug fixes #414

Performance and traceability was also proven to be an area in need of focus with many improvements and refactors affecting file system, database persistence and networking:

Re-implementation of LMDB bindings using non-copyable types #381
Move block validation to a concurrent background queue #422
Upgraded libsecp256k1 integration #421

On the library side of things the public API was completely streamlined and documented #374 375. A pre-release build was issued and submitted to the Swift Package Index for publication with new unified DocC documentation for users and automatically generated developer documentation. An announcement was made on the Swift Forums as well as on social media in an effort to promote collaboration.

A project board was set up 3 months ago to track all work items covered by the OpenSats grant commitment in real time. As of this write up, over 50 work items have been completed while about 25 items remain either in backlog or in progress with more to be added in the upcoming weeks. The project itself has over 80 recorded GitHub Issues.

Plans for the remainder of the year

For what's left of 2025 the main objectives continue to be:

Bitcoin Node (bcnode) support of Testnet 4 which includes initial block download, keeping up with new blocks, handling reorgs and relaying transactions.
Bitcoin Utility (bcutil) capabilities to verify the correct operation of node instances via RPC commands and off-chain operations. This includes listing recorded reorgs and submitting raw transactions.
Library API covering all base bitcoin protocol and wallet functionality in a way that is fully compatible with Testnet 4. For this we need to keep making sure we follow the official Swift Language API Design Guidelines in order to provide a solid 1.0 release that's both idiomatic and ergonomic.

We want users to be able to download Swift Bitcoin (Linux Docker images and binaries already being provided with each release) and have a testnet instance that they can sync and interact in a way that's similar to Bitcoin Core. By the same token we want developers to use Swift Bitcoin in their apps whether it be building a simple wallet or an e-commerce site. We already received some positive feedback (privately and publicly on our X account from daredevil iOS developers integrating the library into experimental products. We'd like to give those developers a proper release and a chance to contribute back in a positive feedback loop.

To that effect here's a few GitHub issues to highlight from the Kanban board:

Behind the scenes on the purely technical side we'd also like to integrate Apple's Swift Metrics to get a better picture of the network client's behavior and operation through either Open Telemetry or Prometheus. There's also a new official binary parser that might help us boost our serialization/deserialization code.

One additional requirement will be to start incorporating many of the new Swift 6.2 (released September 16, 2025) features that can greatly impact our package's performance like inline arrays and spans. A full refactor of the affected code may not be possible but a partial implementation should be sufficient to make a dent in performance.