Matrice de support Token-2022

Quels programmes Raydium supportent Token-2022, la liste d’autorisation explicite d’extensions que chaque programme applique à la création de pool, et les chemins de contournement (liste blanche statique de mints, registre par mint, détection Superstate) qui admettent les mints autrement rejetés.

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. Une poignée de mints de confiance sont admis par adresse codée en dur ; CLMM supporte en outre un registre par mint géré par l’administrateur et une détection de token Superstate à l’exécution. Cette page est la référence unique pour ce qui est appliqué et où, avec des citations fichier-et-ligne dans la source du programme.

​

Support au niveau du programme

Programme	Mints base/quote Token-2022 ?	Mode
CPMM	Oui — contrôlé	Liste d’autorisation stricte d’extensions + liste blanche statique de 4 mints.
CLMM	Oui — contrôlé	Liste d’autorisation stricte d’extensions + liste blanche statique de 6 mints + registre par mint administrateur + détection Superstate.
AMM v4	Non	Le programme est antérieur à Token-2022 ; les deux mints doivent être du Token SPL classique.
Stable AMM	Non	Mêmes contraintes que AMM v4.
Farm v6	Oui, partiel	Le mint de récompense peut être Token-2022 (soumis à la même liste d’autorisation quand une farm enveloppe un LP CPMM/CLMM) ; les mints LP de stake utilisateur héritent du pool enveloppé.
LaunchLab	Oui — base gérée par le programme, quote non contrôlée	Le mint de base peut être Token-2022, mais uniquement via l’instruction dédiée initialize_with_token_2022 ; le programme crée lui-même le mint avec MetadataPointer (toujours) et optionnellement TransferFeeConfig (taux ≤ 5 %). Les mints Token-2022 préexistants avec des extensions arbitraires ne peuvent pas être utilisés comme base. Le mint quote peut être n’importe quel mint Token-2022 qu’un administrateur lie à une GlobalConfig, sans vérification d’extension — voir ci-dessous.
Burn & Earn	Reflète le programme de pool	Hérite du contrôle CPMM / CLMM.

Les vérifications de liste d’autorisation se trouvent dans :

• CPMM : is_supported_mint dans raydium-cp-swap/programs/cp-swap/src/utils/token.rs:178, appelé depuis Initialize.
• CLMM : is_supported_mint dans raydium-clmm/programs/amm/src/util/token.rs:280, appelé depuis CreatePool.
• LaunchLab : initialize_with_token_2022 dans raydium-launchpad/programs/launchpad/src/instructions/initialize_with_token_2022.rs (source non disponible publiquement).

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 du NFT de position CLMM pour les émetteurs restreints

Les comptes NFT de position restent dégelés par défaut. CLMM gèle un seul quand la position utilise un chemin ouvert V2 et qu’au moins un mint de vault a sa freeze_authority actuelle qui correspond à la liste d’autorités d’émetteur restreint codée en dur. La liste initiale contient la même autorité utilisée par le chemin de détection Superstate ci-dessous. 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 autre 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 d’autorité de lancement jusqu’à la graduation, tandis que sa withdraw_withheld_authority est la transfer_fee_extension_auth configurée de la plateforme depuis la création du mint — le programme launchpad lui-même n’a pas d’instruction de retrait de retenue. 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 administrateur choisit de lier à une GlobalConfig.

Cela rend la liaison d’un mint quote Token-2022 une action de haute confiance, avec le même raisonnement que les listes blanches statiques CPMM et CLMM 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 propre programme du mint quote.
• TransferFeeConfig du côté quote est intégré au prix 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 le 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 d’extensions CPMM et CLMM

Après les raccourcis de liste blanche statique (couverts ci-dessous), le programme itère les extensions du mint et rejette le mint s’il porte n’importe quelle extension autre que ces cinq :

Extension	Raison pour laquelle elle est autorisée
TransferFeeConfig	Les mathématiques du pool soustraient les frais entrants ; le programme Token-2022 gère les frais sortants. Voir algorithms/token-2022-transfer-fees.
MetadataPointer	Décoratif — pointe vers les métadonnées on-chain.
TokenMetadata	Décoratif — métadonnées en ligne.
InterestBearingConfig	Le pool voit le montant principal ; le multiplicateur UI est décorateur uniquement et le solde sous-jacent est préservé.
ScaledUiAmount	Même forme que l’intérêt composé — le facteur d’échelle s’applique uniquement à l’affichage UI.

