Skip to main content
Cette page est traduite automatiquement par IA. La version anglaise fait foi.Voir la version anglaise →
PlatformConfig est la surcouche au niveau de la plateforme qui s’ajoute à GlobalConfig. Tandis que GlobalConfig définit les règles au niveau du protocole (« les frais de trading sont de 1 %, l’offre doit être d’au moins 10M, seul ce portefeuille peut diplômer »), PlatformConfig est ce que chaque plateforme de lancement — pump.fun, l’interface propre de Raydium, les launchpads tiers — utilise pour ajouter ses frais, réclamer sa part du LP post-graduation, restreindre les paramètres de lancement que leurs lancements peuvent choisir, et afficher leur image de marque (nom, site web, image) on-chain.

Qu’est-ce que c’est

Un compte PlatformConfig gère cinq domaines transversaux pour une plateforme :
  1. Image de marque — nom, site web, lien d’image, tous stockés en ligne pour que tout explorateur ou agrégateur puisse afficher la plateforme qui a lancé un token.
  2. Frais de plateforme — un frais de trading supplémentaire (fee_rate) en plus du trade_fee_rate du protocole. S’accumule dans le platform_fee_wallet de la plateforme. Plafonné à 500 bps (50000) sur les chemins de création et de mise à jour, relevé de 100 bps (10000) le 2026-08-26 — voir Plafonds de taux.
  3. Répartition de migration LP — trois entiers stockés (platform_scale, creator_scale, burn_scale) qui totalisent 1_000_000. Avant la mise à niveau du 2026-08-17, l’échelle du créateur produisait une clé de frais créateur séparée. Les migrations exécutées après la mise à niveau combinent les deux premières en une seule part LP verrouillée appartenant à la plateforme ; le reste est brûlé.
  4. Règles de paramètres de lancement — une restriction optionnelle (restrict_curve_param) qui exige qu’un lancement satisfasse le compte PlatformCurveRule du GlobalConfig qu’il a sélectionné. Les règles supportent les bandes de valeurs, les niveaux alternatifs et le gating par type de token ; elles vivent dans leurs propres comptes, pas sur PlatformConfig.
  5. Liste blanche de configuration globale — une restriction optionnelle qui exige qu’une plateforme crée un PlatformAllowConfig pour le GlobalConfig sélectionné.
Dérivation PDA :
(Voir create_platform_config dans le code source pour la liste des seeds canonique.)

Disposition

Le compte fait 944 octets fixes. Il contenait un Vec<PlatformCurveParam> de fin jusqu’à la version du 2026-08-31 qui a déplacé les paramètres de lancement dans les comptes PlatformCurveRule ; restrict_curve_param, curve_rule_manager et les 4 octets du préfixe de longueur du vec proviennent tous du padding, donc le nombre d’octets et tous les décalages de champs antérieurs sont inchangés. Voir l’entrée du changelog pour ce que les décodeurs doivent changer. platform_scale + creator_scale + burn_scale doit égaler 1_000_000. Avant la mise à niveau du 2026-08-17, creator_scale était verrouillé séparément et sa clé de frais allait au créateur du token. Pour les migrations exécutées après la mise à niveau, elle est ajoutée à platform_scale et ses droits LP verrouillés vont à la plateforme à la place. Exemples de résultats selon la logique mise à jour :
  • (0, 100_000, 900_000) — 90 % du LP brûlé, 10 % verrouillé pour la plateforme.
  • (50_000, 100_000, 850_000) — 85 % brûlé, 15 % verrouillé pour la plateforme.
  • (0, 0, 1_000_000) — brûlage complet, pas de frappe de NFT. Lancements stricts « sans initiés ».

Champs d’image de marque

name, web et img sont des tableaux d’octets en ligne complétés avec des zéros jusqu’à leurs constantes de taille. Pour les lire en tant que chaînes, découpez jusqu’au premier \0 :
Les constantes sont délibérément généreuses (name: 64, web: 256, img: 256) pour que les plateformes puissent inclure suffisamment de métadonnées pour les explorateurs et agrégateurs sans accéder au stockage hors-chaîne. Tout ce qui dépasse ces tailles revient à CreatePlatformConfig avec InvalidInput.

