> 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/security-overview.md). # Security Overview Hello.Fun is designed so that the core rules governing launches, trading, graduation, fees and liquidity are enforced through smart contracts. The security model combines fixed contract logic, limited administrative permissions, wallet controlled transactions and permanent liquidity protections. ### Security by Architecture Several principles form the foundation of the Hello.Fun security model: 1. Non upgradeable contracts 2. User signed transactions 3. No backend custody of user funds 4. Fixed token supply 5. No token owner controls 6. Permanent graduated liquidity locking 7. Fixed fee rules for existing launches 8. Permissionless graduation completion 9. Limited administrative permissions 10. Reentrancy protections ```mermaid flowchart TD A["Hello.Fun Security Model"] --> B["Fixed Contract Logic"] A --> C["Wallet Control"] A --> D["Token Protections"] A --> E["Liquidity Protections"] A --> F["Limited Permissions"] A --> G["Graduation Protections"] ``` ### Non Upgradeable Contracts Hello.Fun contracts are non upgradeable. The deployed architecture does not use proxies that allow the underlying contract implementation to be replaced later. ```mermaid flowchart LR A["Contract Deployment"] --> B["Fixed Logic"] B --> C["Onchain Operation"] ``` There is no upgrade function that allows Hello.Fun to replace the deployed contract logic for an existing launch. ### User Controlled Transactions State changing actions require authorization from the user's wallet. This includes actions such as: 1. Launching a token 2. Buying 3. Selling 4. Claiming eligible fees ```mermaid sequenceDiagram participant U as User participant H as Hello.Fun participant W as Wallet participant C as Contracts U->>H: Select action H->>W: Prepare transaction W->>U: Request signature U->>W: Authorize W->>C: Submit transaction ``` Hello.Fun does not hold user private keys. The backend cannot sign trades or launch tokens on behalf of users. ### No Backend Custody The backend is used to read, organize and serve information. It does not control the funds used in Hello.Fun markets. ```mermaid flowchart LR A["User Wallet"] --> B["Smart Contracts"] B --> C["Onchain Market"] D["Hello.Fun Backend"] --> E["Market Data"] ``` This separates financial execution from the infrastructure used to display market information. ### Token Protections Tokens created through Hello.Fun use fixed core token logic. Each launch token has: 1. A fixed supply of 1,000,000,000 tokens 2. 18 decimals 3. Supply minted once 4. No additional mint function 5. No token owner 6. No blacklist 7. No transfer freeze ```mermaid flowchart TD A["LaunchToken"] --> B["Fixed Supply"] A --> C["No Additional Minting"] A --> D["No Token Owner"] A --> E["No Blacklist"] A --> F["No Transfer Freeze"] ``` The launched token does not provide a privileged owner with the ability to mint additional supply or block ordinary transfers. ### Liquidity Protections When a launch graduates, its Uniswap v4 liquidity position is transferred into LiquidityLockerV4. The locker does not provide functions for: 1. Withdrawing the liquidity position 2. Unlocking the liquidity position 3. Transferring the position 4. Decreasing the locked liquidity 5. Removing the liquidity principal ```mermaid flowchart LR A["Graduated Liquidity"] --> B["LiquidityLockerV4"] B --> C["Permanent Custody"] ``` Liquidity fees can be collected without removing the locked liquidity principal. ### No Global Pause The deployed Hello.Fun contracts do not contain a global pause mechanism. There is no administrative control that can simply halt all trading across the deployed system. ```mermaid flowchart LR A["Deployed Markets"] --> B["No Global Pause Control"] ``` Individual transactions can still fail because of contract conditions, slippage, market state or normal blockchain behavior. That is different from a platform administrator having a global trading pause. ### Fixed Fees The protocol fee is fixed in the deployed contracts. Creator fees are selected within the permitted range when a launch is created and are then fixed for that launch. ```mermaid flowchart LR A["Launch Created"] --> B["Creator Fee Set"] B --> C["Fee Fixed for Launch"] ``` Administrative roles cannot later raise the fee on an existing launch. ### Permissionless Graduation Completion Graduation is designed so that completion does not depend exclusively on the Hello.Fun team. When a launch reaches the required state, the completing trade can attempt graduation automatically. If that process does not complete, another user can trigger graduation completion. ```mermaid flowchart TD A["Launch Ready"] --> B["Automatic Graduation Attempt"] B --> C{"Completed?"} C -->|"Yes"| D["Graduated Market"] C -->|"No"| E["Permissionless Completion"] E --> D ``` This reduces dependence on a single operator for completing the transition. ### Limited Administrative Permissions Hello.Fun has administrative roles for specific operational responsibilities. These permissions are limited to defined areas such as pair management, selected hook configuration and a restricted graduation recovery path. Administrative roles cannot: 1. Mint additional launch tokens 2. Freeze token transfers 3. Blacklist holders 4. Withdraw graduated liquidity 5. Unlock graduated liquidity 6. Raise fees on an existing launch 7. Pause all trading 8. Upgrade deployed contracts 9. Take creator funds 10. Take user funds ```mermaid flowchart TD A["Administrative Roles"] --> B["Defined Operational Permissions"] A --> C["No Token Minting"] A --> D["No Liquidity Withdrawal"] A --> E["No Global Pause"] A --> F["No Contract Upgrade"] ``` ### Graduation Recovery The graduation system includes a restricted recovery path for a specific failure state. It applies only after launch reserves have already been swept for graduation and the pool seeding process has failed. The recovery path is subject to contract conditions and a delay. If used, the affected funds are directed to the creator rather than to the administrator. ```mermaid flowchart TD A["Reserves Swept"] --> B["Pool Seeding Failure"] B --> C["Recovery Conditions"] C --> D["Required Delay"] D --> E["Creator"] ``` This recovery mechanism does not provide a general withdrawal path for active launch funds or permanently locked liquidity. ### Reentrancy Protection Hello.Fun uses reentrancy guards in relevant contract flows. These protections are designed to prevent protected functions from being reentered unexpectedly during execution. This forms one part of the broader smart contract security model. ### Pool Creation Protection The Uniswap v4 integration restricts initialization of Hello.Fun launch pools to the expected pool creation infrastructure. ```mermaid flowchart LR A["Graduation Infrastructure"] --> B["Pool Initialization"] B --> C["Hello.Fun Uniswap v4 Market"] ``` This helps connect graduated pool creation to the intended Hello.Fun lifecycle. ### Minimized Hook Permissions The Hello.Fun Uniswap v4 hook uses a limited set of permissions. Enabled permissions include: 1. Before Initialize 2. After Swap 3. After Swap Returns Delta Before Swap is not enabled. The hook therefore cannot use a Before Swap permission to prevent a user from selling before the swap executes. ### Contract Testing The current contract suite includes tests covering areas such as: 1. Launch lifecycle 2. Fee distribution 3. Graduation 4. Liquidity locking 5. Adversarial scenarios Testing helps validate expected contract behavior, but it does not eliminate smart contract risk. ### External Audit Status The current Hello.Fun contract architecture has not completed an external third party security audit. Contract verification and internal testing should not be interpreted as substitutes for an independent security audit. This distinction is important when evaluating the security status of the platform. ### Security Model Summary ```mermaid flowchart TD A["Hello.Fun"] --> B["Non Upgradeable Contracts"] A --> C["User Signed Transactions"] A --> D["Fixed Token Rules"] A --> E["Permanent Liquidity"] A --> F["Fixed Fee Rules"] A --> G["Limited Admin Permissions"] A --> H["Permissionless Graduation"] ``` No smart contract system can eliminate every possible risk. Hello.Fun's security architecture is designed to limit privileged control, keep user actions wallet authorized and enforce core market rules through deployed smart contracts. --- # 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/security-overview.md?ask=&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.