Skip to main content
Cette page est traduite automatiquement par IA. La version anglaise fait foi.Voir la version anglaise →
Cette page documente le graphe des comptes par lancement : le PoolState (le compte d’état racine pour un lancement), ses deux coffres, l’autorité PDA, et les références post-graduation qu’il acquiert lors du règlement du lancement.Pour la configuration au niveau du protocole qui encadre chaque lancement, consultez products/launchlab/global-config. Pour la surcouche par plateforme, consultez products/launchlab/platform-config. Pour les comptes de vesting (VestingSchedule sur PoolState, VestingRecord par bénéficiaire), consultez products/launchlab/vesting.

Inventaire des comptes

La méthode raydium.launchpad.getLaunchById du SDK retourne PoolState plus un drapeau indiquant si le lancement a été diplômé ; si c’est le cas, l’ID du pool post-migration est inclus.

PoolState

L’état racine par lancement. Les noms de champs ci-dessous correspondent à la structure Rust on-chain (states/pool.rs) ; certaines valeurs sont simplifiées pour la lisibilité — consultez la source pour la disposition exacte de la mémoire.
Valeurs de PoolStatus (depuis l’IDL Anchor) :
Champs visibles pour les intégrateurs :
  • status — trois valeurs, monotones (Funding → Migrate → Migrated). Les lectures sont toujours sûres ; les écritures sont contrôlées.
  • real_base, real_quote — état actuel de la courbe. Combinés avec virtual_base / virtual_quote, ils suffisent pour calculer le prix au comptant sans toucher aux coffres. Consultez bonding-curve.
  • total_base_sell vs real_base — ratio « progression vers la graduation » pour les interfaces utilisateur.
  • migrate_type — l’initialisation nouvelle nécessite 1 (CPSWAP). Un 0 stocké reste significatif uniquement pour un lancement existant créé avant l’application obligatoire de CPMM.
  • amm_creator_fee_on — choisit creator_fee_on = OnlyQuoteToken (0) ou BothToken (1) sur le pool CPMM post-graduation. Il ne choisit pas la cible de migration. Consultez creator-fees.
  • quote_protocol_fee / platform_fee / migrate_fee — trois compteurs de frais indépendants. Chacun a sa propre instruction de réclamation ; consultez instructions.
  • vesting_schedule — présent sur chaque PoolState mais inactif lorsque total_locked_amount == 0. Consultez vesting pour le cycle de vie complet.

L’autorité PDA

LaunchLab utilise une seule autorité PDA sur tous les lancements, dérivée sans graine par lancement :
Ce PDA unique est :
  • L’autorité sur chaque base_vault et quote_vault du lancement.
  • La mint_authority sur chaque base_mint du lancement (pré-graduation).
  • Le signataire sur le CPI de graduation CPMM, et sur la graduation AMM v4 hérité pour l’état existant.
  • Le signataire sur les transferts ClaimVestedToken hors du coffre de base.
La mint_authority est révoquée immédiatement après un appel MigrateToCpswap ou un appel MigrateToAmm hérité, de sorte que l’approvisionnement est définitivement fixé. Deux PDAs supplémentaires contrôlent les coffres de frais :
Ceux-ci signent le transfert hors des coffres de frais correspondants lors de ClaimCreatorFee et ClaimPlatformFeeFromVault.

Mint de base

Créé en ligne par Initialize avec :
  • mint_authority = authority (révoquée à la graduation).
  • freeze_authority = None.
  • supply = supply, entièrement frappé dans base_vault.
  • decimals choisi par le créateur à Initialize (généralement 6).
Comme l’approvisionnement complet est pré-frappé, base_mint.supply est constant pendant la durée de vie du lancement. Les achats de courbe déplacent les jetons de base_vault vers l’acheteur, mais n’appellent pas mint_to. Initialize / InitializeV2 créent des lancements SPL Token. L’instruction dédiée InitializeWithToken2022 permet au mint de base d’être un mint Token-2022 (avec TransferFeeConfig optionnel) ; le mint de cotation reste SPL Token. Les trois chemins d’initialisation nécessitent une graduation CPMM.

Coffres

base_vault et quote_vault sont tous deux des comptes SPL Token standard possédés par le PDA LaunchLab authority. Les adresses sont stockées sur PoolState et peuvent également être dérivées :
(Vérifiez les préfixes de graine exacts à partir de la structure des comptes Initialize de la source avant de vous fier à une dérivation en production.)

Coffres de frais

Deux PDAs agrègent les frais sur les lancements :
  • Coffre de frais de créateur — PDA aux graines [creator, quote_mint]. Chaque lancement qui gagne les mêmes frais de créateur sur le même mint de cotation verse dans le même coffre. Le créateur le vide via ClaimCreatorFee.
  • Coffre de frais de plateforme — PDA aux graines [platform_config, quote_mint]. Chaque lancement acheminé via la même plateforme qui utilise le même mint de cotation verse dans le même coffre. Le platform_fee_wallet de la plateforme le vide via ClaimPlatformFeeFromVault. Il existe également une variante de balayage par lancement (ClaimPlatformFee) qui tire directement du quote_vault du lancement sans passer par le coffre agrégé.
Le modèle de coffre agrégé permet à un créateur ou une plateforme à haut volume d’amortir le coût du loyer de l’accumulation de frais sur de nombreux lancements.

Quote vault ↔ real_quote

quote_vault.balance et PoolState.real_quote doivent rester synchronisés. Ils peuvent dériver d’au maximum la somme des trois compteurs de frais en attente (quote_protocol_fee, platform_fee, migrate_fee), qui se trouvent dans le coffre mais appartiennent aux compteurs de frais et non à la réserve de courbe. Les mathématiques de courbe utilisent toujours real_quote, jamais le solde brut du coffre. Invariant pré-graduation :

Transitions de compte du cycle de vie

Où aller ensuite

Sources :
  • raydium-launch/programs/launchpad/src/states/pool.rsPoolState, PoolStatus, VestingSchedule, AmmCreatorFeeOn.
  • raydium-launch/programs/launchpad/src/lib.rs — constantes de graine PDA (AUTH_SEED, CREATOR_FEE_VAULT_AUTH_SEED, PLATFORM_FEE_VAULT_AUTH_SEED).
  • Module launchpad du SDK Raydium v2.