The protocol model relies on atomic swaps for parties exchanging assets across different chains. The model outlines the core flow of assets and actions that should be taken by each party for a successful asset exchange. Depending on the source and destination, and whether there is a party willing to exchange on those chains, either the Standard flow or Multi-hop flow is used.

​
Standard flow

When a party directly supports both the source and destination chains and is willing to perform the swap, the standard flow applies. The user initiates the process by calling commit and setting the timelock to T+βT + \beta, where TT is the current timestamp and β\beta is the duration for which the user is willing to lock their funds. The party performing the exchange must then call the lock function on the destination chain, setting the timelock to T+2ΔT + 2\Delta (β<2Δ\beta < 2\Delta), where Δ\Delta is a reasonable duration (e.g., 15 minutes) to ensure the user has time to act and leave sufficient time for the party. Finally, the user calls addLock, specifying the timelock T+ΔT + \Delta and completing their commitment with a hashlock. Here are the steps:
1

User Commit

The user creates a commit object on the source chain with a timelock of T+βT + \beta.
2

Party Lock

The party creates a lock object on the destination chain with a hashlock and a timelock of T+2ΔT + 2\Delta.
3

User AddLock

The user adds a lock to the commitment on the source chain, adding a hashlock and updating the timelock to T+ΔT + \Delta.
4

Party Redeem

The party redeems the locked funds on the destination chain.
5

User Redeem

The user redeems the locked funds on the source chain.

​
Multi-hop flow

When transferring funds from a source chain to a destination chain is not possible due to the absence of a party directly linking the two, a multi-hop approach is used, with the chain length denoted as nn. In this process, the user initially commits funds on the source chain to the first party. Each party in the sequence subsequently calls commit, committing funds for the next party, until the final party on the destination chain calls lock. This locks the funds with a hashlock and the longest timelock, set to T+2n−1ΔT + 2^{n-1}\Delta, where TT is the current timestamp and Δ\Delta is a reasonable duration (e.g., 15 minutes). The Solver on the destination chain locks funds with a duration of 2n−1Δ2^{n-1}\Delta from the current timestamp, ensuring sufficient time for each Solver in the chain to act. Following this, each party in the hop-chain, starting from the user to the second-to-last party, performs the addLock function with the same hashlock as used on the destination chain but with progressively shorter timelocks. For the user, the timelock is set to T+2n−2ΔT + 2^{n-2}\Delta, while for the second-to-last party, it is T+20ΔT + 2^0\Delta. This pattern continues recursively, with each party adding a lock using the hashlock and a timelock specific to their position in the chain. When the party on the destination chain calls redeem and reveals the secret, they transfer the user’s funds and redeem the locked funds for themselves. This revelation of the secret allows each preceding party in the chain to sequentially redeem their funds, completing the multi-hop swap. Here are the steps:
1

User Commit

The user creates a PreHTLC for Solver(AB).
2

Solver(AB) Commit

Once detected, Solver(AB) creates a PreHTLC for Solver(BC).
3

Solver(BC) Lock

Solver(BC) then creates an HTLC for the user.
4

User, Solver(AB) AddLock

The user detects the last transaction, retrieves the hashlock, and converts their PreHTLC to an HTLC on Chain A. Solver(AB) does the same on Chain B.
5

Unlocks

Solver(BC) can now release the user’s funds on Chain C and claim their funds on Chain B, while Solver(AB) can claim their funds on Chain A.