Construyendo un bot sniper para Pump.fun en Solana: detección, ejecución y medición

Alcance y la respuesta directa

Un bot sniper para Pump.fun es un programa que se suscribe a la actividad de Solana en torno al programa de lanzamiento de Pump.fun, identifica las nuevas mints de tokens creadas y dispara una transacción de compra con una tarifa prioritaria y un deslizamiento configurados antes de que otros compradores llenen la curva de vinculación. No es una sola llamada a la API: es un pipeline de detección, decodificación, construcción de transacciones, selección de tarifas, envío y seguimiento de confirmación.

Este artículo cubre la ingeniería de ese pipeline para personas que ya tienen un par de claves de Solana y familiaridad básica con las transacciones. No recomienda un producto de bot específico y no afirma ninguna velocidad medida. Cada número que te importa —retraso de detección, tasa de inclusión, precio de ejecución— debe medirse en tu propia infraestructura, porque esos valores dependen de tu región, ruta RPC, configuración de tarifas y el lanzamiento en sí.

Si solo necesitas una recomendación concreta de endpoint RPC o proveedor para cargas de trabajo de trading en Solana, utiliza la guía de RPC Assistant sobre el mejor proveedor RPC de Solana en lugar de tratar esta página como una lista de proveedores.

• Se asume: un par de claves de Solana con fondos, Node.js o Python, y acceso a un endpoint RPC de Solana que controles o alquiles.
• Fuera de alcance: asesoramiento legal, fiscal o de mercado; estrategias con ganancias garantizadas; cualquier afirmación sobre tasas de éxito.
• Entregable: un bucle de detección, un constructor de transacciones y un arnés de medición que puedas ejecutar repetidamente.

Requisitos previos y suposiciones antes de escribir código

Necesitas un endpoint RPC de Solana que admita los métodos de suscripción y consulta que utiliza tu bot. Los endpoints públicos tienen límites de velocidad y no son adecuados para sniping, así que planifica un endpoint dedicado o de alto rendimiento; consulta la descripción general del alojamiento de nodos y la página de precios de RPC para planificar la capacidad. También necesitas el ID del programa Pump.fun y su IDL de Anchor, porque la decodificación de las cuentas de lanzamiento depende del diseño de cuentas del programa, no de una API REST pública.

Asume que el programa de lanzamiento puede cambiar. Los discriminadores de Anchor y el orden de las cuentas forman parte de la interfaz del programa, así que fija la versión del IDL con la que construyes y vuelve a verificarla después de cualquier actualización del programa. Asume también que tu transacción competirá con muchas otras en el mismo slot; el diseño debe tolerar fallos y reintentar en lugar de asumir que un único envío se incluirá.

• Un par de claves almacenado fuera del control de código fuente, cargado desde una variable de entorno como PRIVATE_KEY.
• Un marcador de posición RPC_URL que reemplazarás con tu propio endpoint.
• El ID del programa Pump.fun y un archivo IDL fijado para la decodificación.
• Un destino de registro para que cada detección y envío tenga una marca de tiempo para su posterior análisis.

Cómo funciona realmente la detección de lanzamientos

Hay tres rutas prácticas de detección y difieren en latencia y coste operativo. La primera es la suscripción a logs: suscribirse a los logs que mencionan el programa Pump.fun y filtrar por la instrucción de creación. La segunda es la suscripción a cuentas: vigilar las cuentas asociadas del programa o las cuentas de la curva de vinculación derivadas por mint. La tercera es el streaming a nivel de bloque o de shred, donde recibes los datos de la transacción antes en la ruta de propagación, a costa de más infraestructura y trabajo de análisis.

La suscripción a logs es la más sencilla de operar y es suficiente para construir un bot correcto. También es la ruta más sensible a la rapidez con que tu nodo RPC ve la transacción y la reenvía la notificación. Los streams a nivel de shred o estilo Geyser pueden reducir ese retraso, pero requieren un proveedor que los exponga y un analizador que maneje datos no finalizados. Empieza con logs, mide y luego decide si los datos más tempranos merecen la complejidad.

• logsSubscribe con un filtro de mención en el programa de lanzamiento: menor sobrecarga operativa.
• Suscripción a cuenta o programa: útil cuando necesitas el estado de la cuenta, no solo el evento.
• Streaming de bloques o shreds: datos más tempranos, mayor carga de análisis e infraestructura.

Bucle de detección ejecutable en JavaScript

El siguiente script se suscribe a los logs del programa Pump.fun e imprime cualquier firma cuyas líneas de log contengan el discriminador de creación. Es deliberadamente mínimo: demuestra que tu endpoint entrega notificaciones y te da una marca de tiempo para comparar con el tiempo de bloque. Reemplaza RPC_URL y el ID del programa con tus propios valores, y confirma el discriminador con tu IDL fijado antes de confiar en él.

Ejecútalo durante varios minutos en períodos de lanzamientos activos. Si no ves ninguna notificación, el problema es la conectividad o el filtro, no tu lógica de trading. Si ves notificaciones pero llegan después de que el token ya tenga operaciones, tu ruta de detección es demasiado lenta y deberías probar una suscripción o endpoint diferente.

