Por dentro de la arquitectura de abstracción de cuentas de SSP

SSP es una billetera autocustodia construida en torno a un multisig 2-de-2. Una clave vive en la extensión de navegador SSP Wallet, la segunda vive en la aplicación móvil SSP Key, y ninguna transacción se liquida a menos que ambos dispositivos la aprueben. En cadenas EVM, SSP cumple esa garantía con la abstracción de cuentas de ERC-4337: la billetera es un smart account cuya lógica de validación acepta una única firma Schnorr agregada construida a partir de las dos claves. Este artículo recorre esa arquitectura de principio a fin: cada componente, el flujo exacto de firma y la propiedad de seguridad que produce.

Si la abstracción de cuentas es nueva para ti, empieza por La abstracción de cuentas desde primeros principios y el explicador centrado en ERC-4337. Aquí asumimos que ya sabes a grandes rasgos qué son un smart account y una UserOperation, y nos centramos en cómo SSP los conecta entre sí.

Las piezas en las que se apoya SSP

Antes de trazar el flujo, conviene nombrar los componentes y lo que hace cada uno:

• El smart account. En cadenas EVM tu billetera SSP no es una EOA controlada por una sola clave. Es un smart account ERC-4337: un contrato que guarda tus fondos y contiene su propia lógica de validación. Esa lógica es el corazón del diseño: acepta una transacción solo cuando la firma suministrada coincide con la clave agregada esperada de la billetera.
• Los dos dispositivos. La clave 1 vive en la extensión de navegador SSP Wallet. La clave 2 vive en la aplicación móvil SSP Key. Cada dispositivo guarda una parte y produce una firma parcial. Ninguna parte puede autorizar nada por sí sola.
• La UserOperation. En lugar de una transacción normal, la extensión expresa tu intención como una UserOperation: un objeto estructurado que describe lo que el account debe hacer y la firma que lo autoriza.
• El bundler. Un bundler toma la UserOperation del mempool dedicado, la empaqueta en una transacción real en cadena y paga el gas de la capa base para enviarla.
• El EntryPoint. Un único contrato EntryPoint auditado es la entrada en cadena de toda operación ERC-4337. Llama a tu smart account para ejecutar la lógica de validación de ese account y luego dispara la ejecución si la validación pasa.

Un paymaster puede, opcionalmente, cubrir el gas de una UserOperation; ese es un tema propio, tratado en Patrocinio de gas y paymasters explicados.

El flujo de firma exacto

Esto es lo que ocurre, paso a paso, cuando envías una transacción desde SSP en una cadena EVM:

  SSP Wallet extension (key 1)          SSP Key mobile app (key 2)
        |                                     |
        | 1. initiate tx                      |
        | 2. build UserOperation              |
        | 3. partial Schnorr sig  --- push -->| 4. approve
        |                                     | 5. partial Schnorr sig
        |                                     |
        |        6. aggregate (MuSig2 / secp256k1)
        |                v
        |        ONE Schnorr signature
        |                |
        v                v
  7. UserOperation --> 8. bundler --> 9. EntryPoint --> smart account
                                                  |
                                          validate aggregate sig
                                                  |
                                         valid? --> execute call

Leído como prosa:

1. Inicias una transacción en la extensión de navegador SSP Wallet, que guarda la clave 1.
2. La extensión construye una UserOperation ERC-4337 que describe la acción.
3. La clave 1 produce una firma Schnorr parcial sobre esa operación.
4. La solicitud se envía a la aplicación móvil SSP Key (clave 2) para su aprobación.
5. La clave 2 produce su propia firma parcial.
6. Las dos parciales se agregan, al estilo MuSig2 sobre secp256k1, en una sola firma Schnorr.
7. La UserOperation, ya portando esa única firma agregada, está lista para enviarse.
8. Va a un bundler, que la empaqueta en una transacción y paga el gas.
9. El bundler la envía al contrato EntryPoint, que invoca el smart account de SSP. El account valida la única firma agregada contra la clave agregada esperada de la billetera y, si es válida, ejecuta la llamada.

Ambos dispositivos son necesarios para llegar al paso 6, que es lo que hace de esto un verdadero 2-de-2. Quita cualquiera de las parciales y la agregación no podrá producir una firma que el contrato acepte.

Por qué la cadena solo ve una firma

El detalle que hace elegante el diseño de SSP es la agregación del paso 6. La extensión y el teléfono no adjuntan cada uno una firma separada a la operación. Sus dos firmas Schnorr parciales se combinan —al estilo MuSig2, sobre la misma curva secp256k1 que Ethereum ya usa— en una única firma Schnorr. El smart account verifica esa única firma contra una única clave agregada esperada.

