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 de 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 à la clôture 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 spot sans accéder 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.
  • token_program_flag — un champ de bits, pas un booléen. Bit0 est le mint de base et bit1 est le mint de cotation, chacun 0 pour SPL Token et 1 pour Token-2022, donc l’octet prend quatre valeurs : 0 (les deux hérités), 1 (Token-2022 base), 2 (Token-2022 cotation), 3 (les deux Token-2022). Lisez un mint avec (token_program_flag >> bit) & 1. Comparer l’octet entier à 0 pour classer le mint de base résout 2 au mauvais programme. Bit1 était constant 0 jusqu’à ce que les mints de cotation Token-2022 soient supportés.
  • 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 le base_mint de chaque 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 transfer_fee_config_authority sur la TransferFeeConfig d’un mint de base Token-2022, pour toute la phase pré-graduation — et sa withdraw_withheld_authority aussi, mais uniquement lorsque la plateforme n’a pas défini PlatformConfig.transfer_fee_extension_auth.
La mint_authority est révoquée immédiatement après un appel MigrateToCpswap ou un appel hérité MigrateToAmm, donc l’approvisionnement est définitivement fixé. Deux PDAs supplémentaires contrôlent les coffres de frais :
Ceux-ci signent le transfert hors du coffre de frais correspondant 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).
Parce que l’approvisionnement complet est pré-frappé, base_mint.supply est constant pour 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 mints de base SPL Token. L’instruction dédiée InitializeWithToken2022 permet au mint de base d’être un mint Token-2022 (avec TransferFeeConfig optionnel). Les trois chemins d’initialisation nécessitent une graduation CPMM. Lorsque InitializeWithToken2022 attache une TransferFeeConfig, le mint est créé avec transfer_fee_config_authority = authority et withdraw_withheld_authority = PlatformConfig.transfer_fee_extension_auth, revenant à authority lorsque la plateforme n’a pas défini ce champ. Les deux autorités sont réaffectées à la clé de plateforme à la graduation, le côté retrait uniquement si le PDA le détient toujours. Consultez platform-config. Le mint de cotation est indépendant du mint de base et peut lui-même être un mint Token-2022 — InitializeV2 et InitializeWithToken2022 acceptent l’un ou l’autre programme dans leur slot de programme de cotation. Le Initialize déprécié ne le fait pas : son compte de programme de cotation est toujours typé pour SPL Token, donc une configuration dont le mint de cotation est Token-2022 ne peut être lancée que par les deux autres. Le mint de cotation n’est jamais créé par LaunchLab ; c’est ce que GlobalConfig.quote_mint nomme. Consultez global-config et reference/token-2022-support.

Coffres

base_vault et quote_vault sont tous deux des comptes de jetons possédés par le PDA LaunchLab authority, chacun créé sur le programme qui possède son propre mint — donc un lancement peut avoir un coffre de base hérité et un coffre de cotation Token-2022, ou toute autre combinaison. token_program_flag enregistre lequel est lequel. 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 balaye via ClaimCreatorFee.
  • Coffre de frais de plateforme — PDA aux graines [platform_config, quote_mint]. Chaque lancement acheminé par 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 balaye via ClaimPlatformFeeFromVault. Il y a aussi une variante de balayage par lancement (ClaimPlatformFee) qui tire directement du quote_vault du lancement sans passer par le coffre agrégé.
Les deux sont créés paresseusement au premier swap qui accumule un frais, sur le programme qui possède le mint de cotation. Un créateur ou une plateforme qui exécute des lancements contre un mint de cotation hérité et un mint Token-2022 se retrouve avec un coffre par mint, comme c’était déjà le cas pour deux mints hérités différents. Le modèle de coffre agrégé est ce qui permet à un créateur ou une plateforme à haut volume d’amortir le coût de location 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 :

PlatformCurveRule

Un compte par paire (PlatformConfig, GlobalConfig), contenant les formes de lancement que cette plateforme permet sur cette configuration. Les graines PDA sont [b"platform_curve_rule", platform_config, global_config].
Le compte est créé sans groupe et redimensionné à chaque changement de groupe, donc sa longueur est 150 + Σ(14 + 18 × constraints) et les décodeurs ne doivent pas supposer une taille fixe. Les groupes sont ORés : un lancement est autorisé dès que les contraintes d’un groupe tiennent toutes. Zéro groupe signifie aucune restriction. Lisez-le uniquement lorsque le PlatformConfig.restrict_curve_param propriétaire est 1 — à 0, le programme ignore le compte, et une règle obsolète peut bien être assise là. Les identifiants de champ, les opérateurs et les playbooks se trouvent dans products/launchlab/curve-rules.

Transitions de comptes 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.