> 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/launching-a-token/token-structure.md). # Token Structure Every token launched through Hello.Fun follows the same core token structure. The token is created with a fixed supply and a minimal ERC20 design. There are no creator controls for increasing supply, freezing transfers or blacklisting wallets after launch. ### Fixed Supply Every Hello.Fun launch creates: | Property | Structure | | ------------------ | --------------------- | | Total Supply | 1,000,000,000 tokens | | Decimals | 18 | | Supply Creation | Minted once at launch | | Additional Minting | Not available | | Token Owner | None | | Blacklist | None | | Transfer Freeze | None | The entire supply is created once when the token contract is deployed. There is no additional mint function. This means the total supply cannot be increased after launch. ### How the Supply Moves Once the token is created, the complete supply moves into the bonding curve. The bonding curve then becomes the starting market for the token. ```mermaid flowchart LR A["Token Created"] --> B["1,000,000,000 Tokens Minted"] B --> C["Full Supply Moves to Bonding Curve"] C --> D["Trading Opens"] ``` Tokens are distributed through market activity rather than through additional minting. ### No Token Owner Hello.Fun launch tokens do not include a privileged token owner. Once deployed, there is no token owner with special control over normal token transfers or supply. The creator therefore cannot use the token contract to: 1. Mint additional supply 2. Blacklist a wallet 3. Freeze token transfers 4. Restrict standard ERC20 transfers These restrictions come from the structure of the token contract itself. ### No Additional Minting The token supply is created once during deployment. There is no public or privileged function that can create additional tokens later. ```mermaid flowchart TD A["Token Deployment"] --> B["Fixed Supply Minted Once"] B --> C["Supply Fixed"] C --> D["No Additional Mint Function"] ``` The supply visible after launch represents the complete token supply. ### No Blacklist The token contract does not contain blacklist functionality. Creators do not receive a mechanism for placing individual wallets on a restricted list through the token contract. ### No Transfer Freeze Hello.Fun launch tokens use standard ERC20 transfers without a custom transfer restriction mechanism. There is no creator controlled function for freezing normal token transfers after launch. ### No Burn Function Hello.Fun launch tokens do not include a dedicated burn function. The fixed supply model is therefore based on a supply that is created once and cannot later be increased or reduced through a token contract mint or burn function. ### Identical Core Token Logic Hello.Fun launches use the same core token implementation. Each new launch creates a separate token contract, but the underlying runtime logic of the token contract is identical across Hello.Fun launches. The identity of each token comes from its individual launch information, including its name, symbol and metadata. The core token behavior remains consistent. ### Token Metadata A token also contains a reference to its metadata. This metadata supports the information displayed for the project, including its description, image and related links. The metadata reference is set when the token launches and is immutable. For this reason, creators should review their token information carefully before confirming the launch. ### Token Structure at a Glance ```mermaid flowchart TD A["Hello.Fun Token"] --> B["Fixed Supply"] A --> C["18 Decimals"] A --> D["No Additional Minting"] A --> E["No Token Owner"] A --> F["No Blacklist"] A --> G["No Transfer Freeze"] A --> H["No Burn Function"] A --> I["Immutable Metadata Reference"] ``` ### Built Into Every Launch The token structure is not an optional configuration selected by individual creators. It is part of how Hello.Fun launch tokens are built. Every launch begins with the same fixed supply model and the same core ERC20 behavior. Creators define the identity and market settings of their launch. The fundamental token structure remains consistent. --- # 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/launching-a-token/token-structure.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.