Arquitectura de un bot para Pump.fun: detección, ejecución y medición

Alcance y respuesta directa

Un bot de pump.fun es un software que observa el programa on-chain de pump.fun en Solana, decide si un token o una operación cumple una regla y envía una transacción firmada para comprar o vender. El término abarca varios diseños distintos: snipers de lanzamiento que actúan en la creación del token, bots de copy-trading que replican una billetera, bots de volumen que generan operaciones en un token y bots de salida que gestionan posiciones después de la entrada. Comparten las mismas primitivas de infraestructura: una fuente de eventos, una estrategia, un constructor de transacciones, una billetera de firma y una ruta RPC al clúster.

La respuesta práctica a "cómo construyo uno" es separar la detección de la ejecución y medir cada etapa de forma independiente. La mayoría de los resultados decepcionantes en vivo provienen de una ruta de detección más lenta o ruidosa de lo supuesto, o de un modelo de ejecución que ignora la competencia, las comisiones prioritarias y el slippage. Trata el bot como un sistema distribuido sensible a la latencia, no como un script.

• Detección: suscripción WebSocket, flujo Geyser o sondeo de cuentas del programa.
• Decisión: reglas deterministas sobre eventos analizados, con motivos de rechazo explícitos.
• Ejecución: construcción de la transacción, presupuesto de cómputo, comisión prioritaria, firma, envío, confirmación.
• Medición: etapas con marca de tiempo desde la recepción del evento hasta el slot confirmado.

Suposiciones y requisitos previos

Esta guía asume que puedes ejecutar Python 3.10+ o Node.js 18+, poseer un par de claves de Solana que controlas y tener acceso a un endpoint RPC que admita los métodos que necesitas. Debes entender las cuentas, instrucciones y confirmación de transacciones de Solana. No necesitas un proveedor específico; el código utiliza marcadores de posición como RPC_URL y PRIVATE_KEY.

Antes de escribir el código de la estrategia, confirma que tu endpoint admite las suscripciones y métodos que planeas usar. Las suscripciones WebSocket, getProgramAccounts con filtros, sendTransaction con skipPreflight y getSignatureStatuses se comportan de manera diferente según el proveedor y los límites de velocidad. Para la selección de endpoints, consulta la guía de RPC Assistant sobre el mejor proveedor RPC de Solana y compara planes en la página de precios de RPC.

• Una billetera financiada con un pequeño saldo de SOL para comisiones y operaciones de prueba.
• Una URL RPC con soporte WebSocket si utilizas suscripciones.
• Una fuente de reloj local en la que confíes para medir la latencia.
• Un destino de registro que registre cada decisión y rechazo.

Modelo mental: el bot como una tubería con etapas observables

Piensa en el bot como cinco etapas: ingesta, análisis, decisión, construcción y aterrizaje. La ingesta recibe notificaciones sin procesar. El análisis las decodifica en mints de tokens, cantidades y slots. La decisión aplica tus reglas y produce una intención. La construcción arma y firma una transacción. El aterrizaje la envía y espera confirmación. Cada etapa tiene una marca de tiempo y un modo de fallo.

La vista de tubería evita un error común: optimizar la estrategia mientras se ignora el retraso de ingesta. Una regla que se activa 200 ms después del evento es inútil si un bot competidor se activa a los 50 ms. También hace que la medición sea honesta, porque puedes atribuir la latencia a una etapa en lugar de informar un único número de extremo a extremo que oculta dónde se fue el tiempo.

• Retraso de ingesta: tiempo desde el evento en el clúster hasta que tu proceso lo recibe.
• Costo de análisis: tiempo de CPU para decodificar y validar.
• Costo de decisión: evaluación de la estrategia, generalmente insignificante.
• Costo de construcción: ensamblaje y firma de la transacción.
• Costo de aterrizaje: envío por red, programación del líder, confirmación.

Detección: suscripción a la actividad del programa pump.fun

El método de detección más directo es una suscripción WebSocket a los logs que mencionan el ID del programa pump.fun. Recibes notificaciones a medida que el clúster procesa transacciones y luego filtras por el patrón de instrucción o log que indica un nuevo token o una operación. Esto es más simple que Geyser pero depende de la fiabilidad del WebSocket de tu proveedor y de los límites de velocidad.

El siguiente esquema en Python se suscribe a los logs e imprime las firmas candidatas. Reemplaza RPC_URL y el marcador de posición del ID del programa con valores que hayas verificado. No realiza operaciones; es un arnés de detección que puedes ampliar.

