Channel splicing support #677

jkczyz · 2025-10-23T21:19:16Z

LDK 0.2 added beta support for splicing. This PR exposes it in LDK Node as two new Node methods: splice_in and splice_out. Funds used for splicing in are taken from the on-chain BDK wallet. When splicing out, any on-chain address can be provided as the destination.

Two new events are provided: SplicePending and SpliceFailed. The former is emitted once the new funding transaction has been broadcast. The latter indicates that any contributed inputs may be re-used, though this is not currently exposed. It should be used internally to unlock UTXOs that were intended to be spent.

ldk-reviews-bot · 2025-10-23T21:19:19Z

👋 Thanks for assigning @wpaulino 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.

ldk-reviews-bot · 2025-10-27T00:00:55Z

🔔 1st Reminder

Hey @tnull @TheBlueMatt @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-10-27T00:00:56Z

🔔 1st Reminder

Hey @tnull @TheBlueMatt @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-10-27T00:00:58Z

🔔 1st Reminder

Hey @tnull @TheBlueMatt @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

tnull

Thanks!

Looks mostly good, just a few comments. This will need bindings support, too, and unfortunately also need a rebase by now. Sorry!

src/event.rs

src/wallet/mod.rs

tnull · 2025-10-28T12:27:16Z

src/lib.rs