Mécanique des frais

Un swap sur une courbe liée à un PlatformConfig facture trois frais en couches :
  • trade_fee s’accumule dans le protocol_fee_owner du protocole (réclamé via CollectFee).
  • platform_fee s’accumule dans un coffre par plateforme (réclamé via ClaimPlatformFee ou ClaimPlatformFeeFromVault ; voir instructions).
  • creator_fee s’accumule dans un coffre par créateur clé par la clé publique du créateur + mint de cotation (réclamé via ClaimCreatorFee).

Plafonds de taux

Les deux taux sont libellés en 1/1_000_000, donc 5000 est 50 bps et 50000 est 500 bps. Les deux points d’application pour fee_rate sont des appels require! séparés dans des fichiers différents, ils portent donc des codes d’erreur différents, mais ils appliquent le même plafond. Une plateforme créée à n’importe quel taux autorisé peut être modifiée ultérieurement, y compris via la variante AllInfo en masse qui réécrit chaque champ à la fois. Les deux plafonds fee_rate étaient à l’origine 100 bps (10000). Le plafond de mise à jour est passé à 25000 (250 bps) le 2026-01-27 ; le 2026-08-26, les deux sont passés à 50000 (500 bps) — voir l’entrée du changelog. GlobalConfig.max_share_fee_rate ne limite pas l’un ou l’autre taux. Il limite l’argument share_fee_rate par transaction que les quatre instructions de swap prennent — les frais de parrainage — et rien d’autre. Voir global-config.

Autorités de frais de transfert Token-2022

transfer_fee_extension_auth nomme la clé de plateforme qui finit par détenir les autorités TransferFeeConfig du mint de base lorsqu’un lancement est créé via InitializeWithToken2022 avec un frais de transfert attaché. L’extension porte deux autorités, et elles sont remises à différents points du cycle de vie du lancement : Avant le 2026-08-27, le mint était créé avec la PDA authority sur les deux autorités, et les deux se déplaçaient vers la plateforme à la graduation. Le programme n’expose aucune instruction de retrait des frais retenus ou de récolte, donc les frais retenus pendant la phase de courbe de liaison étaient inaccessibles jusqu’à la graduation du lancement. Écrire le côté retrait à la création du mint les rend réclamables dès le premier trade — voir l’entrée du changelog. Deux conséquences à prévoir :
  • Définissez le champ avant de lancer, pas après. Un lancement créé tandis que transfer_fee_extension_auth est Pubkey::default() met la PDA authority sur le côté retrait. Définir le champ plus tard fonctionne toujours — la graduation trouve la PDA en place et remet l’autorité — mais rien ne peut retirer le solde retenu entre-temps.
  • Faire tourner le champ en cours de lancement divise les deux autorités. Changez transfer_fee_extension_auth entre la création et la graduation d’un lancement et l’autorité de retrait des frais retenus du mint reste avec la clé configurée à la création (la PDA ne la détient plus, donc la migration saute ce transfert) tandis que l’autorité de configuration des frais va à la nouvelle clé. Faites tourner entre les lancements, ou prévoyez de réconcilier les deux clés vous-même via Token-2022 directement.
Une plateforme qui laisse le champ à Pubkey::default() pour toute la vie d’un lancement garde les deux autorités sur la PDA authority définitivement : le taux de frais ne peut jamais être changé et le solde retenu ne peut jamais être retiré. N’attachez un frais de transfert à un lancement que si la plateforme a l’intention de détenir ces clés.

Répartition de migration NFT (CPMM uniquement)

