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.
Nothing was lost. The payment was never claimed: it was spent without the preimage, after the timelock, which is the refund path back to the payer, in 8c566414737c7b7737c83ba2eac33b493d00bd8a08dcbdaae8a3dab502713f3a.
The swap stopped at TakerPaymentSpendFailed. The maker's claim on the taker's coin was rejected; it can be retried for as long as that payment is unspent.
maker_swap:1269] !taker_coin.send_maker_spends_taker_payment: mm2src\coins\utxo\ "utxo_common:998] utxo_common:950] client:1132] : failed to parse list of 11 headers (coin=RVN, from=4416271, requested_count=11): UnexpectedEnd"
Recorded by the swap's own protocol log, which is the only source that knows: the aggregator reports failed and completed swaps identically. Nothing changed hands, so it sets no reference price.
9dd1180a9eef844bd80d280ec576325c2192822f13033d99c5fbab54fb27b7d3
ARRR settles as ZHTLC, whose transfers do not appear as an output any chain server can read, so the transaction the record names cannot be checked against a chain here
- MakerPaymentSent: 9dd1180a9eef844bd80d280ec576325c2192822f13033d99c5fbab54fb27b7d3
6a5843db5e24f97829151b9fc1c81241a77e1b72da9eddd4f82718050a9969e6
confirmed on-chain, locked to this swap's secret hash
- TakerFeeValidated: 5f5b4000648f3a09d07ba81857e0a30a3897592068661f27cbe6e430fc4ef4e9
- TakerPaymentReceived: 6a5843db5e24f97829151b9fc1c81241a77e1b72da9eddd4f82718050a9969e6
No flags are stored against this swap. Flags are written while a swap sits inside a live pricing window, so on an older swap their absence means it was never assessed rather than that it was assessed and found clean.
Reported by kdf-statsdb-8762.