Initially, when RBF was implemented in Bitcoin Core back in 2015, there was a suggestion to document the replacement rules in a Bitcoin Improvement Proposal (BIP 125). This documentation would theoretically enable wallets to understand and comply with these rules. However, the actual application of these rules is complicated by the need for detailed information about the mempool, specifically the feerates and total fees of all conflicting transactions, including their descendants. This complexity has led to a practical approach where wallets generally attempt to increase a transaction's fee until it is accepted by a mempool or confirmed, assuming they have access to full node mempool data.

There is curiosity about whether any wallets actively calculate BIP 125 requirements independently and how they accomplish this, given the intricate knowledge needed about the mempool's state. For a wallet to effectively construct a new transaction that could replace existing ones in the mempool, it would need comprehensive data on the current and potential future orderings of transaction clusters within the mempool, as well as the total fees involved in both the new and existing transactions. Despite these theoretical requirements, recent draft proposals and functional test adjustments suggest that the practical impact and changes to the RBF rules might align closely with user expectations and real-world use cases. This perspective is supported by the minimal substantive changes required in the feature_rbf.py tests, as observed in a draft PR available at https://github.com/bitcoin/bitcoin/pull/28676.