An atomic swap is not instant by design. Each side has to publish a transaction and wait for the other chain to confirm it, so the time it takes is set mostly by the block spacing of the two chains involved rather than by anything either party does.
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 1792111789 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 a3c847410bffcceffa3e80f75934dec11095079ae508a834c69e67d77d4b0408. Checked 2026-10-16 01:45:46 UTC.
e97f41c7a6e665d08be2b203988efcbcc0c6cef397ae01555c4a49b960f20dd4
Both payments are on their chains and locked to the same secret hash d40436ae79850e00e925cae75ce0f7ab0ee84e56, and a preimage hashing to it was published on chain when one side claimed.
- MakerPaymentSent: e97f41c7a6e665d08be2b203988efcbcc0c6cef397ae01555c4a49b960f20dd4
f815b4f96ca3ca02cba60c389c055351a2c244ef6427369cb720cdb66fef1266
Both payments are on their chains and locked to the same secret hash d40436ae79850e00e925cae75ce0f7ab0ee84e56, and a preimage hashing to it was published on chain when one side claimed.
- TakerFeeValidated: 56b0325cbfe57acb8cff873469098d34caaeb4d120d252f3b106fd0ec5c57022
- TakerPaymentReceived: f815b4f96ca3ca02cba60c389c055351a2c244ef6427369cb720cdb66fef1266
- TakerPaymentSpent: a65cda08de20af0d893508962d5be4b8779943bc2476a8663629a9e469d0237e
Reported by kdf-statsdb.