Multichain Exchange

The basic assignment protocol ensures that all parties to an assignment are in agreement with the terms before the assignment can be recorded to the blockchain. However, what protocol can assure that all parties are in agreement about a multi-chain assignment and that the assignment has been recorded in all blockchains before taking effect in any of them? For example: Alice holds 135 CCC. Charlie is advertising that he will exchange 12 CCC for 1 BCG. Alice wants to give Bob 1 BCG. What needs to happen?

The simplest situation would involve trust among the parties: Alice assigns 12 CCC to Charlie and Charlie assigns 1 BCG to Bob, separate assignments on separate blockchains, if they both are recorded everybody is happy. However, if either assignment fails to be recorded then either Bob or Charlie will be unhappy when they discover the missing assignment in the permanent blockchain record. The parties could all get copies of the authorized assignments which would be their proof that the transaction was authorized, but if those same shares are recorded in the blockchain as transferred to another key before this authorized assignment is recorded, then this assignment will be invalidated.

What can happen are conditional assignments in both chains. The shares in question are escrowed for a period of time, and if proof of all required recordings is recorded then the assignment becomes binding. It doesn't sound simple, and it's not, especially when more than 2 blockchains are involved. First, even before starting CAA recording, all concerned asset organizer applications should "ping" all concerned blockchain recorders to ensure they are available to record assignments. Next, the complete exchange is described in a CAA and approved by all parties giving and receiving shares in all chains. Then, this CAA is recorded in every concerned blockchain, Ouroboros style. What this means is: the concerned blockchains are given a numerical order in the CAA. When the CAA is recorded on the first blockchain the signature of that block (proof of recording) is appended to the CAA and the extended CAA is recorded on the next blockchain. While there are additional blockchains involved, the CAA is recorded on each and the proof of recording is appended to the CAA. Finally, when the CAA is recorded on the last blockchain with proof of recording on all other concerned blockchains, and before the escrow period has expired, that recording makes the CAA binding. Still, this binding recording also needs to be recorded to all other concerned blockchains, and so the recording block signature of the binding CAA is appended to the CAA and that completed (binding) CAA is recorded in all other concerned blockchains, binding the transaction in each chain as it is recorded. The process requires two recordings in all concerned blockchains, and a third recording in all but one concerned blockchains. For a three party two chain assignment it's not too bad, it breaks down like this:

Alice tells her AOE that she wants to give 1 BCG to Bob's AOS
^*Alice's AOE is only holding 165 CCC and 0 BCG at the moment
Alice's AOE requests recording fee and time information from both CCC and BCG AORs
Alice's AOE receives responses from both AORs indicating their current fees and recording time lag estimates
Alice's AOE finds
^*the current best available deal for Alice
Charlie's AOI advertising an ASK of 12 CCC for 1 BCG and indicates on-screen "Give 1 BCG for US$12 / 1288 lek worth of CCC Y/N?"
Alice approves the transaction with a tap on her screen
Alice's AOE proposes a CAA to Bob's AOS and Charlie's AOI
^*recording fees neglected for simplicity of presentation, some small fraction of the CCC and BCG would be given to the recording servers during the transaction to cover recording costs (aka SPAM reduction fees.)
:

Alice gives 135 CCC
Alice receives 123 CCC
Charlie receives 12 CCC
Charlie gives 1 BCG
Bob receives 1 BCG
escrow time until some reasonable interval to record the CAA on both CCC and BCG chains

Alice's AOE sends the (unsigned) CAA to Charlie's AOI and Bob's AOS for informal agreement
Charlie's AOI receives Alice's CAA, which constitutes a BID of 12 CCC for 1 BCG, from his perspective
Charlie's AOI requests a share availability check from the CCC AOR for Alice's proposed 165 CCC give shares
Charlie's AOI receives responses from the CCC AOR indicating Alice's 165 CCC shares are available for assignment
Charlie's AOI revises details of the terms of the CAA, including specifying the public keys he is using to receive shares, and sends notes to Alice and Bob that the following CAA looks acceptable to Charlie's AOI

