---
title: "El costo de la latencia en el trading onchain"
description: "Los costos de latencia se manifiestan como la brecha entre el estado observado y la ejecución. Aquí se explica dónde aparece el retraso, por qué importa el p95 y cómo evaluar tu ruta RPC."
---

# El costo de la latencia en el trading onchain

<ImageBlock
  src="https://media.alchemy.com/blog/the-cost-of-latency-in-onchain-trading-hero.png"
  alt="El costo de la latencia"
  width={1024}
  height={480}
  priority
/>

Los costos de latencia se manifiestan como la brecha entre el estado de la cadena que un producto observó y el estado en el que su acción se ejecuta. Esa brecha crece con cada milisegundo que el producto pasa leyendo, decidiendo, enviando y esperando confirmación.

Para una vista de portafolio de largo plazo, esa brecha puede ser una molestia. Para un market maker, un enrutador de swaps, un motor de liquidación, o un trader que intenta cancelar una orden desactualizada, puede consumir una parte considerable del margen de la estrategia. El [RPC de baja latencia](/rpc-api) es fundamental para experiencias de trading exitosas porque ayuda a estos productos a actuar sobre estado más reciente.

## Una cotización puede desactualizarse antes de que una operación se ejecute

Una cotización de swap captura las reservas del pool, la liquidez del libro de órdenes, las condiciones de gas y el estado del mercado en el momento en que la aplicación la solicita. Esos insumos siguen cambiando mientras el usuario confirma una transacción.

El flujo básico es simple:

1. Una app lee el estado de la cadena y del mercado.
2. Calcula una cotización o decisión de trading.
3. El usuario envía una transacción.
4. La red la propaga, secuencia y ejecuta.
5. La app recibe un recibo y actualiza su vista.

Cada retraso hace que la acción final sea menos actual. Una lectura lenta usa datos de mercado más antiguos; un envío lento le da al mercado más tiempo para moverse; y una confirmación lenta deja a los usuarios viendo un estado desactualizado.

[0x](/case-studies/0x) cotiza operaciones entre distintas fuentes de liquidez. Su equipo vincula datos responsivos y precisos con la calidad de la cotización, porque los precios pueden moverse mientras las solicitudes están en tránsito, y genera esas cotizaciones en menos de un segundo.

