Solana plantea retirar gradualmente las durable nonces, un mecanismo que permite firmar transacciones sin conexión y enviarlas más tarde, pero su alternativa mantendría la aprobación de las claves almacenadas en frío. El cambio afectaría, sobre todo, a exchanges, custodios y tesorerías que utilizan este sistema: la clave seguiría autorizando las operaciones, aunque los activos pasarían a estar controlados por una dirección derivada de un programa.
Una nueva capa entre la clave y los fondos
El plan de descontinuación publicado por la Fundación Solana en octubre propone sustituir las durable nonces por programas de firma en cadena. Estos programas verificarían la autorización firmada fuera de línea y ejecutarían las instrucciones aprobadas.
En este diseño, una dirección derivada de un programa —conocida como PDA— controlaría las cuentas afectadas. La clave fría conservaría la capacidad de autorizar acciones, mientras que un operador conectado a internet enviaría la transacción y asumiría el pago de la comisión de red. La PDA no tendría una clave privada propia: su capacidad para actuar dependería de que el programa validase la firma original.
La derivación de esa dirección no transfiere automáticamente fondos ni permisos. Cada operador tendría que migrarlos de forma separada. El proceso puede incluir el traslado de SOL, de saldos de tokens y de permisos sobre los activos, como las facultades de acuñar o congelar tokens. En las cuentas de participación también sería necesario mover, según el caso, la autoridad del delegado, la de retirada o ambas.
Por eso, aprobar el nuevo software de firma sería solo una parte de la migración. Las entidades tendrían que revisar qué cuentas controla cada clave y qué permisos están asociados a ellas. La Fundación propone realizar estos cambios mientras las durable nonces sigan funcionando.
Qué cambia para las operaciones firmadas fuera de línea
Las durable nonces resuelven un problema de tiempo. Una transacción convencional depende de un blockhash reciente que deja de ser válido al cabo de un periodo limitado. Con un nonce almacenado, una clave fría puede aprobar una operación y permitir que su difusión se produzca más tarde.
La propuesta traslada esa lógica a programas ordinarios de Solana. En el diseño denominado Programmatic Signer, la clave fría firmaría un mensaje de autorización en lugar de la transacción que llega directamente a la red. Un intermediario incluiría esa aprobación en una transacción con un blockhash reciente, y el programa verificaría tanto la autorización como las instrucciones.
El otro candidato, Vector, compromete en la firma el conjunto principal de instrucciones, incluidos los datos y las cuentas utilizados para llamar a otros programas. En Programmatic Signer, el intermediario puede añadir instrucciones externas a la autorización; en Vector, las instrucciones que rodean la acción aprobada deben quedar incluidas antes de firmar. En ambos modelos, pagar la comisión no permite modificar la operación autorizada.
Los dos sistemas también contemplan que una ejecución fallida pueda reintentarse. Si los cambios se revierten junto con el avance del nonce, una aprobación no queda necesariamente invalidada por un primer intento fallido. Esa posibilidad introduce un riesgo operativo: una transacción podría quedar retenida y ejecutarse más adelante si no incorpora un plazo de caducidad. La revocación exigiría una autorización separada para avanzar el nonce.
Compatibilidad pendiente y calendario sin cerrar
El cambio no depende solo de la criptografía. Las aplicaciones tendrían que aceptar operaciones recibidas mediante una llamada entre programas, en lugar de exigir que lleguen como instrucciones principales de la transacción. Una firma válida de una PDA no garantiza que una aplicación permita ese recorrido.
La Fundación aún no ha fijado una fecha para retirar las durable nonces ni ha escogido entre Programmatic Signer y Vector. El periodo de migración previsto, de aproximadamente seis meses, queda condicionado a que exista una alternativa adecuada, auditada y desplegada en la red principal.
La documentación disponible de Programmatic Signer señala que su despliegue en devnet y sus auditorías estaban en curso, mientras que algunas herramientas de simulación, retransmisión y migración aún no estaban terminadas. Vector publica su código y sus identificadores de programa, pero su documentación no indica un estado de auditoría o despliegue en la red principal.
El debate llega además tras la fase final, el 9 de octubre, de una actualización que redujo a 200 milisegundos el intervalo de producción de bloques. Ese cambio deja menos margen temporal para las aprobaciones basadas en un blockhash reciente, aunque la propuesta sobre los nonces aborda una cuestión distinta: cómo conservar la aprobación fuera de línea y el control institucional de los fondos.
