Entre v1.29.0 el 2025-12-27 y v1.30.0 el 2026-01-02, SSP lanzó dos versiones que parecen pequeñas en el changelog y grandes en el diagrama de arquitectura. v1.29.0 añadió autenticación de solicitudes — el monedero verifica el origen y la integridad de cada solicitud dApp que recibe. v1.30.0 añadió SSP Identity Signing — el monedero puede probar su propia identidad ante un servicio remoto, no solo firmar una transacción. Juntas endurecen la superficie de solicitudes dApp que se abrió con WalletConnect, y convierten la función de Identidad original en una primitiva de primera clase que los servicios pueden desafiar.
Llega la autenticación de solicitudes (v1.29.0)
Una solicitud dApp — firma esto, aprueba aquello, cambia a esta cadena — llega al monedero por un transporte. Con WalletConnect ese transporte es una sesión retransmitida; con el proveedor en página es un mensaje de la extensión de Chrome. Cada uno tiene al menos una brecha de confianza: el relé puede ser suplantado, la página puede ser un clon de phishing, el mensaje puede ser falsificado.
La autenticación de solicitudes cierra esas brechas del lado del monedero. Antes de que SSP pinte la pantalla de confirmación, verifica quién pregunta y qué pide. El origen reclamado por la solicitud se compara con el transporte que la entregó. La carga útil se comprueba en integridad — el monedero no firma una solicitud que haya sido modificada en tránsito. Y la solicitud se contrasta con el estado de sesión que el monedero ya guarda, para que una solicitud reproducida desde otra sesión no se cuele con el emparejamiento de otra persona.
Nada de esto cambia lo que ves cuando una dApp legítima te pide firmar. La pantalla de confirmación luce igual. Lo que cambia es que el camino entre la dApp y esa pantalla ahora tiene barandas que el monedero impone por sí mismo, en vez de confiar en que el transporte diga la verdad sobre para quién entrega.
Sigue Identity Signing (v1.30.0)
Una semana después, v1.30.0 fue en la dirección opuesta. Hasta entonces, una Identidad SSP podía firmar mensajes — cadenas que prueban que el usuario controla una clave. v1.30.0 añade la capacidad de firmar como una identidad: un servicio remoto puede emitir un reto que nombre la Identidad SSP que espera, y el monedero devuelve una firma que liga la respuesta a esa identidad de un modo que el servicio puede verificar.
La diferencia es sutil y de peso. Firmar un mensaje prueba que una clave controla algo. La firma de identidad prueba que una clave controla una identidad nombrada — un identificador estable que el servicio ya ha asociado con permisos, saldos o suscripciones. Para servicios que necesitan saber no solo «¿hay un usuario ahí?» sino «¿es el mismo usuario que abrió esta cuenta?», la firma de identidad cierra el círculo. v1.30.0 también pulió el manejo de pop-ups de solicitudes — menos parpadeo, menos pop-ups perdidos, vuelta al foco más rápida.
Por qué importa para las dApps
El modelo de amenazas dApp comparte un puñado de causas raíz. Suplantación de origen — una página maliciosa finge ser de confianza. Solicitudes reproducidas — una carga firmada de una sesión se captura y se envía en otra. Superficies de phishing — una solicitud que luce legítima en la pantalla de confirmación va en realidad al contrato de un atacante.
La autenticación de solicitudes estrecha las tres porque el monedero deja de tratar al transporte como autoridad. El origen debe coincidir con el transporte, la carga útil debe coincidir con lo enviado, la sesión debe coincidir con la emparejada. Cada chequeo es pequeño por sí solo; juntos hacen que la pantalla de confirmación sea algo en lo que el usuario puede confiar para reflejar la realidad. La firma de identidad estrecha otro ataque — toma de cuenta por reemparejado — porque un servicio que pide al monedero firmar como una identidad nombrada convierte «un monedero inició sesión» en un enlace verificable.
Cómo encaja con WalletConnect
WalletConnect abrió la puerta a miles de dApps. v1.29.0 le puso la cerradura, y v1.30.0 le puso el timbre. Ambas caen sobre la misma superficie: el flujo de solicitudes. La autenticación de solicitudes garantiza que la solicitud que ve el monedero es la que envió la dApp. La firma de identidad garantiza que la respuesta que ve la dApp es la que envió tu monedero, firmada por la identidad que la dApp esperaba. La pareja convierte una sesión WalletConnect de «dos extremos intercambiando datos» en «dos extremos que pueden probarse mutuamente quiénes son».
De Identidad a Identity-Signing
La función original de Identidad SSP dio al monedero una superficie de identidad estable — una dirección derivada para mensajería y pruebas, separada de las direcciones transaccionales desde las que gastas. Esa fue la introducción. v1.30.0 es la continuación: la misma identidad, ahora usable como credencial que un servicio puede pedir por nombre y verificar de su lado.
Así es como un monedero se convierte en una primitiva de identidad de primera clase en vez de un mero portador de claves. v1.29.0 hace los inputs confiables; v1.30.0 hace los outputs verificables. La mayoría de usuarios nunca verá la diferencia directamente. Las dApps y servicios que integren contra esta superficie, en cambio, encontrarán que SSP ya puede probar quién es y verificar quién pregunta — cada vez.