This one took about 5.4× the usual for PND/LTC. Waiting longer than usual is not in itself a failure: a swap waits on confirmations from both chains, and a slow block or a busy network stretches it.
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 1790564979 for transaction to be confirmed 1 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 2052b0c65c8317a25190ad681c161f2a7266e2b03426633eaf75397f62c29e29. Checked 2026-09-28 11:49:24 UTC.
eb16051e7ac2ba0f43153e4c50996049570d068261cea5d370f48cf8c0af2fb1
Both payments are on their chains and locked to the same secret hash 59bb4653073f79f3075603a24521b5bccded9765, and a preimage hashing to it was published on chain when one side claimed.
- MakerPaymentSent: eb16051e7ac2ba0f43153e4c50996049570d068261cea5d370f48cf8c0af2fb1
dba05ad425a9c26e45f27a32df5dea3b4a2f406f3ebac92b120dca43260995c7
Both payments are on their chains and locked to the same secret hash 59bb4653073f79f3075603a24521b5bccded9765, and a preimage hashing to it was published on chain when one side claimed.
- TakerFeeValidated: 7952a085f44f6046d80aaf2109babd5defaf4de6c00d183902a0f0241fcd46ca
- TakerPaymentReceived: dba05ad425a9c26e45f27a32df5dea3b4a2f406f3ebac92b120dca43260995c7
- TakerPaymentSpent: 979638524ce0b14a14c1f0f2a60f788f6edd90d263e4dfd06de282ca76923c6a
Reported by kdf-statsdb-8762.