Solana en SSP

Solana es rápida, barata y, cada vez más, el lugar por donde realmente circulan las stablecoins. También es la cadena donde históricamente ha sido más difícil hacer bien el multisig en autocustodia, no porque la criptografía sea complicada, sino porque el modelo de cuentas de Solana convierte «una dirección controlada por varias partes» en un objeto mucho más extraño de lo que es en Bitcoin.

SSP guarda SOL y tokens SPL en el mismo multisig 2-de-2 que ya usas para Bitcoin y Ethereum: una clave en la extensión del navegador, otra en tu teléfono, ambas necesarias para cada transacción. Este artículo explica qué significa eso en Solana concretamente: cómo se deriva la dirección, quién paga las comisiones, qué verifican tus dispositivos y qué partes difieren de verdad de las cadenas que ya conoces.

Qué es Solana desde la silla de la autocustodia

Solana es una única máquina de estados global que procesa transacciones en paralelo en lugar de una a una. Para quien custodia sus fondos, tres propiedades importan más que el titular sobre el rendimiento.

Primero, todo es una cuenta. Tu saldo, el mint de un token, el código de un programa y los datos que ese programa almacena viven en cuentas con una dirección y un propietario. Segundo, las cuentas pagan renta: para existir on-chain, una cuenta debe mantener un saldo mínimo de SOL proporcional a su tamaño. Ese depósito es reembolsable cuando la cuenta se cierra, pero es dinero real que tiene que salir de algún sitio. Tercero, las transacciones caducan rápido: una transacción normal de Solana referencia un blockhash reciente y deja de ser válida al cabo de aproximadamente un minuto.

Cada una de esas propiedades tiene una consecuencia directa para la firma con dos dispositivos, y cada una se aborda de forma explícita en SSP en lugar de disimularse. La documentación oficial de Solana es la fuente primaria del modelo de cuentas y renta si quieres la versión en crudo.

Una dirección sin creador

En la mayoría de los diseños de multisig de Solana, la cartera tiene que crearse. Alguien envía una transacción que la establece, y la dirección resultante depende de datos elegidos durante esa transacción, normalmente una clave aleatoria de un solo uso. El efecto práctico es que la dirección no existe hasta que un creador la trae al mundo, y no puede recibir fondos antes de eso.

El programa on-chain de SSP funciona de otra manera. La dirección de tu bóveda es una huella del conjunto ordenado de miembros más el umbral de aprobación, y nada más. Cualquiera que conozca los miembros y el umbral puede calcular la dirección sin conexión, antes de que nada toque la cadena. El registro es sin permisos: el programa solo comprueba que los miembros que presentas realmente producen el hash de la dirección reclamada, de modo que registrar no cambia nada sobre quién puede gastar.

Por eso no hay ningún creador en quien confiar, ningún registrador privilegiado y ninguna clave de administrador. El gasto está regido únicamente por la comprobación del umbral dentro del programa. Si quieres el panorama completo, por qué las direcciones multisig de Solana son difíciles trata el problema de fondo, el multisig autoiniciable de Solana trata el programa, y SSP frente a Squads V4 es la comparación lado a lado.

Si el propio modelo 2-de-2 es nuevo para ti, empieza por qué es el multisig 2-de-2.

Por qué dos dispositivos necesitaban un nonce duradero

Este es el problema que crea la caducidad. Tu extensión construye y firma una transacción. Tu teléfono tiene que aprobarla después. Si sales de la habitación, comes y vuelves, el blockhash que la transacción referenciaba lleva mucho tiempo muerto y hay que reconstruirlo todo.

SSP resuelve esto con una cuenta de nonce duradero derivada de tu dirección multisig. En lugar de un blockhash reciente, la transacción referencia un nonce que solo avanza cuando la transacción se confirma de verdad. La ventana de firma deja de ser un cronómetro. Puedes aprobar en el teléfono minutos u horas después y la transacción sigue siendo válida, pero solo puede usarse una vez, porque ejecutarla hace avanzar el nonce.

La cuenta de nonce se crea la primera vez que envías, y es una de las dos cuentas cuya renta aparece en el coste de tu primer envío. Nonces duraderos y firma con dos dispositivos profundiza en el tema.

