Jito Explorer: Lectura de datos de bundles, tips y validadores en Solana

Qué muestra realmente Jito Explorer

Jito Explorer es un panel web que agrega datos sobre los bundles de Jito en la mainnet de Solana. Un bundle es un grupo ordenado de hasta cinco transacciones que un searcher envía a un motor de bloques de Jito; el bundle aterriza de forma atómica en un solo slot o no aterriza en absoluto. El explorador muestra esa actividad como gráficos y tablas en lugar de registros de transacciones sin procesar.

Las vistas principales que encontrarás son: una descripción general del volumen de bundles y tips en una ventana de tiempo seleccionable (semana, mes, año), una tabla de bundles más recientes y con los tips más grandes, estadísticas de bundles por slot que incluyen el porcentaje de unidades de cómputo aterrizadas y los tips del bloque, una clasificación de los bundles más grandes por firmante y herramientas complementarias como una vista de estadísticas de comisiones, un escaneo de searchers y un flujo en tiempo real del tip-floor. Cada vista responde a una pregunta diferente, y confundirlas es la fuente más común de confusión.

Este artículo trata sobre la interpretación y la reproducción, no sobre el diseño visual del panel. Si solo necesitas un endpoint RPC de Solana para ejecutar las consultas a continuación, la elección concreta del proveedor la gestiona RPC Assistant por separado; la metodología aquí es neutral respecto al proveedor.

• Gráficos de descripción general: tendencias del número de bundles y del volumen de tips a lo largo del tiempo.
• Tablas de bundles: bundles recientes y con los tips más grandes, con activos, tipper, validador y monto del tip.
• Estadísticas por slot: unidades de cómputo aterrizadas, tips del bloque y número de bundles por slot.
• Clasificaciones de firmantes: qué direcciones están produciendo los bundles más grandes.
• Herramientas complementarias: estadísticas de comisiones, escaneo de searchers y un tip-floor en streaming.

Supuestos y requisitos previos

Los procedimientos a continuación suponen que tienes un endpoint RPC de la mainnet de Solana que admite métodos JSON-RPC estándar como getSlot, getBlock, getTransaction y getSignaturesForAddress. Los datos específicos de Jito no son un espacio de nombres nativo del RPC de Solana; los metadatos de los bundles los produce la infraestructura de Jito y se exponen a través de las propias API y paneles de Jito. Tu RPC te da la verdad on-chain (qué transacciones aterrizaron, en qué slot y con qué uso de cómputo), mientras que las superficies de Jito te dan el contexto a nivel de bundle.

También querrás una forma de ejecutar pequeños scripts: curl para pruebas rápidas y Node.js o Python para cualquier cosa que recorra slots. Mantén un RPC_URL de marcador de posición y, si envías bundles, una PRIVATE_KEY en variables de entorno en lugar de en archivos de código. Nada en esta guía requiere SOL de mainnet para leer datos, pero enviar un bundle sí.

El modelo mental: bundles, tips y slots

Una transacción normal de Solana es atómica por sí misma: todas sus instrucciones tienen éxito o fallan juntas. Las transacciones separadas no son atómicas entre sí, por lo que un searcher que necesita que dos operaciones dependientes aterricen ambas no tiene garantía nativa. Los bundles de Jito resuelven eso permitiendo que un searcher envíe una lista ordenada de transacciones que el motor de bloques reenvía a un validador habilitado para Jito como una unidad. Si el bundle no puede ejecutarse en orden dentro del slot, nada de él aterriza.

La palanca económica es el tip. Un bundle incluye una transferencia a una cuenta de tips de Jito, y los validadores tienen incentivos para incluir bundles con tips más altos. Por lo tanto, el tip-floor es un precio de mercado en vivo por la inclusión de bundles, y se mueve con la congestión. La vista del tip-floor de Jito Explorer transmite percentiles de ese precio; las tablas de bundles muestran los tips realizados en bundles que realmente aterrizaron.

El slot es la unidad de comparación. Cada bundle aterriza en un slot específico o se descarta. Por eso el gráfico por slot del explorador (unidades de cómputo aterrizadas, tips del bloque, número de bundles) es la vista más útil analíticamente: te permite ver cuánto del presupuesto de cómputo de un bloque consumieron los bundles y cuánto ganó el bloque en tips.

Leer la tabla de bundles sin malinterpretarla

Las tablas de bundles más recientes y con los tips más grandes enumeran bundles con una firma truncada, los activos involucrados, la dirección del tipper, el validador que aterrizó el bundle, el monto del tip en SOL y una marca de tiempo relativa. Se aplican dos advertencias. Primero, 'tips más grandes' es una clasificación de tips realizados, no de rentabilidad; un tip grande puede seguir siendo una operación perdedora para el searcher. Segundo, la columna de activos refleja movimientos de tokens dentro del bundle, lo cual es útil para detectar patrones de arbitraje pero no es una declaración sobre la intención.

Cuando compares un bundle de la tabla con los datos on-chain, usa la firma completa, no la forma truncada. Los hashes truncados del explorador son comodidades de visualización; los métodos RPC a continuación requieren la firma completa en base58.

Reproducir métricas de bundles a nivel de slot con curl

La forma más rápida de verificar un slot que viste en el explorador es obtener el bloque e inspeccionar sus transacciones y uso de cómputo. La siguiente prueba devuelve el slot actual y luego el bloque en un slot que elijas. Reemplaza RPC_URL y SLOT con tu endpoint y el número de slot del gráfico por slot del explorador.

La respuesta incluye la firma de cada transacción, las unidades de cómputo consumidas y la comisión. Sumar las unidades de cómputo de las transacciones del bloque te da la misma cifra de cómputo aterrizado que grafica el explorador, y puedes cruzar las firmas con la tabla de bundles.

curl -s RPC_URL -X POST -H 'Content-Type: application/json' -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getBlock",
  "params": [
    SLOT,
    {
      "encoding": "json",
      "transactionDetails": "full",
      "rewards": false,
      "maxSupportedTransactionVersion": 0
    }
  ]
}'

Un script ejecutable para agregar la actividad de bundles

Para cualquier cosa más allá de un solo slot, automatiza el bucle. El ejemplo de Node.js a continuación recorre un rango de slots, obtiene cada bloque e imprime el número de transacciones y el total de unidades de cómputo por slot. Usa solo JSON-RPC estándar, por lo que funciona con cualquier endpoint de la mainnet de Solana. Establece RPC_URL y ajusta START_SLOT y END_SLOT a la ventana que quieras estudiar.

La salida es una tabla que puedes pegar en una hoja de cálculo. Compárala con el gráfico por slot del explorador para la misma ventana; si las formas divergen, la causa más probable es que tu ventana incluya slots omitidos, que devuelven null de getBlock y deben contarse por separado en lugar de tratarse como bloques con cero actividad.

const RPC_URL = process.env.RPC_URL;
const START_SLOT = 0; // set to your start slot
const END_SLOT = 0;   // set to your end slot

async function rpc(method, params) {
  const res = await fetch(RPC_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ jsonrpc: '2.0', id: 1, method, params })
  });
  const json = await res.json();
  if (json.error) throw new Error(JSON.stringify(json.error));
  return json.result;
}

async function main() {
  for (let slot = START_SLOT; slot <= END_SLOT; slot++) {
    const block = await rpc('getBlock', [
      slot,
      { encoding: 'json', transactionDetails: 'full', rewards: false, maxSupportedTransactionVersion: 0 }
    ]);
    if (!block) {
      console.log(`${slot}\tskipped`);
      continue;
    }
    const txs = block.transactions || [];
    const cu = txs.reduce((sum, t) => sum + (t.meta?.computeUnitsConsumed || 0), 0);
    console.log(`${slot}\t${txs.length}\t${cu}`);
  }
}

main().catch((e) => { console.error(e); process.exit(1); });

Verificar un bundle específico on-chain

Cuando un bundle aparece en el explorador pero quieres confirmar su contenido, obtén la transacción por firma. La llamada a continuación devuelve la transacción con metadatos, incluidos los mensajes de registro y las instrucciones internas, que es donde aparecen las transferencias de tips y las instrucciones de swap.

Una verificación exitosa tiene tres propiedades: la transacción existe en el slot que reportó el explorador, su meta.err es null y las instrucciones internas incluyen una transferencia a una cuenta de tips de Jito cuyo monto en lamports coincide con el tip mostrado en la tabla. Si alguna de ellas falla, trata la fila del panel como obsoleta o mal atribuida y vuelve a verificar antes de sacar conclusiones.

curl -s RPC_URL -X POST -H 'Content-Type: application/json' -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getTransaction",
  "params": [
    "SIGNATURE",
    { "encoding": "json", "maxSupportedTransactionVersion": 0 }
  ]
}'

Tabla de resultados: qué registrar

Dado que los tip-floors y los volúmenes de bundles cambian continuamente, no hay números fijos que pertenezcan a una guía. En su lugar, registra tus propias mediciones en una tabla con estas columnas para que los resultados sean comparables entre ejecuciones y entre endpoints. Ejecuta la misma ventana contra dos endpoints RPC y completa ambas filas; la divergencia en la cobertura de slots o en los totales de cómputo es una señal sobre la consistencia del endpoint, no sobre Jito en sí.

• Ventana (slot inicial, slot final, marcas de tiempo UTC).
• Etiqueta del endpoint (alias de RPC_URL, no la URL sin procesar).
• Slots solicitados, slots devueltos, slots omitidos.
• Total de transacciones y total de unidades de cómputo consumidas.
• Bundles observados en el explorador para la misma ventana.
• Tip mediano y p90 de la vista del tip-floor en el momento de la captura.
• Notas sobre cualquier slot donde tus totales y el panel no coincidan.

Solución de discrepancias comunes

La mayor parte de la confusión en torno a Jito Explorer proviene de cuatro situaciones recurrentes. Revísalas en orden antes de asumir que el panel está equivocado.

Primero, los slots omitidos. Un slot sin bloque devuelve null, y tratarlo como cero actividad hará que tu agregado parezca más bajo que el gráfico. Segundo, los límites de zona horaria y ventana: el selector de semana/mes/año del explorador usa su propia lógica de límites, por lo que un rango manual de slots rara vez se alineará exactamente. Tercero, las firmas truncadas: copiar un hash acortado de la tabla hará que getTransaction falle. Cuarto, la atribución del tip: el tip mostrado es la transferencia realizada dentro del bundle, que puede diferir del tip-floor en el momento del envío porque el floor se movió entre el envío y el aterrizaje.

• Confirma que el slot realmente produjo un bloque antes de comparar totales.
• Alinea tu ventana de slots con el rango mostrado por el explorador, no con la intuición del reloj de pared.
• Usa firmas completas en base58 para cada consulta RPC.
• Distingue el tip realizado del tip-floor en vivo al razonar sobre la inclusión.

Limitaciones y compensaciones del análisis basado primero en el panel

Un explorador público está optimizado para la exploración, no para la investigación reproducible. Sus agregaciones son convenientes pero opacas: no puedes ver exactamente cómo se calculó un percentil, cómo se cuentan los bundles fallidos o cómo la clasificación de firmantes maneja la agrupación de direcciones. Para preguntas puntuales eso está bien. Para cualquier cosa que vayas a citar, publicar o sobre la que vayas a construir una estrategia, reproduce la métrica a partir de datos RPC sin procesar y conserva el script.

También hay una compensación de dependencia. Depender de un solo panel significa que tu visión del mercado es tan fresca y completa como la ingesta de ese panel. Ejecutar tu propia agregación a nivel de slot contra un endpoint RPC confiable te da una verificación independiente y te permite extender el análisis, por ejemplo, uniendo firmas de bundles con tus propios registros de searcher. El costo es tiempo de ingeniería y rendimiento de RPC; el beneficio es que tus números son tuyos para defenderlos.

De la exploración a un pipeline repetible

Una vez que puedas reproducir los totales a nivel de slot, el siguiente paso natural es programar la agregación y almacenar los resultados. Un pipeline simple ejecuta el bucle de Node.js con un temporizador, escribe una fila por slot en una base de datos y calcula resúmenes móviles de tips y utilización de cómputo. Eso te da una serie histórica que controlas, mucho más útil para ajustar la estrategia de tips que leer un gráfico en vivo.

Si operas a mayor volumen, un nodo dedicado elimina la variabilidad de los endpoints compartidos y mantiene consistente tu cobertura de slots. Revisa las redes y opciones de nodo disponibles antes de comprometerte, y mantén la elección del endpoint separada del código de análisis para poder cambiar de proveedor sin reescribir scripts.

• Programa el bucle de slots y persiste los resultados con una marca de tiempo y una etiqueta de endpoint.
• Calcula medianas móviles en lugar de instantáneas de un solo slot.
• Alerta sobre divergencias repentinas entre tus totales y el panel público.
• Mantén las credenciales RPC en variables de entorno y rótalas.

A dónde ir después

Si tu objetivo es enviar bundles en lugar de solo observarlos, los siguientes temas son la construcción de bundles, la selección de la cuenta de tips y el flujo de envío al motor de bloques; esos son independientes de la interpretación del explorador y merecen su propio tratamiento. Si tu objetivo es la recolección confiable de datos, comienza con un endpoint de Solana que satisfaga tus necesidades de rendimiento y luego construye la agregación de slots anterior contra él.

Para la selección de endpoints específicamente, usa RPC Assistant en lugar de adivinar a partir de una lista. Para la planificación de infraestructura, compara las opciones compartidas y dedicadas con tu volumen de solicitudes esperado, y revisa la tabla de medición después de cualquier cambio de proveedor para confirmar que tu cobertura de slots se mantuvo consistente.