
Una dirección de billetera parece algo sencillo: una cadena que copias, pegas y a la que envías dinero. En Bitcoin es casi así de simple. En Solana, poner una billetera compartida — un multisig — detrás de una dirección resulta sorprendentemente difícil. Este artículo explica por qué y plantea la pregunta que responde el resto de esta serie.
Qué debe prometer una dirección multisig
Una billetera multisig es la que controlan varias claves, donde un número fijo de ellas debe coincidir antes de que se mueva dinero. Un multisig "2 de 3", por ejemplo, tiene tres claves y necesita que dos cualesquiera aprueben un pago. El objetivo es eliminar los puntos únicos de fallo: pierdes una clave, o te roban una clave, y tus fondos siguen a salvo.
Para que eso sea útil, la dirección debe cumplir dos promesas. Primero, debe ser conocida de antemano — quieres entregar a alguien una dirección de depósito antes de terminar de configurar nada. Segundo, debe ser honesta: quien envíe dinero a esa dirección debe poder confiar en que solo el grupo de claves acordado, bajo la regla acordada, podrá gastar desde ella. Recuerda esas dos promesas. Son el hilo conductor de todo lo que sigue.
En Bitcoin, la dirección es la regla
Bitcoin hace que esto parezca fácil. Un multisig de Bitcoin se describe con un pequeño script: la lista de claves públicas más la regla "M de N". Para obtener la dirección, tomas ese script y lo hasheas. La dirección (una dirección P2WSH) literalmente es el hash de las reglas de gasto.
Eso tiene una consecuencia silenciosamente poderosa. Cualquiera puede calcular la dirección sin conexión, en un portátil sin internet, antes de transmitir una sola transacción. No hay paso de "crear la billetera" — la billetera no necesita existir en la red para recibir dinero. El script se revela solo más tarde, al gastar fondos, y la red comprueba que el script revelado coincide con la dirección y que hay suficientes firmas válidas. ¿Dirección conocida de antemano? Sí. ¿Honesta? Sí — porque la dirección deriva de la propia regla, un conjunto distinto de claves produce una dirección distinta.
En Solana, una dirección es una cuenta que debe crearse
Solana funciona de otra manera. En Solana, todo es una cuenta — un espacio de almacenamiento en cadena con un propietario. Tus fondos viven en cuentas, los programas viven en cuentas, y la configuración de un multisig también vive en una cuenta. Es crucial que las cuentas no aparezcan gratis. Una cuenta debe ser creada y pagada explícitamente: alguien la financia con una pequeña cantidad de SOL llamada "renta" para que la red almacene sus datos.
Un multisig en Solana, por tanto, no es solo una dirección — es una cuenta controlada por un programa que contiene la lista de miembros y el umbral. Y esa cuenta debe crearse mediante una transacción antes de que el multisig pueda hacer nada. Esta es la raíz de la dificultad: una billetera compartida en Solana tiene un paso de configuración que Bitcoin simplemente no tiene.
PDAs: direcciones sin clave privada
Solana sí tiene una herramienta elegante para esto, llamada Dirección Derivada de Programa, o PDA. Una dirección normal de Solana tiene una clave privada que le corresponde — quien posee la clave controla la dirección. Una PDA se construye deliberadamente para estar fuera de la curva: es una dirección de apariencia válida para la que no existe ninguna clave privada y no puede existir ninguna. Nadie puede firmar por ella personalmente.
En cambio, una PDA se deriva de forma determinista. Tomas algunos valores de entrada — llamados "semillas" — más el ID de un programa, los pasas por una función unidireccional y de ahí sale la dirección. Las mismas semillas y el mismo programa siempre producen la misma PDA, así que cualquiera puede reproducirla. Y como no hay clave privada, solo el programa propietario puede autorizar acciones para esa dirección, lo cual hace mediante un mecanismo llamado invocación entre programas con invoke_signed: el programa presenta las semillas al runtime de Solana, y el runtime le concede autoridad de firma para la PDA. Nunca se produce una firma criptográfica — el derecho a actuar proviene de conocer las semillas, no de poseer una clave.
Una PDA es exactamente el hogar adecuado para un multisig: una dirección controlada por la lógica del programa en lugar de por una sola persona. Hasta aquí, bien. La parte difícil es qué se elige como semillas.
El problema de financiar antes de crear
Aquí es donde los multisig dominantes de Solana se topan con un obstáculo. A diferencia del modelo determinista de Bitcoin, los multisig de Solana más usados — Squads V4 es el ejemplo líder, maduro y muy auditado — derivan la dirección del multisig de un valor aleatorio recién generado y elegido en el momento de la creación, no del conjunto de miembros. En Squads V4 ese valor se llama create_key, una clave efímera que se produce cuando un creador ejecuta la transacción de creación.
Derivar la dirección de un create_key aleatorio es una decisión de diseño deliberada y razonable — sortea un caso límite incómodo en el que dos grupos distintos quieren exactamente la misma composición de miembros. Pero tiene dos consecuencias que conviene entender con claridad:
- No puedes conocer la dirección de antemano. La semilla no existe hasta que alguien ejecuta la transacción de creación, así que tampoco existe la dirección. No hay forma de imprimir una dirección de depósito y financiarla antes de la configuración — el problema de financiar antes de crear. La primera promesa se rompe.
- El creador es un punto único de confianza en la configuración. Una cuenta específica debe ejecutar esa transacción de creación y elegir ese valor aleatorio. Durante la breve ventana de configuración, confías en que esa parte lo haga correctamente.
Nada de esto hace que Squads V4 sea inseguro — es el multisig más probado en batalla de Solana y custodia sumas muy grandes. Es simplemente una forma distinta de confianza que la de Bitcoin. La dirección ya no es "el hash de la regla"; es "lo que sea que la transacción de creación haya producido".
Ethereum encontró un camino intermedio
Ethereum se enfrentó a un problema similar y lo resolvió con una función llamada CREATE2. Permite calcular la dirección de un contrato inteligente antes de que el contrato se despliegue, a partir de entradas fijas. Billeteras como Safe usan esto para darte una llamada dirección contrafáctica: una dirección real y financiable que puedes compartir y en la que recibir dinero, mientras el contrato real se despliega de forma diferida — solo cuando los fondos necesitan moverse por primera vez. El estándar más reciente de abstracción de cuentas, ERC-4337, formaliza la misma idea. Ethereum recupera así la promesa de "conocida de antemano" aunque, como Solana, necesite que un objeto en cadena exista finalmente.
La pregunta que responde esta serie
Pon los tres modelos lado a lado. Bitcoin: la dirección es el hash de la regla — conocible sin conexión, honesta por construcción, sin paso de creación. Ethereum: una dirección contrafáctica — conocible de antemano, con el despliegue diferido. Los multisig generales de Solana: la dirección proviene de aleatoriedad del momento de creación — no conocible de antemano, con un creador en quien confiar durante la configuración.
Así que aquí está la pregunta. Solana necesita cuentas, y las cuentas necesitan crearse — eso no va a desaparecer. Pero ¿tiene un multisig de Solana que renunciar a la propiedad de Bitcoin? ¿Podría la dirección derivarse en cambio puramente del conjunto de miembros y el umbral — la propia regla — de modo que sea conocible sin conexión, financiable antes de la configuración y honesta porque un grupo distinto de claves produce una dirección distinta?
Esa es exactamente la propiedad que el equipo de SSP incorporó a su propio programa de multisig de Solana. El siguiente artículo muestra cómo: una dirección que es el conjunto de miembros, una bóveda que puedes financiar antes de que nada esté registrado en cadena y un paso de registro que no necesita creador alguno. El diseño se lanzó junto con el soporte de Solana en SSP Wallet — consulta el anuncio de lanzamiento — y, en línea con cómo SSP trata la seguridad, el programa está actualmente solo en devnet y a la espera de una auditoría externa antes de mainnet. Si aún eres nuevo en el multisig en sí, empieza por qué es un multisig y por qué importa; de lo contrario, sigue leyendo.


