> 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/token-sales/pre-sale-stages-and-lifecycle.md).

# Pre-Sale Stages & Lifecycle

Canonical planned SONIC pre-sale state machine from provider evaluation and policy approval through sale, refund/success finalization, liquidity bootstrap and reconciliation.

**Target: Q4 2026 · Status: PLANNED**

This lifecycle is authoritative for product state naming. It does not imply that the pre-sale is open.

## Canonical lifecycle

```
DRAFT
→ PROVIDER_EVALUATION
→ POLICY_APPROVED
→ INVENTORY_FUNDED
→ CONFIGURED
→ SECURITY_REVIEW
→ VERIFIED
→ ANNOUNCED
→ OPEN
→ CLOSED
→ FINALIZING
   ├─ SUCCESS → ALLOCATED → CLAIMABLE/DISTRIBUTING → DEX_BOOTSTRAP → LIQUIDITY_VERIFIED → ROUTABLE → RECONCILED
   └─ FAILED  → REFUNDABLE → REFUNDING → REFUNDED → RECONCILED
```

Exceptional states: `PAUSED`, `CANCELLED`, `REQUIRES_REVIEW`.

## Stage contract

| Stage                 | Required outcome                                                                                                                    |
| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| `DRAFT`               | Commercial, tokenomics, legal and technical assumptions are documented.                                                             |
| `PROVIDER_EVALUATION` | PinkSale/Smithii.io or another approved provider is compared for Token-2022, fees, liquidity, refunds, security and reconciliation. |
| `POLICY_APPROVED`     | Exact sale amount/source allocation, pricing, eligibility, caps, vesting/claim and liquidity policy are approved.                   |
| `INVENTORY_FUNDED`    | Sale inventory is provably sourced from existing allocations with no double counting.                                               |
| `CONFIGURED`          | Provider/contract parameters, dates, accepted assets, treasury and limits are entered and frozen/versioned.                         |
| `SECURITY_REVIEW`     | Contract/program identity, authorities, signing flows, admin controls, refunds and dependencies pass review.                        |
| `VERIFIED`            | Production mint, provider/contract, inventory, treasury and final terms match the approved release manifest.                        |
| `ANNOUNCED`           | Public terms, risks, dates and canonical sale URL are published.                                                                    |
| `OPEN`                | Contributions are accepted only inside the approved window and eligibility policy.                                                  |
| `CLOSED`              | New contributions stop; late/ambiguous observations continue to reconciliation.                                                     |
| `FINALIZING`          | Provider/contract success condition, contributions, fees and inventory are verified.                                                |
| `SUCCESS`             | Approved minimum/soft-cap rule and finalization conditions passed.                                                                  |
| `FAILED`              | Approved success condition was not met or finalization was rejected.                                                                |
| `ALLOCATED`           | Concrete SONIC entitlements are recorded against settled contributions.                                                             |
| `CLAIMABLE`           | Claim prerequisites/vesting permit distribution.                                                                                    |
| `DISTRIBUTING`        | Authorized token distribution is executing.                                                                                         |
| `DEX_BOOTSTRAP`       | Approved liquidity is being created at the launch policy/reference.                                                                 |
| `LIQUIDITY_VERIFIED`  | Pool addresses, balances, pair configuration and on-chain creation are verified.                                                    |
| `ROUTABLE`            | Approved routing sources can discover valid liquidity; route availability remains external/provider-dependent.                      |
| `REFUNDABLE`          | Failed-sale contributions are eligible for the configured refund path.                                                              |
| `REFUNDING`           | Refund transactions are in progress.                                                                                                |
| `REFUNDED`            | Required refundable contributions have reached verified terminal outcomes.                                                          |
| `RECONCILED`          | Contributions, fees, inventory, claims/refunds, treasury and liquidity agree with authoritative evidence.                           |

## Success branch

```
CLOSED
→ verify soft/minimum threshold
→ verify final provider/contract state
→ settle accepted contributions
→ reconcile sold + unsold inventory
→ allocate contributor entitlements
→ create/verify launch liquidity when required
→ enable product market state
→ reconcile
```

A provider's visual `success` badge is evidence, not SONIC's final accounting authority.

## Failure/refund branch

```
CLOSED / CANCELLED
→ success condition not satisfied
→ freeze new allocations
→ determine refundable contributions from authoritative provider/contract state
→ execute or expose refund path
→ verify refunds
→ reconcile remaining inventory + treasury
```

No failed sale may be reclassified as successful merely to proceed to a DEX launch.

## Idempotency and identity

Use a durable SONIC `saleId`, `contributionId`, `allocationId` and `reconciliationId`. Provider transaction signatures and provider pool IDs are correlation/evidence fields, not SONIC business primary keys.

```
one logical contribution
→ at most one settled sale contribution
→ at most one funded SONIC allocation
→ one terminal claim/refund outcome per entitlement
```

Retries recover the same logical operation and must not duplicate payment, allocation, refund or distribution effects.


---

# 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/token-sales/pre-sale-stages-and-lifecycle.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.