Skip to main content

​
Technical Implementation

​
Security Model

  • Pre-Signed Transactions: Minimizes user intervention while maintaining security.
  • Time-Lock Mechanism: Ensures funds can always be claimed by the rightful owner.
  • Atomic Execution: Prevents partial swaps and asymmetric risks.

​
HTLC Deployment Process

​
Step 1: Swap Initialization

  1. User requests a price quote from the Liquidity Node
  2. Upon acceptance, Liquidity Node generates SECRET_X and HASH(SECRET_X)
  3. User receives pre-signed claim transaction for future redemption

​
Step 2: Contract Deployment

  • Liquidity Node HTLC:
    • Deploys on ChainOut
    • Contains HASH(SECRET_X), AmountOut, LOCKTIME_1
    • Monitored for confirmation
  • User HTLC:
    • Created on ChainIn
    • Matches HASH(SECRET_X)
    • Sets LOCKTIME_2 where L2 < L1
    • Broadcast by Liquidity Node

​
Locktime Considerations

​
Why L1 >> L2?

Setting LOCKTIME_1 (L1) > LOCKTIME_2 (L2) ensures that the swap process remains atomic and secure. The reasoning behind this is as follows:
  • Ensures Claimability: Since the Liquidity Node must reveal SECRET_X on ChainIn first, the user is guaranteed to be able to claim funds on ChainOut.
  • Prevents Asymmetric Execution: If L1 and L2 were reversed, the Liquidity Node could claim TOKEN_OUT without fulfilling their obligation on ChainIn.
  • Atomicity Guarantee: The structure ensures that either the swap is fully executed, or both parties retrieve their original assets after expiration.

​
Claim Process and Settlement

​
Liquidity Node Claims

  1. Waits for USER_HTLC_CHAIN_IN confirmation
  2. Reveals SECRET_X to claim TOKEN_IN
  3. Transaction automatically executes if hash matches

​
User Claims

  1. SECRET_X becomes public on ChainIn
  2. Liquidity Node broadcasts pre-signed claim
  3. User can manually claim if needed using revealed SECRET_X

​
Fail-Safe Design

  • If Liquidity Node fails to claim before L2, user reclaims funds
  • Pre-signed transactions minimize manual intervention
  • Automatic fallback ensures fund safety

​
Transaction Flow Summary

  1. Initialization
    • User requests swap
    • Price quote provided
    • Secret generation and commitment
  2. Contract Deployment
    • Liquidity Node deploys HTLC on ChainOut
    • User creates matching HTLC on ChainIn
    • Both contracts use same HASH(SECRET_X)
  3. Claim Process
    • Liquidity Node reveals secret on ChainIn
    • User claims funds on ChainOut
    • Automatic reversion if unclaimed