> 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/smart-contracts.md). # Smart Contracts Hello.Fun uses a set of smart contracts to manage token launches, bonding curve markets, graduation, liquidity, trading and fees. The contracts operate on Robinhood Chain and define the onchain rules behind every Hello.Fun launch. ### Contract Architecture A Hello.Fun launch moves through several specialized contracts rather than relying on one contract to control the entire lifecycle. ```mermaid flowchart TD A["LaunchFactory"] --> B["LaunchDeployer"] B --> C["LaunchToken"] B --> D["BondingCurve"] D --> E["GraduationManager"] E --> F["UniswapV4Adapter"] F --> G["Uniswap v4 Pool"] G --> H["LiquidityLockerV4"] G --> I["LaunchFeeHook"] I --> J["FeeEscrow"] E --> K["ResidualVault"] L["LaunchSwapRouterV4"] --> G ``` Each component has a defined role within the system. ### LaunchFactory The LaunchFactory is the main registry and entry point for Hello.Fun launches. It is responsible for recording information including: 1. Launches 2. Launch identifiers 3. Supported pair assets 4. Pair specific economics 5. Pair approval status The factory connects the launch process with the pairing system and starts the graduation process when a launch becomes ready. ```mermaid flowchart LR A["Launch Request"] --> B["LaunchFactory"] B --> C["Launch Record"] B --> D["Pair Configuration"] B --> E["Launch Deployment"] ``` Pair assets must be approved before they can be used for new launches. ### LaunchDeployer The LaunchDeployer creates the contracts required for an individual launch. Each launch receives: 1. A LaunchToken 2. A BondingCurve ```mermaid flowchart TD A["LaunchDeployer"] --> B["LaunchToken"] A --> C["BondingCurve"] ``` The contracts are deployed at deterministic CREATE2 addresses. Hello.Fun launch tokens use the same core token contract logic. ### LaunchToken LaunchToken is the token contract created for a Hello.Fun launch. Every LaunchToken has: | Property | Configuration | | ------------------ | -------------------- | | Total Supply | 1,000,000,000 tokens | | Decimals | 18 | | Additional Minting | No | | Owner | None | | Blacklist | None | | Pause | None | The full supply is created once when the token is deployed and minted entirely to its BondingCurve. There is no function that allows additional tokens to be minted later. ```mermaid flowchart LR A["Token Creation"] --> B["1,000,000,000 Tokens Minted"] B --> C["BondingCurve"] C --> D["Fixed Supply"] ``` The token contract does not contain privileged transfer controls for freezing or blacklisting holders. ### BondingCurve Each launch receives its own BondingCurve contract. The BondingCurve manages the initial market before graduation. Its responsibilities include: 1. Holding the launched token supply during the curve phase 2. Receiving the pairing asset from buyers 3. Sending tokens to buyers 4. Processing sales while curve selling remains available 5. Maintaining the launch market state 6. Building reserves 7. Tracking progress toward graduation ```mermaid flowchart TD A["BondingCurve"] --> B["Buy"] A --> C["Sell"] B --> D["Pair Reserves"] C --> D D --> E["Graduation State"] ``` The bonding curve is the first market for a Hello.Fun token. ### GraduationManager The GraduationManager handles the transition from the bonding curve into the graduated market. Graduation takes place in two main stages. ```mermaid flowchart LR A["Graduation Ready"] --> B["Sweep Reserves"] B --> C["Seed Market"] C --> D["Uniswap v4 Pool"] ``` The GraduationManager moves the completed launch reserves into the infrastructure required to establish the Uniswap v4 market. If automatic graduation does not complete successfully, graduation completion can be triggered permissionlessly. This means completion does not depend exclusively on Hello.Fun initiating another transaction. ### UniswapV4Adapter The UniswapV4Adapter connects the Hello.Fun graduation process with Uniswap v4. It is responsible for creating the graduated pool and establishing its liquidity position. ```mermaid flowchart LR A["GraduationManager"] --> B["UniswapV4Adapter"] B --> C["Uniswap v4 Pool"] C --> D["Full Range Liquidity Position"] ``` The resulting liquidity position is created across the full price range. The position is minted directly into the permanent liquidity locker. ### LiquidityLockerV4 LiquidityLockerV4 is the permanent custodian of graduated liquidity positions. Once the liquidity position enters the locker, the contract does not provide functions for: 1. Withdrawing the position 2. Unlocking the position 3. Transferring the position 4. Decreasing the locked liquidity 5. Removing the liquidity principal ```mermaid flowchart LR A["Uniswap v4 Liquidity Position"] --> B["LiquidityLockerV4"] B --> C["Permanent Custody"] ``` The liquidity position remains permanently held by the locker. ### LaunchFeeHook Graduated Hello.Fun markets use a Uniswap v4 hook for protocol and creator fee handling. The hook operates during swaps. Its enabled permissions include: 1. Before Initialize 2. After Swap 3. After Swap Returns Delta Before Swap is not enabled. ```mermaid flowchart LR A["Uniswap v4 Swap"] --> B["LaunchFeeHook"] B --> C["Protocol Fee"] B --> D["Creator Fee"] C --> E["FeeEscrow"] D --> E ``` Because the hook does not have Before Swap permission, it cannot use that permission to block a sell before the swap occurs. The Protocol Fee is fixed in the contract. The Creator Fee for a launch is established when that launch is created. ### FeeEscrow FeeEscrow holds claimable protocol and creator balances generated through Hello.Fun markets. These balances are assigned to the appropriate recipients. ```mermaid flowchart TD A["Trading Activity"] --> B["Fee Credits"] B --> C["FeeEscrow"] C --> D["Creator"] C --> E["Protocol"] ``` Eligible recipients can claim the fees assigned to them. Fees are accounted for separately from the liquidity principal. ### ResidualVault During graduation, the protocol establishes the graduated market using the final state of the bonding curve. In some cases, token supply that cannot enter the pool without changing the intended opening market state is separated from the liquidity position. That supply is held by the ResidualVault. ```mermaid flowchart LR A["Graduation"] --> B["Pool Supply"] A --> C["Residual Supply"] B --> D["Uniswap v4 Market"] C --> E["ResidualVault"] ``` The ResidualVault does not provide a withdrawal function for this residual supply. ### LaunchSwapRouterV4 LaunchSwapRouterV4 is the router used for trading graduated Hello.Fun launches through their Uniswap v4 markets. ```mermaid flowchart LR A["Trader"] --> B["LaunchSwapRouterV4"] B --> C["LaunchFeeHook"] C --> D["Uniswap v4 Pool"] ``` It provides the trading route used after a launch has graduated from its bonding curve. ### Contracts Per Launch Hello.Fun uses shared infrastructure together with contracts created for individual launches. Every launch receives its own: 1. LaunchToken 2. BondingCurve ```mermaid flowchart TD A["Hello.Fun Infrastructure"] --> B["Launch 1"] A --> C["Launch 2"] A --> D["Launch 3"] B --> E["LaunchToken"] B --> F["BondingCurve"] C --> G["LaunchToken"] C --> H["BondingCurve"] D --> I["LaunchToken"] D --> J["BondingCurve"] ``` Each launch receives its own token and bonding curve while using the broader Hello.Fun graduation, liquidity, trading and fee infrastructure. Because the LaunchToken and BondingCurve addresses are created separately for each launch, they should be resolved through the LaunchFactory rather than hardcoded. ### Deployed Contract Addresses The following Hello.Fun infrastructure contracts are live on Robinhood Chain. **Network:** Robinhood Chain **Chain ID:** 4663 | Contract | Address | | ------------------ | -------------------------------------------- | | LaunchFactory | `0x83c69e1d4eb8c566b32ed3efa62ea798c3a1b9d3` | | LaunchDeployer | `0x95559c5AB9C0D5AF95049dc8461795c2BeBd5e30` | | LaunchFeeHook | `0x7c7d6cfb8ce006d6ccf0e9f92265a872e4302044` | | FeeEscrow | `0xeacfdb885d987667b6e6795af2c4e186f84e6461` | | GraduationManager | `0xf87abf5a6abd9a4b557652aab080899f9834cd9d` | | UniswapV4Adapter | `0x5b99a45100222af7445d40949f68e6ee39fc0f39` | | LiquidityLockerV4 | `0x5ed76f3c7500800553737aa647937b462227031c` | | ResidualVault | `0x45d2af8efd7b1dc6cc484b92f1f2b836b297516d` | | LaunchSwapRouterV4 | `0xe49c80270555dee3a72eef5f1d10e9539818d609` | LaunchToken and BondingCurve addresses are not listed as fixed infrastructure addresses because they are created separately for each launch. ### Non Upgradeable Design The deployed Hello.Fun contracts are non upgradeable. They do not use a proxy system that allows deployed contract logic to be replaced later. ```mermaid flowchart LR A["Deploy Contract"] --> B["Fixed Logic"] B --> C["Onchain Operation"] ``` This applies to the deployed contract logic itself. ### No Global Trading Pause The deployed system does not contain a global pause mechanism. There is no platform control that can simply pause all Hello.Fun trading across the deployed contracts. This is separate from normal transaction failures, market conditions or the state transitions of an individual launch. ### Contract Responsibilities Together, these contracts create the onchain lifecycle behind Hello.Fun: ```mermaid flowchart LR A["Create"] --> B["Launch"] B --> C["Trade"] C --> D["Graduate"] D --> E["Create Liquidity"] E --> F["Lock Liquidity"] F --> G["Continue Trading"] ``` From token creation through the graduated market, the core lifecycle is executed through smart contracts on Robinhood Chain. --- # 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/smart-contracts.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.