import asyncio, json, time
import websockets

RPC_WS = "RPC_URL".replace("https", "wss")
PUMP_PROGRAM = "PUMP_PROGRAM_ID"

async def main():
    async with websockets.connect(RPC_WS, ping_interval=20) as ws:
        sub = {
            "jsonrpc": "2.0", "id": 1, "method": "logsSubscribe",
            "params": [{"mentions": [PUMP_PROGRAM]}, {"commitment": "processed"}]
        }
        await ws.send(json.dumps(sub))
        while True:
            msg = json.loads(await ws.recv())
            if msg.get("method") != "logsNotification":
                continue
            value = msg["params"]["result"]["value"]
            sig = value.get("signature")
            logs = value.get("logs", [])
            ts = time.time()
            print(json.dumps({"ts": ts, "sig": sig, "log_count": len(logs)}))

asyncio.run(main())

Ejecución: construir y enviar una transacción

La ejecución requiere construir la instrucción correcta para el programa pump.fun, establecer un presupuesto de cómputo, adjuntar una comisión prioritaria, firmar y enviar. El diseño exacto de la instrucción depende de la interfaz actual del programa; utiliza el IDL del programa o una biblioteca cliente mantenida en lugar de codificar el orden de las cuentas. El ejemplo a continuación muestra el bucle de envío y confirmación con skipPreflight y sondeo de estado, que puedes envolver alrededor de cualquier constructor de instrucciones.

Establece un límite de unidades de cómputo y un precio de forma deliberada. Demasiado bajo y la transacción falla; demasiado alto y pagas de más. Las comisiones prioritarias son impulsadas por el mercado y cambian con la congestión, así que trátalas como un parámetro configurable y registra el valor utilizado en cada intento.

import time, base64
import requests

RPC_URL = "RPC_URL"

def send_and_confirm(signed_tx_b64: str, timeout_s: float = 30.0) -> dict:
    payload = {
        "jsonrpc": "2.0", "id": 1, "method": "sendTransaction",
        "params": [signed_tx_b64, {"encoding": "base64", "skipPreflight": True,
                                   "maxRetries": 3}]
    }
    r = requests.post(RPC_URL, json=payload, timeout=10).json()
    if "error" in r:
        return {"stage": "send", "error": r["error"]}
    sig = r["result"]
    deadline = time.time() + timeout_s
    while time.time() < deadline:
        status = requests.post(RPC_URL, json={
            "jsonrpc": "2.0", "id": 2, "method": "getSignatureStatuses",
            "params": [[sig], {"searchTransactionHistory": False}]
        }, timeout=10).json()
        val = status.get("result", {}).get("value", [None])[0]
        if val and val.get("confirmationStatus") in ("confirmed", "finalized"):
            return {"stage": "confirmed", "sig": sig, "slot": val.get("slot")}
        if val and val.get("err"):
            return {"stage": "failed", "sig": sig, "err": val["err"]}
        time.sleep(0.5)
    return {"stage": "timeout", "sig": sig}

Medición: un procedimiento de latencia reproducible

No informes un único número de latencia. Registra una marca de tiempo en cada etapa de la tubería y calcula la distribución sobre una muestra fija. Ejecuta el procedimiento en la misma máquina, red y endpoint para toda la muestra, y registra el endpoint, el nivel de compromiso y la ventana de tiempo junto con los resultados.

Procedimiento: (1) inicia el arnés de detección y registra las marcas de tiempo de ingesta; (2) para cada evento detectado, registra las marcas de tiempo de decisión, construcción, envío y confirmación; (3) recopila al menos 200 eventos; (4) calcula p50, p90 y p99 para cada etapa y para el extremo a extremo; (5) repite en un segundo endpoint y compara. La tabla a continuación es la plantilla para completar con tus propias mediciones; no copies números de otros lugares.

• | Etapa | p50 (ms) | p90 (ms) | p99 (ms) | Notas |
• | Ingesta | | | | endpoint, compromiso |
• | Análisis + decisión | | | | limitado por CPU |
• | Construcción + firma | | | | tipo de par de claves |
• | Envío a confirmado | | | | comisión prioritaria utilizada |
• | Extremo a extremo | | | | tamaño de muestra |

Verificación: cómo se ve una ejecución saludable