Alice gives 135 CCC
Alice receives 123 CCC
Charlie receives 12 CCC
Charlie gives 15 BCG
^*Charlie happens to be holding a block of 15 BCG which he wants to use in this transaction for whatever reason. AO share blocks can only be assigned atomically so Charlie puts in 15 BCG and then has a fresh block of 14 BCG from this assignment that he is free to assign elsewhere, once this CAA is binding.
Charlie receives 14 BCG
Bob receives 1 BCG
escrow time until some reasonable interval to record the CAA on both CCC and BCG chains

Bob's AOS queries the CCC AOR regarding Alice's proposed 165 CCC give
Bob's AOS queries the BCG AOR regarding Charlie's proposed 15 BCG give
Bob's AOS receives confirmation from the CCC AOR that Alice's 165 CCC is available for assignment
Bob's AOS receives confirmation from the BCG AOR that Charlie's 15 BCG is available for assignment
Bob's AOS indicates on-screen that Alice is proposing giving Bob 1 BCG (and that the transaction looks valid)
Bob tells his AOS he will accept 1 BCG from Alice with a tap on the screen
Bob's AOS, having already received informal agreement from Charlie and implicit approval from the proposer Alice, revises the CAA to insert the public key he will receive the BCG under, and signs the CAA with the private key for the BCG he will be receiving
Bob's AOS sends the signed CAA to Alice and Charlie.
Alice's AOE, having received informal agreement from Charlie and a signed agreement from Bob, authorizes the CAA by signing it with private keys for the shares she is giving and receiving
Alice's AOE sends the signed agreement to Bob and Charlie
Charlie's AOI, having received formal agreement from Bob and implicit agreement from the proposer Alice authorizes (signs) the CAA with the private keys for the shares Charlie is giving and receiving
Charlie's AOI sends the signed CAA to Alice and Bob
^*or, potentially, Bob's AOS could receive the signed CAA from Alice say if her communication with Bob was better than Bob's communication with Charlie - it doesn't matter who sent it (much) what matters is who signed it and that the signature is valid.
Alice's AOE, being the proposer, communicates the fully signed CAA to the CCC AOR for recording
Alice's AOE notifies Bob's AOS and Charlie's AOI that the initial CAA recordings are in progress
The CCC AOR notifies Alice's AOE that the CAA is recorded
Alice's AOE appends the CCC recording block information to the CAA and communicates it to the BCG AOR for recording
Alice's AOE notifies Bob's AOS and Charlie's AOI that the CAA recordings are progressing
The BCG AOR notifies Alice's AOE that the CAA is recorded, and now binding
Alice's AOE sends a final record to the CCC AOR to finalize the binding record in the CCC blockchain also
Alice's AOE notifies Bob's AOS and Charlie's AOI that the CAA recordings are progressing and now binding
The CCC AOR notifies Alice's AOE that the binding CAA is recorded
Alice's AOE notifies Bob's AOS and Charlie's AOI that the CAA recordings are finalized
Alice's AOE notifies her on-screen that Bob has received 1 BCG and her current CCC balance is 143
Bob's AOS notifies him on-screen that he has just received 1 BCG
Charlie's AOI indicates new balances of CCC and BCG
^*onscreen if Charlie is looking, more often Charlie is not looking.
, potentially adjusting affected BID ASK prices and perhaps initiating some other trades

Key points:

Until Bob places the final signature on the CAA it has no binding effect. Only when all givers and receivers of shares in the CAA have signed it is it ready for recording.

However, when Alice and Charlie sign the CAA, it is then out of their hands whether or not Bob will sign. They must act as if Bob will sign and the CAA will be recorded until the escrow period has expired.

When the CAA is first recorded on a blockchain, it places the "give" shares in escrow for the agreed period of time on that blockchain.
The "conditional" part of a CAA is that the CAA is not binding unless and until it has been recorded on all concerned blockchains before the escrow expiration time.

