> 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/token-protections.md).

# Token Protections

Every token launched through Hello.Fun uses the same core token contract logic.

The token structure is intentionally minimal, with a fixed supply and without privileged controls that could later change supply or restrict ordinary token transfers.

### Fixed Supply

Every Hello.Fun launch token has a total supply of:

**1,000,000,000 tokens**

The entire supply is minted once when the token is created.

```mermaid
flowchart LR
    A["Token Creation"] --> B["1,000,000,000 Tokens Minted"]
    B --> C["Fixed Supply"]
```

There is no additional mint function in the launch token contract.

Once the token has been created, additional supply cannot be minted through the token contract.

### 18 Decimals

Hello.Fun launch tokens use:

**18 decimals**

This is fixed within the token structure used for launches.

### No Token Owner

The launched token does not have an owner role.

```mermaid
flowchart TD
    A["LaunchToken"] --> B["No Token Owner"]
    B --> C["No Owner Minting"]
    B --> D["No Owner Blacklist"]
    B --> E["No Owner Transfer Freeze"]
```

This means there is no token owner with privileged controls over ordinary token transfers or token supply.

### No Additional Minting

The token supply is created once.

There is no function that allows the creator, Hello.Fun or another administrator to mint additional tokens later.

```mermaid
flowchart LR
    A["Initial Mint"] --> B["Fixed Supply"]
    B --> C["No Additional Mint Function"]
```

This prevents later supply expansion through the launch token contract.

### No Blacklist

Hello.Fun launch tokens do not contain blacklist functionality.

There is no privileged token role that can place a holder on a blacklist and prevent that wallet from transferring tokens through the token contract.

### No Transfer Freeze

The token contract does not include a privileged transfer freeze.

```mermaid
flowchart LR
    A["Token Holder"] --> B["Standard ERC20 Transfer"]
    B --> C["Recipient"]
```

The creator does not receive a special token permission that allows ordinary holder transfers to be frozen.

### Standard ERC20 Transfers

Hello.Fun launch tokens use standard ERC20 transfer behavior.

The token does not include a custom transfer hook that gives the creator or platform additional control over transfers.

```mermaid
flowchart TD
    A["LaunchToken"] --> B["ERC20 Transfers"]
    A --> C["No Blacklist"]
    A --> D["No Transfer Freeze"]
    A --> E["No Privileged Transfer Hook"]
```

This keeps the token contract focused on standard token functionality.

### No Burn Function

Hello.Fun launch tokens do not include a token burn function.

The fixed supply structure should therefore not be interpreted as a supply that creators can later modify through minting or burning controls.

```mermaid
flowchart LR
    A["1,000,000,000 Token Supply"] --> B["No Mint Function"]
    A --> C["No Burn Function"]
```

### Same Core Runtime Logic

Tokens created through Hello.Fun use identical core runtime bytecode.

```mermaid
flowchart TD
    A["Hello.Fun LaunchToken Logic"] --> B["Token A"]
    A --> C["Token B"]
    A --> D["Token C"]
```

Token names, symbols and metadata can differ between launches.

The underlying core token logic remains consistent.

### Immutable Metadata Reference

Token metadata is prepared before launch.

The resulting metadata reference is written into the token when it is created.

That reference is immutable after launch.

```mermaid
flowchart LR
    A["Metadata Prepared"] --> B["Token Created"]
    B --> C["Metadata Reference Written"]
    C --> D["Reference Remains Fixed"]
```

Creators should therefore review their metadata carefully before signing the launch transaction.

### Creator Control After Launch

Creating a token does not give the creator privileged control over the token contract.

The creator cannot use the launch token contract to:

1. Mint more supply
2. Burn supply
3. Blacklist holders
4. Freeze transfers
5. Change the token owner
6. Add privileged transfer restrictions

The creator's ongoing economic role is separate from control of the token contract.

For example, a creator may earn the creator fee configured for the launch, but that does not provide control over holder balances or token transfers.

### Hello.Fun Control After Launch

Hello.Fun administrative roles also do not receive token level powers to:

1. Mint additional supply
2. Burn holder tokens
3. Blacklist wallets
4. Freeze ordinary transfers

```mermaid
flowchart TD
    A["LaunchToken"] --> B["Creator"]
    A --> C["Hello.Fun"]
    B --> D["No Privileged Token Control"]
    C --> D
```

The token rules are enforced by the deployed token contract.

### Token Rules at a Glance

| Token Property           | Hello.Fun LaunchToken      |
| ------------------------ | -------------------------- |
| Total Supply             | 1,000,000,000              |
| Decimals                 | 18                         |
| Supply Minted            | Once at creation           |
| Additional Minting       | No                         |
| Burn Function            | No                         |
| Token Owner              | No                         |
| Blacklist                | No                         |
| Transfer Freeze          | No                         |
| Privileged Transfer Hook | No                         |
| Core Runtime Logic       | Consistent across launches |
| Metadata Reference       | Immutable after launch     |

### What These Protections Do Not Mean

A fixed and minimal token contract does not remove normal market or smart contract risk.

Token price can still rise or fall.

Liquidity and trading activity can change.

Users remain responsible for evaluating the project, market and risks associated with a token.

The token protections described here relate specifically to the powers available within the Hello.Fun launch token contract.

### Fixed From Launch

The Hello.Fun token model is designed to make the core token rules clear from the moment a launch is created.

```mermaid
flowchart LR
    A["Launch"] --> B["Fixed Supply"]
    B --> C["No Additional Minting"]
    C --> D["No Owner Controls"]
    D --> E["Standard Transfers"]
```

**Minted once. Fixed supply. No token owner. No blacklist. No transfer freeze.**


---

# 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/token-protections.md?ask=<question>&goal=<user_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.