> For the complete documentation index, see [llms.txt](https://paimon-finance.gitbook.io/paimon.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://paimon-finance.gitbook.io/paimon.finance/architecture/launchpad.md).

# Launchpad: 4-Layer Drop

The Paimon Launchpad is the issuance venue for Paimon-curated alternative assets. It is **live on BSC mainnet** and has executed at least one production drop (xSPCX SpaceX SPV, V4 contract, April 2026).

| Module                       | Mainnet address                                       |
| ---------------------------- | ----------------------------------------------------- |
| `LaunchpadDrop` (V4.2.2)     | `0xea088Af719F3238982823fa5eE1C1FaCb2E0e231`          |
| `LaunchpadSettlement`        | (operational, not enumerated)                         |
| `PaimonTreasury` (launchpad) | (operational, not enumerated)                         |
| `PaimonBadge`                | `0x48e9a6846D9722599621aF8A6af0F23b0dB8184a`          |
| `PointsHubV2`                | `0x748560eaCcd4C01FC29b3B5b72d3b8C85B2B5017`          |
| Settlement currency          | USDT BSC `0x55d398326f99059fF775485246999027B3197955` |

## Drop Lifecycle

A Drop progresses through eight on-chain phases, defined in `DropPhase` (`ILaunchpadDrop.sol:8-17`):

```
Created ──► QuestActive ──► Snapshot ──► Commitment ──► LayerSale ──► Settled ──► Finalized
                                                                          │
                                                                          └──► Cancelled (any phase)
```

| Phase         | What happens                                                                                                                                 | Triggered by                             |
| ------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------- |
| `Created`     | Drop config + 4 layers configured; RWA token escrowed; metadata linked                                                                       | `createDrop` (KEEPER)                    |
| `QuestActive` | Pre-drop quest period (if any) — users earn points via tasks                                                                                 | `advancePhase`                           |
| `Snapshot`    | Merkle snapshot of points balances taken; users below the per-layer threshold are filtered out                                               | `setSnapshot` (KEEPER, off-chain merkle) |
| `Commitment`  | Users call `commit(layerIdx, usdtAmount)` — locks points + escrows USDT                                                                      | `advancePhase`                           |
| `LayerSale`   | Layer-by-layer settlement: keeper calls `settleLayerBatch` (Batch mode) or sets `settlementRoot` (MerkleClaim mode); users `claimAllocation` | `advancePhase`                           |
| `Settled`     | Refund window opens; over-committed USDT returned via `requestRefund`; per-layer `closeRefundWindow` ends the window                         | `advancePhase`                           |
| `Finalized`   | All layers closed, USDT split between Treasury and vePool, leftover RWA returned to issuer, badges minted via `finalizeUserPoints`           | `finalizeSettlement`                     |

## Layer Structure

Every drop has **exactly four layers** (`LAYER_COUNT = 4`, `LaunchpadDrop.sol:47`). Each layer is independently configured via the `LayerConfig` struct (`ILaunchpadDrop.sol:37-46`):

| Field                           | Meaning                                                                                                                                                           |
| ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `priceDiscount`                 | Discount in basis points off `basePrice` (e.g. `6032` = 60.32 % off)                                                                                              |
| `minUsdtRequired`               | Minimum USDT a wallet must commit to participate in this layer (`0` = no floor)                                                                                   |
| `pointsPerUsd`                  | Points consumed per 1 USDT committed (`1e18` precision; e.g. `1.5e18` = 1.5 points per $1)                                                                        |
| `allocationBps`                 | Layer's share of the total raise in basis points (the four layers must sum to `10000`)                                                                            |
| `perWalletCap`                  | Maximum USDT a single wallet can commit in this layer (`0` = no cap)                                                                                              |
| `saleStartTime` / `saleEndTime` | Layer-specific sale window (layers can overlap or stagger)                                                                                                        |
| `mode`                          | `SettlementMode.Batch` (keeper allocates on-chain, gas-bounded `MAX_BATCH_SIZE = 200`) or `SettlementMode.MerkleClaim` (off-chain merkle, user claims with proof) |

The points-and-USDT double-gate is what differentiates a Paimon drop from a plain "first-come-first-served" sale: lower layers offer steeper discounts but require more points, so users who consistently engage with the protocol (staking, social tasks, holding) get priority access to the best prices.

## Worked Example — xSPCX V4 (April 2026)

This is a real drop that executed on mainnet, with parameters as committed via the V4 contract.

| Metric                | Value                                    |
| --------------------- | ---------------------------------------- |
| Asset                 | `xSPCX` Paimon Tradable SpaceX SPV Token |
| Total supply for sale | 30,600 xSPCX                             |
| Total raise target    | $200,000 USDT                            |
| Base price            | $6.93                                    |
| Settlement mode       | `MerkleClaim`                            |
| Refund window         | 1 minute (operational, configurable)     |
| Commitment window     | 4/13 → 4/20 (7 days)                     |
| Sale window           | 4/20 21:00 → 23:00 EDT (2 hours)         |

### Layer pricing

| Layer         | Public name  | Discount | Effective price | Min commit | Per-wallet cap | Points/USD | Implicit points floor |
| ------------- | ------------ | -------- | --------------- | ---------- | -------------- | ---------- | --------------------- |
| L0 — Pioneer  | The Founders | 60.32 %  | $2.75           | $2,000     | $20,000        | 1.5        | 3,000 pts             |
| L1 — Builder  | The Core     | 33.91 %  | $4.58           | $500       | $10,000        | 1.0        | 500 pts               |
| L2 — Explorer | Early Movers | 7.65 %   | $6.40           | $100       | $5,000         | 0.5        | 50 pts                |
| L3 — Open     | Community    | 0 %      | $6.93           | —          | $2,000         | 0          | 0                     |

Points required to fully fill a layer's per-wallet cap = `cap × pointsPerUsd`. So a user who wants to max out the Pioneer layer ($20,000 cap) needs **30,000 points**, while the Open layer is freely available to anyone.

## Fee Routing

Per drop, the platform takes a configurable issuance fee (`issuanceFeeBps`, default 100 bps = 1 %), split between the protocol Treasury and the vePool:

| Default split                     | Bucket             | Purpose                                                |
| --------------------------------- | ------------------ | ------------------------------------------------------ |
| 70 % of fee                       | `PaimonTreasury`   | Protocol operations, audit, compliance reserves        |
| 30 % of fee                       | `vePool`           | Reserved for future vePAIMON / governance distribution |
| Project revenue (raise minus fee) | Issuer Treasury    | Settles to the issuer per drop config                  |
| Unsold RWA                        | Returned to issuer | Reduces dilution of secondary holders                  |

All routing is recorded in `DropTreasuryRecord` (`ILaunchpadDrop.sol:84-89`) and re-derivable from `LaunchpadDrop` events.

## Soulbound Badges

Successful commitment in a drop mints a non-transferable `PaimonBadge` (`PaimonBadge.sol:208-211`):

| Enum           | Badge name    | Earned by                                                      |
| -------------- | ------------- | -------------------------------------------------------------- |
| `SpacePioneer` | Space Pioneer | Participating in a SpaceX-themed drop (e.g. xSPCX)             |
| `AIBeliever`   | AI Believer   | Participating in an AI-themed drop (e.g. future Anthropic SPV) |
| `DualHolder`   | Dual Holder   | Holding badges across multiple categories                      |
| `TopReferrer`  | Top Referrer  | Driving qualified referrals into a drop                        |
| `QuestMaster`  | Quest Master  | Completing all pre-drop quests                                 |

Badges are mapped per `(user, BadgeType)` and each combination can only be minted once (`userBadges[user][type] == false → mintable`). They serve as on-chain proof of participation and unlock multipliers in the points system.

## Refund Window

After a layer settles in MerkleClaim mode, users who committed but did not receive their full requested allocation can call `requestRefund`. Once the operator calls `closeRefundWindow` for a layer, no further refunds can be claimed. The refund window duration is global (`refundWindowDuration`, default 3 days; can be reduced operationally — for the xSPCX V4 it was set to 1 minute since the entire sale was a 2-hour event).

## Operator Flow

End-to-end Drop lifecycle as executed by the issuance operator:

1. Configure refund window duration
2. Create drop — escrows the RWA token, runs on-chain `createDrop` with the layer config
3. Link metadata (project info / image / description) to the drop
4. Advance `Created → QuestActive`
5. Wait for the commitment window to close
6. Advance to `LayerSale`; for each layer, set the settlement merkle root (MerkleClaim mode) or run batch settlement (Batch mode)
7. Users `claimAllocation` with their merkle proof
8. Advance to `Settled`
9. `closeRefundWindow(layerIdx)` × 4 → `finalizeSettlement(dropId)`

All steps map to on-chain calls on `LaunchpadDrop` / `LaunchpadSettlement`; the operator dashboard is the off-chain UI that batches these calls and signs them with the KEEPER service account under multisig review.

## What This Replaces

A previous draft of this document described a "Hard Gate Review + Soft Scoring + Candidate Pool" governance flow for asset onboarding. **That mechanism is not implemented in any contract.** Asset curation today is performed off-chain by the Paimon team prior to drop creation; on-chain enforcement is limited to the drop / layer / settlement mechanics described above.

The on-chain points-and-USDT double-gate is what enforces "fair access" — it does not screen *which* assets get listed (that is a curatorial decision), but it does control *who* gets early access at favourable prices.