Tout ce qui n’est 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) :

for e in extensions {
    if e != ExtensionType::TransferFeeConfig
        && e != ExtensionType::MetadataPointer
        && e != ExtensionType::TokenMetadata
        && e != ExtensionType::InterestBearingConfig
        && e != ExtensionType::ScaledUiAmount
    {
        return Ok(false);
    }
}
Ok(true)

— cp-swap/src/utils/token.rs:190–200

​

Chemins de contournement

Un mint Token-2022 qui ne correspond pas à la liste d’autorisation peut toujours être admis via l’un des trois contournements explicites. Ils sont tentés dans l’ordre, avant que l’itération d’extension ne s’exécute.

​

1. Liste blanche statique de mints

Un tableau constant MINT_WHITELIST de chaînes base58 est codé en dur dans chaque programme. Si l’adresse du mint correspond, la fonction retourne true immédiatement et aucune vérification d’extension n’est effectuée.

Programme	Mints sur liste blanche
CPMM	HVbpJAQGNpkgBaYBZQBR1t7yFdvaYVp2vCQQfKKEN4tM, Crn4x1Y2HUKko7ox2EZMT6N2t2ZyH7eKtwkBGVnhEq1g, FrBfWJ4qE5sCzKm3k3JaAtqZcXUh4LvJygDeketsrsH4, 2b1kV6DkPAnxd5ixfnxCpjxmKwqjjaYmCZfHsFu24GXo
CLMM	Les quatre mêmes, plus DAUcJBg4jSpVoEzASxYzdqHMUN8vuTpQyG2TvDcCHfZg, AUSD1jCcCyPLybk1YnvPWsHQSrZ46dxwoMniN4N2UEB9

Ces adresses sont intégrées au programme ; la mise à jour de la liste nécessite une mise à niveau du programme via le multisig de mise à niveau 3/4.

​

2. Registre par mint — CLMM uniquement

CLMM consulte en outre un PDA SupportMintAssociated à la graine [b"support_mint", mint]. Si ce PDA existe pour le mint, il est admis indépendamment de son ensemble d’extensions.

Le PDA est créé par CreateSupportMintAssociated (admin/create_support_mint_associated.rs). L’instruction est contrôlée par deux signataires :

• crate::admin::ID — l’autorité administrateur Raydium standard.
• crate::create_support_mint_associated_owner::ID — une autorité dédiée à cet effet : RayVyjyJQz9vAi126A4sGexKnSU1XeZaHTRcM1mZMPY (mainnet), rayf3nEbb3bnfN6RDGFpqPbjc5uUa3tRUzu6UVYrRx5 (devnet).

Effet : l’équipe CLMM peut opter pour un mint Token-2022 spécifique dans la création de pool sans mise à niveau du programme. CPMM n’a pas d’équivalent — sa liste d’autorisation est strictement codée en source.

​

3. Détection Superstate — CLMM uniquement

CLMM a un troisième chemin spécifiquement pour les actifs tokenisés de Superstate, qui utilisent l’extension ScaledUiConfig que la version de spl-token-2022 liée au programme CLMM ne peut pas dépacker. Plutôt que de mettre à niveau la dépendance, CLMM détecte les tokens Superstate par leur forme d’autorité :

superstate_allowlist::ID == freeze_authority
    && *mint_account_info.owner == spl_token_2022::ID
    && default_account_state_freeze
    && maybe_permanent_delegate

— raydium-clmm/programs/amm/src/util/token.rs:485

Un mint passe cette branche si les quatre conditions tiennent :

• Son programme propriétaire est le programme Token-2022.
• Son autorité de gel est égale à superstate_allowlist::ID. Voir reference/program-addresses pour les valeurs mainnet-beta et devnet.
• Son extension DefaultAccountState est définie sur Frozen.
• Son délégué permanent est également superstate_allowlist::ID.

C’est une heuristique, pas un registre — tout mint futur que Superstate émet avec la même forme d’autorité sera automatiquement admis.

​

