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 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

As 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 PDA do pool 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 PDA do pool 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 Token-2022 restritos 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, o transfer_fee_config_authority do mint é o PDA de autoridade de lançamento até a graduação, enquanto seu withdraw_withheld_authority é o transfer_fee_extension_auth configurado da plataforma a partir da criação do mint — o próprio programa de launchpad não tem instrução de retirada retida. 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 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 com que is_supported_mint retorne false e a criação do pool reverta. 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: Em ambos os programas a instrução aceita crate::admin::ID ou a autoridade dedicada desse programa, e requer que o mint seja de propriedade do 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 poderiam desaparecer. Cada programa consulta o registro de cada caminho de criação de pool que possui: 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 CreatePermissionedPool.

Os bypasses removidos

Ambos os mecanismos codificados desapareceram dos programas implantados. Eles são documentados aqui apenas porque integrações escritas contra o comportamento mais antigo ainda podem assumir.

MINT_WHITELIST estático — removido

Uma matriz constante de endereços de mint em base58 costumava fazer um atalho em is_supported_mint antes da iteração de extensão. A de CLMM continha seis endereços e foi deletada em 2026-07-24; a de CPMM continha os primeiros quatro do mesmo conjunto e foi deletada na atualização 2026-09-09. Um pool que já existe para um desses mints continua negociando — a verificação de mint é executada apenas na criação do pool. Criar um novo pool para um agora requer um PDA de registro para ele.

Detecção de forma de autoridade Superstate — removido

CLMM brevemente identificou ativos tokenizados do Superstate por sua forma de autoridade em vez de por endereço: um mint Token-2022 cujo freeze_authority e delegado permanente ambos 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 estreito e serve um propósito diferente: frozen_position_nft_authorities::IDS, que não admite nada — decide se um NFT de posição fica congelado, e é descrito acima. A autoridade de emissor única que a heurística antiga correspondia é a entrada única nessa lista.

O que os bypasses não dispensam

Os bypasses pulam a lista de permissões de extensão, mas o programa ainda aplica:
  • O mint é de propriedade de 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 lista de permissões ou registrado em PDA que, por exemplo, adiciona um TransferHook depois não ganha uma verificação no tempo de swap; o hook simplesmente seria executado em cada transferência e poderia quebrar swaps. Registrar um mint é, portanto, uma ação de alta confiança.

Semântica “Bloqueado”

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 nesta verificação — o controle é executado apenas na criação. Extensões de mint são imutáveis para as categorias que Raydium rejeita (transfer hook, não-transferível, transferência confidencial não pode ser adicionada 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. Nenhuma sandbox segura existe. Alguns DEXes mantêm listas de permissões de hook; Raydium não.
  • NonTransferableTransfer sempre falha. Um pool não pode tomar custódia.
  • ConfidentialTransfer — os valores de transferência são criptografados; a curva não pode precificar o swap.
  • PermanentDelegate — um detentor do delegado pode varrer qualquer conta de token, incluindo o vault do pool. Admissível apenas registrando o mint, que é como um emissor confiável (por exemplo, uma stablecoin regulada) é integrado caso a caso.
  • MintCloseAuthority — o mint pode ser fechado; pools existentes se tornam inutilizáveis. Desaprovado por padrão.
  • DefaultAccountState (Frozen) — ATAs do pool aterrariam em estado Frozen e exigiriam descongelamento por conta. Admissível apenas registrando o mint, que assume que o emissor descongela contas institucionais no registro.
  • Ponteiros de grupo/membro — não ativamente prejudiciais, mas não revisados. Desaprovados por padrão para manter a superfície estreita.

Contabilidade de taxa de transferência

Para mints carregando TransferFeeConfig, cada swap, depósito e retirada 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, ao lado de 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 retirada o expõem diretamente: computePairAmount retorna inputAmountFee e anotherAmount como valores GetTransferAmountFee. Uma UI correta mostra:
  • o valor de entrada mais sua transferência fee como “você envia”
  • o valor de saída menos sua transferência fee como “você recebe”
  • a fee 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 época é o que seleciona entre a config de taxa older e newer de um mint.

Limite de maximumFee

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

Transição de época

Uma autoridade de mint pode agendar uma mudança de taxa que se ativa na próxima época. Durante a janela de transição, duas configs (older, newer) vivem no mint ao mesmo tempo e TransferChecked seleciona por época atual. CPMM SwapV2 e CLMM SwapV2 ambos passam a conta de mint completa em accounts, então o programa lê a config correta sem uma busca extra. Se você citar mais de uma época antecipadamente via Trade API ou SDK, a taxa executada pode diferir da taxa cotada — limitada pelo maximum_fee_basis_points da config mais antiga.

Juros compostos e ScaledUiAmount

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

Definição de “pool Token-2022”

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

Helpers do SDK

Erros comuns de integração

  • Pré-voo apenas do ID do programa. Um mint pode ser Token-2022 e não suportado. Caminhe pela lista de extensões contra a lista de permissões, e verifique o PDA de registro do mint, antes de permitir a criação do pool.
  • Confiar na cotação do SDK quando o mint não é aceito. A API de cotação não se recusa a cotar — a criação do pool é o que reverte. Confirme a semântica is_supported_mint off-chain antes de expor a criação do pool em sua UI.
  • Cotação sem o corte de taxa de transferência. Um mint de 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 cotação da Trade API — nunca compute taxa manualmente apenas a partir do nível de taxa do pool.
  • Chamar a instrução Swap legada em um pool Token-2022. Swap é anterior ao Token-2022. Use SwapV2 sempre que qualquer mint for Token-2022.
  • Auto-listar novos mints Token-2022. Carteiras e agregadores devem verificar TransferHook e NonTransferable antes de exibir um mint aos usuários; ambos são hostis ao Raydium.

Trabalho futuro

Itens do roteiro do ecossistema Solana e protocolo que mudariam esta matriz:
  • Programas de transfer-hook permitidos no nível Solana (convenção de ecossistema evoluindo).
  • AMMs compatíveis com transferência confidencial (estágio de pesquisa).
  • Registro por mint CPMM 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 em si.
Esta página será atualizada quando qualquer um deles chegar.

Ponteiros

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