Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.train.tech/llms.txt

Use this file to discover all available pages before exploring further.

Atomic Swaps (HTLC - Hashed Time Lock Contract) enable peer-to-peer asset exchange without requiring one Network to know the state of the other. The User generates a secret and locks funds on the Source Network. Then, the Solver locks funds on the Destination Network. They exchange the secret to unlock their respective funds, with a time limit ensuring fund retrieval if the exchange fails.

​
The Standard HTLC Flow

HTLC
1

User Lock

The User generates a Secret S and computes Hashlock HASH(S). Then, they create an HTLC, locking funds for the selected Solver in the Source Network.
2

Solver Lock

The Solver detects this HTLC and creates a counterparty HTLC with the same Hashlock. This locks funds for the User (initial amount minus the Solver Fee) in the Destination Network.
3

User Unlock

The User detects the HTLC in the Destination Network and reveals S to claim the funds.
4

Solver Unlock

The Solver detects the revealed S and reveals it in the Source Network to claim their funds.

​
Challenges with HTLCs

Despite their potential, HTLCs have proven impractical for real-world bridging due to three main issues:
  • Secret Management: Users must generate and securely manage a Secret until the counterparty completes their transaction.
  • Claim Transaction on the Destination Network: Users may lack assets on the Destination Network, especially if it’s their first time interacting with that Network.
  • Liveness: Users must maintain the state of the bridging process locally and actively monitor and respond to counterparty transactions.
These challenges significantly impact the User experience and create barriers to adoption. The requirement for Users to have assets on the Destination Network is particularly problematic. It creates a chicken-and-egg situation for those trying to bridge to a new Network for the first time. Additionally, having the User manage the Secret creates a dependency issue. If the User closes the browser, clears the cache, or loses access to the Secret, the transaction flow cannot be recovered from the chain data.