El soporte de Solana en SSP pasa de devnet a mainnet. La misma autocustodia 2-de-2 que usas en Bitcoin y Ethereum cubre ahora SOL y tokens SPL reales, firmados a través del propio programa multisig de SSP, que corre en la mainnet de Solana en SSPWVu7dtTDkZYmDx73StqV46PioSmdiNE7igpjHK1r.
Lanzamos Solana primero en devnet, deliberadamente, en SSP Wallet v1.39.0. Todo lo que vino después se dedicó a la parte que es difícil de deshacer cuando hay dinero real de por medio: el programa en cadena, la forma en que tu dispositivo lo comprueba y la garantía de que el código que corre en mainnet es el código que publicamos.
Sin creador, sin coordinador
El multisig en Solana suele empezar con alguien que lo crea. Squads V4 —la opción madura y ampliamente usada, y con la que vale la pena compararse— crea una wallet con una instrucción en cadena que necesita dos cosas: un creador y una create_key aleatoria, fresca y de un solo uso. La dirección de la bóveda se deriva de esa clave aleatoria, lo que significa que la dirección no existe y no puede recibir fondos hasta que alguien ejecuta la transacción de creación, y que en ese momento hay una parte presente como creador.
El programa de SSP no tiene un paso de creación de esa forma. La dirección de tu bóveda es una huella del conjunto ordenado de miembros junto con el umbral de aprobación: nada más. Cualquiera que sepa quiénes son los miembros y cuántos deben aprobar puede calcular la dirección sin conexión, antes de que nada toque la cadena. El registro es sin permisos: el programa se limita a comprobar que los miembros que presentas realmente producen el hash de la dirección declarada, así que registrar no cambia nada sobre quién puede gastar.
El resultado es que no hay ningún creador en quien confiar, ningún registrador privilegiado y ninguna clave de administrador. El gasto está condicionado únicamente por la comprobación de umbral dentro de execute_transaction: la dirección es la regla, en lugar de un registro de quien la configuró.
Esa propiedad es la que permite que tus dos dispositivos se comporten en Solana igual que en el resto de SSP. Si el modelo es nuevo para ti, qué es realmente el multisig 2-de-2 es el lugar por donde empezar; la implementación de SSP en Solana entra en el programa en sí, y SSP frente a Squads V4 es la comparación completa.
Tu dispositivo no confía en nuestro relay
Las transacciones de Solana son opacas de una forma en que las de Bitcoin no lo son: lo que hace una transacción vive en datos de instrucción que una wallet debe decodificar antes de poder decirte algo veraz.
Por eso SSP la decodifica en tu dispositivo, byte a byte, usando la biblioteca de código abierto @runonflux/solana-multisig. Los destinatarios, los importes y los mints de tokens se verifican contra los bytes en bruto de la transacción en lugar de creerse a partir de lo que envía el relay. Si ambos discrepan, la firma queda bloqueada por completo: una discrepancia ahí indica un ataque activo, no un fallo de visualización.
Ese trabajo se publicó antes de mainnet en la v1.40.0, junto con un techo independiente para el reembolso de comisiones del paymaster y una lista blanca de instrucciones en las aprobaciones. Mainnet enciende un decodificador que lleva semanas en producción en devnet.
Builds que puedes verificar
El programa de mainnet se compila con un toolchain fijado y builds verificables, de modo que el bytecode desplegado en esa dirección puede reproducirse a partir del código publicado. No tienes que creernos sobre lo que está corriendo: puedes reconstruirlo y comparar.
Es la misma postura que la de los builds deterministas de la wallet: una afirmación de seguridad vale solo lo que valga tu capacidad de comprobarla por ti mismo.
Cómo empezar
Actualiza a la última versión de SSP Wallet y SSP Key y luego activa Solana desde el selector de cadenas. Con la sincronización por lotes de la v2 puedes habilitarla junto a cualquier otra cadena con una sola aprobación en tu Key.
A partir de ahí, Solana se comporta como cualquier otra cadena en SSP: aparece en el total de tu Portfolio, los envíos siguen el mismo flujo de componer → revisar → aprobar con la dirección completa del destinatario a la vista, y cada transacción se cofirma con tus dos dispositivos.
