6 publicaciones etiquetados con "Account Abstraction"

Durante quince años, la experiencia de incorporación a las criptomonedas ha estado rota de forma inexcusable. Los nuevos usuarios descargan una billetera, son bombardeados con doce palabras aleatorias que no entienden, descubren que necesitan ETH para hacer cualquier cosa ( pero no pueden comprar ETH sin tener primero ETH para el gas ) y abandonan frustrados antes de completar una sola transacción. La industria llamó a esto "descentralización". Los usuarios lo llamaron diseño hostil.

La abstracción de cuentas — específicamente ERC-4337 junto con la actualización EIP-7702 de Ethereum en mayo de 2025 — finalmente está arreglando lo que nunca debió estar roto. Se han desplegado más de 40 millones de cuentas inteligentes en Ethereum y redes de Capa 2, con casi 20 millones creadas solo en 2024. El estándar ha permitido más de 100 millones de UserOperations, lo que marca un aumento de 10 veces con respecto a 2023. Y con el 87 % de esas transacciones patrocinadas por paymasters, estamos presenciando la muerte de la paradoja de "necesitas ETH para usar Ethereum".

Esto no es una mejora incremental; es el punto de inflexión en el que las criptomonedas dejan de castigar a los usuarios por no ser criptógrafos.

El hito de las 40 millones de cuentas inteligentes: ¿Qué cambió?​

La abstracción de cuentas no es algo nuevo; los desarrolladores la han discutido desde los inicios de Ethereum. Lo que cambió en 2024-2025 fue la infraestructura de despliegue, el soporte de las billeteras y el escalado de la Capa 2 que hizo que las cuentas inteligentes fueran económicamente viables.

ERC-4337, finalizado en marzo de 2023, introdujo una forma estandarizada de implementar billeteras de contratos inteligentes sin cambiar el protocolo principal de Ethereum. Funciona a través de UserOperations — pseudotransacciones agrupadas y enviadas por nodos especializados llamados bundlers — que habilitan funciones imposibles con las cuentas de propiedad externa ( EOA ) tradicionales:

• Transacciones sin gas: Los paymasters patrocinan las tarifas de gas, eliminando el problema de la financiación inicial con ETH.
• Transacciones por lotes: Agrupan múltiples operaciones en una sola, reduciendo costos y clics.
• Recuperación social: Permiten recuperar cuentas a través de contactos de confianza en lugar de frases semilla.
• Claves de sesión: Otorgan permisos temporales a las aplicaciones sin exponer las claves maestras.
• Seguridad programable: Lógica de validación personalizada, límites de gasto y detección de fraude.

El hito de los 40 millones de despliegues representa un crecimiento de 7 veces año tras año. Casi la mitad de esas cuentas se crearon en 2024, acelerándose a lo largo de 2025 a medida que las principales billeteras y Capas 2 adoptaron la infraestructura ERC-4337.

Base, Polygon y Optimism lideran la adopción. La integración de Base con Coinbase Wallet permitió una incorporación sin gas para millones de usuarios. El sólido ecosistema de juegos de Polygon aprovecha las cuentas inteligentes para las economías internas del juego sin requerir que los jugadores gestionen llaves privadas. La estandarización de OP Stack de Optimism ayudó a que las L2 más pequeñas adoptaran la abstracción de cuentas sin implementaciones personalizadas.

Pero el verdadero catalizador fue EIP-7702, que se activó con la actualización Pectra de Ethereum el 7 de mayo de 2025.

EIP-7702: Cómo actualizar 300 millones de billeteras existentes​

Las cuentas inteligentes ERC-4337 son potentes, pero son cuentas nuevas. Si has usado Ethereum desde 2015, tus activos residen en una EOA — un simple par clave-valor donde la llave privada lo controla todo. Migrar esos activos a una cuenta inteligente requiere transacciones, tarifas de gas y riesgo de errores. Para la mayoría de los usuarios, esa fricción era demasiado alta.

EIP-7702 resolvió esto permitiendo que las EOA existentes ejecuten temporalmente código de contrato inteligente durante las transacciones. Introduce un nuevo tipo de transacción ( 0x04 ) donde una EOA puede adjuntar bytecode ejecutable sin convertirse permanentemente en un contrato.

Así es como funciona: el propietario de una EOA firma un "designador de delegación" — una dirección que contiene el código ejecutable que su cuenta adopta temporalmente. Durante esa transacción, la EOA adquiere capacidades de contrato inteligente: operaciones por lotes, patrocinio de gas y lógica de validación personalizada. Una vez completada la transacción, la EOA vuelve a su estado original, pero la infraestructura ahora la reconoce como compatible con la abstracción de cuentas.

Esto significa que más de 300 millones de direcciones de Ethereum existentes pueden obtener funciones de cuenta inteligente sin migrar activos ni desplegar nuevos contratos. Billeteras como MetaMask, Trust Wallet y Ambire pueden actualizar las cuentas de los usuarios de forma transparente, permitiendo:

• Incorporación sin gas: Las aplicaciones patrocinan el gas para los nuevos usuarios, eliminando la paradoja del ETH.
• Agrupación de transacciones: Aprueba y canjea tokens en un solo clic en lugar de dos transacciones.
• Delegación a esquemas de claves alternativos: Usa Face ID, passkeys o billeteras de hardware como autenticación principal.

Las principales billeteras implementaron el soporte para EIP-7702 a las pocas semanas de la actualización Pectra. Ambire y Trust Wallet lanzaron el soporte de inmediato, dejando las EOA de sus usuarios listas para la abstracción de cuentas sin necesidad de migración manual. Esto no fue solo una actualización de funciones; fue reacondicionar toda la base instalada de usuarios de Ethereum con una UX moderna.

La combinación de ERC-4337 ( nuevas cuentas inteligentes ) y EIP-7702 ( cuentas existentes actualizadas ) crea un camino hacia más de 200 millones de cuentas inteligentes para finales de 2025, según estiman las proyecciones de la industria. Eso no es exageración; es el resultado natural de eliminar la fricción de incorporación que las criptomonedas se impusieron a sí mismas sin ninguna buena razón.

100 millones de UserOperations: La verdadera métrica de adopción​

Los despliegues de cuentas inteligentes son una métrica de vanidad si nadie los utiliza. Las UserOperations —los paquetes similares a transacciones que envían las cuentas inteligentes ERC-4337— cuentan la historia real.

El estándar ERC-4337 ha habilitado más de 100 millones de UserOperations, frente a los 8,3 millones en 2023. Eso es un aumento de 12 veces en solo un año, impulsado principalmente por el gaming, DeFi y los flujos de incorporación (onboarding) sin gas.

El 87 % de esas UserOperations fueron patrocinadas por gas por paymasters: contratos inteligentes que pagan las tarifas de transacción en nombre de los usuarios. Esta es la característica estrella. En lugar de obligar a los usuarios a adquirir ETH antes de interactuar con su aplicación, los desarrolladores pueden patrocinar el gas e incorporar usuarios al instante. ¿El coste? Unos pocos céntimos por transacción. ¿El beneficio? Eliminar el punto de fricción número uno en la incorporación al mundo cripto.

Los paymasters funcionan en tres modos:

1. Patrocinio total: La aplicación paga todas las tarifas de gas. Se utiliza para la incorporación, referencias o campañas promocionales.
2. Pago con ERC-20: Los usuarios pagan el gas en USDC, DAI o tokens nativos de la aplicación en lugar de ETH. Es común en el gaming, donde los jugadores ganan tokens pero no poseen ETH.
3. Patrocinio condicional: Las tarifas de gas se patrocinan si se cumplen ciertas condiciones (por ejemplo, la primera transacción, el valor de la transacción supera un umbral, el usuario fue referido por un miembro existente).

El impacto práctico: un nuevo usuario puede pasar del registro a la primera transacción en menos de 60 segundos sin tocar un intercambio centralizado, sin descargar múltiples carteras y sin entender las tarifas de gas. Se registran con correo electrónico y contraseña (o autenticación social), y la aplicación patrocina sus primeras transacciones. Para cuando necesitan entender las carteras y las claves, ya están usando la aplicación y experimentando su valor.

Así es como funcionan las aplicaciones Web2. Así es como el mundo cripto debería haber funcionado siempre.

Transacciones sin gas: El fin del problema del arranque (bootstrapping) de ETH​

El problema de "necesitas ETH para usar Ethereum" ha sido el fallo de UX más vergonzoso de las criptomonedas. Imagine decirles a los usuarios de una nueva aplicación: "Antes de poder probar esto, debe ir a un servicio independiente, verificar su identidad, comprar la moneda de la red y luego transferirla a esta aplicación. Además, si se queda sin esa moneda, ninguno de sus otros fondos funcionará".

Los paymasters terminaron con este absurdo. Los desarrolladores ahora pueden incorporar a usuarios que tienen cero ETH, patrocinar sus primeras transacciones y permitirles interactuar con DeFi, gaming o aplicaciones sociales de inmediato. Una vez que los usuarios ganan familiaridad, pueden hacer la transición a la autocustodia y gestionar el gas ellos mismos, pero la experiencia inicial no castiga a los recién llegados por no entender los aspectos internos de la blockchain.

El Paymaster de Circle es un ejemplo excelente. Permite que las aplicaciones patrocinen las tarifas de gas para los usuarios que pagan en USDC. Un usuario con USDC en su cartera puede transaccionar en Ethereum o Capas 2 sin tener que adquirir ETH nunca. El paymaster convierte USDC para cubrir el gas en segundo plano, de forma invisible para el usuario. Para las aplicaciones centradas en stablecoins (remesas, pagos, ahorros), esto elimina la carga mental de gestionar un token de gas volátil.

La infraestructura de paymaster de Base permitió a Coinbase incorporar a millones de usuarios a DeFi sin la complejidad cripto. Coinbase Wallet usa Base por defecto, patrocina las transacciones iniciales y permite a los usuarios interactuar con aplicaciones como Uniswap o Aave antes de entender qué es el gas. Para cuando los usuarios necesitan comprar ETH, ya están experimentando valor y tienen contexto sobre por qué el sistema funciona de la manera en que lo hace.

Las plataformas de gaming como Immutable X y Treasure DAO utilizan paymasters para subvencionar las transacciones de los jugadores. Las acciones dentro del juego —mintear objetos, comerciar en mercados, reclamar recompensas— ocurren instantáneamente sin interrumpir el juego para aprobar transacciones de gas. Los jugadores ganan tokens a través del juego, que luego pueden usar para el gas o para comerciar, pero la experiencia inicial no tiene fricciones.

El resultado: decenas de millones de dólares en tarifas de gas patrocinadas por aplicaciones en 2024 - 2025. Eso no es caridad; es coste de adquisición de clientes. Las aplicaciones han decidido que pagar entre 0,02 $- 0,10$ por transacción para incorporar usuarios es más barato y efectivo que obligar a los usuarios a navegar primero por intercambios centralizados.

Transacciones por lotes: Un clic, múltiples acciones​

Uno de los aspectos más frustrantes de la UX tradicional de Ethereum es la necesidad de aprobar cada acción por separado. ¿Quiere intercambiar USDC por ETH en Uniswap? Eso requiere dos transacciones: una para aprobar que Uniswap gaste su USDC y otra para ejecutar el intercambio (swap). Cada transacción requiere una ventana emergente de la cartera, la confirmación de la tarifa de gas y el tiempo de confirmación del bloque. Para los nuevos usuarios, esto da la sensación de que la aplicación está rota. Para los usuarios experimentados, es simplemente molesto.

ERC-4337 y EIP-7702 permiten la agrupación de transacciones (batching), donde múltiples operaciones se agrupan en una sola UserOperation. Ese mismo intercambio en Uniswap se convierte en un clic, una confirmación y una tarifa de gas. La cuenta inteligente ejecuta internamente la aprobación y el intercambio de forma secuencial, pero el usuario solo ve una única transacción.

Los casos de uso se extienden mucho más allá de DeFi:

• Minteo de NFT: Aprobar USDC, mintear el NFT y listarlo en el mercado en una sola transacción.
• Gaming: Reclamar recompensas, mejorar objetos y hacer staking de tokens simultáneamente.
• Gobernanza de DAO: Votar en múltiples propuestas en una sola transacción en lugar de pagar gas por cada una.
• Aplicaciones sociales: Publicar contenido, dar propinas a creadores y seguir cuentas sin confirmaciones por cada acción.

Esto no es solo un pulido de UX; cambia fundamentalmente la forma en que los usuarios interactúan con las aplicaciones on-chain. Los flujos complejos de múltiples pasos que antes se sentían toscos y caros ahora se sienten instantáneos y cohesivos. La diferencia entre "esta aplicación es complicada" y "esta aplicación simplemente funciona" a menudo se reduce al procesamiento por lotes (batching).

Recuperación social: El fin de la ansiedad por la frase semilla​

Pregunte a cualquier usuario que no sea nativo de las criptomonedas qué es lo que más teme de la autocustodia, y la respuesta es invariablemente: "¿Qué pasa si pierdo mi frase semilla?". Las frases semilla son seguras en teoría, pero catastróficas en la práctica. Los usuarios las escriben en papel (se pierden o dañan fácilmente), las guardan en gestores de contraseñas (punto único de fallo) o no hacen ninguna copia de seguridad (pérdida garantizada en caso de fallo del dispositivo).

La recuperación social invierte el modelo. En lugar de un mnemónico de 12 palabras como único método de recuperación, las cuentas inteligentes permiten a los usuarios designar "guardianes" de confianza —amigos, familiares o incluso dispositivos de hardware— que pueden restaurar colectivamente el acceso si se pierde la clave principal.

Así es como funciona: un usuario configura su cuenta inteligente y designa tres guardianes (podría ser cualquier número y umbral, por ejemplo, 2 de 3, 3 de 5). Cada guardián posee un fragmento de recuperación —una clave parcial que, por sí sola, no puede acceder a la cuenta. Si el usuario pierde su clave principal, se pone en contacto con los guardianes y solicita la recuperación. Una vez que se alcanza el umbral (por ejemplo, 2 de los 3 guardianes lo aprueban), el acceso de la cuenta inteligente se transfiere a una nueva clave controlada por el usuario.

Argent fue pionero en este modelo en 2019. Para 2025, Argent ha habilitado la recuperación social para cientos de miles de usuarios, con tasas de éxito de recuperación superiores al 95 % para los usuarios que pierden sus dispositivos. El cambio mental es significativo: en lugar de "necesito proteger esta frase semilla para siempre o lo perderé todo", se convierte en "necesito mantener relaciones con personas en las que confío, algo que ya estoy haciendo".

Ambire Wallet adoptó un enfoque híbrido, combinando la autenticación por correo electrónico / contraseña con la recuperación social opcional para cuentas de alto valor. Los usuarios que prefieren la simplicidad pueden confiar en la recuperación basada en correo electrónico (con fragmentos de claves cifrados almacenados en varios servidores). Los usuarios avanzados pueden añadir una capa de recuperación social para obtener seguridad adicional.

La crítica: la recuperación social no es puramente trustless —requiere confiar en que los guardianes no coludirán. Es justo. Pero para la mayoría de los usuarios, confiar en tres amigos es mucho más práctico que confiar en sí mismos para no perder nunca un trozo de papel. La postura maximalista de las criptomonedas sobre la "autocustodia pura" ha hecho que el ecosistema sea inutilizable para el 99 % de la humanidad. La recuperación social es un compromiso pragmático que permite la incorporación sin sacrificar la seguridad en modelos de amenaza realistas.

Claves de sesión: Permisos delegados sin exposición​

Las EOA tradicionales son de todo o nada: si una aplicación tiene su clave privada, puede vaciar toda su billetera. Esto crea un dilema para las aplicaciones interactivas (juegos, aplicaciones sociales, bots de trading automatizados) que necesitan la firma frecuente de transacciones sin la intervención constante del usuario.

Las claves de sesión resuelven esto otorgando permisos temporales y limitados a las aplicaciones. El propietario de una cuenta inteligente puede crear una clave de sesión que sea válida por una duración específica (por ejemplo, 24 horas) y solo para acciones específicas (por ejemplo, operar en Uniswap, acuñar NFT, publicar en una aplicación social). La aplicación posee la clave de sesión, puede ejecutar transacciones dentro de esas restricciones, pero no puede acceder a los fondos completos de la cuenta ni realizar acciones no autorizadas.

Casos de uso que explotan en 2025-2026:

• Juegos: los jugadores otorgan claves de sesión a los clientes de juegos, lo que permite transacciones instantáneas dentro del juego (reclamar botines, intercambiar artículos, mejorar personajes) sin ventanas emergentes de la billetera cada 30 segundos. La clave de sesión se limita a los contratos relacionados con el juego y caduca una vez que finaliza la sesión.

• Bots de trading: los usuarios de DeFi crean claves de sesión para estrategias de trading automatizadas. El bot puede ejecutar operaciones, reequilibrar carteras y reclamar rendimientos, pero no puede retirar fondos ni interactuar con contratos fuera de la lista blanca.

• Aplicaciones sociales: las alternativas descentralizadas a Twitter / Reddit utilizan claves de sesión para permitir que los usuarios publiquen, comenten y den propinas sin aprobar cada acción. La clave de sesión se limita a las interacciones con contratos sociales y tiene un límite de gasto para las propinas.

El modelo de seguridad consiste en permisos limitados en tiempo y alcance, exactamente como funciona OAuth para las aplicaciones Web2. En lugar de dar a una aplicación acceso total a la cuenta, se otorgan permisos específicos por un tiempo limitado. Si la aplicación se ve comprometida o se comporta de forma maliciosa, el daño en el peor de los casos se limita al alcance y la duración de la clave de sesión.

Esta es la expectativa de experiencia de usuario (UX) que los usuarios traen de la Web2. El hecho de que las criptomonedas no hayan tenido esto durante 15 años es inexcusable, y la abstracción de cuentas finalmente lo está solucionando.

Base, Polygon, Optimism: Donde viven realmente 40 millones de cuentas inteligentes​

Los 40 millones de despliegues de cuentas inteligentes no están distribuidos uniformemente; se concentran en las Capas 2 donde las tarifas de gas son lo suficientemente bajas como para que la abstracción de cuentas sea económicamente viable.

Base lidera la adopción, aprovechando la distribución de Coinbase para incorporar a usuarios minoristas a gran escala. Coinbase Wallet utiliza Base de forma predeterminada para los nuevos usuarios, con cuentas inteligentes creadas de forma transparente. La mayoría de los usuarios ni siquiera se dan cuenta de que están usando una cuenta inteligente: se registran con el correo electrónico, comienzan a realizar transacciones y experimentan una incorporación sin gas sin entender la tecnología subyacente. Ese es el objetivo. Las criptomonedas no deberían requerir que los usuarios entiendan los árboles de Merkle y las curvas elípticas antes de que puedan probar una aplicación.

El ecosistema de juegos de Base se beneficia enormemente de la abstracción de cuentas. Los juegos creados en Base utilizan claves de sesión para permitir una jugabilidad sin fricciones, transacciones por lotes para reducir la latencia de las acciones dentro del juego y paymasters para subsidiar la incorporación de jugadores. El resultado: jugadores con cero experiencia en cripto pueden empezar a jugar juegos Web3 sin notar que están en una cadena de bloques.

Polygon tuvo un impulso temprano con plataformas de juegos y NFT que adoptaron el ERC-4337. Las bajas tarifas de Polygon (a menudo < $ 0,01 por transacción) hacen que el gas patrocinado por paymasters sea económicamente sostenible. Proyectos como Aavegotchi, Decentraland y The Sandbox utilizan cuentas inteligentes para eliminar la fricción de los usuarios que quieren interactuar con mundos virtuales, no gestionar billeteras.

Polygon también se asoció con grandes marcas (Starbucks Odyssey, Reddit Collectible Avatars, Nike .SWOOSH) para incorporar a millones de usuarios no cripto. Estos usuarios no ven billeteras, frases semilla o tarifas de gas; ven programas de fidelización gamificados y coleccionables digitales. Internamente, están utilizando cuentas inteligentes habilitadas para la abstracción de cuentas.

El estándar OP Stack de Optimism hizo que la abstracción de cuentas fuera portátil a través de los rollups. Cualquier cadena OP Stack puede heredar la infraestructura ERC-4337 de Optimism sin una implementación personalizada. Esto creó un efecto de red: los desarrolladores crean aplicaciones habilitadas para la abstracción de cuentas una vez y las despliegan en Base, Optimism y otras cadenas OP Stack con modificaciones mínimas.

El enfoque de Optimism en la financiación de bienes públicos también incentivó a los desarrolladores de billeteras a adoptar la abstracción de cuentas. Las rondas de Financiación Retroactiva de Bienes Públicos (RPGF) recompensaron explícitamente los proyectos que mejoraban la UX de Ethereum, y las billeteras de abstracción de cuentas recibieron asignaciones significativas.

El patrón es: bajas tarifas + canales de distribución + herramientas para desarrolladores = adopción. Las cuentas inteligentes no despegaron en la red principal de Ethereum porque las tarifas de gas de $ 5 - 50 hacen que el patrocinio de los paymasters sea prohibitivamente caro. Despegaron en las L2 donde los costes por transacción cayeron a céntimos, haciendo que la incorporación sin gas fuera económicamente viable.

El objetivo final de las 200 millones de cuentas inteligentes​

Las proyecciones de la industria estiman más de 200 millones de cuentas inteligentes para finales de 2025, impulsadas por la adopción de ERC-4337 y la modernización (retrofitting) de las EOA existentes mediante EIP-7702. Eso no es una especulación disparatada; es el resultado natural de eliminar la fricción artificial.

El camino hacia los 200 millones:

1. Adopción de billeteras móviles. Ambire Mobile, Trust Wallet y MetaMask Mobile ya son compatibles con la abstracción de cuentas (account abstraction), llevando las funciones de cuentas inteligentes a miles de millones de usuarios de smartphones. El sector móvil es donde ocurre la próxima ola de adopción cripto, y la experiencia de usuario (UX) móvil no puede tolerar la gestión de frases semilla (seed phrases) o confirmaciones de gas por cada transacción.

2. Incorporación en juegos. Los juegos Web3 son el caso de uso de mayor volumen para la abstracción de cuentas. Los juegos free-to-play con mecánicas play-to-earn pueden incorporar a millones de jugadores, patrocinar transacciones iniciales y permitir una jugabilidad sin fricciones. Si entre 10 y 20 juegos importantes adoptan la abstracción de cuentas en 2025-2026, eso supondría entre 50 y 100 millones de usuarios.

3. Aplicaciones empresariales. Empresas como Circle, Stripe y PayPal están integrando pagos en blockchain, pero no someterán a sus clientes a la gestión de frases semilla. La abstracción de cuentas permite que las aplicaciones empresariales ofrezcan servicios basados en blockchain con una UX de nivel Web2.

4. Aplicaciones sociales. Las plataformas sociales descentralizadas (Farcaster, Lens, Friend.tech) necesitan una incorporación sin fricciones para competir con Twitter e Instagram. Nadie usará un Twitter descentralizado si cada publicación requiere la aprobación de una billetera. Las llaves de sesión (session keys) y los paymasters hacen que las aplicaciones sociales descentralizadas sean viables.

5. Modernización mediante EIP-7702. Más de 300 millones de EOA de Ethereum existentes pueden obtener funciones de cuenta inteligente sin necesidad de migración. Si solo el 20-30 % de esas cuentas adoptan las funciones de EIP-7702, eso representaría entre 60 y 90 millones de cuentas actualizadas.

El punto de inflexión: cuando las cuentas inteligentes se conviertan en el estándar, no en la excepción. Una vez que las principales billeteras (MetaMask, Trust Wallet, Coinbase Wallet) creen cuentas inteligentes por defecto para los nuevos usuarios, la base instalada cambiará rápidamente. Las EOA se convertirán en infraestructura heredada (legacy), mantenida por compatibilidad pero que ya no será la experiencia de usuario principal.

Por qué debería importarles a los desarrolladores de BlockEden.xyz​

Si estás construyendo en Ethereum o en una Capa 2 (Layer 2), la abstracción de cuentas no es una infraestructura opcional; es el requisito mínimo para una UX competitiva. Los usuarios esperan una incorporación sin gas (gasless), transacciones por lotes (batch transactions) y recuperación social, porque así es como funcionan las aplicaciones Web2 y cómo deberían funcionar las aplicaciones cripto modernas.

Para los desarrolladores, implementar la abstracción de cuentas significa:

Elegir la infraestructura adecuada: Utiliza bundlers de ERC-4337 y servicios de paymaster (Alchemy, Pimlico, Stackup, Biconomy) en lugar de construir desde cero. El protocolo está estandarizado, las herramientas son maduras y reinventar la rueda es una pérdida de tiempo.

Diseñar flujos de incorporación que oculten la complejidad: No muestres frases semilla a los usuarios al registrarse. No pidas aprobaciones de tarifas de gas antes de que hayan experimentado el valor del producto. Patrocina las transacciones iniciales, utiliza llaves de sesión para interacciones repetidas e introduce funciones avanzadas de forma gradual.

Ofrecer recuperación social: Ofrece recuperación basada en correo electrónico para usuarios ocasionales, recuperación social para quienes la deseen y respaldo de frase semilla para usuarios avanzados que exigen un control total. Diferentes usuarios tienen diferentes modelos de amenaza; tu billetera debería adaptarse a todos ellos.

La abstracción de cuentas es la infraestructura que hace que tu aplicación sea accesible para los próximos mil millones de usuarios. Si tu flujo de incorporación aún requiere que los usuarios compren ETH antes de probar tu producto, estás compitiendo con una mano atada a la espalda.

Para los desarrolladores que construyen aplicaciones con abstracción de cuentas, BlockEden.xyz proporciona la infraestructura RPC para soportar cuentas inteligentes a escala. Ya sea que estés implementando UserOperations de ERC-4337, integrando servicios de paymaster o desplegando en Base, Polygon u Optimism, nuestras API gestionan las demandas de rendimiento y fiabilidad de la abstracción de cuentas en producción. Explora nuestro marketplace de API para construir la próxima generación de UX cripto.

Fuentes​

• Documentación de ERC-4337
• ¿Qué es ERC-4337? | Alchemy
• Guía de implementación de EIP-7702 | QuickNode
• Resumen de la actualización Pectra de Ethereum | Alchemy
• La actualización Pectra y EIP-7702 otorgan superpoderes de billetera inteligente a las EOA | Circle
• ¿Qué son los Paymasters? (ERC-4337) | Alchemy
• Transacciones sin gas con paymaster | Documentación de Base
• ¿Qué es la abstracción de cuentas? | Blog de Ambire
• Por qué la abstracción de cuentas solucionará el mayor problema de las criptomonedas | Medium

