Ir para o conteúdo
Financial Context Wiki

Rotação de signatários multissig

Um procedimento centrado em verificação para substituir signatários multissig preservando o quórum, conferindo o conjunto de proprietários e o limite exatos on-chain e respondendo com segurança a uma chave comprometida.

Atualizado

Somente para fins educacionais; não constitui aconselhamento financeiro, jurídico ou de segurança. Um erro na rotação pode transferir o controle, invalidar aprovações pendentes ou bloquear permanentemente uma conta multissig.

Resposta direta

A rotação de signatários multissig altera as contas autorizadas a aprovar transações. Em geral, não exige um novo endereço de carteira nem a transferência de ativos: uma transação privilegiada altera o conjunto de proprietários da conta e, às vezes, o limite de aprovação. As implementações variam, portanto verifique o contrato implantado e o estado on-chain atual em vez de presumir que os rótulos da interface descrevem corretamente os poderes.

Uma rotação segura comprova primeiro o controle de cada novo signatário, preserva durante toda a mudança um quórum executável mas não concentrado, remove o signatário antigo e verifica o estado final on-chain. Perder o quórum exigido antes da execução pode impossibilitar uma rotação comum de proprietários; reduzir o limite por conveniência pode criar uma janela de tomada de controle.

A pessoa, o dispositivo de assinatura, a chave privada e o endereço do proprietário on-chain são registros distintos. Documente o endereço exato, o custodiante, o domínio de controle independente, a situação do backup e o motivo da rotação. Nenhuma rotação legítima exige que alguém revele uma frase-semente ou uma chave privada.

Como funciona

  1. Inventarie os poderes atuais. A partir de uma chain e de um endereço de conta verificados de forma independente, leia a implementação implantada, a lista de proprietários, o limite, o nonce, os módulos habilitados, os guards, o fallback handler, o caminho de recuperação e qualquer timelock. Um módulo ou mecanismo de recuperação pode executar fora do limite comum dos proprietários, enquanto um guard restritivo pode bloquear uma rotação que seria válida.
  2. Defina o estado desejado antes de assinar. Registre o conjunto exato de proprietários e o limite depois da mudança. Confirme que o limite não excede o número de proprietários e que pelo menos essa quantidade de signatários independentes continuará operacional. Separação geográfica não é independência se uma pessoa, um cofre de senhas, uma conta em nuvem ou um administrador controla todos os dispositivos.
  3. Cadastre e autentique o novo signatário. Gere ou restaure a nova chave no ambiente de custódia previsto, verifique o endereço em um dispositivo confiável e comprove o controle por um desafio acordado ou uma assinatura de teste. Confirme o endereço por um segundo canal autenticado; não dependa apenas de texto copiado de uma conversa ou da interface da carteira.
  4. Escolha uma ordem com estados intermediários seguros. Alguns contratos conseguem substituir um proprietário atomicamente. A Safe, por exemplo, expõe swapOwner; também expõe addOwnerWithThreshold, removeOwner e changeThreshold. Se uma implementação precisar de várias transações, analise o conjunto de proprietários e o limite depois de cada etapa. Adicione e verifique capacidade antes de removê-la, a menos que um comprometimento ativo torne essa ordem insegura.
  5. Decodifique e simule a transação exata. Confira de forma independente chain ID, endereço da conta, target, seletor da função, endereços antigo e novo do proprietário, limite resultante, nonce, value e tipo de operação. Trate delegatecall, processamento em lote, mudanças de módulo e mudanças de guard como efeitos separados de alto risco. Cada signatário deve aprovar o mesmo payload decodificado e o mesmo hash da transação.
  6. Execute com os poderes existentes. O quórum válido atual autoriza a rotação, salvo se um caminho de recuperação documentado disser o contrário. Em uma emergência, coordene apenas por contatos autenticados e use signatários não comprometidos. Se nem o quórum normal nem uma autoridade de recuperação pré-configurada estiverem disponíveis, uma chamada padrão de gestão de proprietários não poderá restaurar o acesso.
  7. Verifique e encerre a mudança. Após a confirmação, consulte diretamente o conjunto de proprietários e o limite, inspecione os eventos emitidos ou traces conforme a implementação e confirme que o endereço antigo não está mais autorizado. Faça o novo signatário participar de uma transação aprovada, de baixo risco ou valor zero, que exija o limite pretendido. Revise transações pendentes, revogue acessos off-chain e backups do antigo signatário e arquive a proposta, as assinaturas, o hash da transação, o bloco e o estado final.

Exemplo prático

Suponha que uma conta 3-of-5 tenha os proprietários A, B, C, D e E, e que B precise ser substituído por F. Primeiro, a equipe verifica se F controla o endereço exato proposto e continua independente dos demais proprietários. Para uma implantação compatível da Safe, prepara swapOwner(prevOwner, B, F). A chamada é uma transação Safe e, portanto, precisa de 3 confirmações válidas do conjunto atual de proprietários. O resultado decodificado deve preservar um total de 5 proprietários e um limite de 3.

