LDK’s core Lightning library published version 0.3.0-rc3 on October 2, giving wallet developers another testing checkpoint for a release cycle that expands channel splicing. The package’s version index, checked on October 14, still lists 0.2.7 as the latest stable release. The candidate’s release notes describe support for replacing pending splice transactions with higher-fee versions and moving funds into and out of a channel in one splice.
Those capabilities put more responsibility on the application surrounding the library. LDK lets developers supply their own wallet, storage, networking and blockchain connections. A consumer app therefore needs to turn protocol events into accurate balances, understandable progress messages and safe spending decisions. LDK’s documented architecture explains that division of responsibilities.
A channel can change its funding
Splicing changes the Bitcoin output backing an existing Lightning channel. The transaction spends the old funding output and creates a replacement, allowing the participants to adjust the channel’s funds. LDK’s published channel-manager documentation explains that the peer must support splicing and be connected. It also assigns transaction-fee responsibilities to the initiator and the funds being contributed.
The practical attraction is flexibility. A wallet can move additional on-chain bitcoin into an existing channel or withdraw some channel funds to an on-chain destination. The value of that flexibility depends on the transaction cost, the counterparty’s cooperation and the application’s implementation. A feature announcement cannot establish the price or availability in a particular consumer wallet.
The Lightning peer protocol pauses channel updates for splice negotiation. After signatures are exchanged, payments can resume while confirmation is pending, but must remain valid across the possible funding transactions.
Fee bumps require careful input accounting
Replace-by-fee, or RBF, can raise a pending splice’s fee. Under the splice fee-bumping rules, replacements spend the existing funding output and compete to confirm. Participants track these alternatives until the splice locks in.
For wallet builders, that creates a bookkeeping problem: which other coins are still reserved for a transaction that could confirm? Releasing an input too early could let an ordinary wallet payment conflict with the pending splice.
LDK’s merged input-reservation correction, completed September 18, documents precisely that risk. A failed fee-bump attempt after a force close could incorrectly tell the wallet that inputs used by the original splice were available again. The correction tracks which funding components each attempt inherited, so failure releases only the components that attempt reserved itself.
This gives integration teams a useful test case. Start with a pending splice, attempt a replacement, then make that attempt fail. Check which inputs remain unavailable for unrelated spending. A reassuring error message is insufficient if the wallet’s coin selection has already released the wrong funds.
Show users what is still pending
A balance display can conceal these distinctions. LDK’s channel-details documentation says several fields continue describing the pre-splice channel until sufficient confirmations and the exchange of locking messages. That includes the funding output and channel value. An application reading only those fields could appear unchanged while a funding adjustment is underway.
The 0.3 development work adds a separate view of pending splice activity. Its implementation record describes exposing negotiation status, fee rate, contributions and candidate transactions awaiting confirmation. These details give interface designers information for distinguishing a request being negotiated from a transaction awaiting confirmation.
A useful screen should tell the user what is waiting, which amount is affected and whether further action is available. The same distinctions belong in support logs, so an operator can investigate a stalled adjustment without guessing from a single displayed balance.
Plan the version transition around live channels
The candidate’s compatibility notes contain consequential limits. A splice negotiated on an earlier LDK version cannot gain RBF support merely by upgrading while it remains pending. Downgrading to a pre-0.3 version after an RBF is unsupported. The notes also warn that downgrading with a pending splice fails when asynchronous monitor updates are in use.
An integration rehearsal should therefore include existing channels and unfinished operations, alongside newly created channels. Test normal completion, a rejected replacement and the supported restart paths. Record the exact library version and avoid promising a rollback until its compatibility conditions have been checked.
October’s candidate is useful evidence of implementation progress. For users evaluating an app, the useful evidence is its own version-specific documentation and tested behavior, including clear explanations of costs, waiting periods and failure states.