Skip to main content
Cette page est traduite automatiquement par IA. La version anglaise fait foi.Voir la version anglaise →
Cette entrée couvre une mise à jour à venir du programme LaunchLab. Elle a été vérifiée par rapport à la branche de version locale avant le déploiement. Confirmez le programme déployé avant de créer ou de mettre à jour une plateforme au-dessus des anciens plafonds.
Cette version relève le plafond des frais de plateforme à 500 bps. PlatformConfig.fee_rate est validé à deux endroits — une fois quand CreatePlatformConfig construit le compte, et une fois à chaque variante UpdatePlatformConfig qui écrit le champ — et les deux acceptent maintenant jusqu’à 50000. Dans le dénominateur de taux 1/1_000_000 du programme, cela représente 5 % du volume de trading sur chaque achat et vente avant la graduation. Avant cette version, les deux vérifications n’étaient pas d’accord : la création autorisait 100 bps et la mise à jour autorisait 250 bps. Elles maintiennent maintenant la même valeur, donc le taux auquel une plateforme peut être créée est exactement le taux auquel elle peut être mise à jour. Rien d’autre n’a changé. Aucun compte n’a grandi ou rétréci, aucune instruction n’a gagné ou perdu un compte, et aucun code d’erreur n’a bougé.

​
TL;DR pour les intégrateurs

  • Le plafond des frais de plateforme est 500 bps sur les deux chemins. CreatePlatformConfig et UpdatePlatformConfig acceptent tous les deux fee_rate jusqu’à 50000.
  • La création a changé à partir de 100 bps. PlatformParams::check() avait été <= 10000 depuis la première version du programme.
  • La mise à jour a changé à partir de 250 bps. update_platform_fee_rate était <= 25000, lui-même relevé de 100 bps le 2026-01-27.
  • L’inadéquation création/mise à jour a disparu. Une configuration créée au-dessus de 250 bps ne pouvait pas survivre à un appel UpdatePlatformConfig, car AllInfo revalide fee_rate tout en réécrivant tous les autres champs. Les deux vérifications s’accordent maintenant, donc ce chemin d’édition fonctionne à n’importe quel taux autorisé.
  • creator_fee_rate est inchangé à MAX_CREATOR_FEE_RATE = 5000 (50 bps) sur les deux chemins.
  • GlobalConfig.max_share_fee_rate est inchangé à 10_000 (100 bps), et n’a jamais limité les frais de plateforme. Il limite l’argument share_fee_rate de référence par transaction. Les versions antérieures de cette documentation disaient le contraire ; cette version corrige cela.
  • Aucune tarification existante n’a changé. Ces constantes contrôlent les écritures vers fee_rate, pas les lectures. Chaque PlatformConfig déjà en chaîne conserve son taux actuel, et chaque lancement lié à un conserve ses frais actuels.
  • Aucune actualisation IDL n’est requise. Aucune disposition, compte, argument ou code d’erreur n’a changé.

​
Ce qui a changé

Les taux dans LaunchLab sont exprimés en 1/1_000_000 (RATE_DENOMINATOR_VALUE), donc :

​
Où les deux vérifications se trouvent

Le plafond est appliqué par deux appels require! distincts dans deux fichiers. Ils maintiennent maintenant la même valeur, mais ils lèvent toujours des erreurs différentes, donc la gestion des erreurs doit reconnaître les deux : AllInfo est la variante de mise à jour en masse : elle réécrit les portefeuilles, les chaînes de marque, l’échelle d’acquisition progressive, la division NFT, l’autorité de frais de transfert, le taux de frais du créateur et fee_rate en un seul appel, exécutant la même vérification sur fee_rate que la variante à champ unique. Avec les anciennes constantes, cela rendait AllInfo inutilisable pour une plateforme créée dans la bande 250–500 bps, même pour une édition qui ne touchait qu’une URL d’image. L’alignement des deux constantes supprime ce piège.

​
Ce qui n’a pas changé

  • Comptabilité et distribution des frais. platform_fee = amount_in × platform_config.fee_rate / 1_000_000 est la même formule, s’accumulant dans le même coffre par plateforme, balayé par les mêmes instructions ClaimPlatformFee et ClaimPlatformFeeFromVault.
  • Plateformes et lancements existants. Les constantes contrôlent les écritures, pas les lectures. Aucun taux stocké n’a changé, donc aucun lancement actif n’a été retarifié.
  • creator_fee_rate. Toujours plafonné à MAX_CREATOR_FEE_RATE = 5000 (50 bps) sur les deux chemins.
  • GlobalConfig.max_share_fee_rate. Toujours 10_000, limitant toujours uniquement l’argument share_fee_rate sur les quatre instructions de swap.
  • Codes d’erreur. 6000–6023 sont inchangés ; cette version n’en ajoute aucun.
  • Dispositions de compte et IDL. Inchangés.

​
Correction de documentation

Deux pages attribuaient le plafond des frais de plateforme à GlobalConfig.max_share_fee_rate. Le programme n’a jamais fait cela — il compare max_share_fee_rate par rapport à l’argument d’instruction share_fee_rate, et valide PlatformConfig.fee_rate uniquement dans les deux fonctions énumérées ci-dessus. Cette version corrige ces phrases. Le plafond des frais de référence lui-même est inchangé à 100 bps, donc si vous avez lu l’ancienne formulation comme « les frais de plateforme sont plafonnés à 100 bps », le nombre était correct pour le chemin de création jusqu’à cette version même si la raison ne l’était pas.

​
Pages mises à jour

  • products/launchlab/platform-config — nouvelle section « Plafonds de taux » couvrant les deux taux, les deux points d’application et l’historique des taux.
  • products/launchlab/global-config — max_share_fee_rate corrigé pour décrire les frais de partage de référence qu’il limite réellement.