That is in the normal range for LBC/LTC. The time a swap takes is set mostly by the block spacing of the two chains involved, so a pair with slow blocks is slow for everyone, every time.
The record stops at MakerPaymentSpendConfirmFailed. The taker's claim on the maker's coin was broadcast but not seen to confirm.
taker_swap:2052] !wait for maker payment spend confirmations: rpc_clients:119] Waited too long until 1792412883 for transaction to be confirmed 3 times
By this step both payments were on their chains and the price had been struck, so the trade counts toward the reference price. The claim can still be made for as long as the payment is unspent, and since the timelock has passed the payer can take it back as well, so whichever lands first settles it. Whether it was retried is a question for the chain rather than for this log.
The chain says the claim landed: the payment was spent with the preimage, in d2787f0f3a9ab4afb1e68f40b17f575ad40d926e93d960ea7c0eb51da3b3762d. Checked 2026-10-19 14:59:06 UTC.
94c8250562efad7907457db9cf5a1db47775363a3657da849929ba3ae49876ef
Both payments are on their chains and locked to the same secret hash 4c1cace9db0be0e1f7dfdc691d901dcd477ecde5, and a preimage hashing to it was published on chain when one side claimed.
- MakerPaymentSent: 94c8250562efad7907457db9cf5a1db47775363a3657da849929ba3ae49876ef
7f8a5189a5b3c3c1b3cc443ae77f9cd903812d7a195477ece45bf1b8fd1ed8b3
Both payments are on their chains and locked to the same secret hash 4c1cace9db0be0e1f7dfdc691d901dcd477ecde5, and a preimage hashing to it was published on chain when one side claimed.
- TakerFeeValidated: e6d4e90920475c850265daaec56373052bff4e28ffcfb573a7ea788de516e055
- TakerPaymentReceived: 7f8a5189a5b3c3c1b3cc443ae77f9cd903812d7a195477ece45bf1b8fd1ed8b3
- TakerPaymentSpent: bfdd2cf84cb12ed2e5101e33d2ef482d15ec6ca57063f8a59c57823a842197d9
Reported by kdf-statsdb.