> For the complete documentation index, see [llms.txt](https://hello-fun-1.gitbook.io/hello.fun-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hello-fun-1.gitbook.io/hello.fun-docs/security/liquidity-protections.md).

# Liquidity Protections

When a Hello.Fun launch graduates, its market moves from the bonding curve into Uniswap v4.

The liquidity created during this transition is placed into a dedicated smart contract designed to permanently hold the liquidity position.

### Liquidity Comes From the Launch

Graduated liquidity is built from the assets accumulated through the bonding curve.

The creator does not need to separately provide the liquidity used for graduation.

```mermaid
flowchart LR
    A["Bonding Curve Trading"] --> B["Launch Reserves"]
    B --> C["Graduation"]
    C --> D["Uniswap v4 Liquidity"]
```

The reserves created through launch activity become part of the graduated market.

### Liquidity Position Creation

During graduation, Hello.Fun creates the Uniswap v4 pool and establishes a full range liquidity position.

```mermaid
flowchart LR
    A["Graduation"] --> B["Uniswap v4 Pool"]
    B --> C["Full Range Liquidity Position"]
    C --> D["LiquidityLockerV4"]
```

The liquidity position is then transferred into the dedicated liquidity locker.

### Permanent Liquidity Custody

LiquidityLockerV4 is designed to permanently hold graduated liquidity.

The contract does not provide functions for:

1. Withdrawing the liquidity position
2. Unlocking the position
3. Transferring the position
4. Decreasing the locked liquidity
5. Removing the liquidity principal

```mermaid
flowchart TD
    A["Liquidity Position"] --> B["LiquidityLockerV4"]
    B --> C["Permanent Custody"]
```

There is no scheduled unlock date for the graduated liquidity position.

### Locked, Not Burned

The liquidity position is not sent to a burn address.

Instead, ownership of the position is held by LiquidityLockerV4.

```mermaid
flowchart LR
    A["Uniswap v4 Position"] --> B["LiquidityLockerV4"]
    B --> C["Position Remains Held"]
```

This distinction matters.

The liquidity position continues to exist and can generate liquidity fees, while the contract holding it does not provide a path for withdrawing the liquidity principal.

### No Creator Withdrawal

The creator does not receive the graduated liquidity position.

The creator cannot later use Hello.Fun's liquidity locker to withdraw or unlock that position.

```mermaid
flowchart LR
    A["Graduated Liquidity"] --> B["LiquidityLockerV4"]
    A -.-> C["Creator"]
```

Creator earnings are handled separately through creator trading fees.

They do not require ownership of the liquidity position.

### No Administrative Withdrawal

Hello.Fun administrative roles also do not have a general function for withdrawing graduated liquidity from LiquidityLockerV4.

```mermaid
flowchart TD
    A["LiquidityLockerV4"] --> B["No Withdrawal Function"]
    A --> C["No Unlock Function"]
    A --> D["No Transfer Function"]
    A --> E["No Liquidity Decrease Function"]
```

The permanent liquidity rule is enforced through the locker contract itself.

### Liquidity Fees Can Still Be Collected

Permanent locking does not prevent the liquidity position from generating fees.

Uniswap v4 liquidity fees can accrue through trading activity.

Hello.Fun can collect those fees without removing the underlying liquidity principal.

```mermaid
flowchart TD
    A["Pool Trading"] --> B["Liquidity Position"]
    B --> C["Liquidity Fees"]
    B --> D["Liquidity Principal"]
    C --> E["Fee Collection"]
    D --> F["Remains Locked"]
```

Fee collection and liquidity withdrawal are therefore separate actions.

The locker supports fee collection without providing a route for removing the locked principal.

### Principal Protection During Fee Collection

The locker includes checks around fee collection.

When fees are collected, the process is designed to ensure that the liquidity principal remains unchanged and that the position remains held by the locker.

```mermaid
flowchart LR
    A["Collect Fees"] --> B["Verify Position"]
    B --> C["Verify Principal"]
    C --> D["Fees Collected"]
    D --> E["Liquidity Remains Locked"]
```

This allows the market to continue generating liquidity fees without turning fee collection into a liquidity withdrawal mechanism.

### Residual Supply

Not all token supply necessarily enters the graduated liquidity position.

If part of the supply cannot be added without changing the intended opening market state, that amount is treated as residual supply.

```mermaid
flowchart TD
    A["Graduation Supply"] --> B["Pool Supply"]
    A --> C["Residual Supply"]
    B --> D["Uniswap v4 Liquidity"]
    C --> E["ResidualVault"]
```

Residual supply is moved into the ResidualVault.

The ResidualVault does not provide a withdrawal function.

This keeps residual supply separate from both the active liquidity position and creator control.

### Liquidity After Graduation

Once graduation is complete, the market structure becomes:

```mermaid
flowchart TD
    A["Graduated Token"] --> B["Uniswap v4 Pool"]
    B --> C["Trading"]
    B --> D["Full Range Liquidity Position"]
    D --> E["LiquidityLockerV4"]
    E --> F["Permanent Custody"]
```

Trading can continue while the liquidity position remains locked.

### Third Party Liquidity Trackers

Some third party tools identify locked liquidity by recognizing specific locker providers or by checking whether liquidity has been sent to a burn address.

Hello.Fun uses its own smart contract based liquidity locker.

As a result, an external tracker that does not recognize the Hello.Fun locker may not correctly identify the position as locked.

The relevant protection comes from the functionality of the locker contract itself.

### What Cannot Be Done With Locked Liquidity

Once a graduated position is held by LiquidityLockerV4, the locker does not provide a mechanism for the creator or Hello.Fun administrator to:

1. Withdraw the position
2. Unlock it
3. Transfer it elsewhere
4. Reduce its liquidity
5. Remove its principal

This applies to the graduated liquidity position held by the locker.

### Liquidity Protection Summary

| Protection                               | Hello.Fun |
| ---------------------------------------- | --------- |
| Full range liquidity position            | Yes       |
| Dedicated liquidity locker               | Yes       |
| Creator withdrawal                       | No        |
| Administrative withdrawal                | No        |
| Unlock function                          | No        |
| Position transfer function               | No        |
| Liquidity decrease function              | No        |
| Scheduled unlock date                    | No        |
| Fee collection without principal removal | Yes       |
| Residual supply withdrawal               | No        |

### Permanent by Contract Design

The liquidity protection does not depend on a promise to leave liquidity untouched.

It comes from the functions available in the deployed locker contract.

```mermaid
flowchart LR
    A["Graduation"] --> B["Create Liquidity"]
    B --> C["Transfer to Locker"]
    C --> D["Permanent Liquidity"]
    D --> E["Market Continues Trading"]
```

**The market stays active.**

**The liquidity stays locked.**


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://hello-fun-1.gitbook.io/hello.fun-docs/security/liquidity-protections.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