Ce que les contournements ne dispensent pas

Les contournements contournent la liste d’autorisation d’extensions, mais le programme applique toujours :

• Le mint est détenu par Token ou 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 sur liste blanche ou enregistré dans le PDA qui, par exemple, ajoute un TransferHook plus tard ne gagne pas de vérification au moment du swap ; le hook s’exécuterait simplement à chaque transfert et pourrait bloquer les swaps. La mise sur liste blanche 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 création), donc la vérification statique est suffisante.

​

Pourquoi chaque extension exclue est exclue

• TransferHook — invoque un programme personnalisé à chaque transfert, avec consommation CU arbitraire, 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. Autorisé uniquement via la liste blanche statique pour les émetteurs de confiance (par exemple, les stablecoins réglementés).
• 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. Autorisé uniquement via la détection Superstate, 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. Le SDK affiche les deux moitiés du calcul :

const { amountIn, amountOut, feeAmount, token2022FeeIn, token2022FeeOut } =
  await raydium.cpmm.computeSwapAmount({ ... });

Une UI correcte affiche :

• amountIn + token2022FeeIn comme « vous envoyez »
• amountOut - token2022FeeOut comme « vous recevez »
• feeAmount comme les frais du pool (LP + protocole), qui sont séparés des frais de transfert Token-2022

Une UI naïve qui affiche uniquement amountIn → amountOut sous-estime les coûts.

​

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 planifier 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 composé 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’administrateur. Les mathématiques du swap opèrent sur le principal :

principal_in = ui_amount_in / ui_multiplier(now)

Le SDK convertit automatiquement. Les lecteurs RPC directs doivent traiter pool.token0Vault.amount comme principal.

​

Définition de « pool Token-2022 »

Un pool est un pool Token-2022 si l’un ou l’autre mint a programId == TokenzQdB.... L’API affiche ceci :

GET /pools/info/ids?ids=<POOL_ID>

{
  "data": [{
    "mintA": { "programId": "TokenzQdB...", "hasTransferFee": true, ... },
    "mintB": { "programId": "Tokenkeg...", ... }
  }]
}

Utilisez programId pour dispatcher, et hasTransferFee pour afficher un avertissement UI.

​

Assistants SDK

import { Raydium, TOKEN_2022_PROGRAM_ID } from "@raydium-io/raydium-sdk-v2";
import { ExtensionType, getExtensionTypes, unpackMint } from "@solana/spl-token";

const raydium = await Raydium.load({ owner, connection });

const acct = await connection.getAccountInfo(mintPubkey);
if (!acct) throw new Error("mint not found");
const mint = unpackMint(mintPubkey, acct, acct.owner);

if (acct.owner.equals(TOKEN_2022_PROGRAM_ID)) {
  const extensions = getExtensionTypes(mint.tlvData);
  const accepted = new Set([
    ExtensionType.TransferFeeConfig,
    ExtensionType.MetadataPointer,
    ExtensionType.TokenMetadata,
    ExtensionType.InterestBearingConfig,
    ExtensionType.ScaledUiAmount,
  ]);
  const rejecting = extensions.filter(e => !accepted.has(e));
  if (rejecting.length) {
    console.warn("Pool creation will revert unless this mint is whitelisted:", rejecting);
  }
}

​

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 la liste blanche statique) 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.
• Lister automatiquement les nouveaux mints Token-2022. Les portefeuilles et agrégateurs doivent vérifier TransferHook et NonTransferable avant de présenter 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 sur liste blanche au niveau Solana (convention d’écosystème en évolution).
• AMM compatibles avec le transfert confidentiel (stade de recherche).
• Registre par mint CPMM plus large (parité avec CLMM).
• Mise à niveau de dépendance pour que le décodage ScaledUiConfig de CLMM fonctionne sans l’heuristique Superstate.

Cette page sera mise à jour quand l’un d’eux arrivera.

​

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ériques NotSupportMint par programme.

Sources :

• raydium-cp-swap/programs/cp-swap/src/utils/token.rs — MINT_WHITELIST, is_supported_mint.
• raydium-clmm/programs/amm/src/util/token.rs — MINT_WHITELIST, superstate_allowlist, is_superstate_token, is_supported_mint.
• 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).