Skip to main content
Esta página foi traduzida automaticamente por IA. A versão em inglês é a fonte oficial.Ver versão em inglês →
Raydium não aceita mints Token-2022 arbitrários. CPMM e CLMM executam um modo de lista de permissões rigorosa: apenas um pequeno conjunto de extensões passa por padrão; tudo o mais é rejeitado na criação do pool. Cada programa admite um mint individual através de um mecanismo — um PDA de registro por mint gerenciado por admin. Ambos os programas também tinham bypasses codificados em vários pontos; todos eles foram agora removidos. Esta página é a referência única para o que é aplicado e onde, com citações no código-fonte do programa.

Suporte no nível do programa

As verificações da lista de permissões residem em: Não há verificação de mint no tempo de swap em CPMM ou CLMM — o controle é acionado apenas na criação do pool. Uma vez que um pool existe, os swaps apenas confiam que os mints não mudaram, o que é correto para as partes imutáveis do estado do mint Token-2022.

Congelamento de NFT de posição CLMM para emissores restritos

Contas de NFT de posição permanecem descongeladas por padrão. CLMM congela uma apenas quando a posição usa um caminho aberto V2 e pelo menos um mint de vault atual freeze_authority aparece na lista codificada frozen_position_nft_authorities::IDS. Essa lista é o que substituiu a detecção anterior de token Superstate do CLMM, e carrega a mesma autoridade de emissor que a heurística antiga correspondia. Definir o pool PDA como a autoridade de congelamento do mint de NFT de posição não é em si um congelamento. Esta é uma regra de custódia de posição, não uma lista de permissões de criação de pool:
  • O pool já pode existir e permanecer permutável.
  • O mint de NFT de posição usa o pool PDA do CLMM como sua própria autoridade de congelamento; o emissor subjacente não controla o NFT de posição.
  • OpenPositionV2 cobre NFTs de posição SPL clássicos sobre ativos de pool Token-2022. OpenPositionWithToken22Nft cobre NFTs de posição Token-2022.
  • OpenPosition V1 não inspeciona mints de vault e não pode servir os ativos restritos Token-2022 direcionados pela lista enviada.
  • Posições existentes permanecem inalteradas.
Posições congeladas permanecem gerenciáveis por seu proprietário, mas não podem ser transferidas. ClosePosition descongela e queima atomicamente quando o cliente passa o pool como a primeira conta restante. Veja products/clmm/ticks-and-positions.

Mints quote do LaunchLab

Os dois mints do LaunchLab são controlados de forma muito diferente, e a assimetria é fácil de perder.
  • Mint base — LaunchLab o cria. Um mint base Token-2022 é alcançável apenas através de initialize_with_token_2022, e o programa apenas anexará MetadataPointer e (opcionalmente) TransferFeeConfig. Qualquer outra coisa retorna NoSupportExtension. Um mint Token-2022 pré-existente não pode ser fornecido como base. Quando TransferFeeConfig é anexado, a transfer_fee_config_authority do mint é o PDA de autoridade de lançamento até a graduação, enquanto sua withdraw_withheld_authority é a transfer_fee_extension_auth configurada da plataforma a partir da criação do mint — o próprio programa launchpad não tem instrução de retirada de retido. Veja products/launchlab/platform-config.
  • Mint quote — LaunchLab não o cria e não o verifica. CreateConfig aceita a conta de mint como fornecida, então não há equivalente is_supported_mint no lado quote. O único controle é quais mints um admin escolhe vincular a um GlobalConfig.
Isso torna vincular um mint quote Token-2022 uma ação de alta confiança, pela mesma razão que registrar um mint abaixo: um mint quote TransferHook executaria seu hook em cada compra, venda e reivindicação de taxa em cada pool cotado nele, e um mint quote PermanentDelegate deixaria o delegado varrer os vaults de quote desses pools. Nenhum é bloqueado pelo programa. O que LaunchLab faz corretamente uma vez que um mint quote é vinculado:
  • O vault de quote, ambos os vaults de taxa e a conta de token do receptor de taxa de compartilhamento são criados no próprio programa do mint quote.
  • TransferFeeConfig no lado quote é precificado em todas as quatro instruções de negociação, e o limite de slippage é verificado contra o valor líquido do pagador em vez do movimento bruto do vault. Veja products/launchlab/instructions.
  • PoolState.token_program_flag registra os programas de ambos os mints — bit0 para o mint base, bit1 para o mint quote. Decodifique por bit; o byte não é um booleano. Veja products/launchlab/accounts.
A instrução Initialize descontinuada ainda aceita um programa quote apenas legado, então uma config com um mint quote Token-2022 é alcançável apenas através de InitializeV2 e InitializeWithToken2022.

Lista de permissões de extensão CPMM e CLMM

Após os dois atalhos cobertos abaixo, o programa itera as extensões do mint e rejeita o mint se ele carregar qualquer extensão que não seja estas cinco: Qualquer coisa não nesta lista — TransferHook, NonTransferable, ConfidentialTransferMint, PermanentDelegate, MintCloseAuthority, DefaultAccountState, GroupPointer, GroupMemberPointer, MemberPointer, Pausable, etc. — faz is_supported_mint retornar false e a criação do pool reverter. As linhas relevantes (CPMM, forma idêntica em CLMM):
— cp-swap/src/utils/token.rs

Caminhos de bypass

Um mint Token-2022 que não se encaixa na lista de permissões ainda pode ser admitido, através de um mecanismo em cada programa. Ambos os programas também tinham bypasses codificados no passado; nenhum deles sobrevive. is_supported_mint agora é byte-por-byte a mesma função em ambos os programas: mints SPL Token legados passam, um mint com um PDA de registro passa, e tudo o mais deve carregar apenas extensões permitidas.

O único bypass: o registro por mint

Ambos os programas consultam um PDA SupportMintAssociated na seed [b"support_mint", mint]. Se esse PDA existe para o mint, o mint é admitido independentemente de seu conjunto de extensões. Cada programa tem sua própria cópia do PDA (derivam sob IDs de programa diferentes), seu próprio par CreateSupportMintAssociated / CloseSupportMintAssociated, e sua própria autoridade dedicada ao lado do admin compartilhado: As quatro chaves (CPMM e CLMM × mainnet e devnet) estão listadas em Autoridades de registro de mint de suporte. Em ambos os programas a instrução aceita crate::admin::ID ou a autoridade dedicada desse programa, e requer que o mint seja possuído por Token-2022. Efeito: um mint Token-2022 específico pode ser optado para criação de pool sem uma atualização de programa — é por isso que as listas codificadas puderam ir embora. Cada programa consulta o registro de cada caminho de criação de pool que tem: CPMM de Initialize e InitializeWithPermission (o último é o que as graduações do LaunchLab usam, então um mint registrado se gradua bem como cria), CLMM de CreatePool, CreateCustomizablePool e CreateCustomizablePoolV2.

Os bypasses removidos

Ambos os mecanismos hardcoded foram removidos dos programas implantados. Estão documentados aqui apenas porque integrações escritas contra o comportamento anterior ainda podem assumir sua existência.

MINT_WHITELIST estática — removida

Um array constante de endereços de mint em base58 usado para contornar is_supported_mint antes da iteração de extensões. O CLMM continha seis endereços e foi deletado em 2026-07-24; o CPMM continha os primeiros quatro do mesmo conjunto e foi deletado na atualização de 2026-09-09. Um pool que já existe para um desses mints continua negociando — a verificação de mint ocorre apenas na criação do pool. Criar um novo pool para um deles agora requer um PDA de registro em seu lugar.

Detecção de forma de autoridade Superstate — removida

