Chaves de administrador e multisig

A superfície de autoridade em todos os programas Raydium — o que cada administrador pode fazer, como a multisig é estruturada e como verificar on-chain quem atualmente detém cada função.

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

Função	Endereço de autoridade	O que pode fazer
Upgrade de programa	Squads multisig (3/4)	Implantar novo bytecode do programa
Admin de pool	Treasury multisig (3/5)	Alternar status do pool, atualizar taxas em pools existentes

​

CPMM

Função	Endereço de autoridade	O que pode fazer
Upgrade de programa	Squads multisig (3/4)	Implantar novo bytecode do programa
Admin de AmmConfig	Treasury multisig (3/5)	Criar novas AmmConfigs (níveis de taxa); alternar as existentes
Destinatário de taxa de criação de pool	Treasury multisig (3/5)	Receber a taxa única de criação de pool
Criador de Permission-PDA	Program admin ou um proprietário dedicado de create-permission-PDA (valor diferente em mainnet vs devnet)	Chamar CreatePermissionPda para conceder a uma autoridade acesso a InitializeWithPermission. Desde o upgrade 2026-09, o proprietário dedicado também pode chamar ClosePermissionPda, portanto concede e revoga; antes desse upgrade a revogação era apenas para admin.

A coleta de taxa de 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

Função	Endereço de autoridade	O que pode fazer
Upgrade de programa	Squads multisig (3/4)	Implantar 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 optar por usar
Coletor de lamports em excesso	Program admin ou uma carteira dedicada de coleta de lamports (valor diferente em mainnet vs devnet)	CollectExcessLamports: varrer lamports acima do mínimo isento de aluguel de um PoolState do pool e vaults, além de qualquer PDA de propriedade de CLMM passado. Move apenas lamports, nunca saldos de tokens, e não pode fechar contas. Adicionado em 2026-09-30.
limit_order_admin (em nível de programa)	Carteira operacional quente off-chain, não uma multisig	Liquidar e fechar ordens limitadas em nome de seus proprietários. A chave do keeper é uma constante única em nível de programa (valor diferente em mainnet vs devnet), verificada via signer == limit_order.owner || signer == limit_order_admin::ID em SettleLimitOrder / CloseLimitOrder. A saída sempre vai para o ATA original do proprietário; o keeper não pode redirecionar fundos, modificar ordens ou abrir novas.

Criar pools adicionais para um par em um endereço derivado de seed_index (CreateCustomizablePoolV2) não requer nenhuma função. Antes do upgrade 2026-10-22 era necessária uma PDA Permission emitida por uma chave dedicada permission_pda_admin; essa função, a conta Permission e suas duas instruções de admin foram removidas.

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 (reside 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).

Não pode chamar OpenLimitOrder, IncreaseLimitOrder, DecreaseLimitOrder, mutar nenhum campo de pool ou assinar qualquer outra instrução — essas verificações são aplicadas on-chain pela seed e restrições 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 algum além de onde o proprietário já os autorizou.

​

Farm v6

Função	Endereço de autoridade	O que pode fazer
Upgrade de programa	Squads multisig (3/4)	Implantar novo bytecode do programa
Criador de farm (por farm)	Carteira criadora do farm	Financiar vaults de recompensa, estender cronogramas, recuperar recompensas não utilizadas

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 mint de staking).

​

LaunchLab

Função	Endereço de autoridade	O que pode fazer
Upgrade de programa	Squads multisig (3/4)	Implantar novo bytecode do programa
Admin de programa	Admin Raydium compartilhado	Criar e atualizar contas GlobalConfig; operar outros caminhos apenas para admin
Criador de config delegado	Autoridade específica de cluster dedicada	Criar um novo GlobalConfig; não pode atualizar uma config existente
Admin de plataforma	Autoridade de seed de PDA para um PlatformConfig	Atualizar configurações de plataforma e criar ou fechar contas PlatformAllowConfig dessa plataforma
Criador de launch (por launch)	Carteira criadora do launch	Reivindicar taxas de criador de curva de ligação; recebe direitos de taxa de criador CPMM apenas quando a plataforma não substitui platform_cp_creator

A lista de permissões de admin de 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ônica vivem em reference/program-addresses.

​

Autoridade de upgrade de 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 dispositivo frio 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. 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 desvio 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 qualquer um deles está dormindo:

Programa	Última implantação (mainnet)
LaunchLab	2026-09-02
CPMM / CLMM / AMM Routing	2026-08-17
AMM v4	2026-07-22
Stable AMM	2026-06-22
Lock (Burn & Earn)	2025-08-23
Farm v6	2024-05-13

(Da conta ProgramData de cada programa; solana program show <PROGRAM_ID> relata o mesmo slot.)

​

Autoridade de AmmConfig

Cada criação de novo AmmConfig é permissionada — a multisig treasury 3/5 autoriza novos níveis de taxa e espaçamentos de tick. Pools existentes referenciam seu AmmConfig por PDA; o nível 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 silenciosamente a economia de todos os pools usando essa config. 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 de taxa de protocolo; esse é um endereço imutável separado por pool.

​

Reivindicação de taxa de protocolo

Uma porção de taxas de swap (tipicamente 3–12 bps de 25 bps de taxa de swap, dependendo da config) se 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 parte pré-alocada do protocolo, não dinheiro de LP.

​

Autoridade de criador de farm

Farms v6 dão ao criador o poder de:

• Financiar o vault de recompensa (adicionar mais tokens).
• Estender o cronograma (empurrar tempo de término mais tarde).
• Chamar withdrawReward após o tempo de término para recuperar saldo de vault não utilizado.

Criadores de farm não podem:

• Sacar LP de stake de usuário.
• Alterar o mint de staking.
• Alterar taxas de emissão retroativamente (apenas prospectivamente via setRewards).
• Congelar harvests de usuário.

Um criador de farm malicioso pode no máximo sub-financiar o vault para que o farm seque; o stake principal do usuário está sempre seguro.

​

Configuração de 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.

Multisig	Limite	Timelock	Escopo
Upgrade de programa	3/4	24 horas	Autoridade única para implantar novo bytecode de programa para AMM v4, CPMM, CLMM, LaunchLab, Lock, AMM Routing, Stable Swap e os programas legados Farm/Staking. Visualizar em app.squads.so/.../FytDr…ceZQK.
Treasury	3/5	nenhum	Ativos de treasury, receita de protocolo, despesas operacionais. Também detém a autoridade limitada de admin de programa Raydium (criando AmmConfigs, varrendo taxas de protocolo, configurando parâmetros de pool) por enquanto. Visualizar em v3.squads.so/dashboard/RVha…dHdtYz09.

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 após um dispositivo frio gerar e assinar 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.

A multisig de treasury não tem timelock — seu escopo é mais estreito e ops rotineiras (criar AmmConfigs, varrer taxas) precisam chegar no mesmo dia. A multisig de treasury também detém a autoridade limitada de admin de programa listada nas tabelas por programa acima; este é um arranjo interim e é revisado periodicamente com os parceiros de segurança do projeto.

​

Verificando autoridade on-chain

A forma mais simples de verificar a autoridade de upgrade atual de um programa:

solana program show <PROGRAM_ID>

A saída inclui:

Program Id:          CPMMoo8L3F4NbTegBCKVNunggL7H1ZpdTHKxQB5qKP1C
Owner:               BPFLoaderUpgradeab1e11111111111111111111111
ProgramData Address: <ProgramDataPDA>
Authority:           <EXPECTED_MULTISIG_ADDRESS>
Last Deployed In Slot: <slot>
Data Length: <n> bytes

Se Authority não for o endereço multisig Squads esperado, algo está errado. Raydium publica os endereços de autoridade esperados em reference/program-addresses.

Para funções de admin de AmmConfig / pool, busque a conta on-chain e decodifique:

import { CpmmConfigInfoLayout } from "@raydium-io/raydium-sdk-v2";

const info = await connection.getAccountInfo(configPda);
const config = CpmmConfigInfoLayout.decode(info!.data);
console.log("protocol owner:", config.protocolOwner.toBase58());
console.log("fund owner:",     config.fundOwner.toBase58());

AmmConfig não possui um campo admin — o admin do programa é uma chave pública compilada no programa (crate::admin::ID), e as autoridades operacionais por configuração são protocolOwner / fundOwner. A autoridade de upgrade BPF é uma preocupação separada no nível do loader; leia-a com solana program show.

​

Histórico de mudanças de autoridade

Data	Programa	Mudança
2022-12	AMM v4	Autoridade de upgrade migrada de single-sig para multisig 3/4 após incidente
2023-02	Todos os programas	Todos os papéis operacionais unificados sob multisig de tesouro 3/5
2023-11	CLMM	Adicionado segundo multisig para operações apenas de recompensas para reduzir exposição
2024-05	CPMM	Deploy inicial com autoridade multisig desde o primeiro dia

​

Considerações do lado do usuário

O que você deve fazer como usuário/LP/integrador?

1. Verifique a autoridade de upgrade antes de alocações grandes. Confirme que corresponde ao multisig documentado.
2. Monitore a atividade do multisig. Squads UI mostra transações pendentes; um upgrade agendado lhe dá 24 horas para se desfazer se discordar da mudança.
3. Estratégias de resgate cientes de time-lock. Se você estiver executando um auto-compounder, certifique-se de que seu caminho de unwinding não requer uma instrução que está sendo alterada.
4. 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ê hardcodificar a autoridade de upgrade ou o endereço multisig de admin no seu código e ele rotacionar depois, sua verificação falha. Busque de reference/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 configuração periodicamente (a cada hora está bom).

​

3. Vetores de grief de 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 recompensas (assumindo que nenhum usuário tenha feito stake ainda). Uma vez que usuários tenham feito stake, as alocações pro-rata são aplicadas pelo programa; a recuperação apenas obtém o restante após o encerramento racional.

​

Referências

• reference/program-addresses — endereços de autoridade canônicos.
• security/attack-vectors — como comprometimentos de admin se manifestam.
• ray/treasury — endereços de tesouro e coleta de taxas.
• security/disclosure — reportando problemas de admin suspeitos.

Fontes:

• Squads Protocol — UI multisig.
• Solana program & loader docs — o mecanismo de upgrade e como revogar a autoridade de upgrade torna um programa imutável.