AllScale.io es una plataforma de pago de stablecoins legítima y respaldada por capital de riesgo —no un proyecto de token— dirigida a freelancers y pequeñas empresas en mercados emergentes. Fundada en febrero de 2025 y respaldada por $6.5M de VCs cripto de renombre, incluyendo YZi Labs, Draper Dragon y KuCoin Ventures, la compañía muestra señales positivas: un equipo públicamente identificado con experiencia verificable en Kraken, Capital One y Block, además de respaldo institucional de la incubadora Cyberport de Hong Kong. Sin embargo, la ausencia de auditorías de seguridad públicas y la extrema juventud de la plataforma (menos de un año) justifican una diligencia debida cuidadosa antes de una participación significativa.

Qué hace AllScale y qué problema resuelve​

AllScale se posiciona como el "primer neobanco de stablecoins con autocustodia del mundo", diseñado específicamente para los más de 600 millones de microempresas globales —freelancers, creadores de contenido, pymes y contratistas remotos— que tienen dificultades con los pagos transfronterizos tradicionales. El problema central: los freelancers internacionales se enfrentan a barreras de cuentas bancarias, altas tarifas de transferencia, pérdidas por conversión de moneda y retrasos en la liquidación que a menudo superan los 5 días hábiles.

La plataforma permite a las empresas crear facturas, recibir pagos en USDT o USDC independientemente de cómo paguen los clientes (tarjeta de crédito, transferencia bancaria o cripto), y acceder a los fondos instantáneamente a través de una billetera no custodial. Los productos clave incluyen AllScale Invoice (activo desde septiembre de 2025), AllScale Pay (comercio social a través de Telegram, WhatsApp, Line) y AllScale Payroll (pagos transfronterizos a contratistas). La empresa enfatiza el "cripto invisible": los clientes pueden no saber que están utilizando la infraestructura blockchain mientras los comerciantes reciben stablecoins.

Etapa actual de desarrollo: La plataforma se encuentra en beta pública con un producto funcional en la mainnet de BNB Chain. Los usuarios pueden acceder al panel de control en dashboard.allscale.io, aunque puede aplicarse una lista de espera.

La arquitectura técnica se basa en BNB Chain y la abstracción de cuentas​

AllScale se basa en la infraestructura blockchain existente en lugar de operar su propia cadena. La pila tecnológica principal incluye:

El enfoque basado en passkey elimina la notoria fricción de UX de la gestión de frases semilla, reduciendo la barrera para la adopción masiva. La arquitectura de patrocinio de paymaster multi-cadena gestiona los costos de transacción entre bastidores.

Lo que falta: AllScale no mantiene repositorios públicos en GitHub —la infraestructura es propietaria y de código cerrado. No se han publicado direcciones de contratos inteligentes, no hay APIs o SDKs públicos disponibles, y la documentación técnica en docs.allscale.io se centra en guías de usuario en lugar de especificaciones de arquitectura. Esta opacidad impide la verificación técnica independiente de sus afirmaciones.

Sin token nativo —la plataforma utiliza USDT y USDC​

AllScale no tiene un token de criptomoneda nativo. Esta es una distinción crítica de muchos proyectos Web3: no hay ICO, IDO, venta de tokens o activo especulativo involucrado. La empresa opera como una corporación C tradicional de Delaware que recauda financiación de capital.

La plataforma utiliza stablecoins de terceros —principalmente USDT y USDC— como medio de pago. Los usuarios reciben pagos en stablecoins, con conversión automática de pagos fiduciarios o con tarjeta. La integración con BNB Chain también proporciona acceso a USD1 (la stablecoin afiliada a Binance).

Modelo de ingresos (estimado, no divulgado públicamente):

• Tarifas de transacción por procesamiento de facturas/pagos
• Márgenes de conversión de moneda en intercambios de fiat a stablecoin
• Servicios de gestión de nóminas B2B
• Tarifas de integración de on/off-ramp

La ausencia de un token elimina ciertos riesgos (volatilidad especulativa, manipulación de tokenomics, preocupaciones regulatorias de valores) pero también significa que no hay exposición basada en tokens para los inversores más allá de la participación en el capital.

Cuatro fundadores públicamente identificados con antecedentes verificables​

El equipo de AllScale demuestra una gran transparencia: todos los fundadores están públicamente identificados con historiales profesionales verificables:

Shawn Pang (CEO y Co-Fundador): Ciencias de la Computación y Negocios de Western University. Ex-Gerente de Producto para fraude de pagos en Capital One; primer PM en Canadá en TikTok; co-fundador de HashMatrix, una agencia de marketing de crecimiento para productos de IA.

Ruoyang "Leo" Wang (COO y Co-Fundador): Ingeniería Informática de la Universidad de Toronto. Experiencia en PingCAP (bases de datos distribuidas), IBM, AMD y Scotiabank. Experiencia previa en startups con CP Clickme.

Jun Li y Khalil Lin (Co-Fundadores): Co-fundadores adicionales con experiencia legal/de cumplimiento, que según se informa incluyen antecedentes en OKX. Perfiles de LinkedIn disponibles.

Avrilyn Li (Gerente de Producto Fundadora): Emprendedora de IA a Web3 de Ivey Business School, liderando el producto de nóminas.

El equipo afirma tener experiencia colectiva de Binance, OKX, Kraken, Block (Square), Amazon, Dell y HP. El tamaño total del equipo es de aproximadamente 7-11 empleados.

Financiación e inversores​

Entre los inversores participantes notables se encuentran KuCoin Ventures, Oak Grove Ventures, BlockBooster, Aptos, GSR Ventures y V3V Ventures. Los inversores ángeles incluyen a Gracy Chen y Jedi Lu. La empresa es miembro del Programa de Incubación Cyberport de Hong Kong, una aceleradora tecnológica respaldada por el gobierno.

Principal preocupación de seguridad: sin auditorías públicas ni programa de recompensas por errores​

Esta es la señal de alerta más significativa en la investigación. A pesar de gestionar fondos de usuarios a través de billeteras de contratos inteligentes:

• Sin auditorías públicas de contratos inteligentes de firmas reconocidas (CertiK, Hacken, Trail of Bits, OpenZeppelin, SlowMist)
• No listado en CertiK Skynet o bases de datos de seguridad similares
• Sin programa de recompensas por errores en Immunefi, HackerOne o Bugcrowd
• Sin mecanismos de seguro o cobertura divulgados
• Sin política de divulgación de seguridad visible públicamente

AllScale afirma tener características de seguridad que incluyen arquitectura de autocustodia, cumplimiento automatizado de KYC/KYB/KYT, integración de módulo de seguridad de hardware (HSM) para passkeys y soporte 2FA. El modelo de autocustodia reduce el riesgo de contraparte de la plataforma: si AllScale se viera comprometida, los fondos de los usuarios en sus propias billeteras estarían teóricamente más seguros que en un servicio de custodia.

En el lado positivo: No se han reportado incidentes de seguridad, hacks o exploits para AllScale. Sin embargo, dada la juventud de la plataforma, esta ausencia de incidentes puede simplemente reflejar una exposición limitada en lugar de una seguridad robusta.

Panorama competitivo y posicionamiento en el mercado​

AllScale compite en el espacio de pagos con stablecoins, que evoluciona rápidamente:

Factores de diferenciación de AllScale:

• Modelo de autocustodia (los usuarios controlan los fondos)
• Autenticación con passkey que elimina la fricción de UX de las frases semilla
• Cero tarifas de gas a través de la abstracción de cuentas
• Enfoque en mercados emergentes (África, América Latina, Sudeste Asiático)
• Orientación a pymes de "última milla" frente al enfoque empresarial

Desventajas: Extrema juventud, equipo pequeño, trayectoria limitada, compitiendo contra empresas establecidas y bien financiadas con canales de distribución consolidados.

La presencia comunitaria es incipiente y centrada en B2B​

AllScale mantiene los canales sociales estándar de Web3:

• X (Twitter): @allscaleio (activo desde abril de 2025)
• Telegram: Grupo comunitario AllScaleHQ
• Discord: Servidor activo con ID de comunidad visible
• LinkedIn: Página de empresa AllScale Inc
• Newsletter: "The Stablecoin Scoop" en Substack

La comunidad está en una etapa inicial, con la participación principalmente a través de sesiones AMA, X Spaces y anuncios de asociaciones. AllScale organizó la Cumbre Scale Stablecoin en Hong Kong (junio de 2025) con HashKey Group y Amber Group.

No se aplican métricas DeFi tradicionales: AllScale es una plataforma de pagos, no un protocolo DeFi, por lo que las métricas de TVL (Valor Total Bloqueado) no son aplicables. La plataforma no está listada en DeFiLlama o Dune Analytics. Las métricas de recuento de usuarios y retención son mencionadas por los inversores pero no se divulgan públicamente.

Las asociaciones notables incluyen BNB Chain (socio oficial del ecosistema), Skill Afrika (comunidades de freelancers africanos), Ethscriptions (permanencia L1) y Asseto (tokenización RWA para productos de rendimiento).

La evaluación de riesgos revela una empresa en etapa inicial de riesgo moderado​

Señales positivas de legitimidad​

• Equipo públicamente identificado con antecedentes profesionales verificables
• VCs cripto de renombre (YZi Labs, Draper Dragon, Amber Group, KuCoin Ventures)
• Respaldo institucional de Hong Kong Cyberport
• Estructura legal de Delaware C-corp
• Producto funcional en la mainnet de BNB Chain
• No se encontraron acusaciones de estafa, quejas de BBB o advertencias de la comunidad
• Sin preocupaciones por equipo anónimo
• Sin promesas de rendimiento poco realistas o especulación de tokens
• Posicionamiento pro-cumplimiento (GENIUS Act, Ordenanza de Stablecoins de Hong Kong)

Áreas que requieren precaución​

• Extrema juventud: Fundada en febrero de 2025, con menos de un año de antigüedad
• Sin auditorías de seguridad públicas a pesar de manejar fondos
• Sin programa de recompensas por errores
• Sin reseñas de usuarios independientes o comentarios de la comunidad disponibles
• Infraestructura de código cerrado —no se pueden verificar las afirmaciones de forma independiente
• Cobertura de prensa principalmente sindicación de comunicados de prensa, no periodismo independiente
• Riesgos de centralización: Plataforma operada por la empresa, dependencia de BNB Chain
• Equipo pequeño (~7-11 personas) ejecutando un ambicioso alcance global

No encontrado (posibles señales de alerta por ausencia)​

• Sin métricas de usuario divulgadas públicamente
• Sin cifras de ingresos
• Sin una junta asesora formal
• Sin licencias regulatorias específicas (el marco de Hong Kong aún no es efectivo)

Desarrollos recientes y hoja de ruta​

Hitos recientes (2025):

• 8 de diciembre: Anunciada ronda semilla de $5M (liderada por YZi Labs)
• Noviembre: AllScale Pay en vivo en BNB Chain; asociación con Skill Afrika
• Octubre: Asociación con Ethscriptions para la permanencia L1
• Septiembre: Lanzamiento del producto AllScale Invoice
• Agosto: Integración de BNB Chain con soporte USD1
• Junio: Cumbre Scale Stablecoin Hong Kong; financiación pre-semilla de $1.5M

Próximo:

• Q1 2026: Expansión al mercado de América Latina
• Futuro: Opciones de rendimiento DeFi, capacidades cross-chain expandidas, soluciones empresariales B2B

Conclusión​

AllScale.io emerge como una startup legítima en etapa inicial en lugar de una preocupación por estafa, respaldada por inversores creíbles y un equipo transparente y verificable. El proyecto aborda un problema real del mercado —la fricción en los pagos transfronterizos para freelancers de mercados emergentes— con un enfoque técnico bien pensado que aprovecha la abstracción de cuentas y las stablecoins.

Sin embargo, dos brechas significativas exigen atención antes de una participación significativa: la ausencia total de auditorías de seguridad públicas y la infraestructura de código cerrado que impide la verificación independiente. Para una plataforma que maneja fondos de usuarios, estas omisiones son preocupaciones materiales independientemente de las credenciales del equipo.

Calificación de riesgo general: Moderado. La empresa muestra fuertes señales de legitimidad pero conlleva riesgos inherentes a la etapa inicial. Los usuarios potenciales deben comenzar con pequeñas cantidades hasta que se publiquen las auditorías de seguridad. Los socios potenciales deben solicitar acceso directo a las especificaciones técnicas y a los informes de auditoría. Vale la pena monitorear el proyecto a medida que madura, particularmente por cualquier anuncio de auditoría de seguridad en el primer trimestre de 2026.

Imagina un mundo donde los usuarios puedan interactuar con tu dApp de forma fluida, sin necesidad de poseer tokens nativos (SUI). Esto ya no es un sueño lejano. Con la Gas Station de Sui (también conocida como Paymaster), los desarrolladores pueden cubrir las tarifas de gas en nombre de sus usuarios, eliminando por completo una de las mayores barreras para los nuevos participantes en Web3 y habilitando una experiencia verdaderamente sin fricción en cadena.

Este artículo ofrece una guía completa para actualizar tu dApp y hacerla sin gas. Profundizaremos en los conceptos centrales del Sui Paymaster, su arquitectura, patrones de implementación y mejores prácticas.

1. Antecedentes y conceptos clave: ¿Qué es una transacción patrocinada?​

En el mundo de la blockchain, cada transacción requiere una tarifa de red, o “gas”. Para los usuarios acostumbrados a la fluidez de Web2, esto representa un obstáculo cognitivo y operativo significativo. Sui aborda este desafío a nivel de protocolo con Transacciones Patrocinadas.

La idea central es simple: permitir que una parte (el Patrocinador) pague las tarifas de gas en SUI por la transacción de otra parte (el Usuario). De este modo, incluso si un usuario no tiene SUI en su billetera, puede iniciar acciones en cadena con éxito.

Paymaster ≈ Gas Station​

En el ecosistema Sui, la lógica para patrocinar transacciones suele ser manejada por un servicio fuera de cadena o en cadena llamado Gas Station o Paymaster. Sus responsabilidades principales incluyen:

1. Evaluar la transacción: recibe los datos de la transacción sin gas del usuario (GasLessTransactionData).
2. Proveer gas: bloquea y asigna la tarifa de gas necesaria para la transacción. Esto normalmente se gestiona mediante un pool de gas compuesto por muchos objetos SUI Coin.
3. Generar una firma del patrocinador: tras aprobar el patrocinio, la Gas Station firma la transacción con su clave privada (SponsorSig), certificando su disposición a pagar la tarifa.
4. Devolver la transacción firmada: envía de vuelta el TransactionData, que ahora incluye los datos de gas y la firma del patrocinador, a la espera de la firma final del usuario.

En resumen, una Gas Station actúa como un servicio de repostaje para los usuarios de tu dApp, asegurando que sus “vehículos” (transacciones) puedan viajar sin problemas por la red Sui.

2. Arquitectura de alto nivel y flujo de interacción​

Una transacción sin gas típica implica coordinación entre el usuario, el frontend de la dApp, la Gas Station y un nodo completo de Sui. La secuencia de interacción es la siguiente:

Desglose del flujo:

1. El Usuario realiza una acción en la UI de la dApp, que construye un paquete de datos de transacción sin información de gas.
2. La dApp envía estos datos a su Gas Station designada para solicitar patrocinio.
3. La Gas Station verifica la validez de la solicitud (p. ej., comprueba si el usuario es elegible para el patrocinio), luego rellena la transacción con una Gas Coin y su firma, devolviendo la transacción semicompleta a la dApp.
4. El Usuario ve los detalles completos de la transacción en su billetera (p. ej., “Comprar un NFT”) y proporciona la firma final. Este paso es crucial para garantizar que el usuario mantenga su consentimiento y control sobre sus acciones.
5. La dApp difunde la transacción completa, que contiene tanto la firma del usuario como la del patrocinador, a un Nodo Completo de Sui.
6. Tras la finalización en cadena, la Gas Station puede confirmar esto escuchando eventos o recibos en cadena y luego notificar al backend de la dApp mediante un webhook para cerrar el bucle del proceso de negocio.

3. Tres modelos de interacción principales​

Puedes usar los siguientes tres modelos de interacción de forma individual o combinada, según tus necesidades comerciales.

Modelo 1: Iniciado por el usuario → Aprobado por el patrocinador (más común)​

Este es el modelo estándar, adecuado para la gran mayoría de interacciones dentro de la dApp.

1. El usuario construye GasLessTransactionData: el usuario realiza una acción dentro de la dApp.
2. El patrocinador añade GasData y firma: el backend de la dApp envía la transacción a la Gas Station, que la aprueba, adjunta una Gas Coin y añade su firma.
3. El usuario revisa y da la firma final: el usuario confirma los detalles finales en su billetera y firma. La dApp entonces la envía a la red.

Este modelo logra un excelente equilibrio entre seguridad y experiencia de usuario.

Modelo 2: Patrocinador inicia airdrops/incentivos​

Este modelo es perfecto para airdrops, incentivos a usuarios o distribuciones masivas de activos.

1. Patrocinador pre‑llena TransactionData + firma: el patrocinador (normalmente el equipo del proyecto) construye la mayor parte de la transacción (p. ej., airdrop de un NFT a una dirección específica) y adjunta su firma de patrocinio.
2. La segunda firma del usuario la hace efectiva: el usuario solo necesita firmar esta transacción “pre‑aprobada” una vez para que se ejecute.