Una ejecución de detección saludable imprime un flujo constante de firmas con recuentos de logs plausibles y sin brechas superiores al intervalo de notificación esperado de tu endpoint. Una ejecución de ejecución saludable muestra transacciones confirmadas con slots cercanos al momento del envío y una baja tasa de errores de preflight o simulación. Si ves brechas largas, verifica el keepalive del WebSocket y los límites de velocidad del proveedor. Si ves muchas fallas, inspecciona los códigos de error antes de cambiar la estrategia.

Para cada intento de operación, registra la intención, la firma de la transacción firmada, la respuesta de envío y el estado final. Este registro es la única base confiable para depurar y para comparar resultados en papel con resultados en vivo.

• Detección: sin brechas inexplicables; errores de análisis cercanos a cero.
• Ejecución: tasa de confirmación y códigos de error registrados por intento.
• Latencia: distribuciones por etapa registradas, no solo promedios.
• Costo: comisiones prioritarias y unidades de cómputo registradas por transacción.

Solución de problemas comunes

La mayoría de las fallas se agrupan en unas pocas categorías. La expiración del blockhash ocurre cuando una transacción se construye pero no aterriza rápidamente; reconstruye con un blockhash fresco. El agotamiento del presupuesto de cómputo aparece como un error de simulación; aumenta el límite o simplifica la instrucción. Los errores de slippage y de cuenta aparecen cuando el estado del pool cambió entre la construcción y el aterrizaje; vuelve a leer el estado y reconstruye. La limitación de velocidad aparece como HTTP 429 o mensajes WebSocket perdidos; reduce el alcance de la suscripción o cambia a un endpoint dedicado.

Las discrepancias en el trading en papel merecen especial atención. Un modelo de ejecución en papel que asume que obtienes el precio de creación ignora que otros bots pueden comprar en el mismo slot. Si tus entradas en vivo son consistentemente peores que en papel, el modelo es el problema, no la red. Mide la brecha entre tu precio previsto y tu precio realizado en muchas operaciones antes de concluir que la latencia es la causa.

• Blockhash no encontrado: reconstruye inmediatamente antes de enviar.
• Cómputo excedido: aumenta el límite, verifica las cuentas de la instrucción.
• Slippage excedido: amplía la tolerancia o reduce el tamaño.
• 429 / suscripción perdida: verifica los límites del proveedor, considera un nodo dedicado.
• Brecha persistente entre papel y vivo: audita primero el modelo de ejecución.

Limitaciones, compensaciones y operación responsable

La latencia tiene un piso establecido por la física y por el calendario de líderes del clúster; ningún bot puede garantizar la primera posición. Las estrategias que dependen de ser el primero son competitivas y frágiles. Los bots de volumen y de comentarios plantean cuestiones éticas y de política de plataforma separadas, y el trading automatizado puede violar las reglas del lugar de negociación o la ley local. Trata cualquier bot como software de alto riesgo que puede perder fondos por errores, compromiso de claves o movimientos adversos del mercado.

Operativamente, elige entre infraestructura compartida y dedicada basándote en la fiabilidad medida, no en afirmaciones de marketing. Un nodo dedicado puede reducir la contención y darte más control sobre las suscripciones; un endpoint compartido es más barato para experimentación de bajo volumen. Compara las compensaciones en la página de nodo dedicado y en la página de precios de RPC, y mantén los secretos fuera de los registros.

• No hay orden garantizado; diseña para fallos parciales.
• Las comisiones prioritarias son un costo recurrente que escala con los intentos.
• La gestión de claves es un límite de seguridad; usa billeteras aisladas.
• Mide antes de optimizar; la intuición sobre la latencia a menudo es errónea.

Próximos pasos

Comienza con el arnés de detección, confirma que tu endpoint entrega notificaciones de manera confiable, luego agrega una ruta de ejecución en seco que construya y simule transacciones sin enviarlas. Solo después de que la simulación esté limpia deberías enviar pequeñas operaciones en vivo y comenzar el procedimiento de medición. Mantén un registro de cambios de estrategia e infraestructura para que los cambios de latencia puedan atribuirse.

Para la selección de endpoints y detalles de red, utiliza RPC Assistant y las páginas de red de OnFinality en lugar de adivinar. Revisa la guía de la red Solana, la descripción general del servicio API y las opciones de nodo dedicado, y vuelve a revisar la tabla de medición después de cualquier cambio de infraestructura.

• Construye la detección, luego la simulación, luego la ejecución en vivo.
• Registra las marcas de tiempo de las etapas desde la primera ejecución.
• Vuelve a medir después de cambiar endpoints o configuraciones de comisiones.
• Mantén separados los cambios de estrategia y de infraestructura.