Esto tiene dos consecuencias en las que vale la pena detenerse:

• La huella en cadena se mantiene pequeña. La UserOperation lleva una firma, no dos. No hay una lista de firmantes que almacenar o recorrer, ni un bucle de verificación por firmante. El contrato hace la misma cantidad de trabajo de validación que haría para un solo firmante.
• La cadena no puede saber que es multisig. Lo que llega al EntryPoint parece una operación firmada ordinaria. La imposición del 2-de-2 ocurre en cómo se produjo la firma —entre dos dispositivos— y no en alguna estructura multiparte visible en cadena. Para un observador externo la billetera se comporta como cualquier otro smart account.

Esa es la diferencia entre el enfoque de SSP y un multisig ingenuo que publica N firmas separadas y verifica cada una. La mecánica de hacer multisig de esta forma en EVM se explora con más detalle en Multisig en EVM al estilo de la abstracción de cuentas.

Qué protege realmente cada dispositivo

Vale la pena ser preciso sobre la propiedad de seguridad, porque es el sentido mismo de la arquitectura.

• Ninguna clave por sí sola puede mover fondos. La clave 1 en la extensión puede construir una UserOperation y firmar su mitad, pero una media firma se agrega a algo que el contrato no aceptará. La clave 2 en el teléfono puede aprobar y firmar su mitad, pero no puede originar ni completar una transferencia por sí sola.
• Comprometer un dispositivo no es suficiente. Un atacante que controle por completo tu extensión de navegador aún no puede gastar, porque no puede producir la firma parcial de la clave 2 sin el teléfono. Lo contrario también se cumple. El modelo de amenaza que una EOA de una sola clave no puede sobrevivir —una clave filtrada, pérdida total— no aplica aquí.
• La aprobación es explícita y en una segunda pantalla. Como el paso 4 envía la solicitud a la aplicación SSP Key, ves y apruebas la operación en un dispositivo físicamente separado antes de que pueda agregarse y enviarse.

Esta es la misma propiedad 2-de-2 descrita en ¿Qué es el multisig 2-de-2?, realizada en cadenas EVM mediante abstracción de cuentas en lugar de un opcode multisig nativo.

Los beneficios, en resumen

Atando los hilos, la arquitectura da a los usuarios de SSP una combinación específica que es difícil de obtener de otra manera:

• Seguridad multisig en cada cadena EVM compatible. El mismo diseño 2-de-2 corre en Ethereum, Polygon, Base, BNB Smart Chain y Avalanche, porque ERC-4337 es un estándar a nivel de contrato y no una característica específica de cada cadena.
• Una huella pequeña en cadena. Una sola firma agregada significa que el smart account valida como un único firmante, manteniendo la verificación ligera.
• UX similar a la de un único firmante. Desde tu lado se siente como aprobar una transacción en dos dispositivos, no como armar un comité. No hay direcciones de cofirmantes que gestionar ni un contrato multisig separado que configurar por transferencia.
• No se requieren cambios en el protocolo. Como todo se apoya en ERC-4337, SSP consigue todo esto sin esperar a que la abstracción de cuentas en la capa base se despliegue.

Una nota sobre la auditoría

Una arquitectura de seguridad es tan confiable como su revisión. Los smart contracts de SSP fueron auditados por Halborn en 2025. Una auditoría externa no vuelve infalible a ningún sistema, pero es una señal de confianza significativa para la lógica del contrato que impone la regla 2-de-2 descrita arriba.

Adónde ir después

Este artículo trazó la abstracción de cuentas de SSP de principio a fin. Para profundizar en el estándar y los conceptos que la rodean:

• La abstracción de cuentas desde primeros principios: por qué las EOA son limitantes y qué significa la abstracción de cuentas.
• ¿Qué es la abstracción de cuentas (ERC-4337)?: el estándar de forma aislada, incluidos los papeles de la UserOperation, el bundler y el EntryPoint.
• Patrocinio de gas y paymasters explicados: cómo un paymaster puede cubrir el gas de una UserOperation.
• Multisig en EVM al estilo de la abstracción de cuentas: la mecánica del multisig en EVM con más detalle.

Para la especificación formal, consulta EIP-4337; para el esfuerzo más amplio, la hoja de ruta de abstracción de cuentas de Ethereum sigue hacia dónde se dirige. La conclusión: SSP convierte la promesa abstracta de un account programable en una billetera 2-de-2 concreta, donde dos dispositivos producen una firma y la cadena simplemente ve una operación válida.