That is in the normal range for PPC/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 1793143353 for transaction to be confirmed 2 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 35d1a3e6d75008ba33591ab01b6151b1c55d28c23df2514e13a12feb99d78fdf. Checked 2026-10-28 15:31:16 UTC.
481e962d36b5fdc30e6c71fc38861e5bd9487e34c60b6d588afa8fac8fffddc4
Both payments are on their chains and locked to the same secret hash 812a44dfd52ac8aad647841361bd4ca4cae66e90, and a preimage hashing to it was published on chain when one side claimed.
- MakerPaymentSent: 481e962d36b5fdc30e6c71fc38861e5bd9487e34c60b6d588afa8fac8fffddc4
070e303376521080dd91bb819658246cf62f8dc8f28b55e95e5cf67aae7c10db
Both payments are on their chains and locked to the same secret hash 812a44dfd52ac8aad647841361bd4ca4cae66e90, and a preimage hashing to it was published on chain when one side claimed.
- TakerFeeValidated: 033d4986dc576cf14d0b46597b3f48cf398b7d4324dc77cebb084b905784a50e
- TakerPaymentReceived: 070e303376521080dd91bb819658246cf62f8dc8f28b55e95e5cf67aae7c10db
- TakerPaymentSpent: 8be73a2ae59a329d5bf64634069c88a6c719a8edd4b1e4961df5a4f3625c006b
Reported by kdf-statsdb.