Skip to main content
Cette page est traduite automatiquement par IA. La version anglaise fait foi.Voir la version anglaise →
Raydium n’accepte pas les mints Token-2022 arbitraires. CPMM et CLMM fonctionnent tous deux en mode liste d’autorisation stricte : seul un petit ensemble d’extensions passe par défaut ; tout le reste est rejeté à la création du pool. Chaque programme admet un mint individuel par un seul mécanisme — un PDA de registre par mint géré par l’admin. Les deux programmes ont également porté des contournements codés en dur à différents moments ; tous ont maintenant été supprimés. Cette page est la référence unique pour ce qui est appliqué et où, avec des citations dans la source du programme.

Support au niveau du programme

Les vérifications de la liste d’autorisation se trouvent dans : Il n’y a pas de vérification de mint au moment du swap sur CPMM ou CLMM — la barrière se déclenche uniquement à la création du pool. Une fois qu’un pool existe, les swaps font simplement confiance au fait que les mints n’ont pas changé, ce qui est correct pour les parties immuables de l’état du mint Token-2022.

Gel des NFT de position CLMM pour les émetteurs restreints

Les comptes NFT de position restent dégelés par défaut. CLMM en gèle un uniquement quand la position utilise un chemin ouvert V2 et que la freeze_authority actuelle d’au moins un mint de vault apparaît dans la liste codée en dur frozen_position_nft_authorities::IDS. Cette liste est ce qui a remplacé la détection antérieure de token Superstate de CLMM, et elle porte la même autorité d’émetteur que l’ancienne heuristique correspondait. Définir le PDA du pool comme autorité de gel du mint NFT de position n’est pas en soi un gel. C’est une règle de garde de position, pas une liste d’autorisation de création de pool :
  • Le pool peut déjà exister et rester échangeable.
  • Le mint NFT de position utilise le PDA du pool CLMM comme sa propre autorité de gel ; l’émetteur sous-jacent ne contrôle pas le NFT de position.
  • OpenPositionV2 couvre les NFT de position SPL classiques sur les actifs de pool Token-2022. OpenPositionWithToken22Nft couvre les NFT de position Token-2022.
  • OpenPosition V1 n’inspecte pas les mints de vault et ne peut pas servir les actifs Token-2022 restreints ciblés par la liste expédiée.
  • Les positions existantes restent inchangées.
Les positions gelées restent gérables par leur propriétaire mais ne peuvent pas être transférées. ClosePosition dégèle et brûle atomiquement quand le client passe le pool comme premier compte restant. Voir products/clmm/ticks-and-positions.

Mints quote LaunchLab

Les deux mints de LaunchLab sont contrôlés très différemment, et l’asymétrie est facile à manquer.
  • Mint de base — LaunchLab le crée. Un mint de base Token-2022 n’est accessible que via initialize_with_token_2022, et le programme n’attachera que MetadataPointer et (optionnellement) TransferFeeConfig. Tout le reste retourne NoSupportExtension. Un mint Token-2022 préexistant ne peut pas du tout être fourni comme base. Quand TransferFeeConfig est attaché, la transfer_fee_config_authority du mint est le PDA de l’autorité de lancement jusqu’à la graduation, tandis que sa withdraw_withheld_authority est la transfer_fee_extension_auth configurée de la plateforme à partir de la création du mint — le programme launchpad lui-même n’a pas d’instruction de retrait des montants retenus. Voir products/launchlab/platform-config.
  • Mint quote — LaunchLab ne le crée pas et ne le contrôle pas. CreateConfig accepte le compte mint tel quel, donc il n’y a pas d’équivalent is_supported_mint du côté quote. Le seul contrôle est les mints qu’un admin choisit de lier à une GlobalConfig.
Cela rend la liaison d’un mint quote Token-2022 une action de haute confiance, pour la même raison que l’enregistrement d’un mint ci-dessous : un mint quote TransferHook exécuterait son hook à chaque achat, vente et réclamation de frais dans chaque pool coté en lui, et un mint quote PermanentDelegate laisserait le délégué balayer les vaults quote de ces pools. Aucun n’est bloqué par le programme. Ce que LaunchLab gère correctement une fois qu’un mint quote est lié :
  • Le vault quote, les deux vaults de frais et le compte token du destinataire des frais de partage sont créés sur le programme du mint quote lui-même.
  • TransferFeeConfig du côté quote est intégré dans les quatre instructions de trade, et la limite de slippage est vérifiée par rapport au montant net du payeur plutôt que au mouvement brut du vault. Voir products/launchlab/instructions.
  • PoolState.token_program_flag enregistre les programmes des deux mints — bit0 pour le mint de base, bit1 pour le mint quote. Décodez-le par bit ; l’octet n’est pas un booléen. Voir products/launchlab/accounts.
