Allow specifying a fee rate for channel-open funding transactions by kaloudis · Pull Request #1099 · lightningdevkit/ldk-node

kaloudis · 2026-09-14T17:04:34Z

Motivation

Wallet UIs commonly collect a sat/vB fee rate in their channel-open flow, but LDK Node offers no way to apply it: the funding transaction is always built at the internal estimator's ChannelFunding rate. #176 added exactly this kind of override for the on-chain send APIs; this PR extends the same pattern to channel opens.

Surveying ldk-node integrators: Zeus collects an open-channel fee rate in its UI and had to carry this as a downstream fork patch (ZeusLN#6, adapted here to current main), and Alby Hub and Bitkit currently have no way to offer the option at all through ldk-node's API.

Changes

All Node::open_channel variants (open_channel, open_announced_channel, the _with_all and _0reserve variants) gain a trailing Option<FeeRate> (FeeRate? in bindings):

open_channel_inner stashes the rate in a new pending_funding_fee_rates: Mutex<HashMap<u128, FeeRate>> keyed by user_channel_id once create_channel succeeds
the FundingGenerationReady handler removes the entry and passes it to Wallet::create_funding_transaction, which now takes Option<FeeRate> and falls back to the estimator when None (same shape as send_to_address)
for FundingAmount::Max the override also feeds get_max_funding_amount, so the maximum amount is computed at the rate the funding transaction will actually pay
ChannelClosed clears any still-pending entry, so state stashed for a channel that is rejected or dies before funding does not leak

When the parameter is unset, behavior is byte-for-byte unchanged.

This is a breaking signature change on the six open methods; a Feature and API updates CHANGELOG entry is included, and all internal call sites (tests, doctest) are updated.

Testing

cargo check, cargo check --features uniffi, and cargo check --tests pass
cargo test --lib (196 tests) and cargo test --doc pass
cargo fmt --all -- --check clean

An earlier version of this change (against the 0.7 API) is what Zeus ships; it has unit coverage on the wallet side and device testing pending there.

Disclosure

This change was developed with the assistance of an AI coding tool (Claude Code), per the repository's contribution guidelines.

ldk-reviews-bot · 2026-09-14T17:04:37Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

tnull

Hmm, I'm honestly not convinced we should do this as it kind of introduces additional footguns that might be more easily to hit in comparison to the onchain send cases.

Do you really expose manual fee rate setting to the user? Can you explain why a user wants to set a specific manual fee rate override? Would having more general fee estimator profiles would make more sense (allowing to specify 'economical' vs. 'fast confirmation' or similar)?

kaloudis · 2026-09-17T15:13:34Z

Hmm, I'm honestly not convinced we should do this as it kind of introduces additional footguns that might be more easily to hit in comparison to the onchain send cases.

Do you really expose manual fee rate setting to the user? Can you explain why a user wants to set a specific manual fee rate override? Would having more general fee estimator profiles would make more sense (allowing to specify 'economical' vs. 'fast confirmation' or similar)?

Yes, we've supported manual fee rates for on-chain sends and channel operations since the early days of ZEUS. We've defaulted to using recommendations from our Mempool.space/Esplora instances but some users want more granular controls, especially in higher fee rate environments.

tnull · 2026-09-17T17:14:12Z

Yes, we've supported manual fee rates for on-chain sends and channel operations since the early days of ZEUS. We've defaulted to using recommendations from our Mempool.space/Esplora instances but some users want more granular controls, especially in higher fee rate environments.

Alright, honestly don't quite buy the argument for mobile (or rather think that if it just were for mobile we could find a better API than raw fee rates), but I do buy it for LDK Server users. So fine by me to move forward with this.

CI is currently failing though, could you also adjus the Python/Kotlin tests for the new API?

kaloudis · 2026-10-03T00:57:52Z

Yes, we've supported manual fee rates for on-chain sends and channel operations since the early days of ZEUS. We've defaulted to using recommendations from our Mempool.space/Esplora instances but some users want more granular controls, especially in higher fee rate environments.

Alright, honestly don't quite buy the argument for mobile (or rather think that if it just were for mobile we could find a better API than raw fee rates), but I do buy it for LDK Server users. So fine by me to move forward with this.

CI is currently failing though, could you also adjus the Python/Kotlin tests for the new API?

Tests updated

tnull · 2026-10-05T12:09:50Z

 				);
