Understanding the Challenges of BSV Wallet Development

In the world of blockchain development, creating a robust and reliable wallet is no simple task. For BSV (Bitcoin SV), this challenge is compounded by two fundamental issues rooted in the design of the SV node's mempool architecture. These issues not only complicate wallet development but also hinder broader adoption, as they introduce significant complexity and uncertainty.

The Core Problem: Multiple Mempools

BSV nodes maintain three different types of mempools, a legacy design decision inherited from the days of BTC node development. While this design may have served BTC’s network, which embraces a limited block size, it creates significant challenges in the BSV ecosystem. Two specific problems arise from this architecture:

1. Orphan Mempool and Double Spend Risks

The first issue is the orphan mempool, where transactions with missing parent inputs are temporarily stored for up to 25 minutes. This is intended to account for propagation delays in a global network, allowing child transactions to wait for their parents to appear. In theory, this can help ensure that transactions are not prematurely discarded.

However, on BSV, this approach is more of a liability than an asset. The network aspires to a fully connected, high-speed propagation model, where transactions should spread across all nodes almost instantly. The 20-minutes retention of orphan transactions is not just illogical and unnecessary—it actively introduces risks:

• Double Spend Concealment: A transaction attempting to spend an already mined output will appear valid from an SPV (Simple Payment Verification) perspective, as it has a valid structure, fee, and unlocking script. But because it is spending an already consumed output, it is effectively a double spend. This transaction will linger in the orphan mempool without being fully rejected for up to 25 minutes. It bypasses regular double spend detection because that detection relies on the set of currently unspent outputs. It is not practical, even for a mining node, to maintain the complete history of every output that ever existed.

• False Sense of Security with SPV: SPV can verify transaction structure, inputs, and fees, but it cannot detect this form of double spend because it lacks the complete history of all outputs. This creates a dangerous blind spot for wallet developers, who may wrongly assume a transaction is safe if it passes SPV checks and then also sits in the node without getting rejected.

• Worsened by Network Congestion: In a congested network scenario—common on BSV due to low transaction fees and legacy software design—legitimate transactions can also end up in the orphan mempool due to temporary propagation delays. This means a wallet cannot easily distinguish between a delayed but legitimate transaction and a double spend attempt.

• Extended Risk Duration: The 20 to 25 minutes retention period is excessive. In a high-speed, high-capacity network like BSV, orphan transactions should be resolved in seconds if not immediately. This excessive duration only prolongs uncertainty and complicates wallet risk assessment when managing zero conf deposits.

• Impact on Instant Payments: For a wallet aiming to provide zero-confirmation payments, the existence of the orphan mempool introduces significant uncertainty. Even transactions that pass SPV verification can later be invalidated if they linger in the orphan mempool. This forces the wallet to monitor whether the transaction reaches the main mempool of a mining node. But how long should it wait? Ideally, this should not be the wallet’s responsibility—nodes should promptly reject transactions that cannot be resolved, rather than allowing them to linger for that long. Wallets also need to respond promptly to the sender party if they will accept a transaction or not.

In practice, this means wallet developers must design around this issue, implementing redundant broadcast mechanisms and multiple cross-node double spend detections—adding complexity to what should be a straightforward process.

2. Child Pays for Parent (CPFP) Fee Mechanism

The second issue is the "Child Pays for Parent" (CPFP) mechanism, another legacy from BTC. This feature allows a low-fee transaction to be saved by attaching a higher-fee child transaction, which covers the fee deficit of the parent. While this may make sense in BTC, where fees fluctuate significantly, it is a liability for BSV, where fees are low, and high transaction throughput is expected.

What makes this even more problematic is that such transactions will persist in the node for up to two weeks, which is excessive and unnecessary. This behavior introduces avoidable complexity for wallet developers, who are now required to validate the entire transaction chain to ensure fee sufficiency—greatly overcomplicating what should be a straightforward check.

The Impact of Network Congestion

Both of these problems become significantly worse under network congestion, which is not uncommon on BSV due to low transaction fees. When the network is flooded with millions of transactions, propagation slows, and even valid transactions struggle to reach miners in time and order.

A Broader Perspective: Wallet Development Shouldn’t Be This Hard

Some may argue that as long as mining nodes continue to operate, the network is fine. But a truly functioning blockchain network is one where users can reliably execute transactions as promised—simply, quickly, and securely. The current reality of BSV is far from this ideal.

Developers should be able to build and deploy wallets without diving deep into node internals or developing custom solutions for basic transaction handling. Yet, on BSV, this is exactly what is required, creating a barrier to adoption.

Looking Forward: Addressing the Problem

There is reason for optimism. The Teranode project aims to eliminate these legacy issues entirely, and protocols like BEEF already offer a partial solution—though not without cost. However, relying solely on future improvements is not a viable strategy. Wallet developers and node operators need practical, actionable solutions today. Mitigations should not become a crutch for flawed design—even if those flaws are inherited from BTC. Instead, the ecosystem should offer robust infrastructure that empowers developers to build secure, efficient wallets without excessive complexity. Protocols like BEEF should not be seen as temporary fixes for underlying problems but as tools for creating state-of-the-art wallet solutions.

If the BSV ecosystem hopes to enable seamless, reliable payments at scale, it must address these core issues directly and promptly. Otherwise, it risks missing the opportunity for widespread adoption entirely.