Esto crea una experiencia de usuario extremadamente fluida. Con un solo clic para confirmar, los usuarios pueden reclamar recompensas o completar tareas, aumentando drásticamente las tasas de conversión de campañas de marketing.

Modelo 3: GasData comodín (modelo de línea de crédito)​

Este es un modelo más flexible y basado en permisos.

1. El patrocinador transfiere un objeto GasData: primero crea uno o varios objetos Gas Coin con un presupuesto específico y transfiere la propiedad directamente al usuario.
2. El usuario gasta libremente dentro del presupuesto: el usuario puede usar esos Gas Coins para pagar cualquier transacción que inicie, siempre que se mantenga dentro de los límites y el periodo de validez del presupuesto.
3. El Gas Coin se devuelve: una vez agotado o expirado, el objeto Gas Coin puede ser diseñado para destruirse automáticamente o volver al patrocinador.

Este modelo equivale a entregar al usuario una “tarjeta de crédito de tarifas de gas” limitada en tiempo y presupuesto, adecuada para escenarios que requieren alta autonomía del usuario, como ofrecer una experiencia free‑to‑play durante una temporada de juego.

4. Escenarios de aplicación típicos​

El poder del Sui Paymaster no solo radica en resolver el problema de las tarifas de gas, sino también en su capacidad de integrarse profundamente con la lógica de negocio para crear nuevas posibilidades.

Escenario 1: Paywalls​

Muchas plataformas de contenido o servicios de dApp requieren que los usuarios cumplan ciertos criterios (p. ej., poseer un NFT VIP, alcanzar un nivel de membresía) para acceder a funcionalidades. El Paymaster puede implementar esta lógica de forma perfecta.

• Flujo: un usuario solicita una acción → el backend de la dApp verifica las calificaciones del usuario (p. ej., propiedad de NFT) → si es elegible, llama al Paymaster para patrocinar la tarifa de gas; si no, simplemente niega la solicitud de firma.
• Ventaja: este modelo es inherentemente resistente a bots y abusos. Dado que la decisión de patrocinio se toma en el backend, los usuarios malintencionados no pueden eludir la verificación de calificaciones para drenar fondos de gas.

Escenario 2: Checkout con un clic​

En e‑commerce o compras dentro de juegos, simplificar el proceso de pago es crítico.

• Flujo: el usuario hace clic en “Comprar ahora” en la página de checkout. La dApp construye una transacción que incluye la lógica de negocio (p. ej., transfer_nft_to_user). El usuario solo necesita firmar para aprobar la transacción de negocio en su billetera, sin preocuparse por el gas. La tarifa de gas la cubre el patrocinador de la dApp.
• Ventaja: puedes codificar parámetros de negocio como un order_id directamente en el ProgrammableTransactionBlock, permitiendo una atribución on‑chain precisa para los pedidos del backend.

Escenario 3: Atribución de datos​

El seguimiento preciso de datos es fundamental para la optimización del negocio.

• Flujo: al construir la transacción, escribe un identificador único (como un order_hash) en los parámetros de la transacción o en un evento que se emitirá al ejecutarse.
• Ventaja: cuando la Gas Station recibe el recibo on‑chain de una transacción exitosa, puede extraer fácilmente ese order_hash analizando el evento o los datos de la transacción. Esto permite mapear con precisión los cambios de estado on‑chain a pedidos o acciones específicas del backend.

5. Esqueleto de código (basado en el SDK de Rust)​

A continuación se muestra un fragmento simplificado que demuestra los pasos centrales de interacción.

// Assume tx_builder, sponsor, and wallet have been initialized

// Step 1: On the user or dApp side, construct a gas-less transaction
let gasless_transaction_data = tx_builder.build_gasless_transaction_data(false)?;

// Step 2: On the Sponsor (Gas Station) side, receive the gasless_transaction_data,
// fill it with a Gas Coin, and return the transaction data with the Sponsor's signature.
// The sponsor_transaction_block function handles gas allocation and signing internally.
let sponsored_transaction = sponsor.sponsor_transaction_block(gasless_transaction_data, user_address, gas_budget)?;

// Step 3: The dApp sends the sponsored_transaction back to the user,
// who signs and executes it with their wallet.
let response = wallet.sign_and_execute_transaction_block(&sponsored_transaction)?;

Para una implementación completa, consulta el Tutorial de Gas Station de la documentación oficial de Sui, que ofrece ejemplos de código listos para usar.

6. Riesgos y protecciones​

Aunque potente, desplegar una Gas Station en producción requiere considerar cuidadosamente los siguientes riesgos:

• Equivocación (doble gasto): un usuario malicioso podría intentar usar la misma Gas Coin en múltiples transacciones paralelas, lo que bloquearía la Gas Coin en la red Sui. Esto se mitiga eficazmente asignando una Gas Coin única por usuario o por transacción, manteniendo una lista negra y limitando la tasa de solicitudes de firma.
• Gestión del pool de gas: en escenarios de alta concurrencia, una sola Gas Coin de gran valor puede convertirse en un cuello de botella de rendimiento. El servicio de Gas Station debe ser capaz de dividir automáticamente grandes SUI Coins en muchas Gas Coins de menor valor y recuperarlas eficientemente después de su uso. Proveedores profesionales de Gas Station como Shinami ofrecen soluciones gestionadas y maduras para esto.
• Autorización y limitación de velocidad: es imprescindible establecer políticas estrictas de autorización y limitación de velocidad. Por ejemplo, gestionar límites y frecuencias de patrocinio basados en la IP del usuario, la dirección de la billetera o tokens API para evitar que el servicio sea drenado por actores malintencionados.

7. Herramientas del ecosistema​

El ecosistema Sui ya ofrece un conjunto rico de herramientas para simplificar el desarrollo y despliegue de Paymasters:

• SDK oficiales (Rust/TypeScript): incluyen APIs de alto nivel como sponsor_transaction_block(), reduciendo significativamente la complejidad de integración.
• Shinami Gas Station: proporciona un servicio gestionado todo‑en‑uno, que incluye división/reclamación automática de Gas Coins, métricas detalladas y notificaciones webhook, permitiendo a los desarrolladores centrarse en la lógica de negocio.
• Enoki / Demos de Mysten: la comunidad y Mysten Labs también ofrecen implementaciones de Paymaster de código abierto que pueden usarse como referencia para construir tu propio servicio.

8. Lista de verificación de implementación​

¿Listo para actualizar tu dApp a la era sin gas? Recorre esta lista antes de comenzar:

• Planifica tu flujo de financiación: define la fuente de fondos del patrocinador, el presupuesto y la estrategia de reposición. Configura monitoreo y alertas para métricas clave (p. ej., saldo del pool de gas, tasa de consumo).
• Reserva campos de atribución: al diseñar los parámetros de tu transacción, asegura reservar campos para identificadores de negocio como order_id o user_id.
• Despliega políticas anti‑abuso: implementa autorización estricta, limitación de velocidad y mecanismos de registro antes de lanzar.
• Ensaya en testnet: ya sea construyendo tu propio servicio o integrando una Gas Station de terceros, realiza pruebas exhaustivas de concurrencia y estrés en una testnet o devnet primero.
• Optimiza continuamente: después del lanzamiento, monitorea continuamente las tasas de éxito de transacciones, razones de fallos y costos de gas. Ajusta tu presupuesto y estrategias basándote en los datos.

Conclusión​

El Sui Paymaster (Gas Station) es mucho más que una herramienta para cubrir tarifas de gas de los usuarios. Es un paradigma poderoso que combina elegantemente una experiencia “cero SUI en cadena” para el usuario con la necesidad empresarial de “atribución a nivel de orden on‑chain” dentro de una única transacción atómica. Allana el camino para que usuarios de Web2 ingresen a Web3 y brinda a los desarrolladores una flexibilidad sin precedentes para la personalización de negocios.

Con un ecosistema de herramientas cada vez más maduro y los actuales bajos costos de gas en la red Sui, nunca ha habido un mejor momento para actualizar los flujos de pago e interacción de tu dApp a la era sin gas.

Cómo eliminar la fricción de la billetera, mantener el flujo de usuarios y prever el potencial de crecimiento

¿Qué pasaría si tu aplicación Web3 tuviera el mismo flujo de registro fluido que un servicio Web2 moderno? Esa es la promesa central de zkLogin en la blockchain Sui. Funciona como OAuth para Sui, permitiendo a los usuarios iniciar sesión con cuentas conocidas de Google, Apple, X y más. Una prueba de conocimiento cero (ZKP) vincula de forma segura esa identidad Web2 a una dirección de Sui en la cadena — sin ventanas emergentes de billeteras, sin frases semilla y sin deserción de usuarios.

El impacto es real e inmediato. Con cientos de miles de cuentas zkLogin ya activas, los casos de estudio informan ganancias masivas en la conversión de usuarios, saltando de un desastroso 17 % a un saludable 42 % después de eliminar las barreras tradicionales de las billeteras. Analicemos cómo funciona y qué puede hacer por tu proyecto.