[Jupiter](https://developers.jup.ag/docs/transaction/submit) ilustra la brecha de tiempo: su ruta de aterrizaje directo apunta a 50–400 milisegundos, o cero a un bloque de Solana, frente a 400 milisegundos a 1.2 segundos, o uno a tres bloques, para el envío estándar por RPC. Menos bloques entre la cotización y la ejecución dejan menos oportunidades para que el estado cambie.

## Las cuatro etapas donde la latencia se acumula

Cada operación pasa por estas etapas. El retraso en cualquiera de ellas hace que el resultado final sea menos actual o menos certero.

<EmbeddedTable
  table={{
    columns: [
      { key: "stage", width: 200, title: "Stage", dataType: "object" },
      {
        key: "measures",
        width: 280,
        title: "What it measures",
        dataType: "object",
      },
      {
        key: "cost",
        width: 300,
        title: "What a delay can cost",
        dataType: "object",
      },
    ],
    data: [
      {
        stage: { title: "Latencia de lectura", tooltip: "", icon: "" },
        measures: {
          title:
            "Tiempo para recibir una respuesta válida sobre balances, estado del pool, cotizaciones, recibos, o el último bloque mediante una llamada a la Node API.",
          tooltip: "",
          icon: "",
        },
        cost: {
          title:
            "Una estrategia o usuario toma una decisión sobre un estado antiguo. Una cotización puede ya estar desactualizada.",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        stage: { title: "Latencia de decisión", tooltip: "", icon: "" },
        measures: {
          title:
            "Tiempo dedicado a calcular una ruta, aplicar controles de riesgo, firmar o preparar una transacción.",
          tooltip: "",
          icon: "",
        },
        cost: {
          title:
            "La ventana de ejecución se amplía antes de que la transacción salga de la aplicación.",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        stage: {
          title: "Latencia de envío e inclusión",
          tooltip: "",
          icon: "",
        },
        measures: {
          title:
            "Tiempo desde la difusión hasta que la cadena o el motor de emparejamiento correspondiente acepta y secuencia la acción.",
          tooltip: "",
          icon: "",
        },
        cost: {
          title:
            "La liquidez cambia, una cancelación llega demasiado tarde, u otro participante obtiene prioridad.",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
      {
        stage: {
          title: "Latencia de confirmación y actualización",
          tooltip: "",
          icon: "",
        },
        measures: {
          title: "Tiempo para conocer el resultado y mostrar el estado actual.",
          tooltip: "",
          icon: "",
        },
        cost: {
          title:
            "Los usuarios ven balances desactualizados o un estado de transacción ambiguo, y los sistemas automatizados reaccionan más tarde.",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
    ],
  }}
/>

Estas etapas interactúan entre sí. Una lectura de mercado antigua sigue siendo antigua aun cuando la vía de escritura sea rápida. Durante un pico de volatilidad, las solicitudes más lentas importan más que el promedio. Las fallas también generan su propio riesgo: reintentos, pantallas desactualizadas y acciones no ejecutadas.

Los productos sensibles a la latencia deben evaluar el tiempo de respuesta p95 y p99 junto con la tasa de éxito. Nuestra [metodología de benchmark](/blog/how-we-benchmark-rpc-performance) pública mide lecturas EVM calentadas a nivel de método y reporta la latencia de respuestas exitosas por separado de las fallas. La [Node API](/rpc-api) subyacente cubre las lecturas y escrituras que un producto usa para interactuar con una cadena. Mide una ruta específica de un proveedor, mientras que un equipo de trading necesita probar sus propias lecturas, escrituras, regiones y patrón de tráfico.

## ¿Cómo se convierte la latencia en un costo económico en el trading onchain?

La latencia se convierte en un costo económico cuando cambia los resultados de ejecución, y la forma en que lo hace depende de la carga de trabajo. A continuación, los patrones que se repiten en sistemas de trading onchain.

### Swaps: una cotización desactualizada se convierte en slippage o en un revert

El impacto en precio y el slippage suelen agruparse, pero describen costos distintos. Nuestra [guía de infraestructura DeFi](/blog/how-alchemys-node-infrastructure-keeps-defi-fast-at-scale) muestra cómo aparecen estos costos en flujos de cotización en producción. El impacto en precio es el cambio predecible que una operación causa en el precio de un pool para un tamaño dado. El slippage es la brecha adicional entre el resultado cotizado y el resultado recibido en la ejecución. Depende de la latencia, las transacciones concurrentes y el orden de inclusión en el bloque.

Esa distinción importa en el diseño de producto. El impacto en precio es visible al momento de cotizar. El slippage crece mientras una transacción está pendiente. Una protección de salida mínima protege al usuario convirtiendo un movimiento de precio excesivo en un revert. Las transacciones con comisiones más bajas pueden esperar más tiempo mientras el entorno de precios cambia; una salida mínima, una entrada máxima, o un plazo límite establecen la peor ejecución que un usuario aceptará.

El resultado visible para el usuario es un precio peor, una operación perdida, o una ruta de ejecución más estricta que reduce la exposición a un mercado cambiante. Lecturas y envíos más rápidos reducen una parte de esa ventana de exposición.

### Market making y gestión de órdenes: una cancelación tardía puede convertirse en flujo tóxico

Los market makers actualizan continuamente sus cotizaciones a medida que los precios se mueven. Si el sistema se entera de un movimiento tarde, o envía una cancelación tarde, una orden pendiente puede completarse después de haberse vuelto no rentable. Los traders que colocan una orden inmediata enfrentan el riesgo opuesto: para cuando llega al mercado, la liquidez disponible puede haber desaparecido.

### Liquidaciones y arbitraje: el tiempo es parte de la oportunidad

Los motores de liquidación y los sistemas de arbitraje compiten por observar un cambio de estado y actuar antes de que la oportunidad se cierre. La carrera relevante puede ser un nuevo precio de oráculo, un factor de salud cambiado, un desbalance de pool, o un movimiento de precio entre plataformas. Perderla puede significar ingresos perdidos. Los intentos fallidos repetidos también pueden consumir comisiones y espacio de bloque.

El diseño de la cadena cambia la forma de esta carrera. En sistemas que secuencian por orden de llegada, una ruta de menor latencia puede ser directamente relevante para el ordenamiento. En sistemas que usan comisiones de prioridad, tanto las comisiones como el tiempo importan. En sistemas con flujo de órdenes privado o bundles, la visibilidad y la ejecución atómica introducen otras contrapartidas. La infraestructura opera dentro de esas reglas de mercado. Su función es evitar agregar demora innecesaria antes de que una estrategia entre en ellas.

### Wallets e interfaces de trading: el retraso se convierte en un problema de confianza

La latencia afecta más que el precio de llenado. Una wallet o app de trading puede emitir muchas llamadas antes de que el usuario vea una pantalla útil: balances, aprobaciones, cotizaciones de rutas, estimaciones de gas, recibos e historial de transacciones. Si esas llamadas responden lento o fallan de forma intermitente, los usuarios ven precios cambiantes, estado retrasado, o una interfaz que parece congelada.

Esto resulta especialmente dañino durante la volatilidad. La misma actualización lenta de balance que es apenas molesta en un mercado tranquilo puede retrasar una cobertura, una decisión de cancelación, o la confirmación de un depósito cuando un usuario está intentando gestionar su riesgo.

## Por qué la latencia de cola importa más que un promedio

Las distribuciones de latencia tienen colas. Cuando un endpoint se ralentiza bajo carga, el producto experimenta la ruta lenta durante un aumento de tráfico, volatilidad o congestión de la cadena.

Por eso una revisión de proveedor debe responder cuatro preguntas:

- ¿Qué métodos están en la ruta crítica? Evalúa una lectura del último bloque, `eth_call`, `eth_getLogs`, la búsqueda de recibos y la difusión de transacciones por separado; cada uno tiene un comportamiento distinto.
- ¿Desde qué regiones se conectan los usuarios y los servicios? La geografía cambia la ruta de red.
- ¿Qué tan lentas son las llamadas exitosas en p95 y p99? Esos valores revelan las solicitudes que un promedio oculta.
- ¿Con qué frecuencia fallan o expiran las solicitudes? Un timeout es un evento de confiabilidad que puede desencadenar reintentos, una UI desactualizada, o una acción no ejecutada.

Un benchmark debe hacer explícitas esas condiciones y medir la ruta de producto que un comprador realmente ejecuta. Nuestra [metodología de benchmark](/blog/how-we-benchmark-rpc-performance) fija el origen de la solicitud, el método, el payload, el timeout, las reglas de éxito y el estado de la conexión para cada comparación a nivel de método, para ayudar a los equipos de desarrollo a tomar decisiones de infraestructura.

## Qué puede y qué no puede resolver el RPC de baja latencia

Una capa de RPC más rápida puede devolver el estado actual antes, enviar una transacción firmada antes, y mantener una interfaz de trading responsiva. La calidad del llenado sigue dependiendo del movimiento del mercado, la liquidez, las comisiones, la selección de ruta, la protección de la transacción, y la política de secuenciación de la cadena. El [benchmark de lectura](/benchmarks) de un proveedor mide el rendimiento de lectura; el rendimiento de swap de extremo a extremo, la inclusión de transacciones, el comportamiento de WebSocket y el PnL de la estrategia requieren pruebas separadas.

Este alcance mantiene honestas las afirmaciones sobre infraestructura y ayuda a los equipos a elegir mediciones que correspondan a su carga de trabajo. El objetivo es eliminar la demora evitable en las rutas donde la economía de un producto es más sensible al tiempo.

Construimos nuestro [trabajo de RPC de baja latencia](/blog/how-we-built-low-latency-rpc-infrastructure) en torno a ese objetivo. [Alchemy Edge Proxy](/blog/alchemy-edge-proxy) elimina la sobrecarga fija de la ruta de solicitud en el ingreso, y redujo el p99 de APAC de 150 milisegundos a 20 milisegundos en su medición de migración. El enrutamiento de [Cortex](/cortex) selecciona un nodo saludable por solicitud en lugar de tratar la proximidad como toda la respuesta. Cortex también sustenta la capacidad y las operaciones de flota que mantienen la ruta de solicitud responsiva bajo carga. Nuestro trabajo de infraestructura de baja latencia abarca el edge, el enrutamiento, la capacidad, las operaciones de nodos y la medición. Cada capa está ajustada para ofrecerte un servicio confiable de baja latencia.

## Cómo evaluar tu propia ruta de ejecución

Comienza por el flujo donde el retraso genera el mayor costo económico o para el usuario.

1. Traza la ruta desde la lectura del estado hasta el resultado visible para el usuario, incluyendo el cálculo de la ruta, la firma, el envío, la inclusión y la actualización de estado.
2. Prueba los métodos y payloads que tu producto realmente usa, desde las regiones donde operan tus servicios y usuarios. Comienza con la [RPC API](/rpc-api) y las [cadenas compatibles](/rpc) de las que depende tu producto. Ejecuta la misma prueba durante períodos normales y durante períodos de alta volatilidad o alto tráfico.
3. Registra p50, p95, p99, tasa de éxito, tasa de timeout, y el tiempo de cotización a resultado. Mantén separadas la latencia de lectura, de envío y de inclusión.
4. Conecta esas mediciones con resultados: desviación entre cotización y llenado, reverts, operaciones perdidas, éxito de cancelación, contactos de soporte, y abandono de usuarios.

Esto genera un modelo de costos para tu estrategia, tus activos y tus usuarios, y muestra dónde una ruta más rápida cambia los resultados de ejecución.

## Preguntas frecuentes

### ¿Cómo afecta la latencia de RPC al rendimiento del trading?

La latencia amplía la brecha entre el estado que una app de trading observó y el estado en el que su transacción se ejecuta. Las lecturas lentas hacen que una cotización se desactualice antes de firmarse, el envío lento le da al mercado más tiempo para moverse, y la confirmación lenta deja a los usuarios actuando sobre una pantalla desactualizada. El resultado son peores llenados, operaciones perdidas, o reverts.

### ¿Una menor latencia de RPC garantiza un mejor llenado de la operación?

Una menor latencia de RPC reduce la demora evitable antes y durante el envío. La calidad del llenado también depende del movimiento del mercado, la liquidez, las comisiones, el flujo de órdenes privado, la selección de ruta, la secuenciación de la cadena, y la protección de la transacción.

### ¿Por qué el p95 es más útil que el promedio de latencia de RPC para apps de trading?

Un promedio puede ocultar las solicitudes lentas que se agrupan durante carga o volatilidad. El p95 muestra que el 95% de las respuestas exitosas fueron al menos así de rápidas bajo las condiciones medidas. Léelo junto con la tasa de éxito, ya que las fallas y los timeouts necesitan su propia medición de confiabilidad.

### ¿Cómo hago benchmark de un proveedor de RPC para una app de trading?

Prueba los métodos y payloads que tu producto realmente usa, desde las regiones donde operan tus usuarios y servicios. Usa nuestra [metodología de benchmark](/blog/how-we-benchmark-rpc-performance) como punto de partida reproducible. Registra p50, p95, p99, tasa de éxito y tasa de timeout, y mantén separadas la latencia de lectura, de envío y de inclusión. Repite la prueba durante ventanas volátiles y de alto tráfico, así como en condiciones de mercado tranquilo.

### ¿El impacto en precio es lo mismo que el slippage?

No. El impacto en precio es el efecto predecible del tamaño de la operación en el pool actual. El slippage es la diferencia, al momento de la ejecución, entre el resultado cotizado y lo que el usuario recibe. La [documentación de Raydium](https://docs.raydium.io/algorithms/slippage-and-price-impact) ofrece una definición técnica clara de cada uno.

### ¿Los equipos de trading deben hacer benchmark de lecturas, escrituras y flujos completos por separado?

Sí. Una prueba de lectura a nivel de método puede comparar el comportamiento de un proveedor en una solicitud específica. Una prueba de flujo de trading completo es necesaria para entender juntos la vigencia de la cotización, la toma de decisiones, el envío, la inclusión y la confirmación. Mantén las conclusiones separadas.