O CLMM identificava brevemente os ativos tokenizados da Superstate pela forma de sua autoridade em vez de por endereço: um mint Token-2022 cuja freeze_authority e permanent delegate ambas igualavam superstate_allowlist::ID, com DefaultAccountState definido como Frozen, era admitido. Era uma heurística, então qualquer mint futuro com a mesma forma teria sido admitido automaticamente. Foi deletado em 2026-07-31, junto com o módulo superstate_allowlist. O que o substituiu é mais restrito e serve um propósito diferente: frozen_position_nft_authorities::IDS, que não admite nada — decide se um position NFT fica congelado, e é descrito acima. A única autoridade de emissor que a heurística antiga correspondia é a única entrada nessa lista.

O que os bypasses não dispensam

Os bypasses pulam a allow-list de extensões, mas o programa ainda reforça:
  • O mint é possuído por Token ou Token-2022. Um programa de token customizado é rejeitado upstream.
  • Os vaults do pool são criados com as extensões ATA corretas para pools Token-2022 (ImmutableOwner, etc.).
  • Todas as transferências passam por transfer_checked — mints com taxa chegam ao valor correto no vault.
Um mint na whitelist ou registrado via PDA que, por exemplo, adiciona um TransferHook depois não ganha uma verificação em tempo de swap; o hook simplesmente rodaria em cada transferência e poderia quebrar swaps. Registrar um mint é portanto uma ação de alta confiança.

Semântica de “Blocked”

Quando is_supported_mint retorna false, a criação do pool reverte com ErrorCode::NotSupportMint (CPMM) / ErrorCode::NotSupportMint (CLMM). Veja reference/error-codes para os códigos numéricos. Pools existentes não podem falhar retroativamente nessa verificação — o gate ocorre apenas na criação. Extensões de mint são imutáveis para as categorias que Raydium rejeita (transfer hook, non-transferable, confidential transfer não podem ser adicionados pós-criação), então a verificação estática é suficiente.

Por que cada extensão excluída é excluída

  • TransferHook — invoca um programa customizado em cada transferência, com consumo de CU arbitrário, condições de falha arbitrárias, e a capacidade de reentrar o programa chamador. Nenhum sandbox seguro existe. Alguns DEXes mantêm allow-lists de hooks; Raydium não.
  • NonTransferable — Transfer sempre falha. Um pool não pode tomar custódia.
  • ConfidentialTransfer — os valores de transferência são criptografados; a curva não consegue precificar o swap.
  • PermanentDelegate — um detentor do delegate pode varrer qualquer conta de token, incluindo o vault do pool. Admissível apenas registrando o mint, que é como um emissor confiável (ex. um stablecoin regulado) é integrado caso a caso.
  • MintCloseAuthority — o mint pode ser fechado; pools existentes ficam inutilizáveis. Desabilitado por padrão.
  • DefaultAccountState (Frozen) — ATAs do pool ficariam em estado Frozen e exigiriam descongelamento por conta. Admissível apenas registrando o mint, que assume que o emissor descongela contas institucionais no registro.
  • Group/Member pointers — não ativamente prejudicial, mas não revisado. Desabilitado por padrão para manter a superfície estreita.

Contabilidade de taxa de transferência

Para mints com TransferFeeConfig, cada swap, depósito e saque move menos que o valor nominal. Dois números separados estão envolvidos, e o SDK os mantém separados:
  • A taxa do pool (LP + protocolo + fundo + criador) vem da curva. raydium.cpmm.computeSwapAmount({ ... }) a retorna como fee, junto com amountIn, amountOut, minAmountOut, executionPrice, priceImpact e o swapResult bruto.
  • A taxa de transferência Token-2022 vem do mint, não do pool. É computada pelos helpers getTransferAmountFee em @raydium-io/raydium-sdk-v2, que retornam um GetTransferAmountFee:
Depósito e saque o expõem diretamente: computePairAmount retorna inputAmountFee e anotherAmount como valores GetTransferAmountFee. Uma UI correta mostra:
  • o valor de entrada mais sua taxa de transferência como “você envia”
  • o valor de saída menos sua taxa de transferência como “você recebe”
  • a taxa do pool como uma linha separada — não é a taxa Token-2022