Por qué las billeteras matan la conversión inicial​

Has construido una dApp innovadora, pero tu embudo de adquisición de usuarios tiene fugas. El culpable es casi siempre el mismo: el botón "Connect Wallet". El onboarding estándar de Web3 es un laberinto de instalaciones de extensiones, advertencias de frases semilla y cuestionarios de jerga cripto.

Es una barrera masiva para los recién llegados. Los investigadores de UX observaron una asombrosa caída del 87 % en el momento en que aparecía un aviso de billetera. En un experimento revelador, simplemente redirigir ese aviso a una etapa posterior en el proceso de pago cambió la tasa de finalización al 94 %. Incluso para los usuarios curiosos por las criptomonedas, el temor principal es: "Podría perder mis fondos si hago clic en el botón equivocado". Eliminar ese único e intimidante paso es la clave para desbloquear el crecimiento exponencial.

Cómo funciona zkLogin (en lenguaje sencillo)​

zkLogin esquiva elegantemente el problema de la billetera utilizando tecnologías en las que todos los usuarios de Internet ya confían. La magia ocurre entre bastidores en unos pocos pasos rápidos:

1. Par de claves efímeras: Cuando un usuario quiere iniciar sesión, se genera localmente en su navegador un par de claves temporales para una sola sesión. Piensa en ello como una clave de acceso temporal, válida solo para esta sesión.
2. Proceso OAuth: El usuario inicia sesión con su cuenta de Google, Apple u otra cuenta social. Tu aplicación inserta hábilmente un valor único (nonce) en esta solicitud de inicio de sesión.
3. Servicio ZKP: Después de un inicio de sesión exitoso, un servicio ZKP (Zero-Knowledge Proof) genera una prueba criptográfica. Esta prueba confirma: "Este token de OAuth autoriza al propietario de la clave de acceso temporal", sin revelar nunca la identidad personal del usuario en la cadena.
4. Derivar dirección: El JWT (JSON Web Token) del usuario proporcionado por el proveedor de OAuth se combina con un salt único para generar de manera determinista su dirección permanente de Sui. El salt se mantiene privado, ya sea en el lado del cliente o en un backend seguro.
5. Enviar transacción: Tu aplicación firma las transacciones con la clave temporal y adjunta la prueba ZK. Los validadores de Sui verifican la prueba en la cadena, confirmando la legitimidad de la transacción sin que el usuario necesite nunca una billetera tradicional.

Guía de integración paso a paso​

¿Listo para implementar esto? Aquí tienes una guía rápida utilizando el SDK de TypeScript. Los principios son idénticos para Rust o Python.

1. Instalar el SDK​

El paquete @mysten/sui incluye todos los ayudantes de zklogin que necesitarás.

pnpm add @mysten/sui

2. Generar claves y Nonce​

Primero, crea un par de claves efímeras y un nonce vinculado a la época actual en la red Sui.

const keypair = new Ed25519Keypair();
const { epoch } = await suiClient.getLatestSuiSystemState();
const nonce = generateNonce(keypair.getPublicKey(), Number(epoch) + 2, generateRandomness());

3. Redirigir a OAuth​

Construye la URL de inicio de sesión OAuth adecuada para el proveedor que estés utilizando (por ejemplo, Google, Facebook, Apple) y redirige al usuario.

4. Decodificar JWT y obtener el Salt del usuario​

Después de que el usuario inicie sesión y sea redirigido de vuelta, toma el id_token de la URL. Úsalo para obtener el salt específico del usuario desde tu backend, luego deriva su dirección de Sui.

const jwt = new URLSearchParams(window.location.search).get('id_token')!;
const salt = await fetch('/api/salt?jwt=' + jwt).then(r => r.text());
const address = jwtToAddress(jwt, salt);

5. Solicitar prueba ZK​

Envía el JWT a un servicio probador (prover) para obtener la prueba ZK. Para el desarrollo, puedes usar el probador público de Mysten. En producción, deberías alojar el tuyo propio o usar un servicio como Enoki.

const proof = await fetch('/api/prove', {
  method:'POST',
  body: JSON.stringify({ jwt, ... })
}).then(r => r.json());

6. Firmar y enviar​

Ahora, construye tu transacción, establece el remitente como la dirección zkLogin del usuario y ejecútala. El SDK se encarga de adjuntar automáticamente los zkLoginInputs (la prueba). ✨

const tx = new TransactionBlock();
tx.moveCall({ target:'0x2::example::touch_grass' }); // Cualquier llamada a Move
tx.setSender(address);
tx.setGasBudget(5_000_000);

await suiClient.signAndExecuteTransactionBlock({
  transactionBlock: tx,
  zkLoginInputs: proof // La magia ocurre aquí
});

7. Persistir la sesión​

Para una experiencia de usuario más fluida, cifra y almacena el par de claves y el salt en IndexedDB o en el almacenamiento local. Recuerda rotarlos cada pocas épocas para mejorar la seguridad.

Plantilla de Proyección de KPI​

La diferencia que marca zkLogin no es solo cualitativa; es cuantificable. Compare un embudo de incorporación típico con uno impulsado por zkLogin:

👉 Lo que esto significa: Para una campaña que atrae 10,000 visitantes únicos, esa es la diferencia entre 300 acciones on-chain el primer día y más de 2,500.

Buenas Prácticas y Aspectos a Considerar​

Para crear una experiencia aún más fluida, tenga en cuenta estos consejos profesionales:

• Use Transacciones Patrocinadas: Pague las tarifas de las primeras transacciones de sus usuarios. Esto elimina toda fricción y ofrece un increíble momento "¡ajá!".
• Maneje los Salts con cuidado: Cambiar el salt de un usuario generará una nueva dirección. Solo haga esto si controla una ruta de recuperación confiable para ellos.
• Exponga la Dirección de Sui: Después del registro, muestre a los usuarios su dirección on-chain. Esto permite a los usuarios avanzados importarla a una billetera tradicional más adelante si así lo desean.
• Evite los bucles de actualización: Almacene en caché el JWT y el par de claves efímeras hasta que expiren para evitar pedir al usuario que inicie sesión repetidamente.
• Monitoree la latencia del Prover: Vigile el tiempo de ida y vuelta de la generación de pruebas. Si supera los 2 segundos, considere alojar un prover regional para mantener la rapidez.

Dónde BlockEden.xyz aporta valor​

Mientras que zkLogin perfecciona el flujo de cara al usuario, escalarlo introduce nuevos desafíos en el backend. Ahí es donde entra BlockEden.xyz.

• Capa de API: Nuestros nodos RPC de alto rendimiento y enrutamiento geográfico garantizan que sus transacciones de zkLogin se procesen con una latencia mínima, independientemente de la ubicación del usuario.
• Observabilidad: Obtenga paneles de control listos para usar para rastrear métricas clave como la latencia de las pruebas, los ratios de éxito/fallo y la salud de su embudo de conversión.
• Cumplimiento: Para las aplicaciones que conectan con fiat, nuestro módulo opcional de KYC proporciona una rampa de entrada (on-ramp) compatible directamente desde la identidad verificada del usuario.

¿Listo para lanzar?​

La era de los flujos de billetera toscos e intimidantes ha terminado. Inicie un sandbox de zkLogin, conecte el endpoint de nodo completo de BlockEden y vea cómo sube su gráfico de registros, mientras sus usuarios ni siquiera tienen que escuchar la palabra “wallet”. 😉

Durante años, el mundo cripto ha estado limitado por un problema crítico de usabilidad: la cartera. Las carteras tradicionales, conocidas como Cuentas Externamente Poseídas (EOA), son implacables. Una sola frase semilla perdida significa que tus fondos se van para siempre. Cada acción requiere una firma y las tarifas de gas deben pagarse con el token nativo de la cadena. Esta experiencia torpe y de alto riesgo es una barrera importante para la adopción masiva.

Entra Abstracción de Cuentas (AA), un cambio de paradigma que redefinirá cómo interactuamos con la cadena de bloques. En esencia, AA transforma la cuenta del usuario en un contrato inteligente programable, desbloqueando funciones como recuperación social, transacciones con un clic y pagos de gas flexibles.

El camino hacia este futuro más inteligente se está desarrollando a lo largo de tres rutas distintas: el probado ERC-4337, el eficiente Native AA y el muy esperado EIP-7702. Analicemos qué significa cada enfoque para desarrolladores y usuarios.

💡 Ruta 1: El Pionero — ERC-4337​

ERC-4337 fue el avance que llevó la abstracción de cuentas a Ethereum y a las cadenas EVM sin modificar el protocolo central. Piensa en ello como una capa inteligente añadida sobre el sistema existente.

Introduce un nuevo flujo de transacciones que involucra:

• UserOperations: Un nuevo objeto que representa la intención del usuario (p. ej., “intercambiar 100 USDC por ETH”).
• Bundlers: Actores fuera de la cadena que recogen UserOperations, los agrupan y los envían a la red.
• EntryPoint: Un contrato inteligente global que valida y ejecuta las operaciones agrupadas.

