La cartera multisig de Solana donde la dirección es el conjunto de miembros
Una cartera multisig necesita dos o más llaves para aprobar cualquier gasto. En Bitcoin, la dirección de la cartera es simplemente un hash de sus propias reglas: la lista de claves públicas y el número de "cuántas firmas se requieren". Puedes calcular esa dirección en una libreta, repartirla y recibir fondos mucho antes de que alguien toque la blockchain.
Solana, tradicionalmente, no puede hacer esto. Como explica el primer artículo de esta serie, las multisig dominantes de Solana te piden ejecutar una transacción de creación con aleatoriedad elegida por el creador antes de que la dirección de la cartera siquiera exista. El propio programa multisig de Solana de SSP adopta en cambio el enfoque de Bitcoin. Es autoinicializable: la dirección de la cartera es el conjunto de miembros.
Una aclaración por adelantado: el programa multisig de Solana de SSP es de código abierto (RunOnFlux/Solana-Multisig) y actualmente funciona solo en devnet, la red de pruebas de Solana. Un despliegue en mainnet depende de una auditoría de seguridad externa.
Dos direcciones: la multisig y el vault
El diseño de SSP usa dos direcciones separadas para cada cartera multisig.
La dirección multisig guarda las reglas: la lista ordenada de claves de miembros, el umbral (la M de "M-de-N") y un contador de transacciones propuestas. Pertenece al programa de SSP.
La dirección del vault guarda el dinero: SOL y tokens SPL. Pertenece al System Program integrado de Solana y no almacena datos propios. El vault es la dirección de depósito: la que entregas a quien quiera pagarte.
Ambas son una Program Derived Address, o PDA: una dirección sin clave privada, colocada deliberadamente fuera de la curva criptográfica para que ninguna llave pueda controlarla. Solo el programa que la derivó puede autorizar movimientos desde ella. Ese detalle importa al final.
Cómo se calcula la dirección a partir de los miembros
Esta es la parte que hace la cartera autoinicializable. Para derivar la dirección multisig, en lenguaje sencillo: toma la etiqueta literal multisig, un hash SHA-256 de la lista ordenada de miembros y el umbral; luego pasa eso, junto con el ID de programa de SSP, a la función de derivación de direcciones de Solana. Tres detalles merecen atención.
Los miembros se ordenan y deduplican primero. Una cartera 2-de-3 con los miembros A, B, C produce la misma dirección tanto si los listas como C, A, B o B, C, A. El orden no importa; solo importa el conjunto.
Se usa el hash completo de 32 bytes, nunca una versión recortada. Truncar el hash abriría un ataque real: un atacante podría buscar un conjunto de miembros distinto que produzca el mismo valor recortado, registrar luego sus propios miembros en tu dirección y vaciar cualquier fondo que hubieras precargado. El hash completo de 32 bytes hace esa búsqueda astronómicamente costosa, así que nunca ocurre.
El umbral forma parte de la dirección. Una cartera 2-de-3 y una 3-de-3 con exactamente los mismos miembros son carteras distintas en direcciones distintas. Las reglas están grabadas en la identidad.
La dirección del vault se deriva luego de la dirección multisig más un pequeño número de índice (SSP siempre usa el índice 0), así que el vault también queda totalmente determinado por el conjunto de miembros y el umbral.
El resultado práctico: cualquiera puede calcular ambas direcciones sin conexión, antes de enviar una sola transacción. Puedes repartir la dirección del vault y recibir fondos en una cartera que, en la cadena, todavía no existe: la propiedad de Bitcoin, llevada a Solana.
Registro sin permiso: cualquiera puede activarla
La dirección de la cartera existe en cuanto conoces los miembros. Pero para gastar desde ella, las reglas tienen que escribirse en la cadena en algún momento; el programa llama a este paso initialize.
En la mayoría de las multisig de Solana, solo un creador privilegiado puede hacer el paso equivalente. En el programa de SSP, la inicialización es sin permiso: cualquiera puede hacerla. Sin cuenta de creador, sin firma de miembro, sin permiso especial. Normalmente el servicio de relay de SSP paga la pequeña tarifa de renta y activa la cartera, pero realmente da igual quién lo haga.
Eso suena alarmante hasta que ves la comprobación de seguridad. Cuando alguien inicializa la cartera, el programa recalcula el hash SHA-256 de la lista de miembros que aportó y rechaza la transacción a menos que ese hash coincida con el grabado en la dirección. El marco de cuentas de Solana vincula de forma independiente la dirección a ese mismo hash. Juntas, esas dos comprobaciones significan que la dirección canónica solo puede contener el conjunto canónico de miembros. Nadie puede registrar tu dirección con una lista de miembros de su elección: el hash no coincidiría y la transacción falla.
Por qué un desconocido que inicialice tu cartera no puede perjudicarte
Repasa lo que un atacante podría intentar realmente.
Inicializa con un conjunto de miembros distinto. Un conjunto distinto produce un hash distinto, que deriva una dirección distinta. El atacante simplemente ha creado su propia cartera no relacionada en otro lugar de Solana: sin conexión con tu vault, sin reclamo sobre tus fondos.
Inicializa con tu conjunto de miembros. El hash coincide, así que la transacción tiene éxito, pero todo lo que ha hecho es pagar tu tarifa de renta por ti. La cartera queda registrada con exactamente las reglas que esperabas, y el atacante no es miembro, así que no puede proponer, aprobar ni ejecutar nada. El dinero nunca está en la dirección multisig misma: está en el vault, que pertenece al sistema y no puede secuestrarse. Quienquiera que inicialice la cartera, y cuando sea, el resultado es la misma cartera canónica con las reglas correctas.
El umbral se comprueba al gastar, no al registrar
Este es el mismo modelo que usa la multisig P2WSH de Bitcoin, y conviene decirlo con claridad: el umbral M-de-N se aplica solo cuando los fondos se mueven, nunca en el registro.
El registro solo anota "estos son los miembros, este es el umbral". No pide firmas porque no puede causar ningún daño. La verdadera barrera es el flujo de gasto, donde el programa cuenta las aprobaciones y se niega a actuar hasta que suficientes miembros hayan dado el visto bueno. La dirección es el hash de las reglas; cualquiera puede financiarla; solo las firmas válidas pueden gastar. Para repasar qué significa "M-de-N", consulta 2-de-2 vs 2-de-3 vs M-de-N multisig.
El ciclo de vida completo, de principio a fin
Juntando las piezas, la vida de una cartera multisig de Solana de SSP:
- Derivar. Cualquiera calcula las direcciones multisig y del vault sin conexión a partir de los miembros y el umbral. Sin blockchain, sin coste.
- Precargar. Cualquiera envía SOL o tokens a la dirección del vault; esto funciona incluso antes de que la cartera se registre.
- Inicializar. Cualquiera, normalmente el relay de SSP, envía la transacción de registro sin permiso. El programa verifica el hash de miembros y escribe las reglas canónicas en la cadena.
- Proponer. Un miembro crea una propuesta de transacción, almacenada de forma compacta en una cuenta de propuesta dedicada.
- Aprobar. Cada miembro aprueba la propuesta, una vez cada uno. Las aprobaciones se acumulan en la cadena.
- Ejecutar. Cuando las aprobaciones alcanzan el umbral, cualquiera puede activar la ejecución. El programa primero marca la propuesta como ejecutada —una protección deliberada para que nunca se ejecute dos veces— y luego lleva a cabo cada instrucción, con el propio vault actuando como firmante.
Ese último paso es donde la dirección del vault sin clave rinde sus frutos. Como el vault es una PDA sin clave privada, ningún humano ni programa puede mover sus fondos firmando de la manera habitual. La única salida es que el programa de SSP ejecute una propuesta aprobada que haya alcanzado el umbral: "firma" por el vault presentando la receta de derivación del vault al runtime de Solana, un permiso que obtiene únicamente porque es el dueño de la dirección.
Sin creador, sin admin, sin rotación de llaves en el sitio
Dos propiedades finales unen el diseño.
El conjunto de miembros y el umbral son inmutables. Una vez inicializada la cartera, ninguna instrucción del programa puede cambiar sus miembros ni su umbral: no existe ruta de código para ello. Para cambiar quién controla una cartera —lo que otros sistemas llaman vagamente "rotar llaves"— creas una multisig nueva con el nuevo conjunto de miembros y mueves los fondos a ella. La dirección antigua conserva sus reglas antiguas para siempre.
No hay rol de creador ni clave de admin, nunca. Muchos diseños multisig mantienen una cuenta privilegiada que puede anular a los miembros o cambiar la configuración. El programa de SSP no tiene ninguna: nada que comprometer, ninguna clave de admin que suplantar, ningún creador que coaccionar. Los miembros y el umbral son toda la historia.
Ese minimalismo es una compensación deliberada: SSP construyó una primitiva pequeña y determinista en lugar de una plataforma de gobernanza con muchas funciones. El siguiente artículo, La multisig de Solana de SSP frente a Squads, compara este diseño con honestidad frente a Squads V4, la multisig de Solana madura, auditada y dominante. Para el contexto del producto, el anuncio de lanzamiento del soporte de Solana cubre lo que llegó en SSP Wallet v1.39.0.
La idea central es lo bastante pequeña como para tenerla en la cabeza: en la multisig de Solana de SSP, la dirección de la cartera es una huella de sus propias reglas. Conoce los miembros y el umbral, y conoces la dirección. No se necesita nada más, y no se confía en nada más.
