Overview
This document describes an architecture design of simple atomic swap predicate.
Background
@syuhei176, @tkmct and I attempted to design a deprecation logic that allows two different coin owners to swap their coins in a safe way, supposing that both participants are online throughout the process until their exits.
We got an idea of this deprecation logic from atomic swap predicate
suggested by @karl here.
Also credits to @benchain, who shared his insight on a potential attack here before, it helped us to elaborate on the operator’s withholding attack, explained later in the Attack Scenario 1 section.
As for use cases, I believe this predicate could nest a Collateral Predicate to build Lending Plapps which was proposed by @syuhei176 before.
Architecture
Swap between Alice and Bob
In the end, you want these following conditions.

[A>B]: Range A, which was previously owned by Alice, has to be transferred to Bob

[B>A]: Range B, which was previously owned by Bob, has to be transferred to Alice
Deprecation Logic
Definition: XY symbolizes a conditional state having two scenarios of state transitions later depending on the situations, either:

both sides of the swap were included, so Y is the new owner; or

only one side of the swap was included (the swap was unsuccessful), so X is still the owner.
First, both coin A and B exit as a conditional state AB and BA, which will be deprecated later either to confirm or cancel the swap process.
To assure that both of the swap participants can exchange their ranges as they agreed in a mutually beneficial way,
 The following conditional state cannot be deprecated by their counterparties unless

[AB>B]: Bob has a confirmation signature from Alice, which claims that Alice agrees that the ownership of range A is transferred Bob, and an inclusion proof of
BA
(corresponding StateUpdate). 
[BA>A]: Alice has a confirmation signature from Bob, which claims that Bob agrees that the ownership of range B is transferred to Alice, and an inclusion proof of
AB
(corresponding StateUpdate).
**Each party sends a confirmation signature to the counterparty after checking that the conditional state of the counter party’s coin is included in a block.
Without them, the swap process will terminate and ownership of the coin will be simply transferred to the original owners. 
[AB>B]: [AB>A] 
[BA>A]: [BA>B]

To
startExit
counterparty’s coin, swap participants need an inclusion proof of its conditional state.
Say Alice checked BA was included, so she sent a confirmation sig A to Bob. While waiting for Bob’s confirmation signature, Alice is always guaranteed an option to exit BA in case Bob deprecates AB without sending a confirmation sig B to Alice. 
If both of the conditional states’ exits have been pending for fixed n days of ‘dispute period’, then the ownership of the coin will be simply transferred back to the original owner.

If B deprecates AB and exits, while A has not been done with BA’s deprecation, then extra dispute period will be executed on Layer 1 and BA will automatically be deprecated as A’s coin.
Attack Scenarios
Attack Scenario 1
Suppose Alice is an honest user and the operator is maliciously colluding with her counterparty Bob. Alice and Bob own their coins at block 1 and submits a state update to a conditional state AB and BA in block 2. Then the operator attempts to exit coin B, which was supposed to be transferred to Alice, in block 3.
Alice can protect her assets in either of the following ways.

Op’s exit happens before the confirmation: Alice can simply cancel her swap choosing not to send a confirmation signature to Bob

Op’s exit happens after the confirmation: Alcie can challenge the operator’s fraudulent exit using the inclusion proof of coin B’s conditional state BA.
Attack Scenario 2
Again, suppose Alice is an honest user here, and the operator is maliciously colluding with her counterparty Bob.
The operator includes both Alice and Bob’s coins’ statUpdate to the conditional state AB and BA in block 1. Both Alice and Bob send confirmation signatures to each other, but the operator withholds Bob’s confirmation signature in block 2. Therefore, only Bob can deprecate Alice’s conditional state and exit with her confirmation signature.
In this case, Alice can exit coin A with the following protocol;
Applying rule 4, exited BA will be put on a trial with an additional dispute period on Layer 1. Coin A’s conditional state will be automatically deprecated if there is an inclusion proof of AB in block 1 and Bob’s confirmation signature in block 2.