> ## Documentation Index
> Fetch the complete documentation index at: https://docs.odinx.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Technical Implementation

> Detailed explanation of the HTLC Extended implementation

# 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