Issue 19: December 3, 2025

Cluster mempool PR merge, formation of the NetSplit WG, and the public beta launch of the ArkSat wallet

Dec 03, 2025

Good morning,

Last Thursday, Bitcoin Core developers discussed updates from the Kernel, Benchmarking, Stratum V2, and Cluster Mempool working groups (WGs), as well as a newly formed group called Net Split.

Below, I explain the Net Split project and the significance of the latest pull request (PR) merged from the Cluster Mempool WG.

One of the other topics I dive into in today’s newsletter is the product-market fit of a recently launched Bitcoin Layer-2 called Arkade. I view Arkade’s value proposition as elusive and hard to pin down, but readers should take my insights on this with a grain of salt.

My primary area of expertise is Bitcoin Layer-1 protocol development and governance. Still, occasionally I like to venture out and research new topics like Bitcoin Layer-2s, just to see what I’ll find being cooked up in other areas of Bitcoin development.

Let’s get into it.

Yours truly,

Christine D. Kim

⏱️Core Release Schedule

(For background on the Bitcoin software development process, refer to the Bitcoin Governance 101 document in the BTC Toolkit.)

First, a quick overview of Bitcoin Core’s software release schedule and the status of the next major release:

Latest Stable Major Release: Bitcoin Core  30.0

Release Date: October 13, 2025

Latest Stable Minor Release: Bitcoin Core 28.3

Release Date: October 17, 2025

Upcoming Major Release: Bitcoin Core 31.0

Target Release Date: April 10, 2026
Open issues: 11
Closed issues: 14
Milestone progress: 56%

The previous newsletter, published two weeks ago, showed 8 open issues, 7 closed, and a milestone progress of 46% for the Bitcoin Core v31 release.

🗒️Meeting Minutes

(Quotes featured in this section and the next may be edited slightly for grammar and clarity. For more information on the people involved in Bitcoin development, refer to the Bitcoin Project Contributor Directory in the BTC Toolkit.)

Kernel WG: The Kernel WG aims to modularize Bitcoin Core by isolating consensus-critical logic from wallet code, user interfaces, and other non-consensus-critical components.

Three new pull requests (PRs) have been created for this project and posted to the group’s project board.
Developers are continuing to work on standardizing tests for the Kernel’s C-header API language bindings.

Benchmarking WG: Efforts to measure and improve the performance of Bitcoin Core software through benchmarking, that is, analyzing how long certain processes take.

The design of PR #31132 (validation: fetch block inputs on parallel threads >40% faster IBD) has been updated and is showing promising results of 36% to 46% faster initial block download (IBD) speeds. Bitcoin Core Developer “L0rinc” asked for review of the PR, and noted there are a few more ideas in the works for this project that have not yet been formalized into a PR.

Cluster Mempool WG: An initiative to build a graph-based mempool that would enable nodes to reason about the relationship between unconfirmed transactions and bundle related ones together for improved transaction fee estimation, prioritization, and storage.

Bitcoin Core Developer “sdaftuar” reported that PR #33629 (cluster mempool) has been merged. They are now working on various follow-ups to the PR and documentation cleanup. They requested review of relevant documentation and polishing related to the PR now that it has been finalized.

Stratum V2 WG: An initiative to modularize and refactor Bitcoin Core components to support a next-generation mining protocol known as Stratum V2.

Bitcoin Core Developer “sjors” reported that he is refactoring the block template generation process. As background, block templates are the blueprints miners use to build blocks that contain transactions and necessary fields for a block to be both maximally valuable and valid.
Sjors is also working on PR #33922 (mining: add getMemoryLoad() and track template non-mempool memory footprint) and assessing node memory usage for block template storage.

Net Split WG: An initiative to separate Bitcoin’s networking layer from its peer-processing layer for improved networking upgradeability and testability.

On behalf of Bitcoin Core Developer “cory,” “stickies-v” reported that developers have started to tackle “the lowest hanging fruit” for this initiative, which was recently created and formalized into a PR last week. Stickies-v encouraged everyone to review the meta PR for this WG for a comprehensive understanding of the net split project.

Meeting Highlights

Discussion: Last Thursday, Bitcoin Core developers celebrated the merging of PR #33629 (cluster mempool). This PR has been in the works since 2023 and represents a major redesign of how Bitcoin Core handles unconfirmed Bitcoin transactions.

To be clear, cluster mempool is a Bitcoin Core policy change that will be included in the next major Bitcoin Core software release, v31. It is not a consensus rule change that changes the Bitcoin protocol and its consensus rules, i.e., which blocks or transactions are considered valid.

Cluster mempool introduces new logic for how Bitcoin Core nodes reason about the log of unconfirmed transactions, also called the mempool. Instead of treating transactions as independent on-chain operations, nodes will be able to group dependent transactions as a cluster for improved fee estimation and transaction prioritization in a block.

In addition, cluster mempool addresses shortcomings in the current mempool logic that mistakenly cause nodes to retain low-value transactions that shouldn’t be included in the next block, and also, at times, evict high-value ones that should be included.

As Sdaftuar writes in a Delving Bitcoin post about this PR:

[The] lack of a total ordering on mempool transactions makes [replace-by-fee] calculations difficult to align with miner incentives, and creates distortions where we sometimes can replace transactions via RBF that would actually be better for a miner than the replacement. To solve all these problems, we can instead maintain a total ordering on mempool transactions, which is used to implement a mining and eviction algorithm that are symmetrically opposite and provide better RBF rules for determining when to allow a replacement to occur.

As background, replace-by-fee (RBF) refers to the Bitcoin Core feature that lets users replace an unconfirmed transaction with a new, higher-fee transaction, giving them a reliable way to bump fees and speed up confirmation.

With cluster mempool now complete, developers are working on polishing the code and creating documentation for it to assist with testing and adoption of the new mempool features.

Sdaftuar said during last Thursday’s meeting:

It’d be helpful to get a lot of eyes on docs, rpc output, etc to get things as polished as possible before [the v31] release.

Bitcoin Core Developer “sipa” said:

I’m happy we got it this early in a release cycle.

Stickies-v said:

Big news on the merge, congrats everyone who contributed!

Takeaway: Cluster mempool is a feature that will directly impact the transaction selection process for Bitcoin miners and improve the profitability of the blocks they build. It also improves the user experience for Bitcoin node operators by making Bitcoin Core nodes more memory-efficient for mempool storage and more resilient to fluctuations in mempool activity.

📧 You’ve Got Mail! (& Other News)

(For a comprehensive overview of all major Bitcoin development meetings and discussion forums, refer to this post in the BTC Toolkit.)

An overview of other notable discussions and news that happened over the past two weeks, sourced from the Bitcoin Development Mailing List and other public forums:

A bug was discovered in a widely used Bitcoin development library for the .NET ecosystem, NBitcoin, using a testing tool created by Bitcoin Core Developer Bruno Garcia. As NBitcoin is not a Bitcoin client implementation, the bug posed no risk to network stability, but it did prompt a new release of the library, which is mostly used by Bitcoin wallet and application developers. (Delving Bitcoin)
Rawbit is a tool that allows users to visualize, build, and test Bitcoin transactions before submitting them on-chain. It is primarily intended as an educational tool and is free and open-source for anyone to use. (Delving Bitcoin)
Bitcoin Core Developer “AntoineP” has recently merged several new test vectors for Bitcoin Improvement Proposal 54, aka the Great Consensus Cleanup BIP. AntoineP has also opened a PR to merge all changes into Bitcoin Inquisition, a testbed version of Bitcoin Core software that activates experimental soft fork features still under discussion by the broader Bitcoin community. (Delving Bitcoin)
Bitcoin Layer-2 project Ark Labs has announced its beta version of the ArkSat wallet, a web wallet for its newly launched Arkade Layer-2 network. (X)

