Esta página foi traduzida automaticamente por IA. A versão em inglês é a fonte oficial.Ver versão em inglês →
Todo programa Raydium tem pelo menos uma função privilegiada — uma chave que pode fazer upgrade do programa, criar novas configurações ou sacar taxas de protocolo. Minimizar o que essas funções podem fazer (e colocá-las atrás de multisigs com atrasos) é a defesa principal contra um administrador comprometido. Esta página cataloga as funções e como elas são protegidas na prática.
Funções por programa
AMM v4
CPMM
A coleta de taxa do criador não introduz uma função privilegiada.
CollectCreatorFeePermissionless aceita qualquer pagador, restringe o proprietário do destinatário a PoolState.pool_creator e restringe ambos os destinos aos ATAs canônicos desse criador. Um chamador pode financiar ATAs ausentes e disparar a varredura, mas não pode redirecionar as taxas.
CLMM
Manter um PDA
Permission permite que sua autoridade chame CreatePermissionedPool — criando pools adicionais para um par que já tem um canônico, cada um em um endereço derivado de seed_index distinto. A permissão é limitada apenas à criação de pool: não pode mover fundos, alterar taxas ou tocar em nenhum pool existente. Revogá-la (ClosePermissionPda) impede que a autoridade crie mais pools, mas deixa os pools já criados intactos.
O limit_order_admin é uma função operacional deliberadamente estreita. Existe para que um keeper off-chain possa varrer ordens preenchidas sem que o proprietário da ordem precise estar online. A chave do keeper é quente (vive na VM do keeper) e é rotacionada independentemente das multisigs acima. Concretamente, a autoridade do keeper é limitada a:
SettleLimitOrder— enviar a saída preenchida de uma ordem para o ATA do proprietário no preço limite da ordem.CloseLimitOrder— fechar a conta de uma ordem totalmente liquidada para recuperar aluguel (aluguel vai para o proprietário da ordem).
OpenLimitOrder, IncreaseLimitOrder, DecreaseLimitOrder, mutar nenhum campo de pool ou assinar qualquer outra instrução — essas verificações são aplicadas on-chain pelas restrições de seed e has_one na struct Accounts da instrução. Um keeper comprometido pode no máximo estar indisponível (ordens ficam estacionadas até o proprietário liquidá-las) ou liquidar/fechar ordens legitimamente preenchíveis fora de ordem; não pode mover fundos do usuário para lugar nenhum além de onde o proprietário já os autorizou.
Farm v6
Farms individuais não têm admin de protocolo — cada criador de farm controla apenas seu farm, e os poderes do criador são limitados (não pode apreender stakes de usuários, não pode alterar o mint de staking).
LaunchLab
A lista de permissões de admin da plataforma é auto-restritiva: limita quais contas
GlobalConfig launches sob essa plataforma podem usar. Não concede autoridade sobre outras plataformas ou fundos de launch existentes. Os endereços de autoridade delegada canônicos vivem em reference/program-addresses.
Autoridade de upgrade do programa
Os programas Raydium usam o mecanismo de upgrade padrão do Solana BPF Loader v3. A autoridade de upgrade para todos os programas é a multisig Squads 3/4. Por que 3/4: signatários suficientes para que um único comprometimento seja insuficiente; poucos o suficiente para que coordenar um upgrade legítimo seja tratável. As quatro autoridades são independentes, signatários de dispositivos frios isolados de rede mantidos por membros do time principal. A assinatura sequencial impede aprovações paralelas na mesma transação; transações carregam uma janela de expiração fixa. As operações de multisig são revisadas periodicamente em parceria com o Programa STRIDE do Solana (Asymmetric Research).Removendo autoridade de upgrade
Raydium não definiu a autoridade de upgrade de nenhum programa como nula. O protocolo opera sob o princípio de que programas precisam ser atualizáveis (para corrigir bugs, adicionar extensões como Token-2022, corrigir desvios de integração). Trade-off: usuários confiam que a multisig 3/4 só implantará upgrades bem revisados. Nenhum programa Raydium está atualmente congelado ou se movendo lentamente o suficiente para ser tratado como uma alternativa imutável — AMM v4, historicamente o mais estático deles, foi ele próprio reimplantado em 2026-07-22. O slot da última implantação para cada programa é público; leia-o antes de assumir que algum deles está dormindo:
(Da conta
ProgramData de cada programa; solana program show <PROGRAM_ID> relata o mesmo slot.)
Autoridade do AmmConfig
Cada criação de novo AmmConfig é permissionada — a multisig treasury 3/5 autoriza novas camadas de taxa e espaçamentos de tick. Pools existentes referenciam seu AmmConfig por PDA; a camada de taxa do pool é o que o AmmConfig diz. Administradores podem alterar um AmmConfig existente? Sim, tecnicamente.updateAmmConfig é chamável pelo admin. Na prática, modificações em AmmConfigs implantados são evitadas porque altera a economia de todos os pools usando essa config silenciosamente. A política de protocolo é criar um novo AmmConfig para qualquer mudança e migrar.
Administradores podem roubar taxas de protocolo via config? Não — o AmmConfig contém parâmetros de taxa, mas não o destinatário da taxa de protocolo; esse é um endereço imutável separado por pool.
Reivindicação de taxa de protocolo
Uma porção das taxas de swap (tipicamente 3–12 bps de 25 bps de taxa de swap, dependendo da config) acumula em um vault de taxa de protocolo. A multisig pode sacar essas taxas acumuladas. Usuários nunca veem seu saldo de LP mudar por isso — é a parcela pré-alocada do protocolo, não dinheiro de LP.Autoridade do criador de farm
Farms v6 dão ao criador o poder de:- Financiar o vault de recompensa (adicionar mais tokens).
- Estender o cronograma (empurrar o tempo final mais tarde).
- Chamar
withdrawRewardapós o tempo final para recuperar o saldo não utilizado do vault.
- Sacar LP de stake de usuários.
- Alterar o mint de staking.
- Alterar taxas de emissão retroativamente (apenas prospectivamente via
setRewards). - Congelar colheitas de usuários.
Configuração da multisig Squads
Raydium opera duas multisigs Squads separadas para superfícies de risco distintas. Ambas podem ser inspecionadas on-chain via a UI do Squads Protocol.
Propriedades operacionais da multisig de upgrade:
- Timelock de 24 horas em qualquer transação. Um upgrade aprovado hoje executa não antes de 24 horas depois, dando aos usuários tempo para responder.
- Assinatura de dispositivo frio isolado de rede. Dispositivos frios têm placas de rede fisicamente removidas; conectam apenas a uma carteira de hardware e leem dados de transação via código QR de um dispositivo quente separado.
- Assinatura sequencial. Apenas depois que um dispositivo frio gera e assina uma transação o próximo dispositivo frio pode começar seu processo de assinatura — prevenindo assinaturas conflitantes ou paralelas na mesma transação.
- Expiração de transação. Toda transação carrega uma janela de expiração fixa, então transações antigas se auto-invalidam.
- Aplicação de TOTP + chave física nos dispositivos quentes usados para iniciação de transação e broadcast on-chain.
- Fila de transação pública. Qualquer um pode monitorar upgrades pendentes na UI do Squads.
Verificando autoridade on-chain
A forma mais simples de verificar a autoridade de upgrade atual de um programa:Authority não for o endereço esperado da multisig Squads, algo está errado. Raydium publica os endereços de autoridade esperados em reference/program-addresses.
Para funções de admin do AmmConfig / pool, busque a conta on-chain e decodifique:
AmmConfig não tem campo admin — o admin do programa é uma pubkey compilada no programa (crate::admin::ID), e as autoridades operacionais por config são protocolOwner / fundOwner. A autoridade de upgrade do BPF é uma preocupação separada em nível de loader; leia-a com solana program show.
Mudanças históricas de autoridade
Considerações do lado do usuário
O que você deve fazer como usuário/LP/integrador?- Verifique a autoridade de upgrade antes de grandes alocações. Confirme que corresponde à multisig documentada.
- Monitore atividade de multisig. UI do Squads mostra transações pendentes; um upgrade agendado lhe dá 24 horas para se desfazer se discordar da mudança.
- Estratégias de resgate cientes de time-lock. Se você está executando um auto-compounder, certifique-se de que seu caminho de unwinding não requer uma instrução que está sendo alterada.
- Não assuma imutabilidade do programa. Todo programa Raydium pode ser atualizado; planeje para isso.
Armadilhas para integradores
1. Cachear endereços de autoridade
Se você codificar o endereço da autoridade de upgrade ou multisig de admin em seu código e ele depois rotar, sua verificação falha. Busque dereference/program-addresses em tempo de execução ou atualize periodicamente.
2. Assumir que AmmConfigs são estáveis
Um novo AmmConfig pode ser criado a qualquer momento. Seu agregador/roteador deve re-buscar a lista completa de config periodicamente (a cada hora está bom).3. Vetores de pesar do criador de farm
Se você está depositando em um farm de baixa reputação, o criador poderia terminar o farm cedo e recuperar o vault de recompensa (assumindo que nenhum usuário tenha feito stake ainda). Uma vez que usuários tenham feito stake, direitos pro-rata são aplicados pelo programa; recuperação apenas obtém o restante após término racional.Ponteiros
reference/program-addresses— endereços de autoridade canônicos.security/attack-vectors— como comprometimentos de admin se manifestam.ray/treasury— endereços de treasury e coleta de taxas.security/disclosure— reportando problemas suspeitos de admin.
- Squads Protocol — UI de multisig.
- Documentação de programa e loader do Solana — o mecanismo de upgrade e como revogar a autoridade de upgrade torna um programa imutável.