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 →
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 (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 (o 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 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 do admin da plataforma é auto-restritiva: limita quais contas GlobalConfig os 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 mantidos por membros do time principal. A assinatura sequencial impede aprovações paralelas na mesma transação; as transações têm 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 os programas precisam ser atualizáveis (para corrigir bugs, adicionar extensões como Token-2022, corrigir desvios de integração). Trade-off: os usuários confiam que a multisig 3/4 só implantará upgrades bem revisados. Para usuários que querem uma alternativa imutável, o programa AMM v4 mais antigo tem sido estável desde seu último audit; zero upgrades em 18 meses. Esse caminho de código é efetivamente congelado mesmo que a autoridade ainda exista.

Autoridade do AmmConfig

Cada criação de novo AmmConfig é permissionada — a multisig treasury 3/5 autoriza novos níveis de taxa e espaçamentos de tick. Os pools existentes referenciam seu AmmConfig por PDA; o nível de taxa do pool é o que o AmmConfig diz. Os admins 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 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.

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) se acumula em um cofre de taxa de protocolo. A multisig pode sacar essas taxas acumuladas. Os usuários nunca veem seu saldo de LP mudar por isso — é a parte 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 cofre de recompensa (adicionar mais tokens).
  • Estender o cronograma (empurrar o tempo final mais tarde).
  • Chamar withdrawReward após o tempo final para recuperar o saldo não utilizado do cofre.
Criadores de farm não podem:
  • Sacar LP de stake do usuário.
  • Alterar o mint de staking.
  • Alterar taxas de emissão retroativamente (apenas prospectivamente via setRewards).
  • Congelar colheitas de usuários.
Um criador de farm malicioso pode no máximo sub-financiar o cofre para que o farm seque; o stake principal do usuário está sempre seguro.

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 é executado não antes de 24 horas depois, dando aos usuários tempo para responder.
  • Assinatura de dispositivo frio isolado. 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 do treasury não tem timelock — seu escopo é mais estreito e ops rotineiras (criar AmmConfigs, varrer taxas) precisam chegar no mesmo dia. A multisig do 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:
A saída inclui:
Se 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:

Mudanças históricas de autoridade

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 grandes alocações. Confirme que corresponde à multisig documentada.
  2. Monitore a atividade da multisig. A UI do Squads 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ê está 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ê 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 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 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 encerrar o farm cedo e recuperar o cofre de recompensa (assumindo que nenhum usuário tenha feito stake ainda). Uma vez que usuários tenham feito stake, os direitos pro-rata são aplicados pelo programa; a recuperação apenas obtém o restante após o término racional.

Referências

Fontes: