> 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/permissions-and-admin-controls.md). # Permissions & Admin Controls Hello.Fun uses limited administrative roles for specific operational responsibilities. These roles do not provide unrestricted control over launches, user funds, token supply or graduated liquidity. The permissions are separated according to function. ### Permission Structure The main privileged roles within the Hello.Fun architecture are: 1. Factory Admin 2. Pair Lister 3. Hook Owner 4. Fee Sweep Operator ```mermaid flowchart TD A["Hello.Fun Permissions"] --> B["Factory Admin"] A --> C["Pair Lister"] A --> D["Hook Owner"] A --> E["Fee Sweep Operator"] ``` Each role has a defined scope. ### Factory Admin The Factory Admin has access to a restricted graduation recovery function. This function is designed for a specific situation where graduation reserves have already been moved but the pool seeding process has failed. It cannot be used as a general withdrawal mechanism. ```mermaid flowchart TD A["Graduation Reserves Swept"] --> B["Pool Seeding Failure"] B --> C["Recovery Conditions"] C --> D["Required Delay"] D --> E["Factory Admin Recovery"] E --> F["Funds Sent to Creator"] ``` For the recovery path to become available: 1. The launch must already be in the required swept state 2. A pool seeding failure must have been recorded 3. The required delay must have elapsed If recovery is executed, the funds are sent to the creator. They are not sent to the Factory Admin. ### Pair Lister The Pair Lister controls which pairing assets can be used for new Hello.Fun launches. Its responsibilities include: 1. Configuring pair economics 2. Setting phantom liquidity 3. Setting graduation conditions 4. Approving a pair for new launches 5. Removing approval for future launches ```mermaid flowchart TD A["Pair Lister"] --> B["Pair Economics"] A --> C["Pair Approval"] B --> D["Phantom Liquidity"] B --> E["Graduation Conditions"] C --> F["Available for New Launches"] ``` This role allows Hello.Fun to expand the supported pairing system over time. ### Existing Launches Are Not Reconfigured Pair management applies to the availability and configuration of pair assets for new launches. Once a launch has been created, its pairing asset and launch economics are fixed for that launch. ```mermaid flowchart LR A["Launch Created"] --> B["Pair and Economics Fixed"] C["Later Pair Configuration Change"] --> D["Future Launches"] ``` Changing the supported pair configuration does not rewrite the economics of an existing launch. ### Hook Owner The Hook Owner has limited configuration permissions related to the Hello.Fun Uniswap v4 hook. The role can configure: 1. The Fee Sweep Operator 2. The maximum internal price impact setting ```mermaid flowchart TD A["Hook Owner"] --> B["Set Fee Sweep Operator"] A --> C["Set Maximum Internal Price Impact"] ``` The Hook Owner cannot use these permissions to change the protocol fee rate. ### Fee Sweep Operator The Fee Sweep Operator has a specific role in handling accumulated fee assets. It can perform supported fee conversions subject to the price impact limits enforced by the system. ```mermaid flowchart LR A["Accumulated Fee Assets"] --> B["Fee Sweep Operator"] B --> C["Controlled Conversion"] C --> D["Price Impact Limit"] ``` This role does not provide control over graduated liquidity. It also does not give the operator ownership of creator or user funds. ### Fee Rates Cannot Be Raised The protocol fee is fixed in the deployed contract logic. The creator fee is selected when a launch is created and remains fixed for that launch. ```mermaid flowchart LR A["Launch Created"] --> B["Fee Terms Established"] B --> C["Existing Launch"] C --> D["Fees Remain Fixed"] ``` Administrative roles do not have a function that allows them to increase the fee rate on an existing launch. ### No Global Pause Hello.Fun does not include an administrative global pause function. ```mermaid flowchart LR A["Administrator"] --> B["No Global Pause Control"] B --> C["Deployed Markets"] ``` An administrator cannot use a platform level pause function to halt all trading across deployed Hello.Fun markets. ### No Contract Upgrades The deployed Hello.Fun contracts are non upgradeable. Administrative roles cannot replace the implementation of an existing contract through a proxy upgrade. ```mermaid flowchart LR A["Deployed Contract"] --> B["Fixed Logic"] B --> C["No Upgrade Path"] ``` This limits the ability of privileged roles to change the fundamental rules of an already deployed contract. ### No Control Over Launch Token Supply Administrative roles cannot use the Hello.Fun launch token contract to: 1. Mint additional supply 2. Burn token supply 3. Freeze transfers 4. Blacklist holders The creator cannot perform these actions either. ```mermaid flowchart TD A["LaunchToken"] --> B["Fixed Supply"] A --> C["No Admin Minting"] A --> D["No Admin Blacklist"] A --> E["No Admin Transfer Freeze"] ``` These restrictions come from the token contract design. ### No Graduated Liquidity Withdrawal Administrative roles cannot withdraw graduated liquidity from LiquidityLockerV4. The locker does not provide a withdrawal or unlock function for the liquidity principal. ```mermaid flowchart LR A["Graduated Liquidity"] --> B["LiquidityLockerV4"] B --> C["Permanent Custody"] ``` This means administrative permissions elsewhere in the system do not provide a route around the liquidity lock. ### What Administrative Roles Can and Cannot Do | Action | Administrative Control | | -------------------------------------------- | ----------------------------- | | Approve pairs for future launches | Yes | | Configure economics for future pair launches | Yes | | Set Fee Sweep Operator | Yes | | Configure maximum internal price impact | Yes | | Use restricted graduation recovery | Yes, under defined conditions | | Raise fees on an existing launch | No | | Mint additional launch tokens | No | | Burn holder tokens | No | | Blacklist holders | No | | Freeze token transfers | No | | Withdraw graduated liquidity | No | | Unlock graduated liquidity | No | | Globally pause trading | No | | Upgrade deployed contracts | No | | Take user funds | No | | Take creator funds | No | ### Separation of Permissions Hello.Fun does not place every privileged action under one unrestricted role. ```mermaid flowchart TD A["Operational Permissions"] --> B["Pair Management"] A --> C["Hook Configuration"] A --> D["Fee Conversion"] A --> E["Restricted Graduation Recovery"] B --> F["Pair Lister"] C --> G["Hook Owner"] D --> H["Fee Sweep Operator"] E --> I["Factory Admin"] ``` Different responsibilities are separated across defined permission areas. ### Administrative Control Has Boundaries Administrative permissions exist where the system requires operational management. Those permissions do not extend to unrestricted control over the core assets and rules of an existing launch. ```mermaid flowchart TD A["Admin Permissions"] --> B["Operational Functions"] A -.-> C["No Token Minting"] A -.-> D["No Liquidity Withdrawal"] A -.-> E["No Fee Increase"] A -.-> F["No Global Pause"] A -.-> G["No Contract Upgrade"] ``` The result is a permission model where administrative roles can perform specific operational functions while core launch protections remain enforced by the deployed 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/permissions-and-admin-controls.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.