Abstracción de cuentas más allá de Ethereum
La abstracción de cuentas suele presentarse como una historia de Ethereum: una forma de convertir una wallet de una sola clave en un smart account programable mediante ERC-4337. Pero la idea no se detiene en Ethereum L1. Viaja por dos caminos muy distintos: hacia fuera, por las cadenas EVM que comparten el modelo de ejecución de Ethereum, y de forma nativa, hacia cadenas diseñadas con la abstracción de cuentas integrada en el protocolo desde el primer día. Este artículo traza ese paisaje más amplio, explica en qué se diferencia la abstracción de cuentas nativa del estándar ERC-4337 superpuesto a Ethereum, y es cuidadoso con un límite en concreto: dónde termina el ecosistema general y dónde empieza lo que SSP realmente admite.
Este es el último artículo de nuestra serie sobre abstracción de cuentas. Si los conceptos básicos son nuevos para ti, empieza por Abstracción de cuentas desde los primeros principios y luego compara los dos modelos de cuenta en EOA frente a smart account: las diferencias que importan. Aquí asumimos que sabes a grandes rasgos qué es un smart account y ampliamos la mirada al resto del cripto.
El mismo estándar, allí donde corre el EVM
La primera forma en que se propaga la abstracción de cuentas es la más sencilla: viaja junto al EVM. ERC-4337 no es un cambio en el protocolo base. Es un estándar a nivel de contrato construido sobre un contrato EntryPoint, objetos UserOperation, bundlers y paymasters opcionales, nada de lo cual requiere modificaciones de consenso. Esa decisión de diseño tiene una consecuencia poderosa. Cualquier cadena que ejecute la Ethereum Virtual Machine puede alojar el mismo EntryPoint, la misma infraestructura de bundlers y los mismos contratos de smart account.
Por eso precisamente las principales L2 y sidechains EVM admiten ERC-4337 igual que Ethereum:
- Polygon ejecuta el EVM, así que el mismo contrato de smart account y el mismo
EntryPointse despliegan sin modificación. - Base es una L2 EVM donde la abstracción de cuentas ERC-4337 funciona igual que en L1.
- BNB Smart Chain es compatible con EVM y aloja el mismo estándar.
- Avalanche C-Chain ejecuta el EVM y admite la misma abstracción de cuentas a nivel de contrato.
Como el estándar es portable, la lógica de smart account de una wallet escrita para Ethereum se traslada a estas cadenas prácticamente sin cambios. Esa portabilidad es justo lo que permite a SSP ejecutar su diseño en todas las cadenas EVM que admite: el mismo contrato 2-de-2 se comporta de forma idéntica tanto si se despliega en Ethereum, Polygon, Base, BNB Smart Chain o Avalanche. Para la visión práctica, cadena por cadena, de usar SSP en estas redes, consulta Usar SSP en Polygon, Base y otras cadenas EVM.
Abstracción de cuentas nativa: cuando es el protocolo, no una capa
La segunda forma en que se propaga la abstracción de cuentas es radicalmente distinta. Algunas cadenas no esperaron a un estándar opcional: integraron la abstracción de cuentas directamente en el protocolo, de modo que no existe ninguna distinción entre "EOA y smart account". Cada cuenta es un smart account por defecto.
Starknet: cada cuenta es un contrato
Starknet ha tenido abstracción de cuentas desde el primer día. En Starknet no hay cuentas de propiedad externa en el sentido de Ethereum; cada cuenta es una cuenta de contrato, escrita en el lenguaje Cairo. Como el comportamiento de la cuenta se define mediante código de contrato a nivel de protocolo, los esquemas de firma, las reglas de validación, el multisig y la lógica de comisiones son propiedades de la propia cuenta y no funciones añadidas después.
El contraste con Ethereum es instructivo. En Ethereum, la cuenta por defecto es una EOA con una única comprobación ECDSA cableada, y ERC-4337 existe para superponer cuentas programables encima sin un hard fork. En Starknet no hay nada que superponer: la cuenta programable es la base. No hay un estándar EntryPoint aparte que adoptar porque la abstracción de cuentas no es opcional. La documentación de Starknet en docs.starknet.io describe este modelo de cuenta en detalle.
zkSync Era: AA nativa con paymasters integrados
zkSync Era adopta un enfoque nativo similar. La abstracción de cuentas forma parte del protocolo en lugar de ser un complemento, y el sistema incluye soporte de paymaster integrado a nivel de protocolo. En Ethereum, un paymaster es un contrato definido por el estándar ERC-4337 y enrutado a través del EntryPoint; en zkSync Era, la funcionalidad de paymaster es una característica de primera clase de la propia cadena, así que patrocinar comisiones o pagar el gas en otro token forma parte de cómo está diseñada la red para funcionar. La documentación de zkSync cubre su abstracción de cuentas nativa y su modelo de paymaster.
AA nativa frente a ERC-4337: la diferencia esencial
Vale la pena enunciar la distinción con claridad, porque es el corazón conceptual de este artículo:
- ERC-4337 es un estándar opcional superpuesto a un protocolo sin cambios. La capa base de Ethereum solo entiende de forma nativa las EOA y su única firma ECDSA. Los smart accounts existen porque los desarrolladores acordaron un conjunto común de componentes on-chain y off-chain —el
EntryPoint, el mempool alternativo, los bundlers— que simulan la abstracción de cuentas a nivel de protocolo sin un cambio de consenso. Es brillante precisamente porque no requirió ningún hard fork, y por la misma razón es portable a cualquier cadena EVM. - La abstracción de cuentas nativa está integrada en el protocolo. En Starknet y zkSync Era, la propia cadena trata cada cuenta como programable. No hay nada opcional, ningún estándar aparte que adoptar, ni distinción entre una cuenta "normal" y una inteligente: el smart account es la cuenta.
Ambas ofrecen los mismos beneficios al usuario final: múltiples firmantes, validación personalizada, lógica de recuperación y gas flexible. Sencillamente llegan desde direcciones opuestas: una como una capa cuidadosamente diseñada, la otra como una decisión de protocolo fundacional. Si quieres la especificación formal del enfoque por capas, EIP-4337 es la referencia canónica.
Dónde encaja SSP, y dónde no
Este es el límite que conviene precisar. SSP es una wallet autocustodial construida en torno a un multisig 2-de-2: una clave en la extensión de navegador SSP Wallet y la segunda en la app móvil SSP Key, sin que ningún dispositivo pueda mover fondos por sí solo. En cadenas EVM, SSP lo implementa como un smart account ERC-4337 cuya lógica de validación verifica una única firma Schnorr agregada construida a partir de ambas claves. Los smart contracts de SSP fueron auditados por Halborn en 2025.
Como ERC-4337 es portable por todo el EVM, el enfoque de SSP se traslada a las cadenas EVM que admite: Ethereum, Polygon, Base, BNB Smart Chain y Avalanche C-Chain. El mismo contrato de smart account 2-de-2 corre en todas ellas.
Starknet y zkSync Era aparecen en este artículo como parte del ecosistema más amplio: ejemplos de cadenas donde la abstracción de cuentas es nativa del protocolo. No forman parte del conjunto de cadenas admitidas por SSP. SSP lleva la abstracción de cuentas ERC-4337 a las cadenas EVM enumeradas arriba; no corre en Starknet, zkSync Era ni otras cadenas no EVM. Cuando leas sobre AA nativa en otros lugares del cripto, tómalo como contexto de lo extendido que está el modelo de smart account, no como una afirmación sobre dónde opera SSP.
Por qué esto importa
Si tomas distancia, el patrón es claro: la experiencia de smart account se está convirtiendo en el estándar en gran parte del cripto, no en una función de nicho para usuarios avanzados.
- En el EVM, ERC-4337 lleva cuentas programables a Ethereum y a cada cadena compatible sin un hard fork, que es lo que permite a una wallet como SSP ofrecer la misma seguridad 2-de-2 en Polygon, Base, BNB Smart Chain y Avalanche que ofrece en Ethereum.
- En las cadenas con abstracción nativa, la pregunta "¿es esto una EOA o un smart account?" sencillamente no se plantea, porque solo hay un tipo de cuenta y es programable.
Para un usuario de autocustodia, la conclusión es que el rígido modelo de una sola clave ya no es la única opción y, cada vez más, no es la opción por defecto. Ya llegue la abstracción de cuentas como un estándar por capas o como una característica nativa del protocolo, el destino es el mismo: cuentas que puedes programar, con reglas de seguridad —como el multisig de dos dispositivos de SSP— que una sola clave privada nunca podría imponer por sí misma. Para repasar cómo se compara ese modelo con la cuenta original de Ethereum, consulta EOA frente a smart account: las diferencias que importan, y para el estándar en aislamiento, ¿Qué es la abstracción de cuentas (ERC-4337)?.