Discussion Spotlight

Subject line: Public beta launch of the ArkSat wallet

Date(s): November 28, 2025

Discussion: Over the last few months, Ark Labs has reached new milestones in the launch of their Layer-2 protocol, Arkade. As of October, Arkade is in public beta, meaning anyone can now start building applications on the network. More recently, the team has announced the public beta of their native web wallet for Arkade, called ArkSat, which will enable end-users to interact with the applications and tokens launched on Arkade.

The design of Arkade is based on a Bitcoin scaling protocol called Ark that enables off-chain Bitcoin transaction execution and batched on-chain transaction settlement. It requires a centralized operator to oversee transaction execution, but the operator does not have the ability to steal funds or trace them to specific users.

Ark is a privacy-preserving and non-custodial way to transact with bitcoin, the cryptocurrency, more cheaply and quickly than directly via the Bitcoin protocol. However, as mentioned, these scalability gains come with tradeoffs. Namely, Ark and therefore Arkade are susceptible to a centralized point of failure, which lies with the operator of the off-chain transaction pool, that Bitcoin, the protocol, does not share.

Ark was initially designed to support off-chain Bitcoin payments. Arkade seeks to go one step further and support programmable smart contracts on Bitcoin. This is an ambitious step that remains highly experimental and not to be confused with the types of smart contracts on Ethereum and Ethereum Layer-2s.

Arkade’s documentation for smart contract development reads:

Bitcoin’s Unspent Transaction Output (UTXO) model differs fundamentally from the account-based model used in platforms like Ethereum. This difference creates both challenges and opportunities for smart contract development. Arkade builds upon Bitcoin’s UTXO model to enable powerful smart contracts while maintaining Bitcoin’s security properties.

Also on the same page, the documentation says:

All code and concepts presented in this documentation are for exploration and proof of concept purposes only. These examples should not be used in production environments. The Arkade Language ecosystem is under active development and subject to significant changes.

Arkade smart contracts are not executed through a general-purpose virtual machine like the Ethereum Virtual Machine (EVM).

Arkade’s scripting, or programming language, is based on Bitcoin’s UTXO environment, which limits the programmability of these contracts to what can be feasibly controlled about the validity of future Bitcoin transactions and their spending paths.

It does not introduce new logic that can support Turing-complete, arbitrary computations on Bitcoin. Rather, the logic used in Arkade’s scripting language, such as covenants, which are spending conditions on Bitcoin transactions, and introspection, which are checks on Bitcoin transaction outputs, makes it easier and more cost-efficient for users to leverage the existing, and compared to Ethereum, still limited, programmability of Bitcoin transactions.

Takeaway: The product market fit for Arkade is elusive.

Though Arkade is commonly thought of as a Layer-2, it is important to note that its functionality differs significantly from Ethereum Layer-2s because it is built on Bitcoin.

Arkade aims to extend Bitcoin’s native scripting capabilities—using covenants, introspection, Taproot techniques, and off-chain coordination—to make Bitcoin transactions more cost-effective and expressive.

It is unlikely that these so-called Bitcoin smart contracts will match the expressivity of Ethereum Layer-2 smart contracts, which inherit and even extend the programmability of Ethereum Layer-1.

Thus, Arkade is a Layer-2 primarily for existing Bitcoin users and developers, many of whom, as recent controversies in the Bitcoin community have shown, expressly do not care for more programmability on Bitcoin.

🟠 You are now officially caught up on the state of Bitcoin Core development and governance.

🙏 Thank you for reading this issue of BTC Before Light. If you like what you read, consider sharing it with a friend who might also enjoy the content.

💥If today’s post sparked any thoughts, opinions, or questions, I’d love to hear them. Please share your feedback on today’s newsletter by leaving a comment.

Discussion about this post

Ready for more?