+		} else {
+			log_error!(
+				self.logger,
+				"Channel not found for user_channel_id: {:?} and counterparty: {}",


Pre-existing, but we should probably implement Display for UserChannelId, now opened #681

src/lib.rs

src/wallet/mod.rs

tnull · 2025-10-28T12:42:57Z

src/wallet/mod.rs

 		Ok(txid)
 	}

+	pub(crate) fn select_confirmed_utxos(


Would be cool to be able to reuse this for impl CoinSelectionSource while dropping impl WalletSource going forward. What do we think the necessary changes would be that would allow for this? Probably just making claim_id optional?

cc: @wpaulino

Hmm... are you saying have LDK Node's Wallet implement CoinSelectionSource directly? Would we implement UTXO locking there? Or are you assuming BDK's wallet will eventually implement this?

To re-use this code, yeah we can extract the Utxo from each FundingTxInput to use in CoinSelection. Though we need to expose that or have a conversion function. Currently, FundingTxInput::utxo is pub(super).

Hmm... are you saying have LDK Node's Wallet implement CoinSelectionSource directly?

Yes, it might be a bit more efficient than the detour over WalletSource, and would allow us to reuse most code, IIUC.

Would we implement UTXO locking there? Or are you assuming BDK's wallet will eventually implement this?

We could, although I still prefer to wait until BDK ships it soon hopefully. Might be debatable if we need to implement it manually in the meantime. However, the UTXO locking discussion seems orthogonal to whether or not to use CoinSelectionSource, no?

We could, although I still prefer to wait until BDK ships it soon hopefully. Might be debatable if we need to implement it manually in the meantime. However, the UTXO locking discussion seems orthogonal to whether or not to use CoinSelectionSource, no?

IIUC, seems we'd replace the lightning::events::bump_transaction::Wallet parameterization in BumpTransactionEventHandler with LDK Node's Wallet. But the former has some sort of locking already. Or at least it prefers not to double spend when possible.

https://github.com/lightningdevkit/rust-lightning/blob/17f7858f01f29ec904c5bddda799365f4f9ff71a/lightning/src/events/bump_transaction/mod.rs#L558-L559

We may be able to maintain a list of OutPoints to pass to TxBuilder::unspendable (filtered by claim id), attempting with and without the list.

We may be able to main a list of OutPoints to pass to TxBuilder::unspendable (filtered by claim id), attempting with and without the list.

Yeah, though note that would require us to track a list of locked OutPoints whenever we generate any Transaction. We'd then need to drop entries whenever they are spent and re-add them in case of a reorg, etc. This might become very complicated real quick, if we want to do it 'properly'.

I think an alternative approach would be to just always act as if we already saw the transaction in the mempool, i.e., call Wallet::apply_unconfirmed_txs, and then the Wallet should do the right thing and eventually mark the transaction as evicted if it wouldn't end up in the mempool afterall.

Hmm, maybe it would even make sense to go with the last described approach in this PR (also for non-splicing funding transactions). If we do, we might however finally need to handle DiscardFunding, too.

I think an alternative approach would be to just always act as if we already saw the transaction in the mempool, i.e., call Wallet::apply_unconfirmed_txs, and then the Wallet should do the right thing and eventually mark the transaction as evicted if it wouldn't end up in the mempool afterall.

Hmmm... would we do this when CoinSelectionSource::sign_psbt is called? We don't have the transaction in CoinSelectionSource::select_confirmed_utxos.

Hmm, maybe it would even make sense to go with the last described approach in this PR (also for non-splicing funding transactions). If we do, we might however finally need to handle DiscardFunding, too.

Which approach?

src/lib.rs

tnull · 2025-10-28T12:51:30Z

src/config.rs

+	/// users should be aware of the backwards compatibility risk prior to using the functionality.
+	///
+	/// [`Node`]: crate::Node
+	pub reject_inbound_splices: bool,


IIUC, contrary to the docs here and in LDK, this flag is necessary to still support downgrades, i.e., forwards, not backwards compatibility (we might want to fix this/make this more clear in the LDK docs).

However, we currently don't support downgrades in LDK Node anyways, so here we can just omit this flag.

I think CI is still failing because reject_inbound_splices is still here even though it hasn't been added to the bindings.

Right, I'm not sure how consistent we've been with using forward and backward compatibility correctly. For instance, IIUC, should this have said backward compatibility?

https://github.com/lightningdevkit/rust-lightning/blob/17f7858f01f29ec904c5bddda799365f4f9ff71a/lightning/src/chain/channelmonitor.rs#L4522-L4523

And these like reject_inbound_splices should have said forward compatibility?

https://github.com/lightningdevkit/rust-lightning/blob/17f7858f01f29ec904c5bddda799365f4f9ff71a/lightning/src/util/config.rs#L915
https://github.com/lightningdevkit/rust-lightning/blob/17f7858f01f29ec904c5bddda799365f4f9ff71a/lightning/src/util/config.rs#L941

Maybe it would be best to avoid "backward" / "forward" and just say "compatibility" when referencing an earlier version. Seems these could be confusing if it is unclear if the term is relative to older or newer version.

I think CI is still failing because reject_inbound_splices is still here even though it hasn't been added to the bindings.

Yup, gonna drop the commit, so that will fix CI.

should this have said backward compatibility

I think so, yes.

And these like reject_inbound_splices should have said forward compatibility?

Yes, I think so, too.

Maybe it would be best to avoid "backward" / "forward" and just say "compatibility" when referencing an earlier version. Seems these could be confusing if it is unclear if the term is relative to older or newer version.

Yeah, that sounds reasonable. Seems there often is confusion around it and 'compatibility with versions prior' is much more precise anyways.

tests/integration_tests_rust.rs

tnull · 2025-10-28T12:53:58Z

tests/integration_tests_rust.rs


+#[test]
+fn splice_channel() {
+	macro_rules! expect_splice_pending_event {


nit: Usually we'd add this to common/mod.rs.

Since it wasn't being used there, having it there would give a build warning.

That's a good point about the build warning.

To resolve that and utilize the macro more broadly, what do you think about adding a test for splice-in/splice-out assertions into do_channel_full_cycle? We could use the new expect_splice_pending_event! macro there, which would justify having it in common/mod.rs and make our full-cycle test more robust for splicing.

Started looking into this. @tnull The channel funding transaction is recognized as an outbound on-chain payment for A -- presumably because we are spending from the wallet. If B were to splice out paying A (or whomever), should the splice funding transaction be considered an outbound on-chain payment for B? It does not currently since it spends from the funding txo.

Started looking into this. @tnull The channel funding transaction is recognized as an outbound on-chain payment for A -- presumably because we are spending from the wallet. If B were to splice out paying A (or whomever), should the splice funding transaction be considered an outbound on-chain payment for B? It does not currently since it spends from the funding txo.

Hmm, yeah, unfortunately that will be the case prior to 0.3 when we get lightningdevkit/rust-lightning#3566. I think having splice-out counting as an outbound onchain transaction makes sense until then. Might be worth noting somewhere that this is the case though, and that PaymentKinds will change in the future. (Tbh. one reason why I think it would make sense to flag splicing support alpha/experimental, simply as the classification API is unstable currently).

Hmm... so currently we don't have the Txid until we see an LdkEvent::FundingTransactionReadyForSigning, but we've lost the context of the transaction at that point. We can assume it is a splice (could be dual-funding later), but it might difficult to determine if it is a splice-out. Maybe simply seeing that none of the inputs belong to our wallet would be sufficient? We should only see the event if we have any contributions / are the initiator, IIRC.

Hmm... so currently we don't have the Txid until we see an LdkEvent::FundingTransactionReadyForSigning, but we've lost the context of the transaction at that point. We can assume it is a splice (could be dual-funding later), but it might difficult to determine if it is a splice-out. Maybe simply seeing that none of the inputs belong to our wallet would be sufficient? We should only see the event if we have any contributions / are the initiator, IIRC.

Okay. That makes me wonder even more if we should wait for LDK#3566 above to be able to classify them properly.

Hmm, maybe let's just stick with adding splice-ins (which will be marked outbound payments) for now, while noting this behavior on the splice_in/splice_out methods under an 'Experimental API' section or similiar?

jkczyz

Need to rebase still.

src/wallet/mod.rs

src/lib.rs

src/wallet/mod.rs

jkczyz · 2025-10-28T23:45:12Z

tests/integration_tests_rust.rs


+#[test]
+fn splice_channel() {
+	macro_rules! expect_splice_pending_event {


Since it wasn't being used there, having it there would give a build warning.

ldk-reviews-bot · 2025-10-29T00:01:48Z

🔔 2nd Reminder

Hey @TheBlueMatt @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-10-29T00:01:51Z

🔔 2nd Reminder

Hey @TheBlueMatt @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

chuksys

I'm really excited to see Splicing being added to LDK-Node - this is a fantastic feature! I learned a lot reviewing this PR.

I've left two minor, non-blocking comments regarding the CI failure and a test organization suggestion (to utilize the new macro in do_channel_full_cycle).

Great work!

chuksys · 2025-10-29T15:47:21Z

src/config.rs

+	/// users should be aware of the backwards compatibility risk prior to using the functionality.
+	///
+	/// [`Node`]: crate::Node
+	pub reject_inbound_splices: bool,


I think CI is still failing because reject_inbound_splices is still here even though it hasn't been added to the bindings.

chuksys · 2025-10-29T16:30:56Z

tests/integration_tests_rust.rs


+#[test]
+fn splice_channel() {
+	macro_rules! expect_splice_pending_event {


That's a good point about the build warning.

To resolve that and utilize the macro more broadly, what do you think about adding a test for splice-in/splice-out assertions into do_channel_full_cycle? We could use the new expect_splice_pending_event! macro there, which would justify having it in common/mod.rs and make our full-cycle test more robust for splicing.

ldk-reviews-bot · 2025-11-01T00:01:01Z

🔔 3rd Reminder

Hey @TheBlueMatt @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-11-01T00:01:04Z

🔔 3rd Reminder

Hey @TheBlueMatt @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-11-03T00:01:25Z

🔔 4th Reminder

Hey @TheBlueMatt @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-11-03T00:01:27Z

🔔 4th Reminder

Hey @TheBlueMatt @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-11-05T00:02:01Z

🔔 5th Reminder

Hey @TheBlueMatt @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-11-05T00:02:03Z

🔔 5th Reminder

Hey @TheBlueMatt @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

benthecarman

have some weirdness with events and tx history that could be fixed or at least documented

spice outs never show up in my history
splice ins do but do not show the fees
would be nice if the ChannelReady event could clarify between spliced channels and new channels. New channels means i have a new balance that is usable, this isn't always the case with splices though

benthecarman · 2025-11-06T00:52:42Z

src/wallet/mod.rs

+				locked_wallet
+					.tx_details(txin.previous_output.txid)
+					.map(|tx_details| tx_details.tx.deref().clone())
+					.map(|prevtx| FundingTxInput::new_p2wpkh(prevtx, txin.previous_output.vout))


this scared me at first but then found the wallet only uses p2wpkh, should add a comment saying that

Added debug assertions.

benthecarman · 2025-11-06T02:53:12Z

src/lib.rs

+	/// This provides for increasing a channel's outbound liquidity without re-balancing or closing
+	/// it. Once negotiation with the counterparty is complete, the channel remains operational
+	/// while waiting for a new funding transaction to confirm.
+	pub fn splice_in(


one issue I am having with this is that there is no way to see how much we spend on fees doing this. Would be nice if this function returned it or if it was somehow included in the PaymentDetails

@tnull How should we expose this? Or should we wait until the payment API changes are addressed?

@tnull How should we expose this? Or should we wait until the payment API changes are addressed?

Yes, I'd be in favor of postponing it for now. How to expose fees for onchain transactions in general is also still an open question (see #578), so we might want to come up with a simliar API design for all cases.

did some digging on this, and found the issue is actually because we don't have the original channel funding utxo in the wallet when calculating the fee here

ldk-node/src/wallet/mod.rs

Line 194 in 3505dfb

let fee = locked_wallet.calculate_fee(&wtx.tx_node.tx).unwrap_or(Amount::ZERO);

can do something like this to fix, not the prettiest though as we have a dummy spk
benthecarman@a51e4b5

Chatted with @benthecarman offline. Yeah, it sounds like this is what we need to do. If we want the actual txout in the wallet, we'd need a way to access from LDK, possibly just through ChannelDetails. @TheBlueMatt @tnull Would it be worth adding that in LDK 0.2?

Summarizing some offline discussions:

Because the BDK wallet doesn't know about the funding transaction, the payment store will show Amount::ZERO fee for the splice-in, which it categorized as an outbound on-chain payment

This can be fixed by having the BDK wallet track the funding txo as @benthecarman shows, but requires using fake pubkeys since LDK doesn't expose the channel's funding pubkeys

Using fake pubkeys may not be ideal because we'd persist these when writing the BDK wallet.

Options:

Keep the current behavior of showing Amount::ZERO for the splice-in fees until it can be done properly in Add APIs to classify channel-related transaction types rust-lightning#3566

Use fake pubkeys and live with having inaccurate txouts in the persisted BDK wallet

Expose the funding pubkeys upstream either as part of ChannelDetails or in the ChannelPending event

Hmm, I think I'd like to avoid adding fake pubkeys, because I am not fully sure what the consequences would be for BDK-internals. In particular, I fear we we could run into issues in case of reorgs/evictions, as the wallet wouldn't detect anything for the fake pubkey during syncing?

Expose the funding pubkeys upstream either as part of ChannelDetails or in the ChannelPending event

That would be my preferred option. If we can't get that in 0.2 still, we could just show Amount::ZERO for now, especially given that we'll need to add a huge disclaimer around payment store misclassification anyways. Note however that I don't see how this issue is connected to lightningdevkit/rust-lightning#3566, given that the solution we currently envision there is to simply add a enum BroadcastType to BroadcasterInterface that would allow us to intercept and curate a mapping of <Txid, BroadcastType>...

Ah, right, the fees would still be inaccurate. Any preference to ChannelDetails or ChannelPending? Both are serializable, so we can't avoid an Option. Though ChannelDetails is only persisted when used with phantom payments, IIUC.

src/lib.rs

tnull

Seems tests are still failing:

thread 'splice_channel' panicked at tests/integration_tests_rust.rs:1021:5:
assertion `left == right` failed
  left: 4399013
 right: 4399056

jkczyz · 2025-11-07T15:46:34Z

Seems tests are still failing:

thread 'splice_channel' panicked at tests/integration_tests_rust.rs:1021:5:
assertion `left == right` failed
  left: 4399013
 right: 4399056

Huh, I couldn't reproduce that locally (macos) even after rebasing. And re-running the canceled macos job shows it passing. So seem limited to ubuntu. Any idea why that would be?

When a channel is spliced, the existing funding transaction's output is spent and a new funding transaction output is formed. Once the splice is considered locked by both parties, LDK will emit a ChannelReady event which will include the new funding_txo. Additionally, the initial ChannelReady event now includes the original funding_txo. Include this data in LDK Node's ChannelReady event.

When the interactive-tx construction protocol completes in LDK during splicing (and in the future dual-funding), LDK Node must provide signatures for any non-shared inputs belonging to its on-chain wallet. This commit implements this when handling the corresponding FundingTransactionReadyForSigning event.

Extract the funds availability checking logic from open_channel_inner into a separate method so that it can be reused for channel splicing.

Instead of closing and re-opening a channel when outbound liquidity is exhausted, splicing allows to adding more funds (splice-in) while keeping the channel operational. This commit implements splice-in using funds from the BDK on-chain wallet.

Instead of closing and re-opening a channel when on-chain funds are needed, splicing allows removing funds (splice-out) while keeping the channel operational. This commit implements splice-out sending funds to a user-provided on-chain address.

Since LDK Node does not support downgrades, there's no need to have a Config parameter for accepting inbound splices. Instead, enable it by default.

jkczyz · 2025-11-07T16:35:36Z

Seems tests are still failing:
thread 'splice_channel' panicked at tests/integration_tests_rust.rs:1021:5:
assertion `left == right` failed
  left: 4399013
 right: 4399056
Huh, I couldn't reproduce that locally (macos) even after rebasing. And re-running the canceled macos job shows it passing. So seem limited to ubuntu. Any idea why that would be?

Ok, my theory is that this is off because LDK will produce a PaymentClaimed event before resolving the HTLC. This throws off the assertion because the closing transaction fee will be higher until then. I had seen something similar when writing a splicing test in LDK before re-working it.

Pushed some fixups to mine a block after receiving the payment as a way to hopefully mitigate this. Not sure if there's a better way.

benthecarman · 2025-11-07T23:02:09Z

Doing this in orange so we can have splice outs in our history, not really sure a better way around this. Maybe we could eventually watch the funding txo with bdk but that would complicate calculating balance

https://github.com/lightningdevkit/orange-sdk/commit/5e649e9dd6c3f27e3a2e422f52223679a31ed780

ldk-reviews-bot · 2025-11-08T00:00:57Z

🔔 6th Reminder

Hey @TheBlueMatt @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-11-08T00:01:01Z

🔔 6th Reminder

Hey @TheBlueMatt @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-11-10T00:01:43Z

🔔 7th Reminder

Hey @TheBlueMatt @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-11-10T00:01:45Z

🔔 7th Reminder

Hey @TheBlueMatt @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-11-12T00:02:15Z

🔔 8th Reminder

Hey @TheBlueMatt @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-11-12T00:02:17Z

🔔 8th Reminder

Hey @TheBlueMatt @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

jkczyz requested review from TheBlueMatt, tnull and wpaulino October 23, 2025 21:19

tnull reviewed Oct 28, 2025

View reviewed changes

jkczyz force-pushed the 2025-10-splicing branch from 982ce34 to 57ad1c8 Compare October 28, 2025 23:45

jkczyz commented Oct 28, 2025

View reviewed changes

jkczyz force-pushed the 2025-10-splicing branch from 57ad1c8 to 281ebce Compare October 29, 2025 03:49

chuksys reviewed Oct 29, 2025

View reviewed changes

jkczyz force-pushed the 2025-10-splicing branch from 281ebce to adb59c8 Compare October 29, 2025 22:23

jkczyz added this to Weekly Goals Oct 30, 2025

jkczyz self-assigned this Oct 30, 2025

benthecarman reviewed Nov 6, 2025

View reviewed changes

jkczyz force-pushed the 2025-10-splicing branch from adb59c8 to a715e63 Compare November 6, 2025 16:47

tnull reviewed Nov 7, 2025

View reviewed changes

tnull mentioned this pull request Nov 7, 2025

Consider allowing users to see transaction details before sending onchain payments #578

Open

jkczyz added 2 commits November 7, 2025 10:20

f - bindings

bc3b23f

jkczyz added 19 commits November 7, 2025 10:20

f - extract_tx

be63d88

Refactor funds checking logic into reusable method

6647b03

Extract the funds availability checking logic from open_channel_inner into a separate method so that it can be reused for channel splicing.

Add Node::splice_in method

118df9f

Instead of closing and re-opening a channel when outbound liquidity is exhausted, splicing allows to adding more funds (splice-in) while keeping the channel operational. This commit implements splice-in using funds from the BDK on-chain wallet.

f - import

5262774

f - fee_estimator clean-up

e1be0ad

f - bindings

71f5208

f - update docs

e888789

f - debug_assert

45b74b0

Add Node::splice_out method

4a5fa58

Instead of closing and re-opening a channel when on-chain funds are needed, splicing allows removing funds (splice-out) while keeping the channel operational. This commit implements splice-out sending funds to a user-provided on-chain address.

f - fee_estimator clean-up

49692d9

f - bindings

1ae1da5

f - update docs

fdd4e41

f - use reference

d7f6c12

Accept inbound splice attempts

2609eea

Since LDK Node does not support downgrades, there's no need to have a Config parameter for accepting inbound splices. Instead, enable it by default.

Add an integration test for splicing

09b17c9

f - fix test flakiness?

68f0d4d

Test splicing in do_channel_full_cycle

4bfb26f

f - fix test flakiness?

913b968

jkczyz force-pushed the 2025-10-splicing branch from a715e63 to 913b968 Compare November 7, 2025 16:25

tnull mentioned this pull request Nov 10, 2025

LDK Node v0.7 Tracking issue #443

Open

9 tasks

tnull added this to the 0.7 milestone Nov 10, 2025

Channel splicing support #677

Are you sure you want to change the base?

Channel splicing support #677

Uh oh!

Conversation

jkczyz commented Oct 23, 2025

Uh oh!

ldk-reviews-bot commented Oct 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ldk-reviews-bot commented Oct 27, 2025

Uh oh!

ldk-reviews-bot commented Oct 27, 2025

Uh oh!

ldk-reviews-bot commented Oct 27, 2025

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

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!

jkczyz Oct 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

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!

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!

jkczyz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ldk-reviews-bot commented Oct 29, 2025

Uh oh!

ldk-reviews-bot commented Oct 23, 2025 •

edited

Loading

jkczyz Oct 29, 2025 •

edited

Loading

benthecarman left a comment •

edited

Loading

tnull Nov 7, 2025 •

edited

Loading