Depois que a transação é confirmada, a equipe lê getOwners e getThreshold, verifica que B está ausente e F presente e faz F e outros dois proprietários executarem um teste aprovado com valor 0. Também revisa as transações pendentes: uma assinatura ou pré-aprovação de B pode deixar de satisfazer as verificações de proprietário após a remoção. As propostas afetadas devem ser canceladas ou reconstruídas, e não presumidas executáveis.

Se B puder estar comprometido, a equipe não pede que ele aprove a remoção. Outros três proprietários não comprometidos executam a substituição e depois inspecionam módulos, permissões de recuperação, allowances, session keys e transações já executadas, pois remover B não reverte ações anteriores nem revoga poderes concedidos por outro caminho. Se menos de 3 proprietários não comprometidos estiverem disponíveis, apenas um caminho de recuperação ou administração configurado previamente poderá ajudar; compartilhar frases-semente ou confiar em um serviço de “recuperação” não solicitado não substitui o quórum.

Riscos e controles

  • Conta ou endereço errado. Verifique chain ID, endereço multissig, implementação e endereço do novo proprietário em dispositivos e fontes independentes. Envenenamento de endereço e erros de cópia podem dar o controle a um invasor.
  • Perda de quórum. Modele cada estado intermediário. Remover cedo demais um proprietário, elevar o limite acima dos signatários disponíveis ou girar juntos vários dispositivos correlacionados pode inutilizar a conta.
  • Concentração temporária. Um limite menor ou um signatário recém-adicionado pode criar um período em que menos partes controlam a conta. Prefira uma substituição atômica quando houver suporte e não reduza o limite apenas para simplificar a cerimônia.
  • Custódia correlacionada. Endereços diferentes não são independentes quando suas sementes, dispositivos, backups, comunicações ou administradores compartilham um mesmo domínio de falha. Teste a recuperação sem centralizar segredos.
  • Poder oculto. Módulos, guards, fallback handlers, session keys, timelocks e contratos de recuperação podem contornar ou bloquear o caminho dos proprietários. Inventarie e verifique esses elementos antes e depois da rotação.
  • Corrida com o signatário comprometido. Antes da confirmação da remoção, um signatário suspeito pode se antecipar, retirar ativos, mudar a configuração ou aprovar outra transação. Use procedimentos de resposta a incidentes, envio privado de transações quando adequado e monitoramento contínuo do estado; não presuma que uma transação enviada venceu a corrida.
  • Aprovações pendentes obsoletas. Mudanças nos proprietários e no limite podem invalidar assinaturas coletadas ou alterar quais aprovações bastam. Reavalie cada transação na fila contra o estado final e cancele propostas obsoletas.
  • Falsa conclusão. Uma notificação de sucesso da interface não comprova o estado pretendido. Aguarde a política de confirmação exigida, depois leia o estado do contrato e verifique o payload da transação, os eventos e o resultado da execução.
  • Desligamento incompleto. Remover um proprietário on-chain não apaga chaves copiadas, acessos organizacionais, credenciais de relayer, entradas no cofre de senhas nem poderes em outros contratos e chains. Revogue cada item separadamente e mantenha uma trilha de auditoria.

Erros comuns

  • “Rotação significa mover todos os ativos para uma carteira nova.” Muitas multissigs de contas inteligentes atualizam os proprietários no mesmo endereço da conta. Migração é outra operação e pode ser exigida somente por determinada implementação ou plano de incidente.
  • “Adicionar primeiro o novo signatário é sempre seguro.” Isso protege a disponibilidade, mas pode ampliar temporariamente o conjunto autorizado. Durante um comprometimento ativo, uma substituição atômica ou outra sequência emergencial pode ser mais segura.
  • “Um limite 3-of-5 significa que quaisquer três pessoas nomeadas estão disponíveis.” O contrato conta contas válidas de proprietários, não pessoas, departamentos ou dispositivos. Custódia compartilhada e chaves inacessíveis reduzem a independência e a disponibilidade efetivas.
  • “Remover um proprietário comprometido desfaz o dano.” Depois da confirmação, a remoção impede o uso futuro daquele caminho de proprietário; não reverte transações executadas nem revoga permissões criadas em outro lugar.
  • “A interface da carteira é prova suficiente.” Interfaces e serviços de indexação podem estar desatualizados, mal configurados ou ser maliciosos. Decodifique a transação e leia o estado final do contrato por um endpoint verificado de forma independente.
  • “Sem quórum, o suporte pode redefinir a carteira.” Uma multissig de autocustódia só possui os caminhos de autoridade codificados ou configurados previamente on-chain. Sem um quórum válido ou caminho de recuperação, o acesso pode ser perdido de forma permanente.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...