This is pretty cool. If I understand it correctly, it means an Ark user could do a swap with someone who has onchain sats and it doesn't require any special modification of the Ark server. Indeed, it seems like something like Boltz could use a protocol like this to set up a swap service. It doesn't much change the security assumptions of Ark, but it seems like a good thing if there are multiple paths for users to get to the chain (in this case, selling your Ark-sats for BTC).

The protocol lets Bob pay BTC on-chain and receive an Ark VTXO from Alice. Alice receives BTC only by revealing the adaptor secret Bob needs to complete the Ark receive. If either party stops before that reveal, the other party has an on-chain recovery path.

This is a client-only protocol. The Ark server is not modified and is not told that a swap is happening. It sees ordinary Ark wallet operations: an adaptor-locked arkoor package, transaction-chain registration, and possible emergency exits.

Under the assumptions below, neither party can steal the other party's principal:

• Alice cannot take Bob's BTC without revealing the adaptor secret t.
• Bob cannot complete the Ark receive without learning t.
• If Alice never reveals t, Bob refunds the BTC lock after its CSV delay.
• If Bob stalls before t is revealed, Alice can abort by starting emergency exits for the original Ark input VTXOs.
• If Alice reveals t and then tries an old-state Ark exit, Bob has the Ark vtxo_exit_delta response window to complete, register, and import the Ark transfer.

This is not grief-free. Either party can force the other into delay, monitoring, and on-chain fees. The atomicity property is "no counterparty rug with correct monitoring and fallback execution", not "instant off-chain rollback".