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

# Security

> Security notes and risk reminders for LFG.RICH users and developers.

LFG.RICH is a smart-contract platform. Users and developers should understand the risks before interacting with contracts or building integrations.

<CardGroup cols={2}>
  <Card title="Wallet safety" icon="wallet">
    Protect seed phrases, use dedicated wallets for bots, and review transactions before signing.
  </Card>

  <Card title="Official routes" icon="route">
    Use official app pages, API endpoints, and V5 contract addresses when interacting with the protocol.
  </Card>

  <Card title="Approval hygiene" icon="key">
    Approve only the required contract: Swap Router for sells and Hook for borrowing collateral.
  </Card>

  <Card title="Bot caution" icon="robot">
    Start with dry runs, smoke tests, tiny amounts, and separate wallets.
  </Card>
</CardGroup>

<Warning>
  Never share your seed phrase or private key. LFG.RICH support, admins, bots, and documentation will never need your private key.
</Warning>

## What LFG.RICH is designed to reduce

LFG.RICH reduces common launch risks by using:

* protocol-managed reserves;
* bonding-curve trading;
* Uniswap V4 Hook settlement;
* floor price protection;
* fixed protocol fees;
* collateral borrowing based on protocol-recognized floor value;
* official contract routing through Factory, Hook, Swap Router, Token, and Pool Manager.

These mechanics are designed to make official launches more transparent and more resistant to traditional liquidity rug mechanics.

## What LFG.RICH does not remove

No smart-contract platform removes every risk. Users should still consider:

* smart contract risk;
* frontend risk;
* RPC/provider risk;
* wallet-signing risk;
* chain/network risk;
* oracle/API/display risk;
* market risk;
* third-party integration bugs;
* phishing and fake contract links.

The existence of a floor mechanism does not mean a token is guaranteed to be profitable, risk-free, or liquid under every condition.

## Verify official contracts

Use official LFG.RICH links and APIs when checking contract addresses.

The public contract labels are:

| Name            | Purpose                                                                             |
| --------------- | ----------------------------------------------------------------------------------- |
| 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.                           |

Developers should verify addresses and bytecode before integrating with real value.

## Safer wallet practices

Use a dedicated wallet when experimenting with new tokens, bots, or integrations.

Recommended practices:

* keep only the BNB you intend to use;
* keep extra BNB for gas;
* do not reuse your long-term cold wallet for bot testing;
* double-check every transaction before signing;
* avoid signing unknown approvals;
* revoke unused approvals when no longer needed.

## Safer BuyBot usage

The Telegram BuyBot is a notification tool only.

It does not need:

* your seed phrase;
* your private key;
* wallet connection;
* signing permission;
* token approvals.

If anyone claiming to be a bot or admin asks for those, treat it as a scam.

## Safer trading bot usage

The community Trading Bot is live trading software when `dry_run` is disabled.

Before running live:

<Steps>
  <Step title="Use a dedicated wallet">
    Keep bot activity separate from your main wallet.
  </Step>

  <Step title="Keep only a small amount of BNB in that wallet">
    Limit possible loss during testing and live operation.
  </Step>

  <Step title="Start with dry_run enabled">
    Confirm behavior before allowing transactions.
  </Step>

  <Step title="Run the smoke test">
    Verify RPC, contracts, token context, and basic reads.
  </Step>

  <Step title="Test one tiny buy">
    Use the smallest practical amount before normal operation.
  </Step>

  <Step title="Confirm dashboard and lots are correct">
    Make sure records match wallet and on-chain behavior.
  </Step>

  <Step title="Only then consider normal live operation">
    Move gradually from testing to real usage.
  </Step>
</Steps>

Do not run a trading bot with a wallet containing funds you cannot afford to risk.

## Safer integration practices

Developers should:

* read contract addresses from official configuration endpoints when possible;
* use read-only calls first;
* resolve the correct `poolId` before V5 estimates or transactions;
* simulate transactions before sending real value;
* use conservative slippage limits;
* handle failed or reverted transactions cleanly;
* check decimals and 18-decimal BNB/token values carefully;
* avoid hard-coding stale contract addresses when an official config endpoint is available;
* never ask users for seed phrases or private keys.

## Common red flags

Be careful if you see:

* a website that looks like LFG.RICH but uses a different domain;
* a token claiming to be official but not created by the official Factory;
* a Telegram account asking for your private key;
* a bot asking for wallet approval to send alerts;
* a transaction that approves unlimited spending for an unknown contract;
* links sent through DMs pretending to be support.

## What to include in a security report

When reporting a suspected security issue, include:

* affected page or contract;
* chain and network;
* token address, if relevant;
* transaction hash, if relevant;
* wallet address, if relevant;
* exact error or unexpected behavior;
* reproduction steps;
* screenshots or logs when useful.

Do not include private keys, seed phrases, or sensitive credentials.