+				if let Some(fee_rate) = fee_rate {
+					self.pending_funding_fee_rates
+						.lock()


AI:

[P2] Register the fee override before creating the channel — /home/tnull/workspace/ldk-node-review-pr-1099-T3mKz4/src/lib.rs:1475. create_channel releases its locks and queues the open message before this insertion. If the caller pauses—such as during the preceding log write—the background processor can handle FundingGenerationReady first and silently use the estimator’s rate. This can overpay fees or fail a _with_all opening calculated at the requested rate. Insert the override before calling LDK, and remove it if creation fails.

Good catch. The override is now inserted into pending_funding_fee_rates before create_channel or create_channel_to_trusted_peer_0reserve is called. user_channel_id is already generated at that point. On Err the entry is removed. If add_peer fails after a successful create_channel the entry stays, since the channel is live and ChannelClosed cleans it up. Fixed in 1669afc.

tnull · 2026-10-05T12:13:44Z

 //! 	let node_id = PublicKey::from_str("NODE_ID").unwrap();
 //! 	let node_addr = SocketAddress::from_str("IP_ADDR:PORT").unwrap();
-//! 	node.open_channel(node_id, node_addr, 10000, None, None).unwrap();
+//! 	node.open_channel(node_id, node_addr, 10000, None, None, None).unwrap();


We need to also update the example in README.md

Updated in 090dc4f

tnull · 2026-10-05T12:15:15Z

 	pub fn open_channel(
 		&self, node_id: PublicKey, address: SocketAddress, channel_amount_sats: u64,
 		push_to_counterparty_msat: Option<u64>, channel_config: Option<ChannelConfig>,
+		fee_rate: Option<FfiFeeRate>,


nit: Can we move this (everywhere) after push_to_counterparty_msat, so that channel_config remains the last argument?

Done in 8c67453. fee_rate now comes right after push_to_counterparty_msat in all six methods and the UDL, so channel_config stays last. Also changed the CHANGELOG entry, which called it "trailing".

tnull · 2026-10-05T12:15:47Z

+#[cfg(feature = "uniffi")]
+type FfiFeeRate = Arc<bitcoin::FeeRate>;
+
+macro_rules! maybe_map_fee_rate_opt {


Please move this macro to ffi/mod.rs and preferably DRY up with the one in payment/onchain.rs.

Would also be great to make it a method rather than a macro.

Done in 39a9570. It's now a maybe_map_fee_rate_opt() function in ffi/mod.rs, with uniffi/non-uniffi variants like maybe_deref/maybe_wrap, plus a shared FfiFeeRate alias. Both the lib.rs macro and the one in payment/onchain.rs are removed.

kaloudis · 2026-10-05T21:18:48Z

@tnull great feedback, thank you. All fixes have separate commits. Let me know if you'd like to squash before merge.

tnull

Please squash fixups. Feel free to pull out the helper moves into a freestanding prefactor commit.

tnull · 2026-10-06T09:24:17Z

 		&self, node_id: PublicKey, address: SocketAddress, channel_amount_sats: FundingAmount,
 		push_to_counterparty_msat: Option<u64>, channel_config: Option<ChannelConfig>,
 		announce_for_forwarding: bool, disable_counterparty_reserve: bool,
+		fee_rate: Option<bitcoin::FeeRate>,


nit: Please make this consistent and move it to before channel_config.

Done in 56ad543. fee_rate now comes before channel_config in open_channel_inner and all of its call sites.

tnull · 2026-10-13T07:44:20Z

@kaloudis Please feel free to re-request review once you squashed.

Replace the `maybe_map_fee_rate_opt!` macro and `FeeRate` alias in `payment/onchain.rs` with a `maybe_map_fee_rate_opt` function and a shared `FfiFeeRate` alias in `ffi/mod.rs`, next to the other `uniffi`/non-`uniffi` conversion helpers, so they can be reused outside of `OnchainPayment`.

Add an optional `fee_rate` parameter to all `open_channel` variants, ahead of `channel_config`. When set, it is used for the funding transaction and for computing the maximum funding amount of the `_with_all` variants instead of the `ChannelFunding` estimate. The override is registered in `pending_funding_fee_rates` before calling `create_channel`, so it is in place when `FundingGenerationReady` is handled, and removed again if channel creation fails. Pending overrides are cleared when channels close. Update the README, docs, and Rust, Python, and Kotlin call sites for the new parameter.

Open one channel with an exact amount and one via `open_channel_with_all` at 25 sat/vB and check the funding transaction pays that rate. The `_with_all` case also covers the maximum amount being computed at the overridden rate.

tnull

Thanks! I think as a follow up we should now include the fees in the anchor reserve checks (cf. #1166), but landing this.

kaloudis mentioned this pull request Sep 14, 2026

feat: allow specifying a fee rate for channel-open funding transactions ZeusLN/ldk-node#6

Open

ldk-reviews-bot requested a review from tnull September 14, 2026 17:15

tnull reviewed Sep 17, 2026

View reviewed changes

kaloudis force-pushed the channel-open-fee-rate-upstream branch from db51d21 to f1128f6 Compare September 17, 2026 17:21

tnull reviewed Oct 5, 2026

View reviewed changes

kaloudis force-pushed the channel-open-fee-rate-upstream branch 2 times, most recently from a44ad44 to e1b7be0 Compare October 5, 2026 21:14

tnull reviewed Oct 6, 2026

View reviewed changes

shubhamkmr04 mentioned this pull request Oct 12, 2026

Allow specifying a fee rate when splicing #1159

Merged

kaloudis added 3 commits October 13, 2026 10:11

Test that channel-open fee-rate override is applied

11454c2

Open one channel with an exact amount and one via `open_channel_with_all` at 25 sat/vB and check the funding transaction pays that rate. The `_with_all` case also covers the maximum amount being computed at the overridden rate.

kaloudis force-pushed the channel-open-fee-rate-upstream branch from e1b7be0 to 11454c2 Compare October 13, 2026 14:22

kaloudis requested a review from tnull October 13, 2026 14:28

tnull mentioned this pull request Oct 14, 2026

Include fees in anchor reserve checks #1166

Open

tnull approved these changes Oct 14, 2026

View reviewed changes

tnull merged commit 60cc83f into lightningdevkit:main Oct 14, 2026
14 of 25 checks passed

Conversation

kaloudis commented Sep 14, 2026

Motivation

Changes

Testing

Disclosure

Uh oh!

ldk-reviews-bot commented Sep 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

kaloudis commented Sep 17, 2026

Uh oh!

tnull commented Sep 17, 2026

Uh oh!

kaloudis commented Oct 3, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kaloudis commented Oct 5, 2026

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tnull commented Oct 13, 2026

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ldk-reviews-bot commented Sep 14, 2026 •

edited

Loading