> 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/audit-status.md). # Audit Status Security review is an important part of evaluating smart contract infrastructure. Hello.Fun combines an extensive contract test suite and deployed source verification with a contract architecture designed to limit privileged control. The current Hello.Fun contract architecture has not yet completed an independent third party security audit. ### Current Security Status | Area | Current Status | | ----------------------------- | --------------------------------- | | Smart Contract Testing | Extensive contract test suite | | Contract Test Files | 63 | | Source Verification | Verified | | Sourcify | Full creation and runtime matches | | Blockscout | Verified | | Independent Third Party Audit | Not completed | These areas represent different forms of technical review and should not be treated as interchangeable. ### Contract Testing The Hello.Fun contract suite includes 63 contract test files. Testing covers areas including: 1. Launch lifecycle 2. Trading behavior 3. Fee distribution 4. Graduation 5. Liquidity locking 6. Adversarial scenarios ```mermaid flowchart TD A["Contract Test Suite"] --> B["Launch Lifecycle"] A --> C["Fees"] A --> D["Graduation"] A --> E["Liquidity Locking"] A --> F["Adversarial Scenarios"] ``` The test suite is used to validate expected contract behavior and identify implementation issues. ### Contract Verification Hello.Fun's deployed contracts are source verified. Verification is available through Sourcify and Blockscout. ```mermaid flowchart LR A["Contract Source"] --> B["Verification"] B --> C["Creation Code Match"] B --> D["Runtime Code Match"] C --> E["Verified Deployment"] D --> E ``` Sourcify reports full matches for both creation and runtime code. This allows the published source to be compared with the bytecode deployed onchain. ### Verification Is Different From an Audit Source verification confirms the relationship between source code and deployed bytecode. An independent audit evaluates the contracts from a security perspective. ```mermaid flowchart TD A["Source Verification"] --> B["Does the source match the deployed code?"] C["Independent Audit"] --> D["Security review of the design and implementation"] ``` A verified contract should therefore not be described as independently audited unless a third party audit of that architecture has actually been completed. ### Current External Audit Status The current Hello.Fun architecture has not completed an independent third party security audit. This status applies to the current contract system described throughout this documentation. Hello.Fun does not treat source verification or its contract test suite as a replacement for an independent audit. ### Security Architecture While an external audit remains separate from the current testing and verification status, the deployed architecture includes several contract level protections. These include: 1. Non upgradeable contracts 2. No global trading pause 3. Fixed launch token supply 4. No token owner 5. No blacklist 6. No transfer freeze 7. Permanent graduated liquidity locking 8. Fixed fee rules for existing launches 9. Permissionless graduation completion 10. Restricted administrative permissions 11. Reentrancy protections 12. Controlled Uniswap v4 pool initialization ```mermaid flowchart TD A["Hello.Fun Security Architecture"] --> B["Fixed Contract Logic"] A --> C["Token Protections"] A --> D["Liquidity Protections"] A --> E["Graduation Protections"] A --> F["Limited Permissions"] ``` These protections describe how the current contracts are structured. They do not eliminate smart contract risk or replace independent security review. ### Non Upgradeable Architecture The deployed contracts do not use an upgradeable proxy architecture. ```mermaid flowchart LR A["Verified Deployment"] --> B["Non Upgradeable Contract"] B --> C["Fixed Runtime Logic"] ``` This means the deployed implementation is not designed to be replaced later through an administrative proxy upgrade. ### Security Review Is More Than One Layer Smart contract security is not determined by a single check. ```mermaid flowchart TD A["Security Review"] --> B["Testing"] A --> C["Source Verification"] A --> D["Architecture Review"] A --> E["Independent Audit"] ``` Testing can identify implementation failures. Verification can show what code is deployed. Architecture can limit privileged capabilities. Independent review can provide another layer of security assessment. Each serves a different purpose. ### Risk Still Exists No testing process, verification system or smart contract design can guarantee that a protocol is free from vulnerabilities. Hello.Fun involves smart contracts, blockchain transactions, bonding curve markets, Uniswap v4 integration and external infrastructure. Users should consider these risks before interacting with the platform. ### Audit Status Summary ```mermaid flowchart LR A["Current Hello.Fun Contracts"] --> B["Extensive Test Suite"] A --> C["Source Verified"] A --> D["Deployed"] A --> E["Independent Third Party Audit Not Completed"] ``` Hello.Fun documents its current audit status separately from its testing and verification status so users can distinguish between the contract test suite, deployed source verification and independent security review. --- # 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/audit-status.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.