Considered and rejected: The CAA may have a two stage escrow period. Stage one expires if the CAA has not been recorded on a chain, and stage two expires later if a CAA has not become binding by stage two expiration time. This allows a party to the CAA to sign the CAA but only commit to the stage one lockup period unless all other parties also sign and start the recording process. Stage two allows a longer period of time to execute all the AOR recordings. Rejected because once a party has signed a CAA, they have no control over whether or not other parties will sign and record the CAA, so they are subject to the Stage two escrow period, regardless. Should strike all references to this two stage escrow period... later.

Once the last blockchain has recorded a copy of the CAA and all recordings were made before the escrow expiration, the CAA then becomes binding on all chains, however...
Chains which do not have a fully validated CAA recorded on them are still in limbo until one of two things happen:

A copy of a fully validated CAA is recorded on the chain, closing the CAA as validated.
A refutation of the CAA is recorded on the chain, including a copy of a post escrow expiration from at least one other chain in the CAA which did not record the CAA before the escrow expiration deadline. This invalidates the CAA and frees the "give" shares in it to be given in other assignments. Note, again, that this refutation cannot be recorded until after the escrow period has expired.
^*Polite transaction processing software will not leave CAAs in limbo. There is a potential hack here where a CAA might point to a defunct chain with unreachable recording servers and malicious actors can "lock up" shares on active chains by putting them under a CAA with such a chain - such shares will eventually expire. As a partial mitigation this is why all participants ping all recording servers before authorizing a CAA.

Once a CAA is fully validated on a blockchain, receivers of shares in that CAA (on that chain) are then free to assign those shares onward, even if the escrow period has not yet expired.
In the above example, Alice's AOE is "driving the transaction" through the blockchains' AOR servers by virtue of having proposed the transaction in the first place... it may be preferable for the more stable
^*by virtue of being run by vendors instead of transient guests
AOS software to take charge of the AOR interface aspects.

Second Pass

Taking another logical walk-through the scenario where Alice's AOE has 135 CCC, Alice wants to give Bob's AOS 1 BCG, while Charlie's AOI is ASKing 12 CCC for 1 BCG:

Bob's AOS is advertising a product: Plate of Curry Goat, with prices listed as: 1 BCG, 15 ZIC, 0.5 DBR and maybe a few others. Alice's AOE is looking at Bob's AOS menu and has selected the Plate of Curry Goat. Alice's AOE isn't holding any of the issues that Bob's AOS is advertising prices for, so it checks with Charlie's AOI and maybe a few others it knows, to see if she can make an exchange for some of the CCC or YKK she is holding. Charlie's AOI offers the best exchange at 12 CCC for 1 BCG, so Alice's AOE proposes this three way exchange to her as:

Alice gives 12.17 CCC (cost US$12.17 / 1306 lek)
Bob receives 1 BCG in exchange for one Plate of Curry Goat
Charlie gives 1 BCG in exchange for 12.12 CCC

When Alice "OK"s the transaction on her AOE, it first proposes it to Bob's AOS and Bob sees:

Bob gives one Plate of Curry Goat in exchange for 1 BCG
Alice and Charlie to participate

Bob doesn't really need to know much about what Alice and Charlie are exchanging as long as he gets 1 BCG in the deal, but he does deserve to know that they are both participating in the exchange, because Charlie is a reliable trading partner known to Bob, whereas a proposal involving Yllka from Albania might be taken a little more cautiously by Bob since he's never dealt with Yllka before he might be more inclined to wait for the whole transaction to process and record before considering it a done deal. Bob "OK"s the transaction on his AOS which then initiates the secure exchange.

Bob's AOS sends a proposal to Alice's AOE and Charlie's AOI saying:

Bob's AOS receives 1 BCG (with public key BK1 the BCG shares receipt will be recorded under)

Recording Deadline: UT1605459600 (5 minutes from now)

Alice's AOE receives Bob's proposal, and considering her earlier approval of the exchange sends the following to Bob's AOS and Charlie's AOI:

Bob's AOS receives 1 BCG (with public key BK1 the BCG shares receipt will be recorded under)
Alice receives 122.83 CCC (with public key AK1 the CCC shares receipt will be recorded under)

Alice gives 135 CCC (with AO_ID_SEQ_NUM of the CCC shares source AK2)

Recording Deadline: UT1605459600

Charlie's AOI was slow to respond to Bob's proposal since it had no source funds to consider,
^*after some delay, Charlie's AOI might have contacted Bob's AOS to complain about the lack of source funds, but since Alice's AOE proposal arrived carrying the same public key BK1 for Bob's BCG receipt, Charlie's AOI ignores the first contact and processes Alice's more compelte request.
but Alice's proposal merits faster attention, Charlie's AOI prepares these conditional assignment agreements, signs them, and transmits them to Alice's AOE and Bob's AOS:

Conditional Assignment Agreement, BCG component:

Bob's AOS receives 1 BCG (with public key BK1 the BCG shares receipt will be recorded under)
Charlie receives 14.04 BCG (with public key CK1 the BCG shares receipt will be recorded under)

Charlie gives 15.05 BCG (with AO_ID_SEQ_NUM of the BCG shares source CK2)

Recording fee: 0.01 BCG

Recording Deadline: UT1605459600
BCG assignment signed by CK1 private key

BCG assignment signed by CK2 private key

Conditional Assignment Agreement, CCC component:

Alice receives 122.83 CCC (with public key AK1 the CCC shares receipt will be recorded under)
Charlie receives 12.12 CCC (with public key CK3 the CCC shares receipt will be recorded under)

Alice gives 135 CCC (with AO_ID_SEQ_NUM of the CCC shares source AK2)
Recording fee: 0.05 CCC

Recording Deadline: UT1605459600
CCC assignment signed by CK3 private key

Overall CAA signed by CK1 private key

Overall CAA signed by CK2 private key

Overall CAA signed by CK3 private key

Even though Bob isn't involved in the CCC exchange, he needs to approve the overall CCA which includes it. Bob's AOS signs and sends the CAA to Alice's AOE and Charlie's AOI.
^*Charlie doesn't strictly need the agreements signed by Bob without Alice, but if the Alice-Charlie communication path goes bad, Charlie might be able to relay the CAA signed by Bob to Alice. Mostly, it's just a courtesy to Charlie's AOI to keep it appraised of progress.

Conditional Assignment Agreement, BCG component:

Bob's AOS receives 1 BCG (with public key BK1 the BCG shares receipt will be recorded under)
Charlie receives 14.04 BCG (with public key CK1 the BCG shares receipt will be recorded under)
Charlie gives 15.05 BCG (with AO_ID_SEQ_NUM of the BCG shares source CK2)
Recording fee: 0.01 BCG
Recording Deadline: UT1605459600
BCG assignment signed by CK1 private key
BCG assignment signed by CK2 private key
BCG assignment signed by BK1 private key

Conditional Assignment Agreement, CCC component:

Alice receives 122.83 CCC (with public key AK1 the CCC shares receipt will be recorded under)
Charlie receives 12.12 CCC (with public key CK3 the CCC shares receipt will be recorded under)
Alice gives 135 CCC (with AO_ID_SEQ_NUM of the CCC shares source AK2)
Recording fee: 0.05 CCC
Recording Deadline: UT1605459600
CCC assignment signed by CK3 private key

Overall CAA signed by CK1 private key
Overall CAA signed by CK2 private key
Overall CAA signed by CK3 private key
Overall CAA signed by BK1 private key

Alice's AOE also recognizes the CAA as matching the previously approved transaction and so signs it and sends it back to Bob, Charlie, and the CCC recording server (AOR) since it is now ready for recording. Alice's AOE doesn't know how to contact the BCG AOR, but either Bob or Charlie will take care of that.

CAA (Conditional Assignment Agreement), BCG component:

Bob's AOS receives 1 BCG (with public key BK1 the BCG shares receipt will be recorded under)
Charlie receives 14.04 BCG (with public key CK1 the BCG shares receipt will be recorded under)
Charlie gives 15.05 BCG (with AO_ID_SEQ_NUM of the BCG shares source CK2)
Recording fee: 0.01 BCG
Recording Deadline: UT1605459600
BCG assignment signed by CK1 private key
BCG assignment signed by CK2 private key
BCG assignment signed by BK1 private key

Conditional Assignment Agreement, CCC component:

Alice receives 122.83 CCC (with public key AK1 the CCC shares receipt will be recorded under)
Charlie receives 12.12 CCC (with public key CK3 the CCC shares receipt will be recorded under)
Alice gives 135 CCC (with AO_ID_SEQ_NUM of the CCC shares source AK2)
Recording fee: 0.05 CCC
Recording Deadline: UT1605459600
CCC assignment signed by CK3 private key
CCC assignment signed by AK1 private key

CCC assignment signed by AK2 private key

Overall CAA signed by CK1 private key
Overall CAA signed by CK2 private key
Overall CAA signed by CK3 private key
Overall CAA signed by BK1 private key
Overall CAA signed by AK1 private key

Overall CAA signed by AK2 private key

Bob's AOS receives the completely signed CAA from Alice, and the note that it has been forwarded to the CCC AOR for recording. Bob's AOS delays for a time, waiting for the CCC AOR's response since that will be needed for recording on the BCG AOR anyway.
Charlie's AOI receives the completely signed CAA from Alice, and the note that it has been forwarded to the CCC AOR for recording. Charlie's AOI similarly delays for a time, waiting for the CCC AOR's response since that will be needed for recording on the BCG AOR anyway.
The CCC AOR records the CAA and sends notice to Alice, Bob and Charlie including the proof of recording.

CAA (Conditional Assignment Agreement), BCG component:

Bob's AOS receives 1 BCG (with public key BK1 the BCG shares receipt will be recorded under)
Charlie receives 14.04 BCG (with public key CK1 the BCG shares receipt will be recorded under)
Charlie gives 15.05 BCG (with AO_ID_SEQ_NUM of the BCG shares source CK2)
Recording fee: 0.01 BCG
Recording Deadline: UT1605459600
BCG assignment signed by CK1 private key
BCG assignment signed by CK2 private key
BCG assignment signed by BK1 private key

Conditional Assignment Agreement, CCC component:

Alice receives 122.83 CCC (with public key AK1 the CCC shares receipt will be recorded under)
Charlie receives 12.12 CCC (with public key CK3 the CCC shares receipt will be recorded under)
Alice gives 135 CCC (with AO_ID_SEQ_NUM of the CCC shares source AK2)
Recording fee: 0.05 CCC
Recording Deadline: UT1605459600
CCC assignment signed by CK3 private key
CCC assignment signed by AK1 private key
CCC assignment signed by AK2 private key

Overall CAA signed by CK1 private key
Overall CAA signed by CK2 private key
Overall CAA signed by CK3 private key
Overall CAA signed by BK1 private key
Overall CAA signed by AK1 private key
Overall CAA signed by AK2 private key
Proof of CAA recording on the CCC blockchain

Charlie's AOI receives the notice from the CCC AOR first, and forwards it on to the BCG AOR for recording, along with notice to Alice and Bob that this has happened.
Bob's AOS has a few seconds longer delay than Charlie's AOI and so notices that the CAA has already been forwarded to the BCG AOR, so waits a few seconds longer for a response.
Alice's AOE receives the notice from the CCC AOR, but doesn't know how to communicate with the BCG AOR, so just waits.
The BCG AOR records the CAA before the recording deadline, making it official and binding. It communicates the completely recorded CAA to all parties except Alice's AOE:

CAA (Conditional Assignment Agreement), BCG component:

