Bank Leumi, el mayor banco de Israel, ofrecerá trading de Solana (SOL), Bitcoin y Ether dentro de su aplicación Leumi Trade a principios de 2027, según el comunicado publicado por Galaxy Digital el 14 de agosto de 2026.

La entidad ha elegido a Galaxy Digital como socio tecnológico para impulsar la compraventa de criptoactivos. Los clientes tanto de Bank Leumi como de Pepper, su marca digital, podrán comprar, mantener y vender los activos seleccionados desde la aplicación de mercados de capitales.

El soporte inicial se limita a tres criptoactivos, una decisión conservadora. Leumi evita exponerse a tokens de menor capitalización y prioriza los dos mayores por capitalización y a Solana por su tracción en pagos y finanzas descentralizadas.

El acuerdo con Galaxy Digital y los activos confirmados

El acuerdo contempla que Galaxy aporte su plataforma institucional GalaxyOne para la ejecución de órdenes y su infraestructura de custodia, antes conocida como GK8, para salvaguardar los fondos. La compañía estadounidense, fundada por Mike Novogratz, es uno de los proveedores de infraestructura cripto más veteranos del sector.

GalaxyOne es la plataforma de trading para contrapartes profesionales que Galaxy ha desplegado en varios mercados. GK8, por su parte, nació como una firma israelí de custodia de cripto adquirida por Galaxy en 2021, un detalle que no es menor: Leumi confía en una solución con raíces locales.

Galaxy declaró contar con aproximadamente 9.000 millones de dólares en activos sobre su plataforma a cierre del 31 de marzo de 2026, una cifra que utiliza para presentar su capacidad institucional ante socios como Bank Leumi.

Ver a Solana en la misma lista que Bitcoin y Ether dentro de un banco sistémico israelí es una señal institucional más poderosa que cualquier narrativa de mercado.

El comunicado detalla que Bitcoin, Ether y Solana estarán disponibles desde el primer despliegue, previsto para principios de 2027. La información pública no especifica comisiones, límites de importe ni activos adicionales.

Qué ha cambiado en la supervisión israelí

Un factor que explica la decisión del banco es la clarificación del Banco de Israel a mediados de julio de 2026. El departamento de supervisión bancaria publicó un borrador para consulta pública en el que detallaba expectativas para los servicios de pago vinculados a activos virtuales.

Aquel documento no abrió la puerta de forma automática, pero sí señaló la intención de apoyar la expansión de estos servicios. Para un banco sistémico como Leumi, ese marco reduce parte de la incertidumbre regulatoria que históricamente frenó a la banca tradicional en cripto.

La integración de cripto dentro de una app bancaria elimina pasos intermedios: el cliente no tiene que abrir una cuenta en un exchange externo y puede operar bajo la supervisión de la propia entidad. Esa comodidad es, en la práctica, el principal argumento comercial del producto.

Análisis: por qué Solana entra en la banca israelí

La elección de Solana como tercer activo oficial no es anecdótica. La red de contratos inteligentes se ha consolidado como una alternativa de bajo coste y alta velocidad, con un ecosistema DeFi y DePIN que atrae a desarrolladores. Incluirla junto a Bitcoin y Ether equivale a reconocerla como parte del núcleo cripto institucional.

El precedente importa. Durante años, la banca israelí mantuvo relaciones tensas con el sector, incluidas restricciones a exchanges locales. El giro supervisor del verano de 2026, unido a la demanda minorista por exposición digital, ha empujado a Leumi a moverse antes que sus competidores.

Aun así, conviene moderar el entusiasmo. El lanzamiento está condicionado a la confirmación regulatoria final del Banco de Israel y a la integración operativa real. La mayoría de los parámetros clave, como la custodia de las claves privadas o los seguros, está todavía sin detallar.

La reflexión de fondo es si este movimiento inaugura una etapa en la que los bancos europeos y de Oriente Medio integran trading cripto sin fricción. En Europa, entidades como BBVA o Deutsche Bank ya han explorado servicios similares con distintos alcances. Leumi, sin embargo, apuesta por una integración nativa dentro de su aplicación de inversión, no por una filial separada.

