
Este es el artículo de cierre de Multisig Deep Dive. A lo largo de seis piezas previas armamos la imagen: qué es multisig, qué umbral elegir, el cableado BIP48, agregación Schnorr, la comparación social-recovery, y la UX single-signer que ata todo para humanos reales. La abstracción funciona bien en condiciones normales. Este artículo es sobre las condiciones anormales.
Toda wallet multisig tiene modos de fallo predecibles — lugares donde la cómoda abstracción single-signer se rompe y el protocolo subyacente se vuelve visible. Saber qué fallos mapean a qué recuperaciones es la diferencia entre un incidente estresante y uno rutinario. Recorreremos cinco de ellos, en el orden en que es más probable que sucedan, con lo que SSP realmente hace (y lo que tú tienes que hacer) en cada caso.
TL;DR
- Modo 1: Un dispositivo perdido, la seed de ese dispositivo intacta. Recuperación trivial — instala SSP en un dispositivo de reemplazo, restaura desde la seed, re-empareja. Fondos sin riesgo.
- Modo 2: Un dispositivo perdido y su seed perdida. La wallet está deteriorada pero no perdida: gasta desde tu dispositivo restante usando tu segunda seed como única llave de recuperación, luego mueve fondos a una wallet recién emparejada.
- Modo 3: Un dispositivo es comprometido por malware/phishing. Los fondos están a salvo porque el atacante tiene solo una de dos firmas. Contienes la brecha re-emparejando con un dispositivo limpio; SSP no puede ser vaciado desde un solo dispositivo comprometido.
- Modo 4: La capa de coordinación de SSP no está disponible. Inconveniente, no catastrófico. La coordinación es transporte de metadata; la wallet multisig subyacente es recuperable por cualquier software compatible con BIP48 usando solo las dos seeds.
- Modo 5: Ambos dispositivos y ambas papeletas de seed destruidos al mismo tiempo. Este es el único modo de fallo catastrófico, y también es aquel para el que tu checklist de self-custody está diseñado para hacer geográficamente improbable.
Leer este artículo una vez es suficiente. No necesitas memorizarlo. El punto es que para cada fallo del que tu yo futuro podría preocuparse, hay una respuesta específica y ejecutable.
Modo 1: Un dispositivo perdido, seed intacta
Este es el fallo más común: cambias de teléfono, dejas caer tu laptop, o haces una reinstalación limpia del OS. El dispositivo que ejecutaba una mitad de tu wallet SSP se ha ido, pero la frase semilla para esa mitad sigue en su lugar (porque seguiste el checklist del primer 1000 y la guardaste físicamente separada).
La recuperación es:
- Instala SSP en un dispositivo de reemplazo (teléfono nuevo, laptop nuevo, etc.).
- Restaura esa mitad desde su frase semilla.
- Re-empareja con tu dispositivo sobreviviente. SSP te guía mostrando cada dispositivo al otro de nuevo — la capa de coordinación multisig detecta la misma xpub en el dispositivo nuevo y la acepta.
- Continúa usando la wallet normalmente. La identidad on-chain de la wallet no ha cambiado — misma dirección, mismo saldo, mismo historial.
En ningún momento los fondos están en riesgo durante este flujo. La frase semilla está destinada a hacer exactamente esto: reconstituir una mitad de firma desde cero. La razón por la que el onboarding de SSP es tan insistente en respaldar ambas seeds por separado es que esta es la recuperación por la que estás pagando.
Coste de tiempo: ~20 minutos si tienes tu papel de seed a mano.
Modo 2: Dispositivo y su seed perdidos
La versión más difícil del modo 1: perdiste un dispositivo y su papel de seed al mismo tiempo. Incendio en casa, inundación, robo de una sola ubicación física, etc. Ahora no puedes reconstituir esa mitad de firma desde su propia seed.
Este es precisamente el caso donde la decisión 2-of-2 vs 2-of-3 muestra sus consecuencias. Bajo 2-of-2 — el default de SSP — te queda exactamente una mitad de firma (el dispositivo sobreviviente, con su propia seed). Bajo 2-of-3 tendrías dos de tres llaves y podrías gastar sin urgencia; bajo 2-of-2 no puedes gastar nada de esta wallet, porque la chain aún requiere ambas firmas originales.
La recuperación es:
- No te asustes. Los fondos están a salvo — ningún atacante puede gastarlos tampoco, porque están bajo una regla 2-of-2.
- Verifica que la seed de tu dispositivo sobreviviente sigue respaldada y accesible. De repente es tu único respaldo.
- Configura una nueva wallet SSP en un par de dispositivos frescos (tu dispositivo restante y un dispositivo nuevo, cada uno con seeds nuevas).
- Envía los fondos de la wallet vieja — espera, no puedes. La 2-of-2 está rota.
Hmm. El paso 4 revela la verdad honesta sobre 2-of-2: en este modo de fallo específico, los fondos están congelados. No robados. No perdidos en el sentido criptográfico. Siguen en la dirección on-chain. Pero no puedes moverlos, porque la wallet impone la regla de gasto 2-of-2 y solo tienes una mitad.
Lo que puedes hacer es re-crear la wallet. Específicamente: el dispositivo sobreviviente aún tiene su seed, configuras un dispositivo nuevo con una seed nueva, los emparejas como una nueva wallet 2-of-2, y gastas de la vieja wallet a la nueva combinando la seed original sobreviviente con la perdida recuperada de otra parte. Si no tienes otra copia de la seed perdida, los fondos están genuinamente varados.
Por eso la instrucción del checklist de "dos seeds, dos ubicaciones físicamente separadas, una de las cuales resistente al fuego" no es paranoia. Es la respuesta al modo 2. Si solo siguieras un consejo de self-custody, sigue las mejores prácticas de seed phrase para ambas de tus seeds SSP. El resto de la wallet está bien diseñado alrededor del supuesto de que lo hiciste.
Modo 3: Un dispositivo comprometido
Imagina el escenario más siniestro: tu laptop está comprometido por malware. La extensión del navegador todavía está instalada; el atacante potencialmente ha observado tu uso, puede tener acceso completo a la llave de firma de ese dispositivo. ¿Qué obtienen?
Bajo una hot wallet single-sig — obtienen todo. La wallet se vacía tan pronto como intentas gastar la próxima vez (o antes, si el malware puede iniciar gastos silenciosamente).
Bajo una wallet SSP 2-of-2, no obtienen nada todavía. Tienen una firma; la chain requiere dos. No pueden gastar por sí solos. Lo más que pueden hacer es fabricar una propuesta de transacción, empujarla a tu teléfono vía la capa de coordinación de SSP, y esperar que la apruebes en el teléfono sin notarlo.
Aquí es donde la discusión de UX single-signer se cruza con la seguridad. El paso de confirmación en el teléfono no es un detalle bonito de UX; es lo único entre un laptop comprometido y una wallet vacía. Lee los detalles de la transacción en el teléfono. Compara la dirección del destinatario. Compara la cantidad. Si algo se ve mal, no la apruebes, sin importar cómo llegó el prompt allí.
La respuesta de contención cuando descubres un compromiso:
- Desde tu dispositivo no comprometido, envía tus fondos a una wallet SSP completamente nueva (configurada en dos dispositivos frescos, dos seeds frescas). Esta es una sola transacción multisig — ambos dispositivos viejos deben firmar una vez, pero inmediatamente después dejas de usar el comprometido.
- Borra el dispositivo comprometido. Reinicio de fábrica; no solo desinstales la extensión.
- Trata la seed comprometida como quemada. Nunca re-importes esa seed específica; considérala filtrada.
Esta contención es mucho más rápida y de menor riesgo que el equivalente para una wallet single-sig, donde tienes que adelantarte al atacante. Con multisig, tienes tiempo para actuar con calma porque el atacante está bloqueado sin la segunda firma. La pieza de siete modos de fallo de la serie anterior lo puso en términos de dinero: la mayoría de las pérdidas de self-custody retail son compromisos de una sola llave, y 2-of-2 es la respuesta para el escenario más común.
Modo 4: La capa de coordinación de SSP no está disponible
¿Qué pasa si SSP, la empresa, tiene un outage? ¿O si el servicio de coordinación que transporta PSBTs entre tu extensión de navegador y tu teléfono está caído? ¿O si has decidido que ya no quieres usar SSP en absoluto?
La respuesta honesta es que la capa de coordinación es transporte de metadata — conveniente pero no de carga. La wallet real vive on-chain, derivada de tus dos seeds BIP48. Si el servidor de firma de SSP está caído por una hora, puedes esperar una hora. Si está caído por una semana, es molesto. Si está caído para siempre, aún puedes recuperar la wallet cargando ambas seeds en cualquier otra wallet compatible con BIP48 — Sparrow en Bitcoin, Electrum, las wallets de descriptor de Bitcoin Core, clientes multisig equivalentes en chains EVM, etc.
El camino de recuperación aquí es:
- Confirma que el problema está en el lado de SSP (vs. tus dispositivos locales) — la página de status de SSP o sus canales de comunidad lo dirán.
- Si necesitas gastar urgentemente, instala una wallet de terceros que soporte la ruta multisig BIP48. Sparrow es la opción más amigable para Bitcoin; para EVM, usarías Safe o un cliente multisig similar.
- Carga ambas seeds en esa wallet de terceros. Aparece la misma dirección, el mismo saldo, la misma capacidad de gasto.
- Firma y transmite normalmente desde allí.
La razón por la que puedes hacer esto — la razón por la que esto no es una afirmación de marketing sino una propiedad verificable — es que SSP usa estándares. El artículo BIP48 y Qué es 2-of-2 multisig lo recorren. SSP es el front-end conveniente sobre una wallet que existe independientemente de SSP.
En la práctica, la infraestructura de firma de SSP está construida con alta disponibilidad — pero la garantía de que la wallet es recuperable sin SSP es lo que hace que la conveniencia importe en vez de asustarte.
Modo 5: Ambos dispositivos y ambas seeds destruidos simultáneamente
Este es el modo de fallo catastrófico y merece ser declarado claramente: si pierdes ambas mitades de firma y ambos backups de seed en el mismo evento, la wallet es permanentemente inaccesible. Los fondos siguen on-chain, en la dirección multisig, pero nadie — incluyendo SSP — puede moverlos. Este es el coste de la verdadera self-custody; la misma propiedad que significa que SSP no puede congelar tus fondos significa que tampoco puede descongelarlos.
La defensa es geográfica y estructural:
- Las dos seeds viven en ubicaciones físicamente separadas. El checklist del primer 1000 nombra "habitación diferente, edificio diferente si es práctico".
- Al menos una de las seeds vive en un contenedor resistente al fuego.
- Si tu stack es lo suficientemente grande como para justificarlo, eventualmente migras a 2-of-3 — añadir una tercera llave (a menudo guardada con un abogado, familiar, o en una caja fuerte bancaria) reduce la superficie de fallo catastrófico de "ambas ubicaciones físicas destruidas" a "dos cualesquiera de tres ubicaciones destruidas".
El encuadre honesto es que este modo de fallo cambia probabilidad por severidad. Las wallets single-key fallan mucho más a menudo (modos 1 y 3 dominan los datos) pero con menor severidad por incidente. Multisig con separación geográfica de seeds reduce la frecuencia de fallo en un orden de magnitud pero eleva ligeramente la severidad por incidente. La mayoría de los usuarios salen adelante.
La introducción Meet SSP Wallet enmarca el producto como una herramienta para self-custody retail sofisticado. La seriedad del modo 5 es parte de por qué ese encuadre es honesto — el producto está construido para personas que están dispuestas a tratar los papeles de seed como infraestructura de carga, no como algo que escribes una vez y olvidas.
Qué significa esto para ti
Conclusiones de cierre:
- La mayoría de los modos de fallo tienen recuperaciones rutinarias. Los modos 1, 3 y 4 — con mucho los más comunes — tienen rutas de recuperación bien definidas y de bajo estrés. El modelo 2-of-2 genuinamente hace lo que promete: absorbe compromisos de punto único y te da tiempo para responder.
- El caso catastrófico es geográfico, no criptográfico. El modo 5 es de lo que tratan tus mejores prácticas de seed phrase. La criptografía de la wallet está bien auditada; la superficie de fallo que queda es si guardaste las dos seeds en lugares físicamente distintos y duraderos.
- Ahora tienes la imagen completa. Esta serie (artículo 1, artículo 2, artículo 3, artículo 4, artículo 5, artículo 6, éste) ha cubierto qué es multisig, cuándo elegir qué umbral, cómo está cableado todo, qué cambia la agregación, cómo difieren los modelos de recuperación, por qué la UX se siente como se siente, y cómo se ve cada modo de fallo operativamente. La serie Self-Custody Fundamentals que la precede te dio el por qué; esta serie te dio el cómo. De aquí, el trabajo es disciplina operativa: higiene de backup, ensayos periódicos de recuperación, y la paciencia para hacer recuperaciones de modo 1 / 2 / 3 / 4 con calma cuando sucedan.
La wallet está bien diseñada. La variable restante eres tú.