L’instruction Initialize dépréciée prend toujours un programme quote hérité uniquement, donc une config avec un mint quote Token-2022 n’est accessible que via InitializeV2 et InitializeWithToken2022.

Liste d’autorisation des extensions CPMM et CLMM

Après les deux court-circuits couverts ci-dessous, le programme itère les extensions du mint et rejette le mint s’il porte une extension autre que ces cinq : Tout ce qui ne figure pas dans cette liste — TransferHook, NonTransferable, ConfidentialTransferMint, PermanentDelegate, MintCloseAuthority, DefaultAccountState, GroupPointer, GroupMemberPointer, MemberPointer, Pausable, etc. — fait que is_supported_mint retourne false et la création du pool revient en arrière. Les lignes pertinentes (CPMM, forme identique dans CLMM) :
cp-swap/src/utils/token.rs

Chemins de contournement

Un mint Token-2022 qui ne correspond pas à la liste d’autorisation peut toujours être admis, via un seul mécanisme dans chaque programme. Les deux programmes portaient également des contournements codés en dur dans le passé ; aucun d’eux ne survit. is_supported_mint est maintenant octet pour octet la même fonction dans les deux programmes : les mints Token SPL hérités passent, un mint avec un PDA de registre passe, et tout le reste doit porter uniquement des extensions autorisées.

Le seul contournement : le registre par mint

Les deux programmes consultent un PDA SupportMintAssociated à la graine [b"support_mint", mint]. Si ce PDA existe pour le mint, le mint est admis indépendamment de son ensemble d’extensions. Chaque programme a sa propre copie du PDA (ils dérivent sous des ID de programme différents), sa propre paire CreateSupportMintAssociated / CloseSupportMintAssociated, et sa propre autorité dédiée aux côtés de l’admin partagé : Les quatre clés (CPMM et CLMM × mainnet et devnet) sont listées sous Autorités du registre des support-mints. Dans les deux programmes, l’instruction accepte soit crate::admin::ID soit l’autorité dédiée de ce programme, et exige que le mint soit détenu par Token-2022. Effet : un mint Token-2022 spécifique peut être accepté pour la création de pool sans mise à niveau du programme — c’est pourquoi les listes codées en dur pouvaient disparaître. Chaque programme consulte le registre depuis chaque chemin de création de pool qu’il a : CPMM depuis Initialize et InitializeWithPermission (ce dernier est ce que les graduations LaunchLab utilisent, donc un mint enregistré se gradue ainsi que crée), CLMM depuis CreatePool, CreateCustomizablePool et CreatePermissionedPool.

Les contournements supprimés

Les deux mécanismes codés en dur ont disparu des programmes déployés. Ils sont documentés ici uniquement parce que les intégrations écrites contre le comportement antérieur peuvent toujours les supposer.

MINT_WHITELIST statique — supprimé

Un tableau constant d’adresses de mint en base58 utilisé pour court-circuiter is_supported_mint avant l’itération des extensions. Celui de CLMM contenait six adresses et a été supprimé le 2026-07-24 ; celui de CPMM contenait les quatre premiers du même ensemble et a été supprimé dans la mise à jour 2026-09-09. Un pool qui existe déjà pour l’un de ces mints continue de trader — la vérification du mint s’exécute uniquement à la création du pool. Créer un nouveau pool pour l’un d’eux nécessite maintenant un PDA de registre pour lui à la place.

Détection de forme d’autorité Superstate — supprimée

CLMM a brièvement identifié les actifs tokenisés de Superstate par leur forme d’autorité plutôt que par adresse : un mint Token-2022 dont la freeze_authority et le délégué permanent égalaient tous deux superstate_allowlist::ID, avec DefaultAccountState défini sur Frozen, était admis. C’était une heuristique, donc tout mint futur avec la même forme aurait été automatiquement admis. Il a été supprimé le 2026-07-31, ainsi que le module superstate_allowlist. Ce qui l’a remplacé est plus étroit et sert un objectif différent : frozen_position_nft_authorities::IDS, qui n’admet rien — il décide si un NFT de position est gelé, et est décrit ci-dessus. La seule autorité d’émetteur que l’ancienne heuristique correspondait est l’une des entrées de cette liste.

