El 16 de enero de 2025, SSP Wallet v1.9.0 cierra una revisión de seguridad de varias semanas con Halborn sobre los contratos Solidity de Account Abstraction de SSP — el Factory y el Account Implementation detrás de cada dirección de Ethereum y Sepolia. La auditoría salió limpia en lo que importa, con solo tres hallazgos Informativos y dos de prioridad Baja, todos en código no usado o muerto. Aun así, decidimos abordar cada uno de ellos, redeployar los contratos y enviar las versiones más limpias en v1.9.0. Ese redeploy es un cambio incompatible para los usuarios de Ethereum y Sepolia: tu dirección determinista en esas dos cadenas cambiará tras actualizar.
TL;DR
- Halborn auditó la parte Solidity de Account Abstraction de SSP: los contratos Factory y Account Implementation.
- Hallazgos: 3 Informativos, 2 Bajos, 0 Medios, 0 Altos. Todos en rutas de código no usadas o muertas. Los contratos desplegados antes eran y siguen siendo seguros.
- Aun así redeployamos para mantener una base de código totalmente limpia — nuevos contratos Factory y Account Implementation llegan en v1.9.0.
- Cambio incompatible: las direcciones de Ethereum y Sepolia cambian tras la actualización. Mueve los fondos antes de actualizar o contacta con soporte de SSP para una guía de migración.
- Las cadenas UTXO — Bitcoin, Zcash, Bitcoin Cash, Flux — no se ven afectadas.
Qué auditó Halborn
El alcance fue la parte Solidity de los contratos ERC-4337 con multisig Schnorr que enviamos en v1.6.0 y hemos iterado desde entonces. Concretamente: el repositorio @runonflux/account-abstraction — el contrato Factory que despliega de forma determinista una cuenta cuando un usuario transacciona por primera vez, y el contrato Account Implementation que define cómo esa cuenta valida UserOperations, comprueba las firmas Schnorr y sigue el flujo bundler-y-EntryPoint de ERC-4337.
El equipo técnico de Halborn ejecutó la batería completa de pruebas que reservan para contratos inteligentes de producción. El repositorio, en sus palabras, es robusto, respeta las recomendaciones de ERC-4337 e implementa Schnorr de forma limpia. Esa conclusión importa porque la implementación Schnorr es la parte del diseño con menor base de arte previo — todas las demás piezas del stack de AA han sido auditadas muchas veces en la industria, pero las firmas Schnorr agregadas dentro de un validador ERC-4337 son algo que construimos nosotros mismos.
Qué encontraron
El informe contiene 3 hallazgos Informativos y 2 de prioridad Baja — ningún Medio, ningún Alto, ningún Crítico. Puedes leer el informe completo en halborn.com/audits/influx-technologies/account-abstraction-schnorr-multisig.
Cada hallazgo se encuentra en código que estaba sin usar en los contratos en vivo o formaba parte de una ruta que no se ejecutaba contra fondos reales de usuarios — andamiaje defensivo, ramas residuales de una iteración anterior, ese tipo de cosas. Ninguno describe una vía para que un atacante tome fondos, falsifique una firma o rompa una cuenta. Los contratos desplegados en Ethereum mainnet permanecieron totalmente seguros durante la ventana de auditoría y después.
Por qué redeployamos de todos modos
Dos motivos. Primero, una base de código limpia es una forma de seguridad en sí misma. El código muerto que se compila en un contrato desplegado es código muerto sobre el que los futuros auditores, integradores y colaboradores deben razonar. Recortarlo reduce la superficie que cualquier revisión futura tendrá que mirar — menos ramas, menos suposiciones, menos formas de leer mal el contrato.
Segundo, cuando tienes la oportunidad de enviar la versión que aborda cada hallazgo en lugar de la que los pospone, la tomas. Así que lo hicimos. v1.9.0 se envía contra contratos Factory y Account Implementation recién desplegados que incorporan cada recomendación de Halborn. La rama estable del repositorio @runonflux/account-abstraction es ahora main (npm ^1.1.0); la rama master y npm ~1.0.0 se mantienen disponibles para quien desee permanecer en los contratos desplegados anteriores.
El CAMBIO INCOMPATIBLE para usuarios de Ethereum y Sepolia
Como el Factory es lo que deriva de forma determinista la dirección de tu cuenta a partir de tus claves públicas, redeployar el Factory significa que las mismas claves derivan una dirección distinta. Para usuarios con fondos en Ethereum mainnet o Sepolia, ese es el impacto práctico de v1.9.0: tras actualizar, la dirección que SSP te muestra para Ethereum o Sepolia es nueva. Cualquier ETH o ERC-20 que esté en la dirección antigua no se moverá por sí solo.
Hay dos maneras seguras de manejarlo. La forma directa es mover los fondos fuera de la dirección antigua antes de actualizar — envíalos a otra cartera o exchange, luego actualiza y después envíalos a tu nueva dirección. La otra vía, para usuarios que ya hayan actualizado o que tengan posiciones más grandes o complejas, es contactar con soporte de SSP para una guía de migración y así podemos guiarte para recuperar los fondos antiguos con los contratos antiguos.
Las cadenas UTXO no se ven afectadas. Las direcciones de Bitcoin, Zcash, Bitcoin Cash y Flux se derivan de tus claves sin pasar por un contrato EVM, por lo que v1.9.0 no cambia esas direcciones. Solo Ethereum y Sepolia están implicados.
Más por venir
Este artículo cubre específicamente la auditoría de los contratos de AA, en su día de lanzamiento. La historia más amplia — el conjunto completo de revisiones de Halborn sobre la SSP Wallet, los contratos y el SDK — está detallada en Dentro de las auditorías de Halborn de SSP en 2025, que pone esta auditoría en contexto con las otras dos.