import { Connection, PublicKey } from '@solana/web3.js';

const RPC_URL = process.env.RPC_URL;
const PUMP_PROGRAM_ID = new PublicKey(process.env.PUMP_PROGRAM_ID);
const CREATE_DISCRIMINATOR = process.env.CREATE_DISCRIMINATOR; // from pinned IDL

const connection = new Connection(RPC_URL, { wsEndpoint: process.env.WS_URL });

connection.onLogs(PUMP_PROGRAM_ID, (logInfo) => {
  const hit = logInfo.logs.some((line) => line.includes(CREATE_DISCRIMINATOR));
  if (!hit) return;
  console.log(JSON.stringify({
    detectedAt: Date.now(),
    signature: logInfo.signature,
    err: logInfo.err
  }));
}, 'confirmed');

console.log('listening for Pump.fun create events');

Decodificación del lanzamiento y construcción de la transacción de compra

Una vez que tengas una firma, obtén la transacción con getTransaction usando codificación jsonParsed o base64, luego decodifica los datos de la instrucción con el IDL de Pump.fun. Necesitas la dirección de la mint, la cuenta de la curva de vinculación y las cuentas de token asociadas que espera la instrucción de compra. No adivines el orden de las cuentas: derívalo del IDL y de las claves de cuenta de la transacción obtenida.

La transacción de compra en sí es una transacción normal de Solana con una instrucción de presupuesto de cómputo, una tarifa prioritaria y la instrucción de compra del programa. Establece el límite de unidades de cómputo a partir de una simulación en lugar de una suposición fija, y establece la tarifa prioritaria según las condiciones recientes de la red. La tolerancia al deslizamiento pertenece a los argumentos de la instrucción donde el programa lo admita; de lo contrario, applícala en tu propia verificación previa a la operación contra el estado de la curva de vinculación.

• Simula primero con simulateTransaction para detectar errores de cuenta o de deslizamiento antes de gastar tarifas.
• Añade ComputeBudgetProgram.setComputeUnitLimit y setComputeUnitPrice explícitamente.
• Firma localmente; nunca envíes una clave privada a un proveedor RPC.
• Sigue la firma con una estrategia de confirmación que distinga processed, confirmed y finalized.

Envío de transacción ejecutable con tarifa prioritaria

Este esbozo en Python muestra la forma de una ruta de envío: construir la transacción, simular, establecer un precio por unidad de cómputo, firmar y enviar con un bucle de reintentos. Utiliza marcadores de posición para la instrucción del programa porque las cuentas exactas provienen de tu lanzamiento decodificado. El detalle de ingeniería importante es que la ruta de envío es idempotente por lanzamiento y registra cada intento con una marca de tiempo.

Mantén el reintento acotado. Reemitir la misma transacción firmada es seguro hasta que expire su blockhash; reconstruir con un nuevo blockhash y una tarifa más alta es una decisión diferente que debe registrarse por separado para que tus datos de medición se mantengan limpios.

import os, time, json
from solana.rpc.api import Client
from solana.rpc.commitment import Confirmed
from solana.transaction import Transaction
from solders.keypair import Keypair
from solders.compute_budget import set_compute_unit_limit, set_compute_unit_price

RPC_URL = os.environ['RPC_URL']
client = Client(RPC_URL)
payer = Keypair.from_base58_string(os.environ['PRIVATE_KEY'])

def submit(build_ix, cu_limit=200_000, micro_lamports=50_000, attempts=3):
    for attempt in range(attempts):
        tx = Transaction()
        tx.add(set_compute_unit_limit(cu_limit))
        tx.add(set_compute_unit_price(micro_lamports))
        tx.add(build_ix())
        tx.recent_blockhash = client.get_latest_blockhash(Confirmed).value.blockhash
        tx.sign(payer)
        sim = client.simulate_transaction(tx)
        if sim.value.err:
            print(json.dumps({'attempt': attempt, 'simErr': str(sim.value.err)}))
            return None
        sent = client.send_raw_transaction(tx.serialize())
        print(json.dumps({'attempt': attempt, 'sentAt': time.time(), 'sig': str(sent.value)}))
        time.sleep(0.2)
    return None

Midiendo tú mismo la latencia de detección y de inclusión

Las páginas de los proveedores citan tiempos de ejecución en milisegundos, pero esos números no son comparables entre bots, regiones o condiciones de red. Construye tu propio arnés. Para cada lanzamiento que detectes, registra cuatro marcas de tiempo: el tiempo de bloque de la transacción de lanzamiento, el momento en que se disparó tu callback de detección, el momento en que enviaste y el tiempo de confirmación de tu compra. La diferencia entre el tiempo de bloque y la detección es tu retraso de detección; entre el envío y la confirmación es tu retraso de inclusión.

Ejecuta al menos unas docenas de lanzamientos en diferentes momentos del día y registra los resultados en una tabla como la siguiente. Deja las celdas vacías hasta que tengas datos reales; no las rellenes con estimaciones. Agrega la mediana y el percentil 90 en lugar de la media, porque las distribuciones de latencia están sesgadas por valores atípicos.

