Qué hace realmente una billetera multisig y por qué una sola clave rara vez basta
Una billetera cripto estándar es una única clave privada que firma cada transacción. Quien controla esa clave controla los fondos, sin más. Si la pierdes, el dinero desaparece; si te la roban, el dinero desaparece. No hay línea de soporte, ni restablecimiento de contraseña, ni departamento antifraude. Para unos pocos cientos de dólares en tenencias personales, ese intercambio puede ser aceptable. Para la tesorería de una DAO, las reservas calientes de un exchange, la billetera operativa de un fondo o el almacenamiento en frío a largo plazo de un family office, no lo es.
Una billetera multisig divide esa autoridad entre N claves independientes y exige que M de ellas firmen cualquier transacción. Una configuración 3 de 5, por ejemplo, necesita que tres de cinco firmantes aprueben antes de que se muevan los fondos. Si pierdes dos claves, la billetera sigue pudiendo gastar. Si roban una clave, el ladrón no puede mover nada por sí solo. El diseño es anterior a las criptomonedas; aparece en cuentas bancarias en depósito, sistemas de tesorería corporativa e incluso esquemas de autenticación de dos factores. On-chain, la lógica reside dentro de un smart contract en lugar de en un banco.
La idea central es que multisig no es una función que activas; es un sistema operativo que gestionas. El smart contract aplica la regla M de N a nivel de protocolo, pero las personas, los dispositivos, las ubicaciones y los hábitos que lo rodean determinan si realmente te protege. Un 3 de 5 en el que las cinco claves están en dispositivos de una misma oficina, firmadas por una sola persona que casualmente conoce las contraseñas de todos, apenas es más seguro que una hot wallet de clave única. Un 2 de 3 en el que los tres firmantes están repartidos por tres continentes en hardware wallets de tres proveedores distintos es significativamente más difícil de atacar, aunque técnicamente ambas billeteras superen la prueba de «¿es multisig?».
Los riesgos reales antes de empezar (lee esto dos veces)
Multisig introduce riesgos que una billetera de clave única no tiene. El primero es el riesgo de bloqueo: si configuras 3 de 5 y tres firmantes pierden sus claves simultáneamente, los fondos son matemáticamente irrecuperables. No hay puerta trasera. Busca en la web «parity wallet frozen» y encontrarás un incidente de 2017 en el que un error en una biblioteca multisig bloqueó accidentalmente más de 500.000 ETH en un solo contrato. El error fue un fallo de programación, no un hackeo, y el dinero sigue ahí. La lección es que el riesgo de smart contract es real incluso en código auditado y ampliamente utilizado.
El segundo riesgo es el problema humano. Multisig presupone que tus firmantes no se confabularán, no caerán en phishing al mismo tiempo y no estarán todos en el mismo aeropuerto cuando aduanas decida clonar sus portátiles. Si dos de tus tres firmantes son cofundadores que viajan juntos, tienes un 2 de 3 en teoría y un 1,5 de 3 en la práctica. El tercer riesgo es operativo: cada firmante debe seguir el mismo procedimiento cada vez. Un firmante que «simplemente hace clic para continuar» sin revisar los detalles de la transacción es un punto único de fallo para toda la billetera.
El cuarto riesgo es la capacidad de actualización del contrato. Algunas implementaciones multisig, incluidas ciertas versiones de Safe, permiten que la lógica del contrato se actualice mediante una votación de los propios firmantes. Eso es cómodo para corregir errores, pero significa que una mayoría hostil de tus firmantes puede cambiar las reglas. Si quieres inmutabilidad, debes verificar que la versión que despliegas no sea actualizable. El quinto riesgo es específico de cada cadena: la mayor parte de esta guía se aplica a cadenas EVM (Ethereum, Arbitrum, Base, Optimism, Polygon, BNB Chain), donde Safe domina. Bitcoin multisig existe, pero funciona de forma distinta y no se trata aquí. Solana y otras cadenas no EVM tienen sus propios estándares multisig, cada uno con sus particularidades.
Paso 1: define quiénes son los firmantes, dónde están y qué custodian
Antes de abrir cualquier software, escribe en una sola página la respuesta a cuatro preguntas. Primero, ¿cuántos firmantes hay en total (N)? Segundo, ¿cuántos deben firmar cada transacción (M)? Tercero, ¿dónde se encuentra físicamente cada firmante? Cuarto, ¿qué dispositivo y qué proveedor utiliza cada firmante?
N suele estar entre 3 y 7. Por debajo de 3, tienes muy poca redundancia. Por encima de 7, aumenta la carga de coordinación y sube la probabilidad de que algún firmante no esté disponible en un momento crítico. M es el número más difícil. Un patrón común es 3 de 5, que tolera dos firmantes perdidos o comprometidos, pero sigue requiriendo que tres personas actúen para las operaciones normales. Un 2 de 3 es más rápido de operar, pero solo tolera un fallo. Un 4 de 7 es conservador y común en DAOs más grandes, pero lento. Las matemáticas no perdonan: con N claves, puedes perder hasta N menos M claves y seguir operando, pero si pierdes más que eso quedas bloqueado para siempre.
La geografía importa por el riesgo correlacionado. Es poco probable que un firmante en Singapur, un firmante en Lisboa, un firmante en Buenos Aires y un firmante en Toronto se vean afectados al mismo tiempo por el mismo huracán, el mismo apagón de internet o la misma actuación de las fuerzas de seguridad. El proveedor de hardware importa por la misma razón: una vulnerabilidad descubierta en el firmware de un proveedor no debería comprometer a todos tus firmantes simultáneamente. Combina Ledger, Trezor, GridPlus y Keystone si puedes; no tengas cinco firmantes en cinco dispositivos idénticos del mismo lote.
Por último, decide quiénes son realmente esas personas. Para una wallet personal, podrías usar tus propias claves en dispositivos que controlas en distintas ubicaciones físicas. Para una DAO, los firmantes suelen ser un subconjunto del equipo principal, posiblemente junto con un asesor de seguridad. Para un family office, los firmantes podrían ser el principal, un responsable de operaciones de confianza y la clave de un custodio externo. Sean quienes sean, todos los firmantes deben entender que no pueden perder su dispositivo, compartir su frase semilla ni firmar transacciones sin leerlas.
Paso 2: despliega un Safe en la cadena que pretendes usar
Safe (anteriormente Gnosis Safe) es el multisig más desplegado en cadenas EVM. Está activo desde 2018, custodia miles de millones de dólares en fondos de tesorería de miles de DAOs y equipos, y ha sido auditado y bifurcado muchas veces. Para la mayoría de los usuarios de EVM, Safe es la referencia por defecto. Dicho esto, «el más usado» no es lo mismo que «seguro para tu caso concreto». Lee los informes de auditoría, comprueba la versión actual y verifica que la dirección del contrato desde la que estás desplegando coincide con la oficial publicada por Safe.
Abre la aplicación oficial de Safe en app.safe.global (no confíes en enlaces de correos electrónicos, tweets o anuncios de búsqueda). Conecta primero una wallet de solo lectura para explorar; no necesitas conectar una wallet de firma hasta que vayas a desplegar de verdad. Elige la red que quieras. La mainnet de Ethereum es la más segura, pero cara para la configuración; las redes Layer 2 como Arbitrum, Base y Optimism son más baratas y aun así heredan la seguridad de Ethereum para la liquidación. Elige la cadena que coincida con el lugar donde opera realmente tu tesorería.
Haz clic en «Create new Safe». Elige tu umbral (M) y añade las direcciones de tus N wallets firmantes. Son direcciones EVM normales generadas por MetaMask, Rabby, Frame, hardware wallets o cualquier otra wallet EVM; al Safe no le importa cómo se creó la clave subyacente, solo qué dirección tiene. Confirma. Firma la transacción de despliegue con el firmante conectado y paga la comisión de red. Safe desplegará una nueva wallet de contrato inteligente en una dirección nueva; esa dirección es tu multisig.
Anota la dirección del Safe. Envía una transacción de prueba diminuta (una pequeña cantidad del token nativo, como 0,001 ETH) para confirmar que la dirección es correcta. Prueba una transacción desde el Safe de vuelta a tu propia dirección. Fírmala con el número requerido de firmantes y ejecútala. Solo después de que esta prueba de extremo a extremo salga bien deberías plantearte enviar fondos reales de tesorería.
Paso 3: distribuye las claves de los firmantes entre dispositivos, proveedores y ubicaciones
Ahora que el Safe existe, tienes que asegurarte de que cada firmante esté realmente preparado. Un firmante no es solo una dirección; es una persona con un dispositivo, una copia de seguridad y un proceso. Para cada firmante, genera la clave en una hardware wallet (Ledger, Trezor, GridPlus, Keystone u otro proveedor reputado). Escribe la frase semilla en papel o metal; no la guardes en un gestor de contraseñas, una unidad en la nube, un correo electrónico ni una foto. Guarda la copia de seguridad en una ubicación físicamente separada del dispositivo.
La distribución geográfica tiene dos capas. La primera capa es donde vive normalmente el dispositivo: una caja fuerte en casa, una caja fuerte en la oficina, una caja de seguridad bancaria. La segunda capa es donde vive la copia de seguridad. No deberían estar en el mismo edificio. Un incendio, una inundación o un robo que se lleve el dispositivo no debería llevarse también la frase de recuperación.
La diversidad de proveedores no es negociable para tesorerías serias. No uses tres dispositivos Ledger, dos Trezor y un GridPlus, porque eso siguen siendo tres de un mismo proveedor. El objetivo es hacer que un único error de firmware o ataque a la cadena de suministro no pueda comprometer M de tus N firmantes. Dos o tres proveedores es un mínimo razonable. Ten en cuenta que la diversidad de proveedores no es solo paranoia; también es una cobertura frente al día en que se descubra que un proveedor tiene una puerta trasera deliberada, como temieron algunos usuarios de Ledger tras la filtración de datos de 2020 y los debates posteriores sobre funciones del producto.
Documenta cada firmante con un registro de una página: dirección, modelo de hardware wallet y versión de firmware, ubicación física del dispositivo, ubicación física de la copia de seguridad de la semilla, contacto principal y un suplente designado que sepa cómo recuperar a ese firmante si el principal no está localizable. Guarda este documento en una ubicación cifrada a la que cada firmante pueda acceder, pero que no esté en el mismo dispositivo que ningún firmante.
Paso 4: escribe el plan de recuperación antes de financiar el Safe
La recuperación es la parte que la gente se salta, y es la parte que determina si un multisig es un sistema de seguridad o una bomba de relojería a cámara lenta. Tres escenarios necesitan planes explícitos: un firmante pierde su dispositivo, la frase semilla de un firmante se ve comprometida y dos o más firmantes están simultáneamente ilocalizables.
Para un único dispositivo perdido, la respuesta es sencilla: los N menos 1 firmantes restantes siguen por encima del umbral, así que la wallet continúa funcionando. Hay que reemplazar al firmante que perdió el dispositivo. Eso significa generar una clave nueva en una hardware wallet nueva y añadir la nueva dirección al Safe mientras se elimina la antigua. Esto es en sí mismo una transacción de Safe, firmada por M de los firmantes existentes, y es la operación de recuperación más importante que ejecutarás. Practícala en un Safe de prueba antes de hacerlo de verdad.
Para una única semilla comprometida, la situación es más urgente. Mueve de inmediato los fondos fuera del Safe a un Safe nuevo con nuevos firmantes, firmado por los firmantes no comprometidos. El tiempo importa porque el atacante tiene ahora una de las M claves requeridas. Si tu umbral era 3 de 5 y solo un firmante está comprometido, aún puedes mover fondos, pero debes hacerlo antes de que el atacante consiga las otras dos. Trata una semilla comprometida como un incendio.
Con dos o más firmantes ilocalizables, estás poniendo a prueba el límite de tu redundancia N menos M. Si tu umbral es 3 de 5 y faltan dos firmantes, la wallet sigue funcionando con los tres restantes. Si faltan tres, la wallet queda bloqueada. Por eso el problema de recuperación es en realidad un problema de diseño previo al lanzamiento. O elegiste un M que te da suficiente redundancia para sobrevivir a pérdidas realistas, o no lo hiciste. Ningún software puede arreglar esto después.
Algunos equipos añaden una capa de «guardian» o de recuperación social encima del multisig, donde un conjunto separado de partes de confianza puede ayudar a recuperar el acceso tras un periodo de espera. Es un diseño distinto y merece la pena considerarlo para wallets personales, pero para tesorerías organizativas la disciplina de un multisig puro suele superar a la complejidad de los esquemas híbridos.
Paso 5: crea un manual operativo y practica la firma
Multisig solo te protege si tus firmantes hacen realmente lo correcto cada vez. Eso requiere un manual escrito que cubra: cómo se propone una transacción, cómo se revisa, cómo verifica cada firmante en su dispositivo, cómo firma, cómo se ejecuta y cómo se registra el resultado. Cada firmante debería leer el manual antes de su primera transacción y volver a leerlo una vez al año.
La revisión de transacciones es el paso más infravalorado. Cada firmante debería comprobar el destino real on-chain, el importe real, el contrato real al que se llama y el selector de función real. La mayoría de los exploits de Safe de los últimos años no han sido hacks de protocolo; han sido ataques de ingeniería social en los que un firmante aprobó una transacción maliciosa porque confiaba en quien la proponía o leyó por encima la interfaz de la wallet. Las hardware wallets muestran las direcciones de destino y los importes en sus propias pantallas, que es la función de seguridad más útil para multisig: el propio dispositivo, no el portátil, es la fuente de la verdad.
Haz simulacros de firma. Propón una transacción sin efecto o una pequeña transacción de prueba cada trimestre y recorre todo el flujo M de N. Esto suena puntilloso, pero saca a la luz problemas que de otro modo descubrirías durante una emergencia: un firmante cuyo firmware del dispositivo está desactualizado, un firmante que viaja sin su hardware wallet, un firmante que nunca aprendió el procedimiento. Los simulacros también crean memoria muscular para que, bajo presión (un hack en curso, una caída del mercado, una fecha límite), el equipo pueda ejecutar con rapidez y sin errores.
Lista de comprobación previa al lanzamiento: todo lo que debe estar listo antes de financiar el Safe
- Umbral y conjunto de firmantes: M y N están elegidos, anotados y acordados por todos los firmantes.
- Independencia de los firmantes: cada firmante es una persona distinta, con un proveedor de hardware distinto, en una ubicación física distinta, con copias de seguridad en un edificio distinto.
- Almacenamiento de la seed: la frase seed de cada firmante está en papel o metal, no en ningún sistema digital, con al menos una copia fuera de la ubicación principal.
- Despliegue de Safe: la dirección del contrato se verifica con la lista oficial de despliegues de Safe para la chain y la versión elegidas.
- Prueba de extremo a extremo: un pequeño depósito y una pequeña retirada han sido firmados por los M firmantes requeridos y ejecutados correctamente.
- Simulacro de recuperación: en un Safe de prueba se ha sustituido a un firmante mediante el procedimiento estándar de Safe, lo que demuestra que el equipo puede rotar firmantes sin complicaciones.
- Manual escrito: un único documento describe cómo proponer, revisar, firmar y ejecutar transacciones, y todos los firmantes lo han leído.
- Plan ante compromisos: el equipo ha acordado de antemano cómo reaccionar ante una única seed comprometida, incluida la dirección de un Safe de escape ya desplegado.
- Canales de comunicación: se acuerdan canales seguros fuera de banda (Signal, Keybase, en persona) para la coordinación de emergencia, de modo que un correo electrónico comprometido no pueda usarse para aplicar ingeniería social a los firmantes.
Cómo seguir las noticias de multisig de forma inteligente
Las configuraciones multisig son duraderas, pero el ecosistema que las rodea cambia rápido: Safe publica actualizaciones, los proveedores de hardware lanzan actualizaciones de firmware, se divulgan nuevas vulnerabilidades de contratos y las prácticas de gobernanza de DAO evolucionan. Seguir todo esto manualmente es una batalla perdida. Zippfeed muestra titulares sobre multisig y autocustodia con puntuación de sentimiento (bullish, neutral o bearish) y una calificación de importancia, para que puedas detectar cambios de gobernanza, hallazgos de auditoría y exploits importantes antes de que afecten a tu tesorería.