Bob's AOS receives 1 BCG (with public key BK1 the BCG shares receipt will be recorded under)
Charlie receives 14.04 BCG (with public key CK1 the BCG shares receipt will be recorded under)
Charlie gives 15.05 BCG (with AO_ID_SEQ_NUM of the BCG shares source CK2)
Recording fee: 0.01 BCG
Recording Deadline: UT1605459600
BCG assignment signed by CK1 private key
BCG assignment signed by CK2 private key
BCG assignment signed by BK1 private key

Conditional Assignment Agreement, CCC component:

Alice receives 122.83 CCC (with public key AK1 the CCC shares receipt will be recorded under)
Charlie receives 12.12 CCC (with public key CK3 the CCC shares receipt will be recorded under)
Alice gives 135 CCC (with AO_ID_SEQ_NUM of the CCC shares source AK2)
Recording fee: 0.05 CCC
Recording Deadline: UT1605459600
CCC assignment signed by CK3 private key
CCC assignment signed by AK1 private key
CCC assignment signed by AK2 private key

Overall CAA signed by CK1 private key
Overall CAA signed by CK2 private key
Overall CAA signed by CK3 private key
Overall CAA signed by BK1 private key
Overall CAA signed by AK1 private key
Overall CAA signed by AK2 private key
Proof of CAA recording on the CCC blockchain
Proof of CAA recording on the BCG blockchain

At this stage, the CAA is binding on the BCG blockchain and "in limbo" on the CCC blockchain. In order to be validated, proof of the completed CAA having been recorded on the BCG blockchain must be added to the CCC blockchain. In order to be refuted, proof of a recording of refutation on the BCG blockchain must be recorded. Neither of these are on a deadline, but if a refutation is to be filed, it must be filed after the recording deadline. While the CAA is in limbo, shares within it are locked up.
Once confirmed, the received shares become free to assign onward, once refuted the given shares become free to assign onward.

Note that more complex transactions involving more trading parties and/or more blockchains are possible, but that the overall CAA must be signed by all participants in all transactions, and that proof of the CAA's recording on all blockchains must be recorded on all blockchains, meaning a minimum of two recordings on all blockchains but one.

What is proof of recording on another blockchain?

On a given blockchain, proof of recording can be a reference to the block in which the recording was made. One of the stipulations of a blockchain is that all previous blocks are available for inspection and unchangeable. However, when "crossing over" to other blockchains, how should a cross-chain transaction be "proven as recorded" on another blockchain? The identification (hash & recording time) of the block it is recorded in is a start, but what happens when a blockchain becomes inaccessible to users of a Conditional Assignment Agreement on another chain? At least for purposes of Conditonal Assignment Agreements, signatures of the proof of recording (identification) by all participants in the CAA component recorded in that chain should be sufficient to satisfy "proof" that participants in that CAA component were satisfied that their interests were adequately recorded. If a participant should fail to acknowledge recording, blocking proof of recording on one or more chains, this would effectively invalidate the CAA, allowing it to be refuted on one or more chains, then proof of that recording of refutation can be used to invalidate recordings on other chains. Need to graph this to see how a refusnik might attempt to game the system.

One way to attempt to game this system would be to record a valid CAA involving an unreliable "other" blockchain, then take down the "other" blockchain and record a false proof of refutation in that blockchain. If, once "Proof" is accepted it cannot be later refuted, I believe this blocks this attack vector. In the example above, Proof of recording on CCC is recorded, then the binding recording is done in the BCG blockchain at which point it is too late to take back the transactions in the BCG blockchain. If the BCG blockchain "disappears" then the CAA on the CCC blockchain can remain in limbo, resulting in a loss of all shares. All parties might sign an agreement of refutation of the CAA and record it in CCC meaning the givers get their shares back on CCC, but this would require the parties to the CAA on BCG to all agree to signing the refutation and recording it on CCC. The BCG blockchain might then reappear, complete with a confirmed recording of the CAA. While this results in cross-chain disagreement about the completeness of the CAA, it is a disagreement of the parties' own making - they first recorded the CAA, then later refuted that recording on another chain. It feels like another "islands of processing" problem where everything is fine as long as the network doesn't get fragmented and unable to communicate with part of itself.