Multi-hop transactions
Explains how multiple Solvers can be used for connecting networks that do not have a direct liquidity connection
By making atomic swaps practical for bridging, we gain a crucial advantage. The same hashlock can be reused across multiple networks (multi-Solver routing) for a single bridging request. Once the secret is revealed, all linked HTLCs/PreHTLCs in all networks can be unlocked.
Let’s assume a user wants to transfer assets from Chain A to Chain C, but no single Solver supports both chains. Instead, there are two Solvers, one supporting transfers from Chain A to Chain B: Solver(AB) and another from Chain B to Chain C: Solver(BC).
The protocol facilitates this request as follows:
User Commit
The user creates a PreHTLC for Solver(AB).
Solver(AB) Commit
Once detected, Solver(AB) creates a PreHTLC for Solver(BC).
Solver(BC) Lock
Solver(BC) then creates an HTLC for the user.
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.
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.
Multi-hop transactions can use two Solvers to move funds to the user’s desired destination autonomously. This process can be expanded to include any number of Solvers, allowing for multiple “hops” to reach the final destination. Meanwhile, the user still only needs to complete two transactions on the source chain, regardless of the number of hops.
Was this page helpful?