Solana acaba de ganar una nueva capa de observabilidad: las preconfirmaciones, también llamadas preconfs, la señal más temprana de que una transacción va a entrar en un bloque. Helius, uno de los proveedores de infraestructura RPC más utilizados del ecosistema —esos nodos que conectan carteras y aplicaciones con la red—, ha detallado cómo los desarrolladores pueden suscribirse a esa señal y recibir el resultado de una transacción entre 5 y 50 milisegundos antes que con los flujos de shreds, los fragmentos en los que Solana divide cada bloque.

Qué es una preconfirmación y de dónde sale

En Solana, cada bloque lo produce un líder rotatorio. Ese validador ejecuta las transacciones antes de empaquetarlas y difundirlas. La preconfirmación nace justo ahí, en la máquina del líder, cuando la ejecución ya tiene un resultado local pero el bloque todavía no ha salido de su máquina. No es una predicción: incluye el estado real de la transacción, con su éxito o su fallo.

Para entender por qué no existe una señal anterior conviene seguir el recorrido dentro del líder. Primero, la transacción llega vía QUIC y pasa por la verificación de firmas; en ese punto es solo una candidata entre miles. Después, el planificador central —el scheduler— la ordena junto a otras operaciones sin conflictos. En Agave, el cliente validador de referencia de Solana, el algoritmo greedy scheduler se encarga de empaquetar los bloques con menos bloqueos. Solo cuando un hilo de ejecución o un bank tile de Firedancer, el cliente validador alternativo, ejecuta la transacción aparece un resultado que pueda transmitirse.

Ese instante es la preconfirmación. Todo lo anterior es ruido: candidatas en cola. Todo lo posterior, como el registro en Proof of History, el reloj criptográfico de Solana, el troceado en shreds y la difusión por Turbine, el protocolo de propagación de Solana, llega después de que el líder ya conoce el desenlace. Por eso Helius puede ofrecer una ventana de 5 a 50 milisegundos de ventaja frente a los flujos de fragmentos.

La escalera de latencia en Solana

La preconfirmación no sustituye a los demás flujos de datos, sino que se suma a una escalera de latencia. Los sistemas que hoy consumen shreds ya se adelantan a los niveles RPC; las preconfs se sitúan un peldaño por encima porque se emiten antes de que el bloque se fragmente. Para un bot de liquidaciones, por ejemplo, no hace falta una garantía absoluta de que la transacción será canónica: basta con conocer el resultado unos milisegundos antes que el resto.

La preconfirmación no promete que el bloque será definitivo: dice que un líder ya ejecutó esa transacción y que este fue su resultado.

Señal, no garantía: el matiz que separa una ventaja de una promesa

Helius es transparente con el modelo de confianza. La cobertura depende de qué validadores deciden compartir su flujo de preconfirmaciones y, por tanto, no es continua por diseño. Además, un bloque ejecutado todavía puede ser descartado o bifurcado antes del consenso; por eso la preconfirmación es una señal, no una certeza. El sistema que actúe sobre ella debe verificar después el resultado mediante otro flujo.

Esa distinción importa. Vender visibilidad temprana no es lo mismo que filtrar la cola de órdenes pendientes. Como la preconfirmación se emite después de la ejecución, la ventana para adelantarse a esa transacción dentro del bloque ya está cerrada. El suscriptor reacciona más rápido, pero no puede manipular la operación que está observando.

En la práctica, Helius expone esta señal a través de una suscripción WebSocket, una conexión persistente en tiempo real, en su endpoint Gatekeeper. Un cliente envía una petición preconfSubscribe con filtros de estado y región; a partir de ahí recibe el resultado de cada transacción ejecutada en los líderes cubiertos. Es un producto pensado para infraestructura de trading, bots y aplicaciones sensibles a la latencia, no para el usuario que consulta su wallet una vez al día.

El lanzamiento refuerza una tesis que ya venía del propio diseño de Solana: la velocidad no depende solo de más transacciones por segundo, sino de cómo y cuándo se observa el estado de la red. La llegada de Firedancer no cambia el modelo; su arquitectura de tiles aislados también emite el resultado local antes de difundir el bloque. De cara a la actualización Alpenglow, que retirará Proof of History, la lógica se mantiene: el líder seguirá ejecutando primero y propagando después. Conviene, eso sí, no confundir preconfirmación con finalidad: el consenso de los validadores sigue decidiendo qué bloque es canónico.

