Cette page est traduite automatiquement par IA. La version anglaise fait foi.Voir la version anglaise →
Support au niveau du programme
Les vérifications de la liste d’autorisation se trouvent dans :
- CPMM :
is_supported_mintdansraydium-cp-swap/programs/cp-swap/src/utils/token.rs, appelée depuisInitializeetInitializeWithPermission. - CLMM :
is_supported_mintdansraydium-clmm/programs/amm/src/util/token.rs, appelée depuisCreatePool. - LaunchLab :
initialize_with_token_2022dansraydium-launchpad/programs/launchpad/src/instructions/initialize_with_token_2022.rs(source non disponible publiquement).
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 lafreeze_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.
OpenPositionV2couvre les NFT de position SPL classiques sur les actifs de pool Token-2022.OpenPositionWithToken22Nftcouvre les NFT de position Token-2022.OpenPositionV1 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.
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 queMetadataPointeret (optionnellement)TransferFeeConfig. Tout le reste retourneNoSupportExtension. Un mint Token-2022 préexistant ne peut pas du tout être fourni comme base. QuandTransferFeeConfigest attaché, latransfer_fee_config_authoritydu mint est le PDA de l’autorité de lancement jusqu’à la graduation, tandis que sawithdraw_withheld_authorityest latransfer_fee_extension_authconfiguré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. Voirproducts/launchlab/platform-config. - Mint quote — LaunchLab ne le crée pas et ne le contrôle pas.
CreateConfigaccepte le compte mint tel quel, donc il n’y a pas d’équivalentis_supported_mintdu côté quote. Le seul contrôle est les mints qu’un admin choisit de lier à uneGlobalConfig.
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.
TransferFeeConfigdu 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. Voirproducts/launchlab/instructions.PoolState.token_program_flagenregistre 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. Voirproducts/launchlab/accounts.
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 PDASupportMintAssociated à 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 lafreeze_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
TokensoitToken-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.
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é »
Quandis_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.
- NonTransferable —
Transferé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
Frozenet 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 portantTransferFeeConfig, 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 commefee, aux côtés deamountIn,amountOut,minAmountOut,executionPrice,priceImpactet leswapResultbrut. - Les frais de transfert Token-2022 proviennent du mint, pas du pool. Ils sont calculés par les assistants
getTransferAmountFeedans@raydium-io/raydium-sdk-v2, qui retournent unGetTransferAmountFee:
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
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 :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 aprogramId == TokenzQdB.... L’API le surface :
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_minthors 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
Swaphéritée sur un pool Token-2022.Swapest antérieur à Token-2022. UtilisezSwapV2chaque 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
TransferHooketNonTransferableavant 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.
Pointeurs
algorithms/token-2022-transfer-fees— mathématiques des frais dans les swaps.products/cpmm/instructions—SwapV2,Initialize.products/clmm/instructions—SwapV2,CreatePool,CreateSupportMintAssociated.reference/error-codes— codes numériquesNotSupportMintpar programme.
raydium-cp-swap/programs/cp-swap/src/utils/token.rs—is_supported_mint,support_mint_associated_is_initialized.raydium-clmm/programs/amm/src/util/token.rs—is_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).