Lo Bueno:

• Compatibilidad Universal: Puede desplegarse en cualquier cadena EVM.
• Flexibilidad: Permite funciones avanzadas como claves de sesión para juegos, seguridad multfirmas y patrocinio de gas mediante Paymasters.

El Compromiso:

• Complejidad y Coste: Introduce una sobrecarga de infraestructura significativa (ejecución de Bundlers) y tiene los costos de gas más altos de los tres enfoques, ya que cada operación pasa por la lógica adicional de EntryPoint. Por eso, su adopción se ha concentrado principalmente en L2s de bajo costo como Base y Polygon.

ERC-4337 abrió el camino para que otras soluciones AA pudieran funcionar. Demostró la demanda y sentó las bases para una experiencia Web3 más intuitiva.

🚀 Ruta 2: El Ideal Integrado — Native Account Abstraction​

Si ERC-4337 es un complemento, Native AA construye funciones inteligentes directamente en la base de la cadena. Cadenas como zkSync Era y Starknet fueron diseñadas desde cero con AA como principio central. En estas redes, cada cuenta es un contrato inteligente.

Lo Bueno:

• Eficiencia: Al integrar la lógica AA en el protocolo, se eliminan capas extra, lo que genera costos de gas significativamente menores en comparación con ERC-4337.
• Simplicidad para los Desarrolladores: No es necesario gestionar Bundlers ni un mempool separado. El flujo de transacciones se asemeja mucho al de una operación estándar.

El Compromiso:

• Fragmentación del Ecosistema: Native AA es específico de cada cadena. Una cuenta en zkSync es distinta de una cuenta en Starknet, y ninguna es nativa de Ethereum mainnet. Esto crea una experiencia fragmentada para usuarios y desarrolladores que operan en múltiples cadenas.

Native AA nos muestra el “juego final” en términos de eficiencia, pero su adopción está ligada al crecimiento de los ecosistemas que la alojan.

🌉 Ruta 3: El Puente Pragmático — EIP-7702​

Programado para incluirse en la actualización “Pectra” de Ethereum en 2025, EIP-7702 es un cambio de juego diseñado para llevar funciones AA a la masa de usuarios de EOAs existentes. Adopta un enfoque híbrido: permite que una EOA delegue temporalmente su autoridad a un contrato inteligente para una única transacción.

Piensa en ello como otorgar superpoderes temporales a tu EOA. No necesitas migrar fondos ni cambiar tu dirección. Tu cartera simplemente añade una autorización a la transacción, permitiendo ejecutar operaciones agrupadas (p. ej., aprobar + intercambiar con un clic) o recibir patrocinio de gas.

Lo Bueno:

• Compatibilidad Retroactiva: Funciona con los miles de millones de dólares asegurados por EOAs actuales. No se requiere migración.
• Baja Complejidad: Utiliza el pool de transacciones estándar, eliminando la necesidad de Bundlers y simplificando drásticamente la infraestructura.
• Catalizador de Adopción Masiva: Al hacer que funciones inteligentes estén al alcance de cualquier usuario de Ethereum de la noche a la mañana, podría acelerar rápidamente la adopción de mejores patrones de UX.

El Compromiso:

• No es “AA Completa”: EIP-7702 no resuelve la gestión de claves de la propia EOA. Si pierdes tu clave privada, sigues sin suerte. Se trata más de mejorar las capacidades de transacción que de rehacer la seguridad de la cuenta.

Comparación Directa: Un Análisis Claro​

El Futuro es Convergente y Centrado en el Usuario​

Estas tres rutas no son mutuamente excluyentes; están convergiendo hacia un futuro donde la cartera deja de ser un punto de fricción.

1. La Recuperación Social se Vuelve Estándar 🛡️: La era de “claves perdidas, fondos perdidos” está terminando. AA permite la recuperación basada en guardianes, haciendo que la auto‑custodia sea tan segura y indulgente como una cuenta bancaria tradicional.
2. UX de Juegos Rediseñada 🎮: Las claves de sesión permitirán una jugabilidad fluida sin constantes ventanas de “aprobar transacción”, logrando que los juegos Web3 se sientan como los juegos Web2.
3. Carteras como Plataformas Programables: Las carteras se volverán modulares. Los usuarios podrán añadir un “módulo DeFi” para farming automatizado o un “módulo de seguridad” que requiera 2FA para transferencias grandes.

Para desarrolladores y proveedores de infraestructura como Blockeden.xyz, esta evolución es increíblemente emocionante. La complejidad de Bundlers, Paymasters y los distintos estándares AA crea una gran oportunidad para ofrecer infraestructura robusta, fiable y abstracta. El objetivo es una experiencia unificada donde el desarrollador pueda integrar fácilmente funciones AA, y la cartera utilice inteligentemente ERC-4337, Native AA o EIP-7702 bajo el capó, según lo que soporte la cadena.

La cartera finalmente recibe la actualización que merece. La transición de EOAs estáticas a cuentas inteligentes dinámicas no es solo una mejora—es la revolución que hará que Web3 sea accesible y segura para el próximo billón de usuarios.

¡Hola y bienvenidos de nuevo a nuestro blog de blockchain! Hoy nos sumergiremos en una nueva propuesta emocionante llamada ERC-4337, que introduce la abstracción de cuentas en Ethereum sin requerir cambios en el protocolo de la capa de consenso. En su lugar, esta propuesta se basa en infraestructura de capa superior para lograr sus objetivos. Exploremos lo que ERC-4337 tiene para ofrecer y cómo aborda las limitaciones del ecosistema actual de Ethereum.

¿Qué es ERC-4337?​

ERC-4337 es una propuesta que introduce la abstracción de cuentas en Ethereum mediante el uso de un mempool separado y un nuevo tipo de objeto pseudo‑transacción llamado UserOperation. Los usuarios envían objetos UserOperation al mempool alternativo, donde una clase especial de actores llamados bundlers los empaquetan en una transacción que realiza una llamada handleOps a un contrato dedicado. Estas transacciones se incluyen luego en un bloque.

La propuesta busca lograr varios objetivos:

1. Permitir a los usuarios utilizar carteras de contratos inteligentes con lógica de verificación arbitraria como sus cuentas principales.
2. Eliminar por completo la necesidad de que los usuarios tengan cuentas externas (EOAs).
3. Garantizar la descentralización permitiendo que cualquier bundler participe en el proceso de inclusión de operaciones de usuario con abstracción de cuentas.
4. Permitir que toda la actividad ocurra a través de un mempool público, eliminando la necesidad de que los usuarios conozcan direcciones de comunicación directa de actores específicos.
5. Evitar suposiciones de confianza sobre los bundlers.
6. Evitar requerir cambios en el consenso de Ethereum para una adopción más rápida.
7. Soportar otros casos de uso como aplicaciones que preservan la privacidad, multi‑operaciones atómicas, pagar tarifas de transacción con tokens ERC‑20 y transacciones patrocinadas por desarrolladores.

Compatibilidad hacia atrás​

Dado que ERC-4337 no modifica la capa de consenso, no existen problemas directos de compatibilidad hacia atrás para Ethereum. Sin embargo, las cuentas anteriores a ERC-4337 no son fácilmente compatibles con el nuevo sistema porque carecen de la función validateUserOp necesaria. Esto puede solucionarse creando una cuenta compatible con ERC-4337 que re‑implemente la lógica de verificación como un wrapper y configurándola como el remitente de operaciones de confianza de la cuenta original.

Implementación de referencia​

Para quienes estén interesados en profundizar en los detalles técnicos de ERC-4337, hay una implementación de referencia disponible en https://github.com/eth-infinitism/account-abstraction/tree/main/contracts.

Consideraciones de seguridad​

El contrato de punto de entrada para ERC-4337 debe ser auditado exhaustivamente y verificado formalmente, ya que sirve como punto central de confianza para todo el sistema. Si bien este enfoque reduce la carga de auditoría y verificación formal para cuentas individuales, concentra el riesgo de seguridad en el contrato de punto de entrada, que debe ser verificado de manera robusta.

La verificación debe cubrir dos afirmaciones principales:

1. Seguridad contra secuestros arbitrarios: el punto de entrada solo llama a una cuenta de forma genérica si la función validateUserOp de esa cuenta específica ha pasado.
2. Seguridad contra el drenaje de tarifas: si el punto de entrada llama a validateUserOp y pasa, también debe realizar la llamada genérica con calldata igual a op.calldata.

Conclusión​

ERC-4337 es una propuesta emocionante que busca introducir la abstracción de cuentas en Ethereum sin requerir cambios en el protocolo de la capa de consenso. Al utilizar infraestructura de capa superior, abre nuevas posibilidades para la descentralización, la flexibilidad y diversos casos de uso. Aunque existen consideraciones de seguridad que abordar, esta propuesta tiene el potencial de mejorar significativamente el ecosistema de Ethereum y la experiencia del usuario.