Risco do proprietário e da recuperação de uma conta inteligente

Audite quem pode controlar uma conta inteligente, como a recuperação troca o proprietário, quais atrasos e direitos de cancelamento se aplicam e se módulos ou upgrades criam caminhos ocultos de tomada de controle.

Somente para fins educacionais; não constitui aconselhamento financeiro, jurídico ou de segurança. Um erro de recuperação ou configuração pode transferir o controle de uma conta inteligente ou bloqueá-la permanentemente.

Resposta direta

Uma conta inteligente é controlada pela lógica de autorização implantada para ela, não necessariamente por uma única chave privada. Um proprietário ou validador pode aprovar operações comuns, enquanto um guardião, módulo de recuperação, executor ou administrador de upgrade pode ter outro caminho para substituir o proprietário ou executar transações.

A recuperação reduz a chance de uma chave perdida inutilizar a conta, mas acrescenta uma superfície de tomada de controle. Audite todos os caminhos capazes de autorizar execução, trocar validadores ou proprietários, instalar módulos, atualizar código ou cancelar e finalizar a recuperação. Rótulos da interface como “proprietário” e “guardião” não comprovam a autoridade real do contrato.

Registre o resultado numa tabela de permissões: endereço on-chain exato, função, ação chamável, limite, atraso, autoridade de cancelamento, expiração, escopo de gastos, autoridade de upgrade e domínio de controle independente. Confira novamente após cada mudança e em cada rede onde a conta exista.

Como funciona

Identifique a conta e o código. Verifique o ID da rede e o endereço; determine implementação, proxy ou beacon, fábrica e versão. Num proxy ERC-1967, leia os slots de implementação, beacon e administrador em vez de confiar num selo da interface.
Enumere os caminhos de autorização. Leia proprietários e limites, validadores ERC-4337, validadores, executores, hooks e fallback handlers ERC-7579, módulos e guards tipo Safe, chaves de sessão, contratos de recuperação e administradores de emergência ou upgrade. Um executor ou módulo Safe pode executar sem o limite normal.
Decodifique a máquina de estados da recuperação. Determine quem indica o substituto, como aprovações são contadas e expiram, quando o atraso começa, quem cancela, quem finaliza e o que ocorre se a recuperação for substituída ou repetida. Nem todo contrato de “recuperação social” segue a mesma sequência.
Teste independência e disponibilidade. Endereços diferentes não são independentes se um dispositivo, pessoa, conta de nuvem, cofre de senhas, custodiante ou administrador os controla. Confirme que o limite ainda pode ser atingido após uma falha esperada sem dar a um domínio poder suficiente para tomar a conta.
Revise a autoridade de configuração. Determine quem adiciona ou remove guardião, validador, executor, hook, módulo ou fallback handler; muda limite ou atraso; suspende cancelamento; ou atualiza conta e recuperação. Um timelock só ajuda se outro papel não puder contornar atraso e cancelamento.
Monitore e verifique. Assine ou consulte de modo independente mudanças em recuperação, proprietário, módulo, limite, implementação e administrador. Após qualquer operação, decodifique a transação e confira recibos, eventos, armazenamento e proprietários finais na rede correta; a mensagem de sucesso não basta.

Exemplo prático

Suponha uma conta com proprietário O e três guardiões G1, G2 e G3. Quaisquer 2-of-3 guardiões podem propor o novo proprietário N; começa um atraso de 24-hour; O pode cancelar durante ele; e qualquer pessoa pode finalizar depois. O módulo pode chamar a troca de proprietário sem aprovação de O na transação final.

Os rótulos sugerem recuperação distribuída, mas G1 e G2 são aplicativos salvos na mesma conta de nuvem. Comprometer essa credencial dá a um atacante o limite efetivo 2-of-3. Ele propõe N; se monitoramento ou cancelamento falhar por 24 hours, a finalização transfere o controle mesmo sem roubar a chave privada de O.

A auditoria marca G1 e G2 como um domínio, verifica endereço e código do módulo, testa cancelamento num dispositivo seguro, confirma o evento que inicia o atraso e confere se um administrador pode substituir o módulo imediatamente. Não faz recuperação real na conta com ativos sem processo de teste documentado e reversível com segurança.

Riscos e controles

Guardiões correlacionados: use dispositivos, credenciais, pessoas ou custodiantes realmente independentes; teste procedimentos sem reunir frases-semente.
Módulo ou executor poderoso demais: inspecione código instalado e escopo exato. Remova módulos ociosos pelo caminho documentado e confirme on-chain.
Limite fraco: avalie resistência à tomada e disponibilidade. Um limite nominal maior não ajuda se signatários compartilham domínio; um limite inalcançável bloqueia a conta.
Atraso ausente ou contornável: confira on-chain o atraso, evento inicial, quem pode reduzi-lo e todo caminho de troca imediata.
Cancelamento ineficaz: ensaie detecção e cancelamento, mantenha gas nativo e rota independente se necessário e confira se cancelar exige proprietário antigo, quórum ou outro papel.
Tomada por upgrade: monitore implementação, beacon e administrador. Quem atualiza sem atraso pode mudar todas as regras documentadas.
Interface maliciosa ou desatualizada: confira rede, conta, módulo, proprietário proposto, limite, atraso e calldata. Nunca revele frase-semente ou chave privada a serviço de “recuperação”.
Falsa finalização: depois de cancelar ou finalizar, confirme recibo e armazenamento final. Verifique que proprietário e módulos desejados estão ativos e a proposta indesejada não é executável.

Se aparecer recuperação não autorizada, pare de assinar pedidos sem relação e preserve ID da proposta, hash, calldata, bloco, endereço do módulo e estado atual. Num dispositivo seguro, confira o alerta por RPC independente, use o cancelamento documentado se disponível e monitore finalização, upgrades, módulos e transferências. Se o controle talvez já esteja perdido, siga um plano de incidente pré-escrito e apenas contatos autenticados; uma transferência improvisada pode sofrer front-running ou revelar o destino.

Equívocos comuns

“Só o proprietário pode mover ativos.” Validadores, executores, módulos, contratos de recuperação ou código atualizado podem oferecer outros caminhos.
“Três guardiões são três partes independentes.” O contrato conta aprovações de endereços; não detecta dispositivos, backups ou administradores compartilhados.
“Um atraso de 24-hour garante tempo de reação.” Também são necessários monitoramento, cancelamento utilizável, gas e inclusão; outra via privilegiada pode contorná-lo.
“Remover um guardião encerra seu acesso.” Confirme a configuração final e confira outros papéis, módulos, chaves de sessão e recuperações pendentes ligados a ele.
“O suporte recupera qualquer conta inteligente.” Só poderes codificados ou pré-configurados on-chain podem mudar uma conta em autocustódia. Sem proprietário ou recuperação válidos, o acesso pode ser perdido para sempre.