> For the complete documentation index, see [llms.txt](https://stonkfun.gitbook.io/stonkfun-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stonkfun.gitbook.io/stonkfun-docs/core-concepts/quote-token-safety.md).

# Quote token safety

This page applies to quote tokens a creator imports by pasting an address on the launch page. Tokens already in the registry are not re-audited.

The problem it solves: a launch locks its liquidity against the quote token forever. If that quote can be reprinted, frozen, taxed or repriced by a single wallet, the launch locked against it is worthless, and the creator signed nothing for any of it.

## The admission gate

An imported quote has to come through one of three doors. Nothing else is accepted, however clean the mint itself looks, and no door can be waived by trying again.

| Door                 | Requirement                                                                                                    |
| -------------------- | -------------------------------------------------------------------------------------------------------------- |
| Launched on StonkFun | At least `$100,000` market cap, read from the platform's own pool for that token                               |
| Jupiter verified     | On Jupiter's verified token list, with at least `$50,000` of total liquidity                                   |
| Launched on pump.fun | At least `$100,000` market cap, proven by the bonding curve existing on-chain rather than by a name or a label |

The market-cap floors matter more than provenance. A launch opens at around `$5,000`, and a `$5,000` quote is one wallet away from being repriced whoever created it. Without a floor the problem nests: a junk quote takes a launch, that launch becomes a quote, and the next launch prices itself against a market cap denominated in nothing.

## Was the supply bundled at birth?

A market cap describes the present, and the present is cheap to stage. A token can be created with most of its supply bought by its own creator in the same transaction, graduate within seconds, and show a large market cap on very little real depth.

So imported pump.fun tokens are also checked against what happened at the moment they first existed: what share of supply was acquired in the first couple of seconds, and whether any single wallet took an outsized piece of it. Roughly a second is far too fast for real demand, since nobody has heard of a token that soon after its mint appears. Anything buying inside that window knew the address in advance.

A creator's own opening buy is allowed up to a limit rather than excused entirely, because an unlimited exemption would just be an instruction to route the bundle through the creator's wallet.

Unlike a market cap, this is a fact about the past, and it cannot be restaged.

## The audit

Once through a door, the mint is checked on-chain.

| Check                                                   | Outcome                       |
| ------------------------------------------------------- | ----------------------------- |
| Live mint or freeze authority                           | **Refused**                   |
| Transfer fee an authority can still change              | **Refused**                   |
| Fixed transfer fee above 1%                             | **Refused**                   |
| Total liquidity below `$25,000`                         | **Refused**                   |
| Liquidity between `$25,000` and `$100,000`              | Warning                       |
| Market younger than 7 days                              | Warning                       |
| Less than half of LP burned or locked, where measurable | Warning                       |
| LP lock not measurable                                  | Warning, reported as unproven |
| Largest holder above 35% of supply                      | Warning                       |

Failures block the import. Warnings require you to acknowledge them before continuing.

Two of those deserve an explanation.

A live **mint authority** lets someone print quote tokens and swap them for the whole other side of your pool. A live **freeze authority** lets them freeze the pool's vault and lock the liquidity permanently. You would sign nothing for either, which is why both are refused rather than flagged.

A **transfer fee an authority can change** is refused no matter how small it is today, because it can be raised to 100% at any point after your liquidity is locked.

**LP lock being unmeasurable is not a red flag.** Concentrated-liquidity venues have no LP token whose supply can be burned, so "unmeasurable" is the normal answer for a lot of perfectly sound tokens. It is reported as unproven rather than as locked, and it never blocks an import on its own.

**Holder concentration is a warning only.** The largest holder of a healthy token is very often a pool vault or a treasury, and this data cannot tell one of those from a wallet about to sell.

## Third-party risk data

LP lock status and known risk flags are also checked against an external risk service. That input is advisory: when it is unreachable those checks become warnings rather than passes, and the on-chain checks above decide the import on their own.


---

# 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://stonkfun.gitbook.io/stonkfun-docs/core-concepts/quote-token-safety.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.