OpenAI y AWS han publicado una guía técnica para que los agentes de inteligencia artificial paguen en USDC sobre la red Base. No es una integración menor: los agentes podrán comprar datos o servicios por su cuenta, sin que una persona apruebe cada operación. Detrás está el protocolo x402, que convierte un viejo código web en un sistema de cobro criptográfico.

Un agente de IA es, en la práctica, un programa que ejecuta tareas por su cuenta, como consultar una fuente de datos o reservar un recurso. La guía publicada el 13 de agosto por OpenAI —titulada Controlled Agentic Commerce with AgentCore Payments— combina el kit de desarrollo de OpenAI con Bedrock AgentCore Payments de Amazon.

Cómo el protocolo x402 convierte un código HTTP en un cobro

El nombre x402 llega del código de estado HTTP 402, que desde los primeros años de internet significaba «pago requerido» y nunca se usó de forma masiva. Ahora sirve para que un servidor exija un pago antes de entregar una respuesta. El flujo es directo: el agente envía una petición; el servicio responde con un error 402 que incluye el importe y el activo exigido, USDC en Base; el agente comprueba si ese gasto cabe en sus límites y, si es así, genera una prueba de pago. Esa prueba regresa al proveedor, la transacción se liquida en Base y el agente recibe el recurso, todo en unos dos segundos.

El servicio Bedrock AgentCore Payments de Amazon se encarga de la infraestructura. Interpreta los desafíos x402, ayuda al agente a generar las pruebas dentro de sesiones de gasto definidas y mantiene registros de auditoría. La gran promesa es evitar los llamados «agentes rogue»: puesto que las reglas de gasto viven en la aplicación y no en el agente, la máquina nunca recibe un cheque en blanco. Opera dentro de límites fijados por el desarrollador.

La elección de Base, no es casual. Es la red de capa 2 creada por Coinbase, con tarifas bajas, y eso la hace compatible con pagos de apenas 0,25 USDC, el coste del escenario de demostración. USDC, la stablecoin de Circle anclada al dólar, aporta estabilidad de precio. Un agente no puede permitirse que la moneda se mueva un 5% entre la cotización y la liquidación.

El código HTTP 402 llevaba décadas esperando un propósito; los agentes de IA acaban de dárselo en forma de micropagos estables.

De Stripe a OpenAI: por qué x402 deja de ser un experimento

x402 nació de los esfuerzos de Coinbase en torno a Base y USDC, y su fundación —con Cloudflare en la gobernanza— lanzó la versión 2 en diciembre de 2025. Stripe añadió soporte para pagos en USDC en Base a través de x402 en febrero de 2026. Publicada el 13 de agosto, la guía de OpenAI funciona como plantilla abierta para cualquier desarrollador. Si además se distribuye entre los clientes empresariales de AWS, el alcance potencial deja de ser marginal.

Esto coloca a x402 en una posición distinta a la de otros estándares de pago para agentes. El respaldo de dos gigantes tecnológicos reduce la fricción de adopción. Pero también transforma un estándar abierto en una infraestructura que, en la práctica, depende de muy pocos actores.

El análisis: adopción real, centralización y la duda regulatoria

El movimiento llega cuando la IA busca modelos de monetización más allá de las suscripciones. Permitir que los agentes paguen por datos o servicios en cadena abre un «internet de los pagos» donde cada interacción puede tarifarse. Para Base y USDC es una validación práctica: micropagos automatizados de bajo valor con stablecoins y capa 2, no solo transferencias personales.

Sin embargo, el riesgo de concentración es evidente. La red Base es descentralizada, pero el flujo de agentes depende de OpenAI y AWS. Si esos dos actores controlan la infraestructura de pagos dominante, surgen dudas sobre censura, tarifas y gobernanza. La mayoría de los casos de uso, por ahora, se apoya en una capa centralizada.

El protocolo x402 tiene de su lado un detalle nada menor: resuelve un problema real de coordinación entre máquinas. Si los reguladores empiezan a mirar los flujos autónomos con criterios de protección al consumidor, el estándar tendrá que demostrar que sus límites de gasto y registros de auditoría bastan. Por ahora, la guía está disponible y el flujo se puede probar. La pregunta no es si los agentes pueden pagar; es quién controlará el carril por el que lo hacen.