Uma UI ingênua que mostra apenas amountIn → amountOut subestima custos. Passe epochInfo do cluster para esses helpers em vez de cachear; a epoch é o que seleciona entre a configuração de taxa older e newer de um mint.

Cap de maximumFee

As taxas de transferência Token-2022 são limitadas por transferência. Para um mint de 1% com um cap de 10.000 tokens, uma transferência de 100.000.000 tokens paga apenas 10.000 em taxa. O computeSwapAmount do SDK aplica o cap; chamadores diretos do programa devem replicá-lo.

Transição de epoch

Uma autoridade de mint pode agendar uma mudança de taxa que se ativa na próxima epoch. Durante a janela de transição, duas configurações (older, newer) vivem no mint simultaneamente e TransferChecked seleciona pela epoch atual. Tanto SwapV2 do CPMM quanto SwapV2 do CLMM passam a conta de mint completa em accounts, então o programa lê a configuração correta sem uma busca extra. Se você cotar mais de uma epoch em antecedência via a Trade API ou SDK, a taxa executada pode diferir da taxa cotada — limitada pelo maximum_fee_basis_points da configuração anterior.

Interest-bearing e ScaledUiAmount

O pool mantém o valor principal; o “valor UI” é o principal multiplicado por um fator de escala dependente do tempo ou definido por admin. A matemática de swap opera no principal:
O SDK converte automaticamente. Leitores RPC diretos devem tratar pool.token0Vault.amount como principal.

Definição de “pool Token-2022”

Um pool é um pool Token-2022 se qualquer um dos mints tem programId == TokenzQdB.... A API expõe isso:
Use programId para dispatch, e hasTransferFee para exibir um aviso na UI.

Helpers do SDK

Erros comuns de integração

  • Fazer pré-flight apenas do program ID. Um mint pode ser Token-2022 e não suportado. Caminhe pela lista de extensões contra a allow-list, e verifique o PDA de registro do mint, antes de permitir criação de pool.
  • Confiar na cotação do SDK quando o mint não é aceito em absoluto. A API de cotação não se recusa a cotar — é a criação do pool que reverte. Confirme a semântica de is_supported_mint off-chain antes de expor criação de pool na sua UI.
  • Cotar sem o corte de taxa de transferência. Um mint com taxa de transferência de 1% em ambos os lados de um pool CPMM de 0,25% tem uma taxa efetiva em torno de 2,25%, não 0,25%. Use a cotação do SDK ou a cotação da Trade API — nunca compute taxa manualmente apenas a partir do tier de taxa do pool.
  • Chamar a instrução Swap legada em um pool Token-2022. Swap é anterior a Token-2022. Use SwapV2 sempre que qualquer mint for Token-2022.
  • Auto-listar novos mints Token-2022. Wallets e agregadores devem verificar TransferHook e NonTransferable antes de expor um mint aos usuários; ambos são hostis ao Raydium.

Trabalho futuro

Itens do roadmap do ecossistema Solana e protocolo que mudariam essa matriz:
  • Programas de transfer-hook com allow-list no nível Solana (convenção de ecossistema evoluindo).
  • AMMs compatíveis com confidential-transfer (estágio de pesquisa).
  • Registro CPMM por-mint mais amplo (paridade com CLMM).
  • Um caminho de leitura público para o registro, para que uma UI possa dizer “não suportado” de “não suportado mas registrado” sem derivar o PDA ela mesma.
Esta página será atualizada quando qualquer um deles chegar.

Referências

Fontes:
  • 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 — instrução de registro por-mint.
  • raydium-launchpad/programs/launchpad/src/instructions/initialize_with_token_2022.rs — criação de base-mint Token-2022 do LaunchLab.
  • raydium-launchpad/programs/launchpad/src/instructions/admin/create_config.rs — vinculação de quote-mint do LaunchLab (sem verificação de extensão).