> 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/contract-verification.md). # Contract Verification Hello.Fun smart contracts are deployed on Robinhood Chain with source verification available through blockchain verification infrastructure. Verification allows the deployed contract bytecode to be matched against its published source code. ### What Contract Verification Means When a smart contract is deployed, the blockchain stores its compiled bytecode. Source verification provides a way to demonstrate that published source code corresponds to the contract running onchain. ```mermaid flowchart LR A["Source Code"] --> B["Compilation"] B --> C["Contract Bytecode"] C --> D["Deployed Contract"] A --> E["Verification"] D --> E E --> F["Match"] ``` This gives users, developers and researchers a way to inspect the logic behind the deployed contracts. ### Hello.Fun Verification The deployed Hello.Fun contracts have been verified through: 1. Sourcify 2. Blockscout Sourcify verification includes matches for both contract creation and runtime code. ```mermaid flowchart TD A["Hello.Fun Contract"] --> B["Sourcify"] A --> C["Blockscout"] B --> D["Verified Source"] C --> D ``` ### Creation and Runtime Verification Contract verification can examine different parts of a deployment. #### Creation Code Creation code is the bytecode used when the contract is initially deployed. #### Runtime Code Runtime code is the contract logic that remains onchain and executes after deployment. Hello.Fun contract verification includes full creation and runtime matches through Sourcify. ```mermaid flowchart LR A["Contract Source"] --> B["Creation Code Match"] A --> C["Runtime Code Match"] B --> D["Verified Deployment"] C --> D ``` ### Why Runtime Verification Matters Runtime bytecode is the logic that executes when users interact with a deployed contract. Matching the runtime code allows the published contract source to be compared with the code actually operating onchain. This is particularly relevant for mechanics such as: 1. Token supply rules 2. Bonding curve behavior 3. Graduation 4. Liquidity locking 5. Fee handling 6. Contract permissions ### Launch Token Consistency Hello.Fun launch tokens use the same core runtime bytecode. This means the core token contract logic is consistent across tokens created through the Hello.Fun launch system. ```mermaid flowchart TD A["Hello.Fun LaunchToken Logic"] --> B["Launch Token A"] A --> C["Launch Token B"] A --> D["Launch Token C"] ``` Each token still has its own launch identity and metadata, but the underlying runtime token logic follows the same Hello.Fun implementation. ### Verification and Non Upgradeable Contracts Hello.Fun contracts are non upgradeable. They do not use a proxy mechanism that allows the deployed implementation to be replaced later. ```mermaid flowchart LR A["Verified Contract"] --> B["Fixed Runtime Logic"] B --> C["Onchain Operation"] ``` This makes verification particularly useful because the deployed contract logic is not designed to later point to a replacement implementation. ### Verification Is Not an Audit Contract verification and a security audit are different. Verification demonstrates that published source corresponds to deployed bytecode. An audit involves an independent security review of the contract design and implementation. ```mermaid flowchart TD A["Contract Verification"] --> B["Source and Bytecode Match"] C["Security Audit"] --> D["Independent Security Review"] ``` A verified contract should not automatically be interpreted as an audited contract. ### Current Audit Status The current Hello.Fun contract architecture has not yet completed an external third party security audit. The system has undergone internal testing, including contract tests covering launch lifecycle behavior, fee handling, graduation, liquidity locking and adversarial scenarios. External verification of the deployed source and internal testing are separate from an independent third party audit. ### Transparency Through Verification Verification makes the deployed contract logic available for technical inspection. ```mermaid flowchart LR A["Deployed Contract"] --> B["Verified Source"] B --> C["Public Inspection"] ``` Users and researchers can use verified source information to examine how the deployed contracts operate rather than relying only on the Hello.Fun interface. ### Contract Addresses Hello.Fun contract addresses should be verified against official Hello.Fun resources before interacting directly with a contract. Users should avoid relying on contract addresses shared through unofficial messages or unverified third party sources. ### Verification Summary | Area | Status | | -------------------------------------------------- | ------------- | | Deployed contract source verification | Verified | | Sourcify verification | Available | | Creation code match | Full match | | Runtime code match | Full match | | Blockscout verification | Available | | Upgradeable proxy architecture | No | | External third party audit of current architecture | Not completed | Contract verification provides transparency into what is deployed. It does not replace security review, risk assessment or responsible interaction with 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/contract-verification.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.