> 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/launching/launch-safety.md).

# Launch safety and atomicity

A launch spends real money on irreversible on-chain actions. This page describes what the platform guarantees about that.

## Before you are shown a price

The platform validates all of this before presenting you with a payment:

* That it is talking to the right Solana network, verified against the chain's own identity
* That the Raydium programs and the fee tier your pool needs are live
* That your quote token is registered, available, and not blocked
* That the quote token's mint really has the properties its record claims
* That Raydium supports the quote token's features
* That your logo decodes and is within size limits
* That a live price for the quote token can be read
* That the platform can afford to execute the launch

Every one of those values is then signed into your quote and bound to your payment, so your launch executes with exactly the values you were quoted.

## The two outcomes

Launches are all or nothing. The payment, mint, pool, liquidity and any dev buy are submitted as one atomic bundle.

| Response                                    | What it means                                                       | What to do                                                   |
| ------------------------------------------- | ------------------------------------------------------------------- | ------------------------------------------------------------ |
| `completed`                                 | The launch is live and recorded                                     | Nothing                                                      |
| `processing`                                | The launch is **on chain**, and the last details are being recorded | Poll the status. It finishes even if your process dies.      |
| `service_unavailable` with `charged: false` | The bundle did not land                                             | **Nothing was charged.** Get a fresh quote and submit again. |

{% hint style="danger" %}
Never pay twice on `processing`. A second payment creates a second token.
{% endhint %}

Poll `GET /api/public/v1/launches/{paymentSignature}` until `status` reads `completed`. The old quote's payment expires on its own either way, which is why a retry after a failed bundle is a fresh quote rather than a resubmission.

## You cannot be charged twice

Once your payment lands, its signature becomes the identity of your launch. Each payment signature can own only one launch job, and a lease stops two workers from ever processing the same payment.

The mint address is deterministic and every address the launch creates is recorded before it is broadcast. On a retry, every existing account is checked against what the launch expected before it is reused, and any step whose accounts already exist is skipped.

## Checks that run mid-launch

Two things are verified during the launch, and both stop it rather than warn.

The pool's fee configuration is read back from the chain and compared against what was requested. That value is immutable, so a mismatch would mean the pool collected fees the wrong way for its entire life.

The realised liquidity split is read back from the two positions and checked against the target before either one is locked. A launch cannot be re-run, so this is the last chance to catch a mismatch before it becomes permanent.

There is also a guard on the opening price: if tick alignment would move the market cap more than 25% from the target, the launch is refused. Failing a launch is recoverable, and a mispriced pool is not.

## Non-custody

* No endpoint accepts, requests or stores a private key.
* You sign your own fee payment, locally.
* No platform key signs anything you supply.
* A fee-claim transaction is only valid signed by the wallet holding the Fee Key, and pays that wallet's own accounts.
* The submit endpoint relays only the exact transaction the prepare step issued. Its instructions are checked against what was built before anything is broadcast, so it cannot be used as a general transaction relay.


---

# 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/launching/launch-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.