This is possible even though Monero (XMR) has neither hashing nor timelocks.
Only one chain must have sufficient scripting capabilities, while the other one does not.
All that's needed of the non-scriptable chain is that it uses elliptic curve signatures and that transactions are immutable after some time. The scheme doesn't have to be used only to swap with XMR, it can be used for any such non-scriptable chain.
More details:
Novel thing is that parties can use their one-time keys from a different curve on the scriptable chain to interactively construct an encrypted one-time key on the non-scriptable chain, such key that signing something on the scriptable chain allows the other party to decrypt the one-time key on the non-scriptable chain.
This means that on scriptable chain the swap contract will be a HTLC multisig (BTC) or a HTLC covenant (BCH), while on the other chain (XMR) it will be just a normal UTXO.
Say Bob has BTC or BCH and wants XMR
Alice has XMR and wants BTC or BCH
A&B generate their one-time keys for the scriptable chain, and then cooperate to construct the XMR pubkey
Bob funds the contract on BTC or BCH chain
Alice observes the transaction has been mined, funds the XMR output
Bob releases the secret to open the hashlock on the scriptable chain
Alice uses the hashlock secret + her one-time key to take the BTC or BCH; in doing so she reveals the other half of the XMR key
Bob learns the missing piece of info from Alice's signature, decrypts the XMR secret key, and takes the XMR
Refund
The contract on the scriptable chain is a 2-transaction contract.
Regular swap uses only one transaction, but if 1st timelock expires, funds can be forwarded to the 2nd contract: the refund HTLC contract.
There, the roles are reversed.
In refund contract it is Bob who uses the revealing signature to take his BTC or BCH back, and in doing so reveals the missing piece for Alice to take back her XMR.
If Bob is missing in action and doesn't claim the refund on time, the 2nd timelock opens a recovery path where Alice can just take his BCH after a grace period (and XMR is stuck/lost). Instead of XMR refund, Alice gets BCH as if trade went through, while Bob gets nothing.
If Bob cooperates on refund (exercises his option), then he can take the BTC or BCH back, and in doing so reveal his half of the key for Alice to take her XMR back.
Note on Signature Malleability
The original paper claimed that SegWit is needed due to malleability because there the involved parties have to pre-sign the refund spending path, and malleating the parent TXID would invalidate the signatures.
This is true for chains that have pre-2017 version of Bitcoin ScriptVM.
However, since then, BCH has seen 2 upgrades that allow an alternative method:
OP_CHECKDATASIG (2018) - this allows for contracts checking a signature for a message from stack, message which can be hardcoded into the contract
Introspection opcodes (2022) - together with OP_CAT and OP_SPLIT (2018) - this allows the Script to generate a custom SIGHASH to sign, emulating ANYPREVOUT, or, just directly verifying parts of the transactions without having to emulate it using checksig.
Using this we can construct a proper covenant, and if parent gets malleated then the other party can just update the child TX's prevout refs by themselves without breaking any signature - so malleability problem is removed by making the descendant TX malleable, too, and the resulting contracts are much smaller, since relatively big multisig signatures are replaced with simple covenant code.
More details here:
This is possible even though Monero (XMR) has neither hashing nor timelocks. Only one chain must have sufficient scripting capabilities, while the other one does not. All that's needed of the non-scriptable chain is that it uses elliptic curve signatures and that transactions are immutable after some time. The scheme doesn't have to be used only to swap with XMR, it can be used for any such non-scriptable chain. More details:
How does it work?
Novel thing is that parties can use their one-time keys from a different curve on the scriptable chain to interactively construct an encrypted one-time key on the non-scriptable chain, such key that signing something on the scriptable chain allows the other party to decrypt the one-time key on the non-scriptable chain.
This means that on scriptable chain the swap contract will be a HTLC multisig (BTC) or a HTLC covenant (BCH), while on the other chain (XMR) it will be just a normal UTXO.
Say Bob has BTC or BCH and wants XMR Alice has XMR and wants BTC or BCH
Refund
The contract on the scriptable chain is a 2-transaction contract. Regular swap uses only one transaction, but if 1st timelock expires, funds can be forwarded to the 2nd contract: the refund HTLC contract.
There, the roles are reversed. In refund contract it is Bob who uses the revealing signature to take his BTC or BCH back, and in doing so reveals the missing piece for Alice to take back her XMR.
If Bob is missing in action and doesn't claim the refund on time, the 2nd timelock opens a recovery path where Alice can just take his BCH after a grace period (and XMR is stuck/lost). Instead of XMR refund, Alice gets BCH as if trade went through, while Bob gets nothing.
If Bob cooperates on refund (exercises his option), then he can take the BTC or BCH back, and in doing so reveal his half of the key for Alice to take her XMR back.
Note on Signature Malleability
The original paper claimed that SegWit is needed due to malleability because there the involved parties have to pre-sign the refund spending path, and malleating the parent TXID would invalidate the signatures. This is true for chains that have pre-2017 version of Bitcoin ScriptVM.
However, since then, BCH has seen 2 upgrades that allow an alternative method:
Using this we can construct a proper covenant, and if parent gets malleated then the other party can just update the child TX's prevout refs by themselves without breaking any signature - so malleability problem is removed by making the descendant TX malleable, too, and the resulting contracts are much smaller, since relatively big multisig signatures are replaced with simple covenant code. More details here:
https://bitcoincashresearch.org/t/monero-bch-atomic-swaps/545/14
Note that there's a 10.5 XMR bounty for the first XMR-BCH swap: https://bounties.monero.social/posts/37/10-500m-bch-xmr-atomic-swaps