Ce que les contournements ne dispensent pas

Les contournements contournent la liste d’autorisation des extensions, mais le programme applique toujours :
  • Le mint est détenu par soit Token soit Token-2022. Un programme token personnalisé est rejeté en amont.
  • Les vaults du pool sont créés avec les bonnes extensions ATA pour les pools Token-2022 (ImmutableOwner, etc.).
  • Tous les transferts passent par transfer_checked — les mints porteurs de frais atterrissent le bon montant dans le vault.
Un mint autorisé ou enregistré par PDA qui, par exemple, ajoute un TransferHook plus tard ne gagne pas une vérification au moment du swap ; le hook s’exécuterait simplement à chaque transfert et pourrait bloquer les swaps. L’enregistrement d’un mint est donc une action de haute confiance.

Sémantique « Bloqué »

Quand is_supported_mint retourne false, la création du pool revient en arrière avec ErrorCode::NotSupportMint (CPMM) / ErrorCode::NotSupportMint (CLMM). Voir reference/error-codes pour les codes numériques. Les pools existants ne peuvent pas échouer rétroactivement cette vérification — la barrière s’exécute uniquement à la création. Les extensions de mint sont immuables pour les catégories que Raydium rejette (le hook de transfert, non-transférable, le transfert confidentiel ne peut pas être ajouté après la création), donc la vérification statique est suffisante.

Pourquoi chaque extension exclue est exclue

  • TransferHook — invoque un programme personnalisé à chaque transfert, avec une consommation CU arbitraire, des conditions d’échec arbitraires, et la capacité de réentrer le programme appelant. Aucun bac à sable sûr n’existe. Certains DEX maintiennent des listes d’autorisation de hooks ; Raydium ne le fait pas.
  • NonTransferableTransfer échoue toujours. Un pool ne peut pas prendre la garde.
  • ConfidentialTransfer — les montants de transfert sont chiffrés ; la courbe ne peut pas évaluer le swap.
  • PermanentDelegate — un détenteur du délégué peut balayer n’importe quel compte token, y compris le vault du pool. Admissible uniquement en enregistrant le mint, c’est ainsi qu’un émetteur de confiance (par exemple une stablecoin réglementée) est intégré au cas par cas.
  • MintCloseAuthority — le mint peut être fermé ; les pools existants deviennent inutilisables. Disallowed par défaut.
  • DefaultAccountState (Frozen) — les ATA du pool atterriraient dans l’état Frozen et nécessiteraient un dégel par compte. Admissible uniquement en enregistrant le mint, ce qui suppose que l’émetteur dégèle les comptes institutionnels à l’inscription.
  • Pointeurs Group/Member — pas activement nuisibles, mais non examinés. Disallowed par défaut pour garder la surface étroite.

Comptabilité des frais de transfert

Pour les mints portant TransferFeeConfig, chaque swap, dépôt et retrait déplace moins que le montant nominal. Deux nombres distincts sont impliqués, et le SDK les garde séparés :
  • Les frais du pool (LP + protocole + fonds + créateur) proviennent de la courbe. raydium.cpmm.computeSwapAmount({ ... }) les retourne comme fee, aux côtés de amountIn, amountOut, minAmountOut, executionPrice, priceImpact et le swapResult brut.
  • Les frais de transfert Token-2022 proviennent du mint, pas du pool. Ils sont calculés par les assistants getTransferAmountFee dans @raydium-io/raydium-sdk-v2, qui retournent un GetTransferAmountFee :
Le dépôt et le retrait le surfacent directement : computePairAmount retourne inputAmountFee et anotherAmount comme valeurs GetTransferAmountFee. Une UI correcte affiche :
  • le montant d’entrée plus ses frais de transfert comme « vous envoyez »
  • le montant de sortie moins ses frais de transfert comme « vous recevez »
  • les frais du pool comme une ligne séparée — ce ne sont pas les frais Token-2022
Une UI naïve qui affiche uniquement amountIn → amountOut sous-estime les coûts. Passez epochInfo du cluster dans ces assistants plutôt que de le mettre en cache ; l’époque est ce qui sélectionne entre la config de frais older et newer d’un mint.

