Se você acompanhou esta série, montou uma imagem de multisig como regra de gasto: m de n chaves assinam, a chain impõe o limiar, o dinheiro se move. Falamos sobre o protocolo, os caminhos de derivação, e o horizonte de agregação Schnorr. Em cada passo, a pergunta sendo respondida era: quem precisa assinar pro dinheiro se mover?
Este artigo é sobre uma pergunta diferente: o que acontece se um desses signatários sumir permanentemente? Multisig tem uma resposta. Social recovery tem outra. Eles parecem semelhantes em termos de marketing — ambos envolvem "mais de uma pessoa" — mas resolvem problemas diferentes. Esta peça é o lado a lado, pra você parar de confundi-los.
TL;DR
- Multisig responde quem pode gastar agora mesmo. Toda transação precisa do limiar de cosigners pra assinar. O próprio blockchain impõe isso.
- Social recovery responde quem pode me ajudar a voltar se minha chave se perdeu. A carteira tem um signatário normal (você). Um conjunto separado de "guardiões" pode coletivamente aprovar uma transação de recuperação que reaponta a carteira pra uma nova chave.
- Multisig está ativo em cada gasto. Social recovery está passivo até você invocá-lo — e mesmo assim, o que ele faz é substituir a chave de gasto, não cofirmar seus gastos.
- Ambos te protegem contra perder acesso. Só multisig genuinamente te protege contra um atacante ganhar acesso, porque só multisig exige múltiplas assinaturas pra gasto normal.
- Eles não são mutuamente exclusivos. Os setups do mundo real mais resilientes combinam uma regra de gasto multisig com uma forma estilo social-recovery de rotacionar uma das chaves cofirmantes se ela se perder.
O que "social recovery" realmente significa
Social recovery, no sentido que o ecossistema Ethereum tornou famoso, vem das carteiras smart-contract — Argent foi a prova de conceito inicial, Safe e o ecossistema ERC-4337 a tornaram mainstream. Mecanicamente: sua carteira é um smart contract, controlada em operação normal por uma chave de assinatura. O contrato também tem uma função recoverWallet(newKey) embutida que só pode ser invocada por um quórum de guardiões que você nomeou quando configurou a carteira.
Guardiões não cofirmam suas transações do dia a dia. Eles não podem gastar em seu nome. O poder deles é mais estreito: se você um dia disser "perdi minha chave de assinatura, por favor me ajudem a reiniciá-la", eles podem coletivamente assinar uma transação de recuperação que troca a chave controladora da carteira da perdida pra uma nova. Depois disso, você volta a gastar normalmente com a chave nova.
Um setup típico pode ter 5 guardiões, com um limiar 3-of-5 pra recuperação. O 3-of-5 é um limiar de recuperação, não um limiar de gasto. Pro gasto cotidiano você ainda só precisa da sua única chave.
O pecado original do social recovery é que ele exige um smart contract — o que significa que funciona nativamente no Ethereum e chains EVM (especialmente via account abstraction / ERC-4337), mas não migra facilmente pro Bitcoin ou outras chains UTXO. O análogo mais próximo do Bitcoin é um multisig em que um dos cosigners é "um serviço de recovery ou pessoa de confiança" em vez do seu próprio dispositivo. Isso é estruturalmente parecido mas conceitualmente diferente — a pessoa de confiança está assinando cada gasto na versão Bitcoin, não só a recuperação.
A mecânica: como cada um lida com "perdi uma chave"
Imagine o pior caso em termos concretos: você jogou seu celular no oceano, o papel da seed daquele celular estava na sua carteira (também no oceano), e você não tem backup funcionando da chave perdida.
Sob um multisig 2-of-2 (o padrão SSP): a carteira está congelada. Ambas as assinaturas são exigidas pra qualquer gasto, e você só tem um signatário restante. Não há truque de smart-contract pra resgatar isso; a regra de gasto on-chain é 2-of-2, ponto. Seu caminho de recuperação é a segunda seed — o checklist de self-custody faz ambas as seeds críticas exatamente pra esse cenário.
Sob um multisig 2-of-3 (o setup solo-com-redundância do artigo seletor): a carteira continua operacional. Você tem duas de três chaves; a chain aceita isso como quórum válido. Você pode gastar, pode mover fundos pra uma nova carteira 2-of-3 com uma terceira chave nova, e a chave velha perdida vira irrelevante.
Sob uma carteira de social-recovery: a carteira também está operacional, mas por um caminho diferente. Você não tem um quórum de chaves de assinatura — você tem uma chave de assinatura (a perdida). Em vez disso, você contata seus guardiões e pede que assinem uma transação de recuperação. Depois que o limiar deles aprovar, a carteira é re-vinculada a uma nova chave de gasto que você controla. Aí você volta ao gasto de uma chave.
As duas recuperações parecem superficialmente parecidas — "pedir a um quórum de partes de confiança que respondam por mim" — mas estão fazendo coisas diferentes. A recuperação multisig usa um quórum existente que sempre esteve lá. Social recovery ativa um quórum latente que existe só pra lidar com esse caso exato.
Contra o que protegem (e contra o que não)
Ambas arquiteturas protegem contra perda de acesso: você pode recuperar quando perde uma chave.
Onde elas divergem fortemente é em proteção contra gasto não autorizado.
Multisig protege contra roubo de qualquer chave única. Se um atacante faz phishing no seu laptop, esvazia sua hot wallet, ou rouba seu dispositivo de hardware — ele tem uma de n chaves e não pode mover dinheiro. O limiar completo de gasto não é atendido. O post de sete modos de falha da série anterior descreve com que frequência isso realmente importa: o comprometimento de uma chave única é o vetor de ataque dominante no self-custody retail, e multisig é a resposta.
Social recovery não protege contra roubo de chave única de jeito nenhum. No modelo padrão de social-recovery, sua única chave de assinatura assina cada transação. Se essa chave for comprometida, um atacante esvazia sua carteira imediatamente — e o processo de social recovery não ajuda, porque os fundos já foram embora antes de os guardiões poderem intervir. Recovery é uma ferramenta pra perda, não pra roubo.
Você pode empilhá-los: uma carteira smart-contract pode implementar tanto uma regra de gasto multisig como um mecanismo de rotação social-recovery. O stack moderno ERC-4337 (veja o explicador de account abstraction pro contexto do protocolo) torna isso componível. Mas social recovery puro, sozinho, é uma história de recuperação — não uma história de segurança.
Uma comparação pragmática
| Propriedade | Multisig (2-of-2 / 2-of-3) | Social recovery |
|---|---|---|
| UX diário | Assinar em cada dispositivo cofirmante | Assinar num único dispositivo |
| Resiste a roubo de chave única | Sim | Não |
| Resiste a perda de chave única | 2-of-2: não; 2-of-3: sim | Sim (via guardiões) |
| Funciona no Bitcoin | Sim | Não (precisa de smart contract) |
| Funciona no Ethereum / EVM | Sim (BIP48 / Safe) | Sim (Argent, Safe, ERC-4337) |
| Tempo pra recuperar | Imediato (assinar com quórum sobrevivente) | Horas-a-dias (coordenação de guardiões) |
| Pressuposto de confiança | Dispositivos/pessoas que possuem as chaves cofirmantes | Guardiões, em quem você confia pra não conspirar maliciosamente |
| Visibilidade on-chain | Visível como output multisig (a menos que Schnorr-agregado) | Parece uma carteira de uma chave a maior parte do tempo |
Dois padrões pra notar nessa tabela:
Primeiro, multisig é a ferramenta mais ampla. Funciona em mais chains, resiste a mais tipos de ataque, e está atualmente melhor auditado no nível do protocolo. Social recovery é mais amigável em UX quando é uma opção, mas é mais estreito.
Segundo, os pressupostos de confiança são diferentes. Multisig confia que os dispositivos que possuem suas chaves cofirmantes não estejam todos comprometidos ao mesmo tempo. Social recovery confia que um número suficiente dos seus guardiões não vai conspirar pra roubar seus fundos. Ambos são modelos de confiança razoáveis pro usuário certo, mas não são o mesmo modelo de confiança.
Quando você quer qual
- Você é um usuário solo com um dispositivo e o resto do mundo é um deserto de UX. Social recovery vence. O fluxo Argent / Safe / smart-account é genuinamente a opção de self-custody com menor fricção, e o cenário de perda de chave é o que a maioria dos iniciantes realmente vive. A desvantagem — sem proteção contra roubo — é uma que você aceita conscientemente, idealmente em troca de saldos sub-cinco-dígitos.
- Você é um usuário solo com posições não triviais. Multisig vence. O default 2-of-2 do SSP eleva a barra contra roubo, a variante 2-of-3 adiciona resiliência a perda de chave, e ambos descansam em padrões abertos em vez de uma plataforma específica de smart contract. A fricção é real mas proporcional ao que está em jogo.
- Você é uma organização, parceria ou family office. Multisig é obrigatório; social recovery é um acréscimo ergonômico. Você quer controle conjunto verdadeiro em cada gasto, não só na recuperação. A maioria das orgs pousa numa regra de gasto multisig com um procedimento separado e cuidadoso de rotação de chaves pra quando um signatário sai.
- Você está em algum lugar intermediário, no Ethereum. Empilhe os dois. Uma carteira smart-contract estilo Safe pode rodar uma regra de gasto multisig 2-of-3 e um fluxo de rotação social-recovery em cima. É pra lá que o ecossistema de account abstraction está indo.
Pro setup SSP 2-of-2 específico que a maioria dos leitores desta série está usando, social recovery não é uma feature hoje — por design. Ambos os cosigners são seus, a história de recuperação é "use a segunda seed", e o valor está na resistência a roubo barata de adquirir. Social recovery resolve um problema diferente, o que vem depois de "estou confortável com custódia, agora torne mais fácil".
O que isso significa pra você
Três conclusões pra arquivar:
- Eles não são substitutos. Se uma carteira vende "temos social recovery, então você não precisa de multisig", isso é marketing, não engenharia. Recovery protege contra perda; multisig protege contra roubo. As perguntas que respondem não se sobrepõem.
- Seu setup SSP 2-of-2 é um produto de regra de gasto. A perda de um dispositivo é recuperada pela sua segunda seed, não por um quórum de guardiões. O artigo de encerramento desta série — Modos de falha multisig e como o SSP os mitiga — passa exatamente como essa recuperação se dá por modo de falha.
- Construa pra frente, não lateralmente. Uma vez que seu stack genuinamente supera o 2-of-2, o próximo passo normalmente é multisig 2-of-3 com uma chave geograficamente separada, não social recovery no lugar de multisig. O artigo 2-of-3 desta série (seletor) prepara essa migração; a peça single-signer multisig que vem a seguir explica como o SSP mantém esse setup futuro parecendo uma única carteira.