Lorsqu’un lancement diplôme vers CPMM, l’instruction de migration divise les tokens LP frappés par CPMM::InitializeWithPermission de deux façons :
Si lp_to_platform est non-zéro, le programme LP-Lock l’enveloppe dans un NFT Fee Key appartenant à platform_nft_wallet. Cela remplace le comportement pré-mise à niveau qui créait des Fee Keys de plateforme et de créateur séparées. Les Fee Keys créées par les migrations complétées avant la mise à niveau restent inchangées. Ce droit de frais LP est séparé des frais de créateur CPMM contrôlés par platform_cp_creator. La tranche de brûlage est brûlée directement, donc aucun compte ne peut la retirer ou réclamer les frais LP représentés par cette part. Les lancements existants avec migrate_type = 0 stocké peuvent toujours utiliser le chemin AMM v4 hérité. La nouvelle initialisation rejette ce type de migration.

Règles de paramètres de lancement

restrict_curve_param est l’interrupteur. À 0, le programme ne lit pas du tout les règles. À 1, chaque lancement acheminé via cette plateforme doit satisfaire le compte PlatformCurveRule du GlobalConfig qu’il a sélectionné, et le constructeur de lancement doit ajouter ce compte à remaining_accounts.
Une règle est un menu de formes de lancement autorisées : les contraintes dans un groupe de vérification sont ET-ées, les groupes sont OU-és, et chaque contrainte est un triple (field, op, value) supportant Eq, Gte, Lte et Neq. Cela couvre les bandes de valeurs, les niveaux alternatifs, les plafonds de valorisation de graduation, les planchers de migration, le gating par type de token et les groupes limités dans le temps — le modèle complet, la table des champs et neuf livrets de travail sont dans products/launchlab/curve-rules. Deux choses appartiennent ici plutôt qu’à cette page :
  • curve_rule_manager est une délégation, pas un transfert. Définissez-le via UpdatePlatformConfig::CurveRuleManager et ce portefeuille peut créer, mettre à jour, supprimer et fermer les comptes de règles de cette plateforme sans la clé d’admin. L’admin de la plateforme garde le même pouvoir en parallèle, donc faire tourner ou effacer le champ récupère le contrôle. Pubkey::default() signifie que seul l’admin peut gérer les règles. Il ne peut pas basculer restrict_curve_param, qui reste un appel réservé à l’admin.
  • Les règles sont appliquées en plus de GlobalConfig, jamais à la place. La vérification des règles s’exécute avant les limites propres de la config et ne peut que les restreindre.
Cela remplace l’ancienne liste blanche curve_params: Vec<PlatformCurveParam>, qui ne pouvait tester que l’égalité exacte, contenait au maximum 10 entrées sur toutes les configs et agrandissait le compte PlatformConfig lui-même. Les plateformes qui l’utilisaient ont été migrées par le protocole en un seul passage ; le champ hérité, ses deux instructions et MAX_CURVE_PARAMS sont partis.

PlatformAllowConfig — restreindre une plateforme

Chaque plateforme décide si elle restreint les comptes GlobalConfig que ses lancements peuvent utiliser. Définissez restrict_global_config avec UpdatePlatformConfig::RestrictGlobalConfig(0 | 1).
Seeds PDA : [b"platform_allow_config", platform_config, global_config]. L’admin de la plateforme crée ou ferme un compte par paire autorisée via CreatePlatformAllowConfig et ClosePlatformAllowConfig. Lorsque la restriction est 1, l’initialisation recherche remaining_accounts pour la PDA attendue et rejette un compte manquant avec NotEnoughRemainingAccounts. Lorsque la restriction est 0, aucun compte d’autorisation n’est requis. Le compte PlatformGlobalAccess géré par l’admin du protocole et ses instructions de création/fermeture sont retirés. Les tailles existantes de PlatformConfig et GlobalConfig ne changent pas, mais les décodeurs doivent remplacer l’ancien drapeau global par le nouveau drapeau de plateforme. Les anciennes PDAs d’accès ne sont pas consommées par la nouvelle vérification.

Chemin de lecture

Pour une interface montrant « d’où ce token a-t-il été lancé », PoolState.platform_config pointe directement sur le PlatformConfig d’origine — récupérez-le une fois et mettez en cache l’image de marque.

Chemin de mise à jour

Les rotations de portefeuille (platform_fee_wallet, platform_nft_wallet, platform_vesting_wallet, platform_cp_creator, transfer_fee_extension_auth, cpswap_config) passent toutes par UpdatePlatformConfig. Lisez la table de dispatch update_platform_config du code source pour les codes param exacts.

Pièges courants

  • restrict_curve_param activé avant la mise à jour du constructeur. Tandis qu’il est 1, la PDA de règle doit être dans remaining_accounts à chaque lancement, même pour une config sans compte de règle — un compte absent est NotEnoughRemainingAccounts, pas un passage. Livrez d’abord le changement du constructeur, puis basculez le drapeau.
  • restrict_curve_param activé avec une règle vide. Une règle contenant zéro groupe, ou un groupe contenant zéro contrainte, autorise tout. Activer le drapeau n’est pas en soi une restriction ; écrivez d’abord les groupes, vérifiez-les avec la vérification du SDK et répétez toute la séquence sur devnet.
  • Arrondi de répartition NFT. Les trois échelles doivent totaliser exactement 1_000_000. Les erreurs d’une unité à CreatePlatformConfig reviennent ; une erreur d’une unité à l’exécution frapperait ou brûlerait une unité LP supplémentaire, ce que la vérification d’égalité stricte est là pour prévenir.
  • Double allocation de vesting de plateforme. Si platform_vesting_scale > 0, la plateforme doit appeler CreatePlatformVestingAccount une fois après la fin de la collecte de fonds du lancement ; si elle oublie, cette part reste non allouée et dormante pour toujours (le budget total_locked_amount du lancement est consommé mais la plateforme ne réclame jamais).
  • Ambiguïté de platform_cp_creator. Lorsqu’il est défini à Pubkey::default(), le créateur du lancement est enregistré comme pool_creator du pool CPMM post-graduation ; lorsqu’il est défini à une clé réelle, cette clé est enregistrée à la place. Cela détermine le bénéficiaire des frais de créateur CPMM post-graduation et qui peut signer le chemin CPMM::CollectCreatorFee d’origine. Le chemin de collection sans permission paie toujours les ATAs canoniques de cette clé enregistrée. Décidez au moment de la création de la config de plateforme quel modèle vous voulez.
  • transfer_fee_extension_auth défini tard ou tourné. Le champ est lu deux fois par lancement Token-2022 — une fois à la création du mint pour withdraw_withheld_authority, une fois à la graduation pour transfer_fee_config_authority — donc une valeur qui change entre ces deux moments laisse les deux autorités sur des clés différentes. Voir Autorités de frais de transfert Token-2022.
  • Restriction sans compte d’autorisation. Activer restrict_global_config avant de créer le PlatformAllowConfig requis bloque les nouveaux lancements qui sélectionnent cette config.

Pointeurs

Sources :
  • raydium-launch/programs/launchpad/src/states/platform_config.rsPlatformConfig, PlatformParams, MigrateNftInfo, is_curve_rule_manager, is_platform_admin.
  • raydium-launch/programs/launchpad/src/states/platform_curve_rule.rsPlatformCurveRule, CurveRuleGroup, ParamConstraint.
  • raydium-launch/programs/launchpad/src/states/platform_allow_config.rsPlatformAllowConfig.
  • raydium-launch/programs/launchpad/src/instructions/platform/update_platform_config.rs — dispatch PlatformConfigParam et les setters par champ qui appliquent les plafonds de taux au moment de la mise à jour.
  • raydium-launch/programs/launchpad/src/lib.rs — points d’entrée de config de plateforme et d’allow-config.
  • raydium-launch/programs/launchpad/src/instructions/initialize_with_token_2022.rs — où transfer_fee_extension_auth est écrit dans le TransferFeeConfig du nouveau mint.
  • raydium-launch/programs/launchpad/src/instructions/admin/migrate_to_cpswap.rs — le transfert d’autorité au moment de la graduation et sa garde get_withdraw_withheld_authority.