• Usa la misma fuente de reloj para todas las marcas de tiempo; solo hosts sincronizados con NTP.
• Registra los envíos fallidos y descartados como filas propias, no como datos faltantes.
• Compara el precio de ejecución con la primera operación en el mismo slot para juzgar si llegaste temprano o tarde.

Resultados de verificación esperados

Un bucle de detección correctamente cableado produce un flujo constante de eventos de creación durante los períodos activos, cada uno con una firma que puedes consultar en un explorador de Solana. Una transacción correctamente construida se simula sin errores y devuelve una firma al enviarse. Una ejecución correctamente medida produce una tabla con marcas de tiempo no vacías y una mezcla de intentos incluidos y fallidos, lo cual es normal en lanzamientos competitivos.

Si tu bucle de detección está silencioso, verifica el endpoint WebSocket por separado del endpoint HTTP; muchos proveedores los exponen en hosts diferentes. Si las simulaciones fallan con errores de cuenta, tu IDL o la derivación de cuentas está desactualizada. Si los envíos devuelven firmas pero nunca se confirman, es probable que tu tarifa prioritaria esté por debajo del mercado actual y que tu blockhash expire antes de la inclusión.

Solución de problemas de modos de fallo comunes

La mayoría de los fallos de los bots sniper se agrupan en cuatro categorías: detección, decodificación, inclusión y contabilidad. Los fallos de detección se manifiestan como silencio o eventos tardíos. Los fallos de decodificación se manifiestan como errores de cuenta no encontrada o instrucción inválida durante la simulación. Los fallos de inclusión se manifiestan como firmas enviadas pero no confirmadas. Los fallos de contabilidad se manifiestan como operaciones que se incluyeron pero no se registraron, lo que corrompe tus datos de medición.

Trabájalos en ese orden. Confirma que la suscripción entrega algo, luego confirma que el IDL coincide con el programa en cadena, después ajusta las tarifas y el comportamiento de reintento, y finalmente concilia tus registros con el historial en cadena. Saltar al ajuste de tarifas mientras la detección está rota produce conclusiones engañosas sobre el rendimiento del endpoint.

• Suscripción silenciosa: verifica WS_URL, el ID del programa y que el endpoint permita suscripciones.
• Errores de cuenta en simulación: actualiza el IDL y vuelve a derivar las cuentas de la curva de vinculación y de token.
• Enviado pero no confirmado: aumenta el precio por unidad de cómputo, actualiza el blockhash y verifica el estado del slot.
• Registros faltantes: concilia las firmas con getSignaturesForAddress para tu cartera.

Limitaciones, compensaciones y controles de riesgo

El sniping es una carrera de suma negativa en el margen: la ventaja de velocidad de cada participante es relativa, y las mejoras en detección o tarifas se igualan rápidamente. Un bot que se incluye de manera fiable aún enfrenta selección adversa, porque los lanzamientos que ganas suelen ser los que otros bots rechazaron. Trata cualquier estrategia como experimental y limita la exposición por lanzamiento y por día en el código, no en la disciplina.

Operativamente, los datos más tempranos cuestan más y fallan más a menudo. Los streams a nivel de shred requieren análisis personalizado y toleran datos no finalizados, por lo que tu bot debe manejar reversiones. Las suscripciones a logs son más simples pero más lentas. Elige según el retraso de detección medido para tu carga de trabajo, no según afirmaciones de marketing. Para capacidad y elección de endpoints, la descripción general de nodos dedicados y la guía de endpoints RPC explican las compensaciones entre infraestructura compartida y dedicada.

• Límites estrictos en el tamaño de la posición y el gasto diario aplicados en la ruta de firma.
• Un interruptor de emergencia que detenga los envíos cuando las tasas de error superen un umbral.
• Carteras separadas para experimentación y para cualquier capital que te importe.
• Re-verificación regular del IDL del programa tras actualizaciones.

Próximos pasos

Una vez que la detección y el envío sean estables, las mejoras de mayor impacto son la disciplina de medición y la ubicación de la infraestructura. Ejecuta el arnés de latencia semanalmente, mantén la tabla de resultados y cambia una variable a la vez: endpoint, región, tipo de suscripción o política de tarifas. Eso convierte el ajuste de conjeturas en un experimento.

Para la decisión concreta del endpoint, recurre a RPC Assistant en lugar de copiar el nombre de un proveedor de una lista. Si aún estás eligiendo una red o planificando capacidad, revisa las redes compatibles y los niveles de precios de RPC, y considera un nodo dedicado si tu medición muestra que los endpoints compartidos son el cuello de botella.

• Lee la guía del mejor proveedor RPC de Solana para la selección de endpoints.
• Revisa la guía de Solana devnet antes de probar estrategias fuera de la mainnet.
• Compara capacidad compartida y dedicada en la página de precios.
• Mantén tu tabla de medición versionada junto con la configuración de tu bot.