Documentation Index
Fetch the complete documentation index at: https://docs.raydium.io/llms.txt
Use this file to discover all available pages before exploring further.
Todo programa da Raydium possui ao menos um papel privilegiado — uma chave capaz de atualizar o programa, criar novas configs ou sacar taxas de protocolo. Minimizar o que esses papéis podem fazer (e protegê-los com multisigs e delays) é a principal defesa contra um admin comprometido. Esta página cataloga os papéis e como eles são protegidos na prática.
Papéis por programa
AMM v4
| Papel | Endereço da autoridade | O que pode fazer |
|---|
| Atualização do programa | Squads multisig (3/4) | Publicar novo bytecode do programa |
| Admin de pool | Treasury multisig (3/5) | Alternar status de pool, atualizar taxas em pools existentes |
CPMM
| Papel | Endereço da autoridade | O que pode fazer |
|---|
| Atualização do programa | Squads multisig (3/4) | Publicar novo bytecode do programa |
| Admin de AmmConfig | Treasury multisig (3/5) | Criar novos AmmConfigs (níveis de taxa); alternar os existentes |
| Destinatário da taxa de criação de pool | Treasury multisig (3/5) | Receber a taxa única de criação de pool |
CLMM
| Papel | Endereço da autoridade | O que pode fazer |
|---|
| Atualização do programa | Squads multisig (3/4) | Publicar novo bytecode do programa |
| Admin de AmmConfig | Treasury multisig (3/5) | Criar/modificar AmmConfigs |
| Admin de DynamicFeeConfig | Treasury multisig (3/5) | CreateDynamicFeeConfig / UpdateDynamicFeeConfig — calibrar os níveis de taxa dinâmica que uma chamada CreateCustomizablePool pode adotar |
limit_order_admin (em nível de programa) | Hot wallet operacional off-chain, não um multisig | Liquidar e fechar limit orders em nome de seus donos. A chave do keeper é uma constante única em todo o programa (valor diferente em mainnet vs devnet), verificada via signer == limit_order.owner || signer == limit_order_admin::ID em SettleLimitOrder / CloseLimitOrder. O resultado sempre vai para a ATA do dono original; o keeper não pode redirecionar fundos, modificar ordens nem abrir novas. |
limit_order_admin é um papel operacional deliberadamente limitado. Ele existe para que um keeper off-chain possa processar ordens preenchidas sem que o dono da ordem precise estar online. A chave do keeper é hot (reside na VM do keeper) e é rotacionada independentemente dos multisigs acima. Em termos concretos, a autoridade do keeper se restringe a:
SettleLimitOrder — enviar o resultado preenchido de uma ordem para a ATA do dono pelo preço limite da ordem.CloseLimitOrder — fechar a conta de uma ordem totalmente liquidada para recuperar o rent (o rent vai para o dono da ordem).
Ele não pode chamar OpenLimitOrder, IncreaseLimitOrder, DecreaseLimitOrder, alterar nenhum campo de pool nem 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 pior caso, ficar indisponível (as ordens permanecem pausadas até que o dono as liquide manualmente) ou liquidar/fechar ordens legitimamente preenchidas fora de ordem; ele não pode mover os fundos do usuário para outro lugar que não seja o destino já autorizado pelo dono.
Farm v6
| Papel | Endereço da autoridade | O que pode fazer |
|---|
| Atualização do programa | Squads multisig (3/4) | Publicar novo bytecode do programa |
| Criador do farm (por farm) | A carteira criadora do farm | Financiar vaults de recompensa, estender cronogramas, recuperar recompensas não utilizadas |
LaunchLab
| Papel | Endereço da autoridade | O que pode fazer |
|---|
| Atualização do programa | Squads multisig (3/4) | Publicar novo bytecode do programa |
| Criador do launch (por launch) | A carteira criadora do launch | Coletar taxas do criador após a graduação; sacar o saldo remanescente da curva não graduada |
Autoridade de atualização do programa
Os programas da Raydium utilizam o mecanismo padrão de atualização do BPF Loader v3 do Solana. A autoridade de atualização de todos os programas é o Squads multisig 3/4.
Por que 3/4: signatários suficientes para que um único comprometimento não seja suficiente; poucos o bastante para que uma atualização legítima seja viável. As quatro autoridades são signatários independentes em dispositivos cold air-gapped, mantidos por membros do time central. A assinatura sequencial impede aprovações paralelas na mesma transação; as transações carregam uma janela de expiração fixa. As operações do multisig são revisadas periodicamente em parceria com o Programa STRIDE da Solana (Asymmetric Research).
Removendo a autoridade de atualização
A Raydium não definiu a autoridade de atualização de nenhum programa como nula. O protocolo opera sob o princípio de que os programas precisam ser atualizáveis (para corrigir bugs, adicionar extensões como Token-2022, resolver drifts de integração). A contrapartida: os usuários confiam que o multisig 3/4 publicará apenas atualizações bem revisadas.
Para usuários que preferem uma alternativa imutável, o programa AMM v4 mais antigo está estável desde sua última auditoria; sem atualizações em 18 meses. Esse caminho de código está efetivamente congelado, mesmo que a autoridade ainda exista.
Autoridade de AmmConfig
A criação de cada novo AmmConfig é permissionada — o treasury multisig 3/5 autoriza novos níveis de taxa e tick spacings. Pools existentes referenciam seu AmmConfig pelo PDA; o nível de taxa do pool é o que o AmmConfig define.
Os admins podem alterar um AmmConfig existente? Sim, tecnicamente. updateAmmConfig pode ser chamado pelo admin. Na prática, modificações em AmmConfigs já publicados são evitadas porque alteram silenciosamente a economia de todos os pools que utilizam aquela config. A política do protocolo é criar um novo AmmConfig para qualquer mudança e migrar.
Os admins 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.
Coleta de taxas de protocolo
Uma parte 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. O multisig pode sacar essas taxas acumuladas. Os usuários nunca veem seu saldo de LP mudar com isso — é a cota pré-alocada do protocolo, não dinheiro do LP.
Autoridade do criador de farm
Os Farms v6 concedem ao criador o poder de:
- Financiar o vault de recompensa (adicionar mais tokens).
- Estender o cronograma (adiar o tempo de término).
- Chamar
withdrawReward após o término para recuperar o saldo não utilizado do vault.
Criadores de farm não podem:
- Sacar o LP de usuários em stake.
- Alterar o mint de staking.
- Alterar taxas de emissão retroativamente (apenas prospectivamente via
setRewards).
- Congelar os harvests dos usuários.
Um criador de farm malicioso pode, no pior caso, subfinanciar o vault para que o farm se esgote; o principal em stake dos usuários está sempre seguro.
Configuração do Squads multisig
A Raydium opera dois Squads multisigs separados para superfícies de risco distintas. Ambos podem ser inspecionados on-chain pela interface do Squads Protocol.
| Multisig | Threshold | Timelock | Escopo |
|---|
| Atualização de programa | 3/4 | 24 horas | Autoridade exclusiva para publicar novo bytecode para AMM v4, CPMM, CLMM, LaunchLab, Lock, AMM Routing, Stable Swap e os programas legados de Farm/Staking. Visualize em app.squads.so/.../FytDr…ceZQK. |
| Treasury | 3/5 | nenhum | Ativos do tesouro, receita do protocolo, despesas operacionais. Também detém a autoridade limitada de admin de programa da Raydium (criação de AmmConfigs, coleta de taxas de protocolo, configuração de parâmetros de pool) por ora. Visualize em v3.squads.so/dashboard/RVha…dHdtYz09. |
- Timelock de 24 horas em qualquer transação. Uma atualização aprovada hoje só será executada após 24 horas, dando tempo aos usuários para reagir.
- Assinatura em dispositivos cold air-gapped. Os dispositivos cold têm placas de rede fisicamente removidas; eles se conectam apenas a uma hardware wallet e leem dados de transação via QR code de um dispositivo hot separado.
- Assinatura sequencial. Somente após um dispositivo cold gerar e assinar uma transação o próximo dispositivo cold pode iniciar seu processo de assinatura — evitando assinaturas conflitantes ou paralelas na mesma transação.
- Expiração de transação. Toda transação carrega uma janela de expiração fixa, fazendo com que transações obsoletas sejam invalidadas automaticamente.
- Aplicação de TOTP + chave física nos dispositivos hot usados para iniciar transações e transmiti-las on-chain.
- Fila de transações pública. Qualquer pessoa pode monitorar atualizações pendentes pela interface do Squads.
O treasury multisig não tem timelock — seu escopo é mais restrito e operações rotineiras (criar AmmConfigs, coletar taxas) precisam ser finalizadas no mesmo dia. O treasury multisig também detém a autoridade limitada de admin de programa listada nas tabelas por programa acima; esse é um arranjo temporário e é revisado periodicamente com os parceiros de segurança do projeto.
Verificando a autoridade on-chain
A forma mais simples de verificar a autoridade de atualização atual de um programa:
solana program show <PROGRAM_ID>
Program Id: CPMMoo8L3F4NbTegBCKVNunggL7H1Zpdmwpwh8KMoZ0F
Owner: BPFLoaderUpgradeab1e11111111111111111111111
ProgramData Address: <ProgramDataPDA>
Authority: <EXPECTED_MULTISIG_ADDRESS>
Last Deployed In Slot: <slot>
Data Length: <n> bytes
Authority não for o endereço do Squads multisig esperado, algo está errado. A Raydium publica os endereços de autoridade esperados em reference/program-addresses.
Para papéis de AmmConfig / admin de pool, busque a conta on-chain e decodifique:
const config = await raydium.cpmm.getAmmConfig(configPda);
console.log("AmmConfig admin:", config.admin.toBase58());
// Esperado: treasury multisig 3/5.
Histórico de mudanças de autoridade
| Data | Programa | Mudança |
|---|
| 2022-12 | AMM v4 | Autoridade de atualização migrada de single-sig para multisig 3/4 após incidente |
| 2023-02 | Todos os programas | Todos os papéis operacionais unificados sob o treasury multisig 3/5 |
| 2023-11 | CLMM | Adicionado segundo multisig para operações exclusivas de recompensa, reduzindo a exposição |
| 2024-05 | CPMM | Deploy inicial com autoridade multisig desde o primeiro dia |
Considerações para o usuário
O que você deve fazer como usuário/LP/integrador?
- Verifique a autoridade de atualização antes de grandes alocações. Confirme que ela corresponde ao multisig documentado.
- Monitore a atividade do multisig. A interface do Squads exibe transações pendentes; uma atualização agendada lhe dá 24 horas para desfazer posições caso discorde da mudança.
- Estratégias de resgate cientes do timelock. Se você opera um auto-compounder, certifique-se de que seu caminho de saída não depende de uma instrução que está sendo alterada.
- Não presuma imutabilidade do programa. Todo programa da Raydium pode ser atualizado; planeje para isso.
Armadilhas para integradores
1. Cache de endereços de autoridade
Se você fixar no código o endereço da autoridade de atualização ou do multisig admin e ele for rotacionado posteriormente, sua verificação falhará. Busque em reference/program-addresses em tempo de execução ou atualize periodicamente.
2. Supor que AmmConfigs são estáveis
Um novo AmmConfig pode ser criado a qualquer momento. Seu aggregator/router deve rebuscar a lista completa de configs periodicamente (de hora em hora é suficiente).
3. Vetores de ataque do criador de farm
Se você estiver depositando em um farm de baixa reputação, o criador pode encerrar o farm antecipadamente e recuperar o vault de recompensa (assumindo que nenhum usuário ainda tenha feito stake). Uma vez que usuários tenham feito stake, os direitos proporcionais são aplicados pelo programa; a recuperação pega apenas o saldo restante após o término racional.
Referências
Fontes:
