Modos de falha multisig e como o SSP os mitiga

Este é o artigo de fechamento de Multisig Deep Dive. Ao longo de seis peças anteriores construímos o quadro: o que é multisig, qual limiar escolher, a montagem BIP48, agregação Schnorr, a comparação social-recovery, e a UX single-signer que amarra tudo isso pra humanos reais. A abstração funciona bem em condições normais. Este artigo é sobre as condições anormais.

Toda carteira multisig tem modos de falha previsíveis — lugares onde a confortável abstração single-signer quebra e o protocolo subjacente fica visível. Saber quais falhas mapeiam pra quais recuperações é a diferença entre um incidente estressante e um rotineiro. Vamos percorrer cinco deles, na ordem em que é mais provável que aconteçam, com o que o SSP de fato faz (e o que você tem que fazer) em cada caso.

TL;DR

• Modo 1: Um dispositivo perdido, a seed daquele dispositivo intacta. Recuperação trivial — instale o SSP em um dispositivo substituto, restaure da seed, re-pareie. Fundos sem risco.
• Modo 2: Um dispositivo perdido e sua seed perdida. A carteira está comprometida mas não perdida: gaste do seu dispositivo restante usando sua segunda seed como única chave de recuperação, depois mova fundos pra uma carteira recém-pareada.
• Modo 3: Um dispositivo é comprometido por malware/phishing. Os fundos estão seguros porque o atacante tem só uma das duas assinaturas. Você contém a brecha re-pareando com um dispositivo limpo; o SSP não pode ser drenado de um único dispositivo comprometido.
• Modo 4: A camada de coordenação do SSP está indisponível. Inconveniente, não catastrófico. Coordenação é transporte de metadata; a carteira multisig subjacente é recuperável por qualquer software compatível com BIP48 usando só as duas seeds.
• Modo 5: Os dois dispositivos e os dois papéis de seed destruídos ao mesmo tempo. Esse é o único modo de falha catastrófico, e é também o que seu checklist de self-custody é projetado pra tornar geograficamente implausível.

Ler este artigo uma vez basta. Você não precisa decorá-lo. O ponto é que pra cada falha que seu eu futuro possa se preocupar, há uma resposta específica, executável.

Modo 1: Um dispositivo perdido, seed intacta

Essa é a falha mais comum: você troca o celular, derruba o laptop, ou faz uma reinstalação limpa do OS. O dispositivo que rodava uma metade da sua carteira SSP se foi, mas a seed phrase pra aquela metade ainda está no seu lugar (porque você seguiu o checklist dos primeiros 1000 e a guardou fisicamente separada).

A recuperação é:

1. Instale o SSP em um dispositivo substituto (celular novo, laptop novo, etc.).
2. Restaure aquela metade da sua seed phrase.
3. Re-pareie com seu dispositivo sobrevivente. O SSP te guia mostrando os dois dispositivos um ao outro de novo — a camada de coordenação multisig detecta o mesmo xpub no novo dispositivo e aceita.
4. Continue usando a carteira normalmente. A identidade on-chain da carteira não mudou — mesmo endereço, mesmo saldo, mesmo histórico.

Em nenhum momento os fundos estão em risco durante esse fluxo. A seed phrase é feita pra exatamente isso: reconstituir uma metade de assinatura do zero. A razão pela qual o onboarding do SSP é tão insistente em fazer backup das duas seeds separadamente é que essa é a recuperação pela qual você está pagando.

Custo de tempo: ~20 minutos se você tem o papel da seed em mãos.

Modo 2: Dispositivo e sua seed perdidos

A versão mais difícil do modo 1: você perdeu um dispositivo e o papel da seed dele ao mesmo tempo. Incêndio em casa, enchente, roubo de uma única localização física, etc. Agora você não pode reconstituir aquela metade de assinatura a partir da própria seed.

Esse é precisamente o caso onde a decisão 2-of-2 vs 2-of-3 mostra suas consequências. Sob 2-of-2 — o padrão do SSP — você tem exatamente uma metade de assinatura sobrando (o dispositivo sobrevivente, com a seed dele). Sob 2-of-3 você teria duas de três chaves e poderia gastar sem urgência; sob 2-of-2 você não pode gastar nada dessa carteira, porque a chain ainda exige as duas assinaturas originais.

A recuperação é:

1. Não entre em pânico. Os fundos estão seguros — nenhum atacante consegue gastá-los também, porque eles estão sob uma regra 2-of-2.
2. Verifique que a seed do seu dispositivo sobrevivente ainda está backupada e acessível. Ela de repente é seu único reserva.
3. Configure uma nova carteira SSP em um par de dispositivos novos (seu dispositivo restante e um dispositivo novo, cada um com seeds novas).
4. Envie os fundos da carteira antiga — espera, você não pode. O 2-of-2 está quebrado.

Hmm. O passo 4 revela a verdade honesta sobre 2-of-2: nesse modo de falha específico, os fundos estão congelados. Não roubados. Não perdidos no sentido criptográfico. Ainda estão no endereço on-chain. Mas você não pode movê-los, porque a carteira impõe a regra de gasto 2-of-2 e você só tem uma metade.

O que você pode fazer é recriar a carteira. Especificamente: o dispositivo sobrevivente ainda tem sua seed, você configura um dispositivo novo com uma seed nova, pareia eles como uma carteira 2-of-2 nova, e gasta da carteira antiga pra nova — e essa é a chave — combinando a seed original sobrevivente com a perdida recuperada de outro lugar. Se você não tem outra cópia da seed perdida, os fundos genuinamente estão encalhados.

É por isso que a instrução do checklist "duas seeds, dois locais fisicamente separados, um deles à prova de fogo" não é paranoia. É a resposta pro modo 2. Se você só fosse seguir um conselho de self-custody, siga as melhores práticas de seed phrase pras duas seeds do SSP. O resto da carteira é bem projetado em torno do pressuposto de que você fez isso.

Modo 3: Um dispositivo comprometido

Imagine o cenário mais sinistro: seu laptop é comprometido por malware. A extensão do navegador ainda está instalada; o atacante potencialmente observou seu uso, pode ter acesso completo à chave de assinatura daquele dispositivo. O que ele consegue?

Sob uma hot wallet single-sig — ele consegue tudo. A carteira é drenada assim que você tenta gastar na próxima vez (ou antes, se o malware consegue iniciar gastos silenciosamente).

Sob uma carteira SSP 2-of-2, ele não consegue nada ainda. Ele tem uma assinatura; a chain exige duas. Ele não pode gastar por conta própria. O máximo que ele pode fazer é fabricar uma proposta de transação, empurrar pro seu celular via a camada de coordenação do SSP, e torcer pra você aprovar no celular sem reparar.

É aqui que a discussão sobre UX single-signer cruza com segurança. O passo de confirmação no celular não é um detalhe de UX bonitinho; é a única coisa entre um laptop comprometido e uma carteira drenada. Leia os detalhes da transação no celular. Compare o endereço do destinatário. Compare o valor. Se alguma coisa parecer errada, não aprove, não importa como o prompt chegou lá.

A resposta de contenção quando você descobre um comprometimento:

1. Do seu dispositivo não comprometido, envie seus fundos pra uma carteira SSP novinha em folha (configurada em dois dispositivos novos, duas seeds novas). Essa é uma única transação multisig — os dois dispositivos antigos precisam assinar uma vez, mas logo depois você para de usar o comprometido.
2. Limpe o dispositivo comprometido. Reset de fábrica; não só desinstale a extensão.
3. Trate a seed comprometida como queimada. Nunca reimporte aquela seed específica; considere ela vazada.

Essa contenção é muito mais rápida e de menor risco que o equivalente pra uma carteira single-sig, onde você tem que correr na frente do atacante. Com multisig, você tem tempo pra agir com calma porque o atacante está bloqueado sem a segunda assinatura. A peça de sete modos de falha da série anterior coloca isso em termos de dinheiro: a maioria das perdas de self-custody retail são comprometimentos de chave única, e 2-of-2 é a resposta pro cenário mais comum.

Modo 4: A camada de coordenação do SSP está indisponível

O que acontece se o SSP, a empresa, tiver um outage? Ou se o serviço de coordenação que transporta PSBTs entre sua extensão de navegador e seu celular estiver fora? Ou se você decidiu que não quer mais usar o SSP de jeito nenhum?

A resposta honesta é que a camada de coordenação é transporte de metadata — conveniente mas não estrutural. A carteira de verdade vive on-chain, derivada das suas duas seeds BIP48. Se o servidor de assinatura do SSP estiver fora por uma hora, você pode esperar uma hora. Se estiver fora por uma semana, é chato. Se estiver fora pra sempre, você ainda pode recuperar a carteira carregando as duas seeds em qualquer outra carteira compatível com BIP48 — Sparrow no Bitcoin, Electrum, as carteiras de descriptor do Bitcoin Core, clientes multisig equivalentes em chains EVM, etc.

O caminho de recuperação aqui é:

1. Confirme que o problema está do lado do SSP (vs. seus dispositivos locais) — a página de status do SSP ou os canais de comunidade dele vão dizer.
2. Se você precisar gastar urgente, instale uma carteira de terceiros que suporte o caminho multisig BIP48. Sparrow é a opção mais amigável pro Bitcoin; pra EVM, você usaria Safe ou um cliente multisig parecido.
3. Carregue as duas seeds nessa carteira de terceiros. O mesmo endereço aparece, o mesmo saldo, a mesma capacidade de gasto.
4. Assine e transmita normalmente de lá.

A razão pela qual você consegue fazer isso — a razão pela qual isso não é uma alegação de marketing mas uma propriedade verificável — é que o SSP usa padrões. O artigo BIP48 e O que é multisig 2-of-2 percorrem isso. O SSP é o front-end conveniente sobre uma carteira que existe independentemente do SSP.

Na prática, a infraestrutura de assinatura do SSP é construída pra alta disponibilidade — mas a garantia de que a carteira é recuperável sem o SSP é o que faz a conveniência importar em vez de te assustar.

Modo 5: Os dois dispositivos e as duas seeds destruídos simultaneamente

Esse é o modo de falha catastrófico e merece ser dito sem rodeios: se você perder as duas metades de assinatura e os dois backups de seed no mesmo evento, a carteira é permanentemente inacessível. Os fundos ainda estão on-chain, no endereço multisig, mas ninguém — incluindo o SSP — pode movê-los. Esse é o custo da self-custody verdadeira; a mesma propriedade que significa que o SSP não pode congelar seus fundos significa que ele também não pode descongelar.

A defesa é geográfica e estrutural:

• As duas seeds vivem em locais fisicamente separados. O checklist dos primeiros 1000 cita "cômodo diferente, prédio diferente se prático".
• Pelo menos uma das seeds vive em um recipiente à prova de fogo.
• Se seu stack é grande o suficiente pra justificar, você eventualmente migra pra 2-of-3 — adicionar uma terceira chave (frequentemente guardada com advogado, familiar, ou em um cofre de banco) reduz a superfície de falha catastrófica de "as duas localizações físicas destruídas" pra "duas quaisquer de três localizações destruídas".

O enquadramento honesto é que esse modo de falha troca probabilidade por severidade. Carteiras single-key falham bem mais (modos 1 e 3 dominam os dados) mas com menor severidade por incidente. Multisig com separação geográfica de seeds reduz a frequência de falha em uma ordem de grandeza mas eleva ligeiramente a severidade por incidente. A maioria dos usuários sai ganhando.

A introdução Meet SSP Wallet enquadra o produto como ferramenta pra self-custody retail sofisticado. A seriedade do modo 5 é parte do porquê esse enquadramento é honesto — o produto é feito pra pessoas dispostas a tratar os papéis de seed como infraestrutura que sustenta carga, não como algo que você escreve uma vez e esquece.

O que isso significa pra você

Conclusões de fechamento:

1. A maioria dos modos de falha tem recuperações rotineiras. Modos 1, 3 e 4 — de longe os mais comuns — têm caminhos de recuperação bem definidos e de baixo estresse. O modelo 2-of-2 genuinamente faz o que promete: absorve comprometimentos de ponto único e te dá tempo pra responder.
2. O caso catastrófico é geográfico, não criptográfico. O modo 5 é sobre o que as suas melhores práticas de seed phrase tratam. A criptografia da carteira é bem auditada; a superfície de falha que sobra é se você guardou as duas seeds em lugares fisicamente distintos e duráveis.
3. Você agora tem o quadro completo. Essa série (artigo 1, artigo 2, artigo 3, artigo 4, artigo 5, artigo 6, esse) cobriu o que é multisig, quando escolher qual limiar, como tudo é cabeado, o que a agregação muda, como os modelos de recuperação diferem, por que a UX se sente do jeito que se sente, e como cada modo de falha se parece operacionalmente. A série Self-Custody Fundamentals que a precede te deu o porquê; essa série te deu o como. Daqui, o trabalho é disciplina operacional: higiene de backup, ensaios periódicos de recuperação, e a paciência pra fazer recuperações de modo 1 / 2 / 3 / 4 com calma quando acontecerem.

A carteira é bem projetada. A variável restante é você.