Plafond maximumFee

Les frais de transfert Token-2022 sont plafonnés par transfert. Pour un mint de 1 % avec un plafond de 10 000 tokens, un transfert de 100 000 000 tokens paie seulement 10 000 en frais. Le computeSwapAmount du SDK applique le plafond ; les appelants de programme directs doivent le répliquer.

Transition d’époque

Une autorité de mint peut programmer un changement de taux de frais qui s’active à la prochaine époque. Pendant la fenêtre de transition, deux configs (older, newer) vivent sur le mint à la fois et TransferChecked sélectionne par époque actuelle. CPMM SwapV2 et CLMM SwapV2 passent tous deux le compte mint complet dans accounts, donc le programme lit la bonne config sans recherche supplémentaire. Si vous cochez plus d’une époque à l’avance via l’API Trade ou le SDK, les frais exécutés peuvent différer des frais cotés — limités par la maximum_fee_basis_points de la config plus ancienne.

Intérêt porteur et ScaledUiAmount

Le pool détient le montant principal ; le « montant UI » est le principal multiplié par un facteur d’échelle dépendant du temps ou défini par l’admin. Les mathématiques de swap opèrent sur le principal :
Le SDK convertit automatiquement. Les lecteurs RPC directs doivent traiter pool.token0Vault.amount comme principal.

Définition du « pool Token-2022 »

Un pool est un pool Token-2022 si l’un ou l’autre mint a programId == TokenzQdB.... L’API le surface :
Utilisez programId pour dispatcher, et hasTransferFee pour surfacer un avertissement UI.

Assistants SDK

Erreurs d’intégration courantes

  • Pré-vol uniquement de l’ID du programme. Un mint peut être Token-2022 et non supporté. Parcourez la liste d’extensions par rapport à la liste d’autorisation, et vérifiez le PDA de registre du mint, avant d’autoriser la création du pool.
  • Faire confiance à la cotation du SDK quand le mint n’est pas du tout accepté. L’API de cotation ne refuse pas de coter — c’est la création du pool qui revient en arrière. Confirmez la sémantique is_supported_mint hors chaîne avant d’exposer la création du pool dans votre UI.
  • Coter sans la réduction des frais de transfert. Un mint avec frais de transfert de 1 % des deux côtés d’un pool CPMM de 0,25 % a des frais effectifs autour de 2,25 %, pas 0,25 %. Utilisez la cotation du SDK ou la cotation de l’API Trade — ne calculez jamais les frais manuellement à partir du seul niveau de frais du pool.
  • Appeler l’instruction Swap héritée sur un pool Token-2022. Swap est antérieur à Token-2022. Utilisez SwapV2 chaque fois que l’un ou l’autre mint est Token-2022.
  • Auto-lister les nouveaux mints Token-2022. Les portefeuilles et agrégateurs doivent vérifier TransferHook et NonTransferable avant de surfacer un mint aux utilisateurs ; les deux sont hostiles à Raydium.

Travaux futurs

Éléments de la feuille de route de l’écosystème Solana et du protocole qui changeraient cette matrice :
  • Programmes de hook de transfert autorisés au niveau Solana (convention d’écosystème en évolution).
  • AMM compatibles avec le transfert confidentiel (stade de la recherche).
  • Registre par mint CPMM plus large (parité avec CLMM).
  • Un chemin de lecture public pour le registre, afin qu’une UI puisse dire « non supporté » par rapport à « non supporté mais enregistré » sans dériver elle-même le PDA.
Cette page sera mise à jour quand l’un d’eux arrivera.

Pointeurs

Sources :
  • raydium-cp-swap/programs/cp-swap/src/utils/token.rsis_supported_mint, support_mint_associated_is_initialized.
  • raydium-clmm/programs/amm/src/util/token.rsis_supported_mint, support_mint_associated_is_initialized, frozen_position_nft_authorities, position_nft_must_freeze.
  • raydium-clmm/programs/amm/src/instructions/admin/create_support_mint_associated.rs — instruction de registre par mint.
  • raydium-launchpad/programs/launchpad/src/instructions/initialize_with_token_2022.rs — création de mint de base Token-2022 LaunchLab.
  • raydium-launchpad/programs/launchpad/src/instructions/admin/create_config.rs — liaison de mint quote LaunchLab (pas de vérification d’extension).