Quién paga las comisiones

En Solana, la cuenta que paga la comisión de una transacción es el fee payer, y tiene que firmar. Eso crea un incómodo problema de arranque para un multisig recién estrenado: la bóveda necesita SOL para pagar la transacción que movería su SOL, y las cuentas que necesitan renta todavía no existen.

SSP usa un paymaster. El relay de SSP opera una cuenta que firma como fee payer, adelanta la comisión de red y cualquier renta, y es reembolsada por tu bóveda dentro de la misma transacción. No hay ningún paso aparte, ningún crédito concedido y ninguna forma de que el reembolso ocurra sin tus dos firmas: viaja dentro de la propuesta que aprueban tus dispositivos.

Dos consecuencias merecen quedarse grabadas:

• No necesitas prefinanciar una dirección con SOL para el gas. Recibe SOL, envía SOL. El primer envío es donde se crean las cuentas.
• Tu primer envío cuesta más que los siguientes. El primer envío paga la renta permanente de la cuenta multisig y de la cuenta de nonce; los envíos posteriores pagan poco más que la comisión de red. Las cifras exactas están en el artículo de comisiones de esta serie.

Si el concepto de paymaster no te resulta familiar, patrocinio de gas y paymasters, explicados cubre el patrón general: SSP ya usa la misma idea en las cadenas EVM, como se describe en Ethereum en SSP.

Qué puedes guardar

Solana en SSP admite SOL nativo y tokens SPL. De serie eso incluye el mint oficial de USDC de Circle y FLUX en Solana, y SSP resuelve otros tokens SPL que encuentre en tu bóveda.

La distinción que despista a mucha gente: en Solana no guardas un token en tu dirección principal. Cada token vive en su propia cuenta de token asociada, propiedad de tu dirección, una por mint. Esa cuenta también necesita renta, y por eso enviar un token SPL a alguien que nunca ha tenido ese token cuesta un poco más: estás pagando por traer su cuenta de token a la existencia. SSP la crea automáticamente como parte de la transferencia en lugar de fallar con un error, y el artículo sobre cuentas de token de esta serie desgrana los detalles.

Qué comprueban tus dispositivos antes de firmar

Las transacciones de Solana son opacas de una forma en que las de Bitcoin no lo son. Lo que hace una transacción vive dentro de los datos de instrucción, y una cartera tiene que decodificar esos datos antes de poder decirte nada cierto sobre ellos. Una cartera que simplemente muestra lo que le dijo un servidor te está pidiendo que confíes en el servidor.

SSP decodifica la transacción en tus propios dispositivos, byte a byte, usando la librería de código abierto @runonflux/solana-multisig. El destinatario, el importe y el mint del token se leen de los bytes en crudo y se comparan con lo que se está mostrando. Si no coinciden, la firma se bloquea por completo: una discrepancia en ese punto indica un ataque activo, no un fallo de representación. En las transferencias SPL, los decimales del token van embebidos en la propia instrucción firmada, de modo que un mint que declare decimales distintos hace que el programa on-chain rechace la transacción.

El mismo principio rige el programa: las compilaciones de mainnet son reproducibles a partir del código publicado, así que el bytecode desplegado en SSPWVu7dtTDkZYmDx73StqV46PioSmdiNE7igpjHK1r puede reconstruirse y compararse de forma independiente. Una afirmación de seguridad vale exactamente lo que tu capacidad de comprobarla por ti mismo.

Cómo empezar

Actualiza SSP Wallet y SSP Key a la última versión y activa Solana desde el selector de cadenas. Con la sincronización por lotes de v2 puedes activarla junto con cualquier otra cadena con una sola aprobación en el teléfono. Si aún no has configurado SSP, configurar tu primera cartera SSP es el punto de partida.

A partir de ahí Solana se comporta como cualquier otra cadena en SSP: cuenta para el total de tu portafolio, los envíos siguen el mismo flujo de componer → revisar → aprobar con la dirección completa del destinatario en pantalla, y cada transacción la cofirman tus dos dispositivos. El anuncio del lanzamiento en mainnet cubre qué se publicó y cuándo.