---
title: "Rotação de signatários multissig"
description: "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."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Rotação de signatários multissig
> 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
- [Carteira de hardware](/pt-br/crypto/hardware-wallet/)
- [Carteira multissig](/pt-br/crypto/multisig-wallet/)
- [Gestão de chaves privadas](/pt-br/crypto/private-key-management/)
- [Risco de recuperação do proprietário de conta inteligente](/pt-br/crypto/smart-account-owner-recovery-risk/)
- [Simulação de transações](/pt-br/crypto/transaction-simulation/)
## Fontes
- [Como funcionam as contas inteligentes Safe?](https://docs.safe.global/advanced/smart-account-overview) - Safe Documentation (acessado em: 2026-08-21)
- [addOwnerWithThreshold](https://docs.safe.global/reference-smart-account/owners/addOwnerWithThreshold) - Safe Documentation (acessado em: 2026-08-21)
- [removeOwner](https://docs.safe.global/reference-smart-account/owners/removeOwner) - Safe Documentation (acessado em: 2026-08-21)
- [swapOwner](https://docs.safe.global/reference-smart-account/owners/swapOwner) - Safe Documentation (acessado em: 2026-08-21)
- [changeThreshold](https://docs.safe.global/reference-smart-account/owners/changeThreshold) - Safe Documentation (acessado em: 2026-08-21)
- [OwnerManager.sol](https://github.com/safe-fndn/safe-smart-account/blob/main/contracts/base/OwnerManager.sol) - Safe Ecosystem Foundation (acessado em: 2026-08-21)
- [Recomendação para gestão de chaves: Parte 1 - Geral](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final) - NIST (acessado em: 2026-08-21)
Source: https://wiki.fcontext.com/pt-br/crypto/multisig-signer-rotation/index.mdx