> 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/choosing-a-pair.md). # Choosing a Pair Every token launched through Hello.Fun starts with a pair. The pair determines what asset the new token trades against and becomes part of the structure of its market from the moment it launches. ### What Is a Pair? A trading pair connects two assets within one market. For a Hello.Fun launch, one side of the pair is the newly created token. The other side is the pairing asset. ```mermaid flowchart LR A["New Token"] --> C["Pair Market"] B["Pairing Asset"] --> C ``` The pairing asset is used throughout the launch lifecycle. It is used for bonding curve trading before graduation and remains the quote asset of the graduated Uniswap v4 market. ### Current Pairing Asset **ETH is currently the live pairing asset available for Hello.Fun launches.** A token launched with ETH begins by trading against ETH through its bonding curve. When the token graduates, its market transitions into a Uniswap v4 pool where ETH remains its pairing asset. ```mermaid flowchart LR A["Token + ETH"] --> B["Bonding Curve"] B --> C["Graduation"] C --> D["Token + ETH"] D --> E["Uniswap v4"] ``` The pair therefore remains connected to the token throughout its market lifecycle. ### Why the Pair Matters The pairing asset is more than a launch setting. It defines the asset used to enter and exit the market. During the bonding curve stage: 1. Buyers provide the pairing asset to purchase tokens. 2. Sellers return tokens to receive the pairing asset. 3. Trading builds reserves in the pairing asset. 4. Those reserves contribute to the token's graduated market. At graduation, the pairing asset becomes part of the liquidity used to establish the Uniswap v4 pool. ### Pairing and Graduation Each approved pairing asset can have its own market configuration. This allows Hello.Fun to define appropriate launch economics for different pairing assets. The pairing configuration can include the conditions used to determine when a launch is ready to graduate. Once a token is launched, its pair configuration is established for that launch. Changes made to the available pair list later do not alter existing launches. ### Approved Pairing Assets Hello.Fun does not allow an arbitrary asset to be entered and used as a pairing asset. Pairing assets must first be supported and approved by the platform. Before an asset can be used for new launches, it must satisfy the requirements of the pairing system. ```mermaid flowchart TD A["Potential Pairing Asset"] --> B["Pair Configuration"] B --> C["Pair Approval"] C --> D["Available for New Launches"] D --> E["Creator Selects Pair"] E --> F["Launch Market Created"] ``` This allows Hello.Fun to expand pair choice while maintaining a defined market structure for launches. ### Expanding Pair Choice The Hello.Fun pairing system is designed to support more than one pairing asset. ETH is the first live pairing asset. Additional approved assets can be introduced as the Hello.Fun ecosystem expands. This is where the broader idea behind Hello.Fun begins. Instead of treating the pair as an afterthought, Hello.Fun makes it part of how a launch market is formed. **Pick your pair. Pick your market.** --- # 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/choosing-a-pair.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.