> For the complete documentation index, see [llms.txt](https://sonic-ai-works.gitbook.io/sonic-networks-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sonic-ai-works.gitbook.io/sonic-networks-docs/documentation/sonic-tokenomics/markets-and-liquidity.md).

# Markets & Liquidity

Planned SONIC post-sale DEX and liquidity policy across Raydium, Meteora, Orca and Jupiter routing, including launch-price references, pool-depth objectives and risk controls.

**Status: PLANNED / DEPLOYMENT-GATED**

A planning price, configured adapter or permissionless pool is not verified SONIC liquidity.

## Launch baseline

| Item                            | Planning state                          |
| ------------------------------- | --------------------------------------- |
| Pre-sale price reference        | **\~$0.000002 / SONIC**                 |
| Initial DEX price reference     | **\~$0.0000025 / SONIC**                |
| Initial direct liquidity venues | **Raydium · Meteora · Orca candidates** |
| Aggregated route discovery      | **Jupiter after verified liquidity**    |
| Pair composition                | **TBA**                                 |
| Initial liquidity amount        | **TBA**                                 |
| Treasury/proceeds funding split | **TBA**                                 |
| Pool addresses                  | **TBA**                                 |

These are planning references, not guaranteed execution prices or market values.

## Venue model

### Direct pool venues

* **Raydium** — candidate primary pool venue and a practical target when the selected launchpad supports verified post-sale liquidity creation.
* **Meteora** — candidate complementary liquidity venue after pair/pool policy and Token-2022 behavior are verified.
* **Orca** — candidate venue; activation requires explicit compatibility, pool and operational verification.

### Jupiter

**Jupiter is treated as an aggregator/routing layer, not the same type of direct listing venue as a liquidity pool.** SONIC should report Jupiter availability only after a valid route to verified SONIC liquidity is actually discoverable.

## Successful pre-sale → market activation

```
successful pre-sale
→ contribution + inventory reconciliation
→ approved liquidity funding
→ create direct pool(s)
→ verify pool addresses + balances + parameters
→ verify launch-market state
→ wait for factual route discovery
→ enable supported Swap / market UI
→ continuous reconciliation
```

No route or venue becomes `Live` because its name is present in configuration.

## Liquidity depth objective

SONIC's launch objective is **deeper, healthier liquidity rather than the maximum number of thin pools**.

More pool liquidity can reduce price impact and slippage for a given trade size, all else equal. It does **not** eliminate or control token-price volatility. Market price can still move materially because of order flow, liquidity withdrawals, external markets, sentiment, concentration and broader crypto-market conditions.

Useful operating metrics include:

* verified token and counter-asset liquidity;
* estimated price impact for representative trade sizes;
* spread/quote quality across routes;
* LP concentration and withdrawal risk;
* route success/failure rate;
* volume relative to pool depth;
* pool/route health and stale-provider detection; and
* reconciliation between product state and on-chain balances.

## Controlled expansion policy

Additional DEX venues should be added progressively when existing liquidity and demand justify them.

```
verified demand
+ sufficient treasury/LP funding
+ Token-2022 compatibility
+ acceptable execution quality
+ operational monitoring
+ security review
→ venue can be activated
```

Adding a venue should not unnecessarily fragment liquidity. A new venue is enabled only when its expected routing, reach or resilience benefit outweighs fragmentation and operational complexity.

## Market truth

```
approved market policy
→ deployment registry
→ verified mint
→ verified pool addresses
→ on-chain balance/config verification
→ route/provider observation
→ product feature enablement
→ reconciliation
```

A token symbol, explorer search result, price-provider response or permissionless pool is not sufficient evidence that SONIC recognizes a market as official.

## Risk notice

{% hint style="danger" %}
Liquidity does not guarantee price stability or exit capacity. DEX users face volatility, slippage, price impact, smart-contract risk, LP withdrawal risk, routing/MEV risk, oracle/provider failures and possible total loss. The planned $0.0000025 launch reference is not a price floor, target return or promise of future value.
{% endhint %}


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://sonic-ai-works.gitbook.io/sonic-networks-docs/documentation/sonic-tokenomics/markets-and-liquidity.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.