Durante cinco años, "insufficient SOL for transaction" ha sido el mensaje de error más costoso de Solana. Cada aplicación de consumo que alguna vez intentó atraer a un usuario ajeno al mundo cripto perdió a un porcentaje de ellos justo ahí — en el paso de pago donde un extraño tiene que adquirir un segundo token solo para gastar el primero. En abril de 2026, la Fundación Solana finalmente lanzó la respuesta: Kora, un relayer de comisiones y nodo de firma que permite a las dApps patrocinar transacciones de forma nativa, pagar comisiones en cualquier token SPL y externalizar la firma a TEEs o bóvedas respaldadas por KMS. No es un lanzamiento llamativo. Es una mejora de la infraestructura base. Y las mejoras de infraestructura son la forma en que Base y Abstract capturaron silenciosamente los últimos doce meses de incorporación de usuarios finales.
La pregunta ya no es si Solana puede igualar la UX sin gas de las cadenas de consumo EVM. Kora hace que esa parte sea trivial. La pregunta es si cerrar la brecha de la última milla es suficiente para recuperar a los desarrolladores que ya construyeron en otro lugar.
Lo que Kora realmente ofrece
Si quitamos el marketing, Kora son tres cosas unidas: un relayer de transacciones, un firmante remoto y un motor de políticas. Una dApp construye una transacción, establece un nodo Kora como el pagador de la comisión (fee payer), el usuario firma la carga útil desde una billetera integrada, y el operador de Kora co-firma y transmite. Los validadores siguen recibiendo el pago en SOL. El usuario nunca posee nada.
Lo que lo hace interesante es la capa de validación. Un nodo Kora no retransmite ciegamente cualquier cosa que los usuarios le entreguen. Realiza tres comprobaciones antes de firmar:
- Validación de instrucciones contra los programas de Solana asociados, para que las instrucciones mal formadas o maliciosas sean rechazadas antes de llegar a un líder.
- Suficiencia de comisiones respaldada por oráculos, comparando la cantidad de tokens SPL ofrecida con el precio actual de SOL más el margen del operador, para que el relayer nunca opere con pérdidas.
- Cumplimiento de listas de permitidos (allowlist) y listas de bloqueados (blocklist) a nivel de programa y token, para que un operador que ejecuta un nodo Kora para una sola dApp nunca patrocine accidentalmente una transacción dirigida a algún contrato aleatorio no auditado.
La ruta de firma es donde la arquitectura se vuelve ambiciosa. Kora admite la firma remota a través de Turnkey y AWS KMS de forma nativa, lo que significa que la clave privada que paga las comisiones nunca reside en el disco del relayer. Para una fintech que construye sobre Solana, esa es la diferencia entre "creamos nuestro propio paymaster y cruzamos los dedos" y "nuestra estrategia de custodia de claves supera una auditoría SOC 2".
Todo el sistema ha sido auditado y sometido a pruebas de fuzzing diferencial por Runtime Verification, que es el tipo de detalle que solo mencionas cuando esperas que las instituciones lean cada línea del informe.
Por qué lo "Nativo" supera al "Contrato Inteligente" en este caso
La tentación es comparar Kora con ERC-4337 y asumir que Solana se está poniendo al día. Las arquitecturas están haciendo cosas diferentes, y la diferencia importa.
ERC-4337 es la abstracción de cuenta implementada como un sistema paralelo sobre Ethereum. Introduce un mempool separado, un objeto UserOperation, un rol de agrupador (bundler) y un contrato EntryPoint — nada de lo cual el protocolo base entiende de forma nativa. Los bundlers empaquetan las operaciones de los usuarios, los paymasters patrocinan las comisiones y un contrato en la cadena aplica la validación. Funciona, y se ha desplegado en la red principal de Ethereum y en las principales L2, pero es un proyecto de construcción de seis años para adaptar una función de UX que el protocolo nunca anticipó.
El diseño de Solana absorbió esa complejidad en la capa del protocolo hace años. Cada transacción ya tiene un campo feePayer. Las firmas parciales son nativas. Los programas pueden validar instrucciones arbitrarias. Kora no es una construcción de bundler y paymaster; es un operador de nodo que completa el campo feePayer y firma con una de las firmas parciales que el protocolo ya acepta.
La consecuencia práctica es la latencia y la superficie de exposición para el desarrollador. Las transacciones ERC-4337 pasan por un mempool separado con sus propias reglas de ordenamiento y retrasos de propagación. Las transacciones de Kora siguen la misma ruta que cualquier otra transacción de Solana, con la misma finalidad de menos de 400 ms. No hay un mercado de arbitraje de bundlers en el que pensar, ni versiones de contratos EntryPoint que rastrear, ni estimaciones de gas de UserOperation que depurar.
Lo que esto ofrece a los desarrolladores de Solana es algo cercano a "configura el campo fee payer y lanza la dApp". Lo que pierde es parte de la opcionalidad que las cuentas inteligentes EVM obtienen de forma gratuita — autenticación multiclave, llamadas por lotes, políticas de sesión en cadena — aunque gran parte de eso se está construyendo por separado en Solana a través de PDAs y cuentas controladas por programas.
La brecha de la última milla que Solana realmente tenía
A pesar de todo lo que se habla sobre el impulso de los desarrolladores de Solana en 2025 y 2026, la capa de billetera de consumo era la parte que se quedaba atrás. La pila de infraestructura maduró rápido: el volumen DEX de Pump.fun superó los $2 mil millones en el primer trimestre de 2026, Jito y Marinade dominan el staking líquido, Tensor convirtió el comercio de NFTs en una terminal profesional. Pero cada uno de esos productos tuvo que lanzar su propia respuesta a "el usuario no tiene SOL".
Las soluciones alternativas fueron creativas. Pump.fun canalizó las adquisiciones iniciales de tokens a través de rampas de acceso integradas. Jito pre-financió cuentas de usuario con cantidades mínimas (dust). Tensor se apoyó en Phantom y Backpack para manejar el paso de adquisición de SOL antes de que los usuarios llegaran al libro de ofertas. Cada una de estas soluciones funcionó individualmente y ninguna de ellas era integrable con las demás. Un usuario que se incorporaba a través del flujo de Pump.fun no llegaba a Tensor con un saldo para pagar comisiones.
Mientras tanto, Base lanzó el flujo de passkeys de Coinbase Smart Wallet, patrocinio de gas gratuito a través de Coinbase Developer Platform y un SDK para desarrolladores que oculta todo el concepto de una clave privada tras el inicio de sesión por correo electrónico. Abstract llevó la misma idea más allá con billeteras integradas que se sienten como aplicaciones Web2. El argumento combinado para un desarrollador de aplicaciones de consumo en 2025 era: construye en Base, tus usuarios no sabrán que están en la cadena (onchain), y nosotros pagaremos las comisiones mientras escalas.
Kora no replica ese argumento palabra por palabra. Lo que hace es eliminar la razón arquitectónica por la cual una dApp de Solana no podría ofrecer lo mismo. Con Kora, un equipo de Solana ahora puede ofrecer:
- Registro por correo electrónico o passkey a través de Privy, Turnkey o Coinbase Embedded Wallets.
- Cero saldo de SOL requerido para realizar transacciones.
- Comisiones pagadas en USDC, BONK o el token nativo de la dApp si tiene uno.
- Finalidad en menos de un segundo sin ningún bundler en la ruta.
Las piezas ya existían antes. Octane fue el antepasado de código abierto. Gas Station de Circle, Openfort, Portal, Gelato, Biconomy y una docena de otros proveedores ofrecieron el relayeo de comisiones como servicio. Lo que cambia Kora es que la propia Fundación Solana está lanzando ahora la implementación de referencia estándar, auditada y compatible con KMS. Eso elimina el dilema de "en qué paymaster de terceros confiamos" del árbol de decisiones para cada equipo que anteriormente estaba creando el suyo propio o pagando a un proveedor.
La capa de proveedores sobre Kora
Donde las cosas se ponen interesantes es en lo que sucede con los proveedores de monederos integrados (embedded wallets) que ya se construyeron en torno a la brecha que Kora acaba de cerrar.
Privy, adquirida por Stripe en junio de 2025, ha sido el monedero preferido para aplicaciones de consumo en dApps de Solana que buscan inicio de sesión por correo electrónico. Solana es oficialmente una cadena secundaria para Privy — la profundidad está en EVM — pero el flujo de monedero integrado se extiende a Solana, y Privy ya permite configurar un monedero pagador de comisiones (fee payer) gestionado por la aplicación. Kora no reemplaza a Privy; le da a Privy un backend estandarizado al cual conectarse, en lugar de que cada cliente tenga que operar su propio servicio de paymaster.
Turnkey es el firmante integrado (embedded signer) enfocado en la seguridad que se combina naturalmente con la API de firma remota de Kora. Turnkey explícitamente no incluye infraestructura de paymaster, por lo que los equipos de Solana que deseaban claves aisladas por hardware junto con una UX sin gas se veían obligados a unir a dos proveedores. Kora colapsa esa integración.
Dynamic, adquirida por Fireblocks en 2025, aporta autenticación multi - cadena a los equipos institucionales. El posicionamiento respaldado por Fireblocks convierte a Dynamic en la opción natural para las fintechs que necesitan cobertura tanto en Solana como en EVM con cumplimiento empresarial. Kora le da a Dynamic una solución limpia de abstracción de comisiones en Solana que no requiere que Fireblocks lance un paymaster competidor.
Coinbase Developer Platform es el caso incómodo. Coinbase ha invertido mucho en hacer de Base la cadena de consumo predeterminada a través de Coinbase Smart Wallet, gas gratuito en Base y el SDK de monedero integrado. Kora reduce la diferenciación que Base ha estado vendiendo, especialmente para aplicaciones que buscan flujos nativos en USDC donde Solana ya tiene ventajas de escala.
El resultado probable es que Kora se convierta en el backend predeterminado de Solana para cada proveedor de monederos integrados que no quiera operar un servicio de paymaster por sí mismo. Los proveedores compiten en la UX de autenticación, la gestión de claves y los controles de políticas. Kora maneja el relevo de comisiones (fee relay) por debajo. Esto es más saludable para el ecosistema que el estado anterior, donde cada dApp de consumo en Solana tomaba una decisión de proveedor independiente y tenía que evaluar la seguridad del relayer propio de cada candidato.
Lo que esto resuelve y lo que no
Kora cierra una brecha de manera definitiva y deja varias otras abiertas. Vale la pena ser precisos sobre cuál es cuál.
Lo que Kora resuelve:
- El abismo de UX de "el usuario debe tener SOL" para cualquier dApp dispuesta a subsidiar comisiones en otro token.
- La decisión de "construir frente a comprar un paymaster" para los equipos que anteriormente tenían que elegir entre la carga operativa y el bloqueo con un proveedor (vendor lock-in).
- La brecha de aceptabilidad institucional, ya que la auditoría y el soporte de KMS permiten que las entidades reguladas operen nodos de Kora sin tener que desarrollar los suyos propios.
Lo que Kora no resuelve:
- La adquisición del monedero en sí — los usuarios aún necesitan un monedero integrado de algún lugar, ya sea Phantom, Privy, Turnkey o Coinbase.
- Primitivas de abstracción de cuentas como llamadas por lotes (batched calls) y claves de sesión, que todavía se están ensamblando por separado en Solana a través de PDAs y otros patrones a nivel de programa.
- La cuestión económica de quién paga por el SOL que los operadores de Kora adelantan. Para una dApp con ingresos en tokens o un flotante de stablecoins, esto está bien; para un producto gratuito, el patrocinio del gas es simplemente un costo de adquisición de clientes.
- La UX entre cadenas (cross-chain), que aún requiere que el usuario interactúe con un puente o una capa de abstracción de cadenas como LayerZero, Wormhole o Across.
La tesis de la "infraestructura sin gas como primitiva de protocolo" funciona en ambos sentidos. Solana tiene ahora la historia de abstracción de comisiones nativa más limpia de cualquier cadena importante. También significa que la diferenciación se desplaza hacia arriba en la pila tecnológica, hacia la UX del monedero, los flujos de recuperación y las características de abstracción de cuentas donde EVM tiene una ventaja de varios años.
La lectura estratégica para los constructores
Para un equipo que elija una cadena a mediados de 2026, el cálculo ha cambiado. Hace doce meses, la respuesta para la incorporación de usuarios de consumo era Base, Abstract o una de las nuevas cadenas de consumo EVM, y punto. Solana tenía el interés de los desarrolladores y el impulso de la infraestructura, pero perdía usuarios minoristas en el paso de adquisición de SOL. Eso ya no es cierto.
Una dApp de consumo que se lance hoy en Solana con Privy o Turnkey en el front - end y Kora en el back - end tiene funcionalmente la misma superficie de UX que la pila equivalente en Base. Inicio de sesión por correo electrónico, transacciones sin gas, pago de comisiones en USDC, finalidad en menos de un segundo. Las diferencias restantes son el modelo de ejecución (runtime), el ecosistema de herramientas y la liquidez disponible. Para una aplicación que desee el rendimiento (throughput) de Solana y la profundidad de sus DEX, el argumento de la UX para elegir EVM se ha debilitado sustancialmente.
Para los equipos que ya están operando en Base, Kora no cambia la decisión inmediata. Pero sí cambia la presión competitiva a largo plazo. Si las dApps de consumo con la UX más limpia comienzan a aparecer en Solana porque la nueva infraestructura es una integración menos de la cual preocuparse, la fuerza de atracción en torno al foso de incorporación de usuarios de Base comienza a desplazarse.
La lectura honesta es que Kora es necesaria pero no suficiente. Elimina una razón específica por la que los desarrolladores no elegían Solana para aplicaciones de consumo. No crea por sí misma una nueva razón para elegir Solana. Los próximos dos trimestres mostrarán si los proveedores de monederos integrados realmente adoptan Kora por defecto, si las nuevas dApps de consumo la citan como una razón para su elección de cadena y si las cadenas de consumo EVM existentes responden mejorando sus propias historias de infraestructura.
De cualquier manera, "el usuario debe adquirir SOL antes de transacting" es finalmente un problema del pasado, no uno actual. Solo eso ya vale la pena el lanzamiento.
BlockEden.xyz opera infraestructura RPC de Solana de grado de producción para equipos que construyen dApps de consumo, rieles de pago y sistemas de trading. Si estás integrando flujos sin gas o escalando un producto en Solana, explora nuestro mercado de APIs para obtener endpoints de baja latencia diseñados para la próxima generación de cripto para el consumidor.
Fuentes
