> ## 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.

# Protocol Flow

> Step-by-step guide to the OdinTrade swap process

# Protocol Flow

## Overview

The OdinTrade protocol follows a carefully orchestrated sequence of steps to ensure secure and atomic cross-chain swaps. Here's a detailed breakdown of the process.

## 1. Swap Initialization

### Important Note on Execution Flow

It’s important to clarify a key aspect of the atomic swap execution flow.
The first on-chain interaction involves the creation of the Liquidity Node’s HTLC, which locks the **amountOut** that the user expects to receive.
At this stage, the user is shown a current estimation of the required **amountIn** for the swap. However, this value may change, as it depends on dynamic factors such as exchange rates and network fees.
The actual **amountIn** that the user must deposit into their own HTLC is only finalized at the moment their HTLC is created.

### Price Quote Request

1. User requests swap quote from Liquidity Node
2. Specifies desired token pair and amount
3. Receives current exchange rate

### Secret Generation

1. Liquidity Node generates `SECRET_X`
2. Computes `HASH(SECRET_X)` using SHA-256
3. Securely stores both values

### Pre-Signed Transaction

1. Liquidity Node creates `UserClaimToSign`
2. User receives and verifies claim transaction
3. User signs claim for future execution

## 2. Contract Deployment

### Liquidity Node HTLC

1. Deploys HTLC on `ChainOut`
2. Includes:
   * `HASH(SECRET_X)`
   * `AmountOut`
   * `LOCKTIME_1`
3. Monitors for confirmation

### User HTLC

1. Creates HTLC on `ChainIn`
2. Matches `HASH(SECRET_X)`
3. Sets `LOCKTIME_2` (where `L2 < L1`)
4. Sends to Liquidity Node for broadcasting

## 3. Claim Process

### Liquidity Node Claims

1. Monitors `ChainIn` for HTLC confirmation
2. Reveals `SECRET_X` to claim `TOKEN_IN`
3. Transaction executes if hash matches

### User Claims

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

## 4. Settlement & Completion

### Successful Completion

1. Liquidity Node receives `TOKEN_IN`
2. User receives `TOKEN_OUT`
3. Both HTLCs are marked as executed

### Fallback Scenarios

1. **Timeout on `ChainIn`**:

   * User reclaims funds after `L2`
   * No action needed from Liquidity Node

2. **Timeout on `ChainOut`**:
   * Liquidity Node reclaims after `L1`
   * Only possible if `ChainIn` claim failed

## Transaction Flow Summary

```mermaid theme={null}
sequenceDiagram
    participant User
    participant LN as Liquidity Node
    participant ChainIn as Chain In (BTC)
    participant ChainOut as Chain Out (ETH)

    User->>LN: Request Quote
    LN->>User: Price & UserClaimToSign
    User->>LN: Accept Quote
    LN->>ChainOut: Deploy HTLC
    ChainOut->>LN: Confirm
    User->>ChainIn: Deploy HTLC
    ChainIn->>LN: Confirm
    LN->>ChainIn: Reveal SECRET_X
    ChainIn->>LN: Release TOKEN_IN
    LN->>ChainOut: Broadcast UserClaim
    ChainOut->>User: Release TOKEN_OUT
```

## Monitoring and Verification

### Status Tracking

* Monitor transaction confirmations
* Track HTLC states
* Verify hash commitments

### Error Handling

* Network congestion management
* Transaction retry mechanisms
* Fallback procedures

### Completion Verification

* Confirm both HTLCs executed
* Verify token transfers
* Update swap status