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

# Uniswap V4 Hooks

> How LFG.RICH uses a Uniswap V4 Hook to route trades, pricing, floor logic, fees, and lending.

LFG.RICH is built around a Uniswap V4 Hook architecture. The Hook is not just a helper contract. It is the protocol component that enforces the bonding curve, floor-price accounting, fee routing, referral-aware fee splits, and collateral borrowing rules for official LFG.RICH tokens.

The user-facing swap flow is intentionally simple, but the on-chain route is precise:

<CardGroup cols={2}>
  <Card title="Factory" icon="industry">
    Creates official LFG.RICH tokens and registers them with the Hook.
  </Card>

  <Card title="Uniswap V4 Hook" icon="anchor">
    Enforces pricing, floors, reserves, fees, collateral, borrowing, and hook callbacks.
  </Card>

  <Card title="Swap Router" icon="route">
    Gives users and integrations simple buy and sell entry points.
  </Card>

  <Card title="Pool Manager" icon="layer-group">
    Executes the Uniswap V4 unlock, swap, settlement, and callback flow used by the Hook and Router.
  </Card>
</CardGroup>

```txt theme={null}
User wallet
  -> Swap Router
  -> Pool Manager unlock(...)
  -> Pool Manager swap(...)
  -> Uniswap V4 Hook beforeSwap(...)
  -> custom curve, floor, fee, and accounting logic
  -> Pool Manager settlement / take
```

## Main contracts

| Contract        | Responsibility                                                                      |
| --------------- | ----------------------------------------------------------------------------------- |
| Factory         | Creates official LFG.RICH tokens and registers them with the hook.                  |
| Uniswap V4 Hook | Handles pricing, floors, reserves, fees, collateral, borrowing, and hook callbacks. |
| Swap Router     | Provides simple buy and sell functions for users and integrations.                  |
| Token           | ERC20-compatible token contract created by the Factory.                             |
| Pool Manager    | Uniswap V4 Pool Manager used by the hook and router flow.                           |

## BSC V5 addresses

| Contract        | Address                                      |
| --------------- | -------------------------------------------- |
| Factory         | `0x429a7ef0129649a97bb3f1e961dd56d9bd4ac01f` |
| Uniswap V4 Hook | `0xc18e6e1926113cdcf53f3ec1a89d3eb84cc6a888` |
| Swap Router     | `0x4018abd5d24ee48c642e7e518a8aef03b59ec150` |
| Token           | Created per launch by the Factory.           |
| Pool Manager    | `0x28e2Ea090877bF75740558f6BFB36A5ffeE9e9dF` |

## PoolKey and poolId

Each official token has its own Uniswap V4 `PoolKey` and its own `poolId`.

```solidity theme={null}
struct PoolKey {
    address currency0;   // native BNB represented as address(0)
    address currency1;   // token address
    uint24 fee;          // 3000
    int24 tickSpacing;   // 60
    address hooks;       // Uniswap V4 Hook
}
```

For integrations, the important rule is: **do not guess the pool**. Resolve the `poolId` and `PoolKey` for the token you are interacting with.

```txt theme={null}
poolId = token.pool_id || token.poolId || hook.tokenToPoolId(tokenAddress)
key    = factory.getPoolKey(tokenAddress)
```

The site code always treats the token's `poolId` as part of the interaction context. Estimates use `poolId`; swaps use `PoolKey`.

## Why the Hook matters

The Hook prevents the token from behaving like a normal unmanaged LP token. Creators do not receive LP tokens to remove. Traders do not interact with arbitrary third-party pools. Official trades are routed through the protocol contracts, where the Hook enforces the same pricing, floor, fee, referral, and collateral rules for everyone.

This gives the protocol a consistent execution path:

* buys and sells use the official Swap Router;
* pricing is calculated by the Hook;
* token mints and burns are controlled by the Hook;
* collateral lending uses the same `poolId`-based state;
* floor updates are tied to the token's own protocol state;
* referral rewards are decided by on-chain invite bindings.

## Important integration rule

<Warning>
  Older V3 examples are not safe for V5 integrations. V5 estimates include the user address, token creation uses `devBuyEth`, and buys/sells must be routed with the token's correct `PoolKey`.
</Warning>

Use this V5 pattern:

<Steps>
  <Step title="Load token data">
    Start from API token data or a known token address.
  </Step>

  <Step title="Resolve poolId">
    Use `token.pool_id`, `token.poolId`, or `hook.tokenToPoolId(tokenAddress)`.
  </Step>

  <Step title="Resolve PoolKey">
    Use `factory.getPoolKey(tokenAddress)` or build from verified V5 constants.
  </Step>

  <Step title="Estimate with Hook + poolId + user address">
    V5 estimate functions include the wallet address because referral state can change fee recipients.
  </Step>

  <Step title="Execute buy/sell with Swap Router + PoolKey">
    Swap execution uses the token-specific PoolKey.
  </Step>

  <Step title="Execute lending with Hook + poolId">
    Borrow, borrowMore, repay, and state reads use the Hook and `poolId`.
  </Step>
</Steps>