Si has seguido esta serie, has armado una imagen del multisig como regla de gasto: m de n llaves firman, la chain impone el umbral, el dinero se mueve. Hemos hablado de el protocolo, las rutas de derivación, y el horizonte de agregación Schnorr. En cada paso, la pregunta que se respondía era: ¿quién tiene que firmar para que el dinero se mueva?
Este artículo trata de otra pregunta: ¿qué pasa si uno de esos firmantes desaparece permanentemente? Multisig tiene una respuesta. Social recovery tiene otra. Se ven parecidos en términos de marketing — ambos involucran "más de una persona" — pero resuelven problemas distintos. Esta pieza es la comparación lado a lado, para que dejes de confundirlos.
TL;DR
- Multisig responde quién puede gastar ahora mismo. Cada transacción necesita el umbral de cosigners para firmar. La propia blockchain impone esto.
- Social recovery responde quién puede ayudarme a volver a entrar si pierdo la llave. La wallet tiene un firmante normal (tú). Un conjunto separado de "guardianes" puede aprobar colectivamente una transacción de recuperación que re-apunte la wallet a una llave nueva.
- Multisig está activo en cada gasto. Social recovery está pasivo hasta que lo invocas — e incluso entonces, lo que hace es reemplazar la llave de gasto, no cofirmar tus gastos.
- Ambos te protegen de perder acceso. Solo multisig te protege genuinamente de que un atacante gane acceso, porque solo multisig requiere múltiples firmas para gasto normal.
- No son mutuamente excluyentes. Los setups del mundo real más resilientes combinan una regla de gasto multisig con una forma estilo social-recovery de rotar una de las llaves cofirmantes si se pierde.
Qué significa realmente "social recovery"
Social recovery, en el sentido que el ecosistema de Ethereum hizo famoso, viene de las wallets smart-contract — Argent fue el primer proof of concept, Safe y el ecosistema ERC-4337 lo hicieron mainstream. Mecánicamente: tu wallet es un smart contract, controlado en operación normal por una llave de firma. El contrato también tiene una función recoverWallet(newKey) que solo puede ser invocada por un quórum de guardianes que nominaste cuando configuraste la wallet.
Los guardianes no cofirman tus transacciones diarias. No pueden gastar en tu nombre. Su poder es más estrecho: si alguna vez dices "perdí mi llave de firma, por favor ayúdenme a reiniciarla", pueden colectivamente firmar una transacción de recuperación que cambie la llave controladora de la wallet de la perdida a una nueva. Después de eso, vuelves a gastar normalmente con la nueva llave.
Un setup típico podría tener 5 guardianes, con un umbral 3-of-5 para recuperación. El 3-of-5 es un umbral de recuperación, no un umbral de gasto. Para el gasto diario sigues necesitando solo tu propia única llave.
El pecado original de social recovery es que requiere un smart contract — lo que significa que funciona nativamente en Ethereum y chains EVM (especialmente vía account abstraction / ERC-4337), pero no porta fácilmente a Bitcoin u otras chains UTXO. El análogo más cercano de Bitcoin es un multisig donde uno de los cosigners es "un servicio de recovery o una persona de confianza" en vez de tu propio dispositivo. Eso es estructuralmente similar pero conceptualmente distinto — la persona de confianza está firmando cada gasto en la versión Bitcoin, no solo la recuperación.
La mecánica: cómo cada uno maneja "perdí una llave"
Imagina el peor caso en términos concretos: tiraste tu teléfono al océano, el papel de seed para ese teléfono estaba en tu billetera (también en el océano), y no tienes backup funcionando de la llave perdida.
Bajo un multisig 2-of-2 (el default de SSP): la wallet está congelada. Ambas firmas son requeridas para cualquier gasto, y solo te queda un firmante. No hay truco de smart-contract para rescatar esto; la regla de gasto on-chain es 2-of-2, punto. Tu ruta de recuperación es la segunda seed — el checklist de self-custody hace ambas seeds críticas exactamente por este escenario.
Bajo un multisig 2-of-3 (el setup solo-con-redundancia del artículo selector): la wallet sigue operativa. Tienes dos de tres llaves; la chain lo acepta como quórum válido. Puedes gastar, puedes mover fondos a una nueva wallet 2-of-3 con una tercera llave fresca, y la vieja llave perdida se vuelve irrelevante.
Bajo una wallet de social-recovery: la wallet también está operativa, pero vía otra ruta. No tienes un quórum de llaves de firma — tienes una llave de firma (la perdida). En cambio, contactas a tus guardianes y les pides firmar una transacción de recuperación. Después de que su umbral apruebe, la wallet se re-vincula a una nueva llave de gasto que tú controlas. Luego vuelves al gasto de una llave.
Las dos recuperaciones se ven superficialmente similares — "pedir a un quórum de partes de confianza que respondan por mí" — pero hacen cosas distintas. La recuperación multisig usa un quórum existente que siempre estuvo ahí. Social recovery activa un quórum latente que existe solo para manejar este caso exacto.
Contra qué protegen (y contra qué no)
Ambas arquitecturas protegen contra pérdida de acceso: puedes recuperar cuando pierdes una llave.
Donde divergen marcadamente es en protección contra gasto no autorizado.
Multisig protege contra el robo de cualquier llave única. Si un atacante hace phishing a tu laptop, vacía tu hot wallet, o roba tu dispositivo de hardware — tienen una de n llaves y no pueden mover dinero. El umbral completo de gasto no se cumple. El post de siete modos de fallo de la serie anterior describe qué tan a menudo esto realmente importa: el compromiso de una sola llave es el vector de ataque dominante en self-custody retail, y multisig es la respuesta.
Social recovery no protege contra el robo de una sola llave en absoluto. En el modelo estándar de social-recovery, tu única llave de firma firma cada transacción. Si esa llave se compromete, un atacante vacía tu wallet inmediatamente — y el proceso de social recovery no ayuda, porque los fondos ya se fueron antes de que los guardianes pudieran intervenir. La recuperación es una herramienta para pérdida, no para robo.
Puedes sobreponerlos: una wallet smart-contract puede implementar tanto una regla de gasto multisig como un mecanismo de rotación social-recovery. El stack moderno ERC-4337 (ver el explicador de account abstraction para el contexto de protocolo) hace esto componible. Pero la social recovery pura, por sí sola, es una historia de recuperación — no una historia de seguridad.
Una comparación pragmática
| Propiedad | Multisig (2-of-2 / 2-of-3) | Social recovery |
|---|---|---|
| UX diario | Firmar en cada dispositivo cofirmante | Firmar en un solo dispositivo |
| Resiste robo de llave única | Sí | No |
| Resiste pérdida de llave única | 2-of-2: no; 2-of-3: sí | Sí (vía guardianes) |
| Funciona en Bitcoin | Sí | No (necesita smart contract) |
| Funciona en Ethereum / EVM | Sí (BIP48 / Safe) | Sí (Argent, Safe, ERC-4337) |
| Tiempo de recuperación | Inmediato (firmar con quórum sobreviviente) | Horas-a-días (coordinación de guardianes) |
| Supuesto de confianza | Dispositivos/personas que tienen las llaves cofirmantes | Guardianes, en quienes confías para no coludirse maliciosamente |
| Visibilidad on-chain | Visible como output multisig (a menos que sea Schnorr-agregado) | Parece una wallet de una sola llave la mayor parte del tiempo |
Dos patrones para notar en esa tabla:
Primero, multisig es la herramienta más amplia. Funciona en más chains, resiste más tipos de ataque, y está actualmente mejor auditado a nivel de protocolo. Social recovery es más amigable en UX cuando es una opción, pero es más estrecha.
Segundo, los supuestos de confianza son distintos. Multisig confía en que los dispositivos que tienen tus llaves cofirmantes no estén todos comprometidos a la vez. Social recovery confía en que un número suficiente de tus guardianes no se coluda para robar tus fondos. Ambos son modelos de confianza razonables para el usuario adecuado, pero no son el mismo modelo de confianza.
Cuándo quieres cuál
- Eres un usuario solo con un dispositivo y el resto del mundo es un yermo de UX. Social recovery gana. El flujo Argent / Safe / smart-account es genuinamente la opción de self-custody con menor fricción, y el escenario de pérdida-de-llave es el que la mayoría de los principiantes realmente vive. La desventaja — sin protección contra robo — es una que aceptas conscientemente, idealmente a cambio de saldos sub-cinco-cifras.
- Eres un usuario solo con saldos no triviales. Multisig gana. El default 2-of-2 de SSP sube el listón contra el robo, la variante 2-of-3 añade resiliencia a pérdida de llave, y ambos se apoyan en estándares abiertos en vez de una plataforma específica de smart contract. La fricción es real pero proporcional a lo que está en juego.
- Eres una organización, sociedad o family office. Multisig es obligatorio; social recovery es un añadido ergonómico. Quieres control conjunto verdadero en cada gasto, no solo en la recuperación. La mayoría de las orgs aterrizan en una regla de gasto multisig con un procedimiento separado y cuidadoso de rotación de llaves para cuando un firmante se va.
- Estás en algún lugar intermedio, en Ethereum. Combínalos. Una wallet smart-contract estilo Safe puede correr una regla de gasto multisig 2-of-3 y un flujo de rotación social-recovery encima. Hacia ahí va el ecosistema de account abstraction.
Para el setup específico SSP 2-of-2 que la mayoría de los lectores de esta serie está usando, social recovery no es una feature hoy — por diseño. Ambos cosigners son tuyos, la historia de recuperación es "usa la segunda seed", y el valor está en la resistencia al robo barata de adquirir. Social recovery resuelve un problema distinto, el que viene después de "estoy cómodo con la custodia, ahora hazla más fácil".
Qué significa esto para ti
Tres conclusiones para archivar:
- No son sustitutos. Si una wallet vende "tenemos social recovery, así que no necesitas multisig", eso es marketing, no ingeniería. La recuperación protege contra pérdida; multisig protege contra robo. Las preguntas que responden no se solapan.
- Tu setup SSP 2-of-2 es un producto de regla de gasto. La pérdida de un dispositivo se recupera desde tu segunda seed, no desde un quórum de guardianes. El artículo de cierre de esta serie — Modos de fallo multisig y cómo SSP los mitiga — recorre exactamente cómo se juega esa recuperación por modo de fallo.
- Construye hacia adelante, no lateralmente. Una vez que tu stack supera genuinamente el 2-of-2, el siguiente paso normalmente es multisig 2-of-3 con una llave geográficamente separada, no social recovery en lugar de multisig. El artículo 2-of-3 de esta serie (selector) plantea esa migración; la pieza single-signer multisig que viene a continuación explica cómo SSP mantiene ese setup futuro sintiéndose como una sola wallet.
