Cross-chain Asset Bridging with Atomic Swaps and Light Clients

1

Preface

For the past three years, as operators of a centralized bridge (Layerswap), we’ve been working hard to find a way to move assets between chains without requiring users to trust a third party. We’ve seen many solutions emerge, but they all rely on third parties to keep things secure, like Validators, DVNs, or Optimistic Oracles. Plus, none of them allow new chains to join freely without permission.

So, we set out to build a new way to bridge assets across chains that meets these key goals:

  • Trustless: No need to rely on any new third party for security.
  • Permissionless: Any new rollup or chain can join without needing approval.

This post and the introduced protocol focus solely on transferring assets across chains. It is not related to cross-chain messaging and does not require such mechanisms to function.

Intents, Solvers, and Atomic Swaps

Let’s set the stage. We have a user with an intent and a solver who is ready to fulfill that intent. To enable these two parties to exchange their assets across different chains, we need a trustless system. This concept has already been introduced with Atomic Swaps. I won’t go too deep into explaining Atomic Swaps, assuming a general knowledge of them, but I will introduce a slightly modified version called PreHTLC.

  1. User Commit

    The user creates a PreHTLC (essentially the same as an HTLC, but without a hashlock) on the origin chain, committing funds for the selected solver.

  2. Solver Lock

    The solver detects this transaction, generates a random secret (S), calculates HASH(S) hashlock and creates an HTLC, locking funds (minus the solver fee) for the user on the destination chain.

  3. User AddLock

    The user observes the transaction on the destination chain, retrieves the hashlock, and converts their PreHTLC to an HTLC on the source chain. The PreHTLC can only be converted once with a single hashlock; no other information can be altered.

  4. Unlocks

    Upon seeing this conversion, the solver reveals the secret (S) on the destination chain to release the user’s funds and then reveals the secret (S) on the source chain to claim their funds.

There are multiple reasons why we decided to go with this design. There’s a lot to discuss, but I would like to focus right now on the third step. The user is inside the dApp and detects the destination transaction via wallet RPC. This is essentially the exact point where verification happens. The user verifies this transaction, and it doesn’t introduce any trust assumptions. The user verifies it and takes responsibility. Is this enough?

Light Client

Not really. To safeguard the user, an ideal solution would be to run a light client of the destination chain inside the dApp, like Helios. The dApp would run a light client of the destination chain and verify that the hashlock retrieved from the destination chain is actually on the chain, after which the user can proceed to the next steps. If there is no Light Client implemented for the destination network (there should be), you can get the hashlock from multiple RPC endpoints, dramatically reducing the risk of compromised data from RPCs.

Any Chain or Rollup Can Join

Now, the PreHTLC contracts are immutable, chain-agnostic, and around 200-300 lines of Solidity code. They can be implemented in any VM and do not need any modification when new chains are added. They are end-to-end immutable. Therefore, what is necessary for any new chain to be added to this protocol? It’s as simple as deploying a PreHTLC contract to a new chain and running a solver. No committees, no approvals, no voting—just these two things, and anyone can have their intent solved.

Underwater Stones & Conclusion

There are many hidden challenges, most of which we have explored and found solutions for—though not perfect yet. We believe this foundation is the right way to go. It ensures trustless exchanges for users and solvers and guarantees permissionless onboarding for new rollups or chains. We have detailed documentation available that covers how to ensure solver liveness, discovery, and the auction system.

We believe this solution will finally solve asset bridging for all chains and rollups. I am happy to discuss any ideas, questions, or concerns. Which parts need more clarification? Are we missing something?

4 Likes