¿TON tiene mempool? Qué se puede ver antes de un bloque

Pregunta «¿TON tiene mempool?» en un chat de desarrolladores y recibirás dos respuestas seguras. Una: «No, TON no tiene mempool». La otra: «Sí, aquí tienes una transacción pendiente de toncenter». Las dos aciertan en algo. TON no tiene un único pool de transacciones sin confirmar, compartido por toda la red, que cada nodo mantenga y acuerde, como ocurre en Bitcoin. Pero un mensaje sí existe antes de entrar en un bloque, los nodos lo ven, y unas cuantas API permiten asomarse a esa ventana.

Este artículo explica qué significa la palabra en TON, por qué «pending» en toncenter es una emulación, qué puede y qué no puede decirte un stream de mensajes previos al bloque, y cómo funciona el stream de mempool de TONNode, empezando por las limitaciones.

Qué significa «mempool» en TON

En Bitcoin o Ethereum el mempool es algo concreto: cada nodo completo guarda un conjunto de transacciones sin confirmar, lo difunde a sus pares y los productores de bloques eligen de él, normalmente por comisión.

TON parte de otra unidad. Un usuario nunca envía una «transacción». La app de la wallet firma un mensaje externo y se lo entrega a un nodo. En palabras de docs.ton.org, «los mensajes externos se envían desde fuera de la blockchain y, por tanto, solo tienen una dirección de remitente externa opcional». El contrato receptor, que para un usuario es el contrato de la wallet, comprueba la firma y el número de secuencia, llama a ACCEPT, y solo entonces nace una transacción: «cuando se procesa un mensaje externo entrante, la transacción se crea solo si el contrato acepta el mensaje».

De ahí se siguen tres consecuencias, y son la razón de que «el mempool de TON» sea una expresión laxa y no un objeto del protocolo.

• No hay con qué pujar. Un mensaje externo no lleva pago de su remitente. El contrato de destino paga el gas después de aceptar, con cargo a un crédito de gas que le permite inspeccionar el mensaje antes. Ninguna cola se ordena por precio, porque el mensaje no tiene precio.
• No hay una cola única. TON está fragmentado en shards: una cuenta pertenece a la shardchain cuyo prefijo coincide con el inicio de su dirección, y un mensaje dirigido a una wallet solo importa a los nodos que producen los bloques de ese shard. Un nodo que recibe un mensaje externo lo difunde en el overlay público, y la documentación señala que «los validadores los comparten entre sí y pueden entregarlo varias veces, por accidente (o a propósito)». Cada nodo guarda lo que ha oído; no existe un conjunto acordado en ninguna parte.
• Un mensaje rechazado no deja rastro. Si el contrato no acepta, porque la firma es incorrecta, el seqno ya se usó, valid_until ha vencido o no hay saldo con que pagar, no se crea ninguna transacción y ningún bloque registra el intento.

Así que cuando alguien dice «mempool de TON», la traducción honesta es: los mensajes externos que algún nodo ha recibido y difundido, y que ningún bloque ha incluido todavía. Es una ventana de unos segundos, se ve distinta desde cada nodo, y una parte de lo que contiene nunca se ejecutará. Esa ventana es lo que te muestra un stream de mempool.

Por qué «pending» en toncenter es una emulación

La API v3 de toncenter tiene GET /api/v3/pendingTransactions, documentado como «consultar transacciones pendientes que coincidan con los filtros indicados», por cuenta o por trace id. Su Streaming API entrega eventos con un campo finality que vale pending, confirmed o finalized, y define el primer nivel con precisión: «pending — resultado de una emulación o de una ejecución especulativa. Este estado puede invalidarse».

Una transacción pendiente en toncenter no se pesca de la cola de un nodo. El indexador toma el mensaje externo, lo ejecuta contra el estado actual de la cuenta tal como lo haría un validador, y publica la transacción prevista y las acciones que produciría. Cuando llega el bloque real, el evento se emite de nuevo como confirmed, y después como finalized; cuando la predicción resulta errónea, sigue una notificación trace_invalidated. Las suscripciones son por dirección: la operación subscribe del WebSocket recibe una lista addresses que «puede dejarse vacía solo al suscribirse a un trace; en los demás tipos de evento es obligatoria».

Esto es excelente para la pregunta que hacen casi todos los productos: ¿el pago de mi usuario ha pasado, y puedo mostrarlo un segundo antes? Lo que no te da es el flujo bruto de la red antes del bloque, cada mensaje de cada wallet, antes de que nada se haya emulado. Son dos productos distintos.

Qué puede y qué no puede mostrar un stream de mempool de TON

Un stream de mempool es el otro producto: un nodo que reenvía los mensajes externos en el momento en que los oye. Antes de construir sobre uno, los límites importan más que las funciones. Estos están tomados de la sección de calidad de datos de la documentación del mempool.

La cobertura es parcial. El stream lleva lo que un nodo recibe del overlay público. Un mensaje que nunca llega a ese nodo no está en el stream, y la ausencia en el stream no demuestra nada. TONNode no publica cifras de completitud ni de velocidad y no afirma ser el primero.

Pendiente no significa incluido. Un mensaje checked pasó las comprobaciones de difusión del nodo, no la ejecución del validador. En una muestra de 90 minutos de octubre de 2026, aproximadamente uno de cada cinco mensajes checked nunca fue aceptado en la cadena.

Los mensajes tempranos no están verificados. El hook más temprano del nodo se ejecuta antes de su comprobación de firma en la difusión, donde cualquier par del overlay puede inyectar bytes. El stream los entrega como "path":"early","unverified":true, por defecto, porque para algunos usos la ventaja de tiempo importa más que la certeza. Todo lo que actúe de forma automática envía "include_unverified":false o espera la copia checked con el mismo cell_hash.

parsed es el mejor esfuerzo. El cuerpo de wallet decodificado (v4r2, v5r1, highload_v3, una transferencia de jetton, un swap en un DEX) se infiere solo de los bytes del mensaje, y un contrato que imite la estructura de una wallet puede etiquetarse mal.

Hay duplicados. El mismo cell_hash puede llegar como early y luego como checked, otra vez tras una reconexión y, rara vez, pasada la ventana de deduplicación. El procesamiento tiene que ser idempotente por cell_hash.

Algunos mensajes se descartan a propósito: BoC de más de 65 535 bytes, BoC que no son mensajes externos y destinos que no son addr_std simples.

Si cualquiera de estos puntos rompe tu caso de uso, lo que necesitas son transacciones confirmadas, no un mempool. Detectar un pago entrante en USDT es el ejemplo canónico: un pago es una transacción en un bloque, y nada anterior debería marcar un pedido como pagado.

Cómo funciona el stream de mempool de TONNode

El stream de TONNode es un único WebSocket, wss://mempool.tonnode.io/v1/stream. Un servidor se autentica con Authorization: Bearer tnmp_…; un navegador no puede fijar cabeceras, así que un backend que guarda la clave pide a POST /v1/ticket un ticket de un solo uso válido 30 segundos y pasa los subprotocolos devueltos a new WebSocket(url, subprotocols). El primer mensaje de cada conexión es hello, copiado aquí de la documentación:

{"v":1,"type":"hello","contract":"1.1","epoch":"9f3c1a7be2d04c11","head_seq":123456,"oldest_seq":118020,
 "ts_gw_us":1791322891600000,"key_id":"0123456789ab",
 "limits":{"max_conn":3,"max_filters":null,"delay_ms":0,"replay_limit":null}}

No se entrega nada hasta que el cliente se suscribe. Los filtros son opcionales y se combinan con OR: dest (la wallet que envía), out_dest (a dónde envía la wallet), op (un código de operación, como 0x0f8a7ea5 para transferencias de jettons) y pool (un pool de DeDust). "filters":{} es el stream completo; una suscripción admite hasta 10 000 entradas, y un subscribe posterior sustituye los filtros sin repetición. Una suscripción con los cuatro tipos de filtro y sin mensajes tempranos:

{"v":1,"type":"subscribe",
 "filters":{"dest":["0:2a18ac1734f34579e6a6c2a9e738bb5799d21e7a73ef106895c00c34549a9167"],
            "out_dest":["EQB3ncyBUTjZUA5EnFKR5_EnOMI9V1tTEAAPaiU71gc4TiUt"],
            "op":["0x0f8a7ea5"],
            "pool":["0:a0d1bc3a139cbc6b39a3e3633f74476be441343f9d0fd88b949fca0327b65a75"]},
 "include_unverified":false}

El servidor confirma con el número de entradas distintas en vigor y el punto donde empieza la entrega:

{"v":1,"type":"subscribed","filters":4,"include_unverified":false,"from_seq":123451}

A partir de ahí llega un objeto JSON por mensaje, en orden de seq: el boc en bruto, sus hashes (cell_hash, el norm_hash normalizado según TEP-467, sha256), la wallet de destino, path y unverified, dos marcas de tiempo y, cuando se reconoce la estructura del cuerpo, parsed con el tipo de wallet, seqno, valid_until y las transferencias y swaps salientes.

Repetición. El servidor conserva los últimos ~60 segundos de eventos, como máximo 64 MiB. Tras una desconexión, reconecta, envía resume con el epoch y el último seq que procesaste, y recibe lo que te perdiste a través de tus nuevos filtros. Un evento gap indica qué se omitió y por qué: slow, source_reconnect o ring.

Planes. No se mide nada salvo las conexiones simultáneas de una clave: Test, 7 días, 1 conexión, $5; Start, 30 días, 1 conexión, $15; Pro, 30 días, 3 conexiones, $30; Business, 30 días, 10 conexiones, $100; más bajo petición. Sin cuota de mensajes, sin retardo añadido, sin plan gratuito. La clave se compra en la consola con el mismo saldo que los planes de nodos; la tabla completa está en la página de precios.

Lo que no está. Los mensajes enviados a través de los propios liteservers de TONNode no se reenvían a los suscriptores del mempool. Si envías con una clave de nodo de TONNode, esas transacciones no aparecen en este stream; para observar una wallet que controlas, envía por otra ruta o lee tus propios envíos desde la cadena.

Los consumidores completos en Node.js, Python y Go, el flujo de navegador con tickets y los códigos de error están en la documentación del stream de mempool.

TonAPI streaming y toncenter streaming, comparados con honestidad

Tres servicios tocan la ventana previa al bloque, y no son intercambiables. La Streaming API de TonAPI ofrecía GET /v2/sse/mempool y un método WebSocket subscribe_mempool con filtro opcional por cuentas; su propia documentación ahora empieza con «Streaming API is deprecated — please use Webhooks API for real-time updates». La Streaming API de Toncenter, en wss://toncenter.com/api/streaming/v2/ws, entrega transacciones, acciones, traces y cambios de estado con un nivel de finalidad; los eventos pendientes se emulan y pueden invalidarse, y las suscripciones exigen direcciones para todo salvo los traces.

Ninguno de los tres publica una cifra que permita comparar la cobertura. Mide con tu propio tráfico antes de decidir.

Quién necesita un stream de mempool y quién no

Probablemente lo necesitas si:

• tienes un DEX o un bot de trading, y los segundos entre que un swap se difunde y se ejecuta son tu ventaja, con include_unverified:false o un paso de confirmación antes de mover nada;
• vigilas un conjunto de wallets o un pool y quieres ver una transferencia o un swap en el momento en que se difunde, no cuando llega el bloque;
• estudias la red: tasas de mensajes, versiones de wallet, routers de DEX con carga, cuántos mensajes nunca se ejecutan.

No lo necesitas si:

• detectas pagos. Un pago es una transacción en un bloque; léela con get_transactions y nunca marques un pedido como pagado a partir de un mensaje pendiente;
• muestras saldos o historial. El mempool no tiene estado; usa el capítulo de LiteServers y el historial de transacciones por lt y hash;
• necesitas todos los mensajes, o tus propios envíos a través de los liteservers de TONNode. La cobertura es parcial por la propia naturaleza del overlay, y tus envíos no están en el stream por diseño.

Para el caso de trading, construir un agente de trading en TON recorre el ciclo de leer, cotizar y hacer swap delante del cual se colocaría un feed de mempool.

FAQ

¿TON tiene mempool?

No uno único y global. TON no tiene un pool de transacciones sin confirmar compartido por toda la red que cada nodo mantenga y acuerde. Lo que existe es el conjunto de mensajes externos que un nodo concreto ha recibido del overlay público y aún no ha visto en un bloque; varía de un nodo a otro, dura unos segundos e incluye mensajes que nunca se ejecutarán.

¿Puedo ver transacciones pendientes en TON?

Sí, en dos sentidos. Toncenter muestra transacciones y acciones pendientes producidas al emular un mensaje externo contra el estado actual, por dirección, y puede invalidarlas después. Un stream de mempool como el de TONNode muestra los propios mensajes externos en bruto, tal como los oye un nodo, antes de cualquier ejecución. Ninguno de los dos es una transacción confirmada; solo lo es un bloque.

¿Por qué un mensaje pendiente no está en un bloque?

Porque la transacción se crea solo si el contrato receptor acepta el mensaje. Una wallet rechaza una firma incorrecta, un seqno ya usado, un valid_until vencido o un mensaje que no puede pagar, y un mensaje rechazado no deja rastro en la cadena. Un mensaje también puede perderse antes de llegar a los nodos que producen los bloques de ese shard. En una muestra de 90 minutos de octubre de 2026, aproximadamente uno de cada cinco mensajes checked nunca fue aceptado.

¿Es completo el stream de mempool de TON?

No, y ningún stream puede serlo. El stream de TONNode lleva lo que un nodo recibe del overlay público; un mensaje que nunca le llega no está en el stream. TONNode no publica cifras de completitud ni de velocidad y no afirma ser el primero. La ausencia en el stream nunca prueba que algo no haya ocurrido.

¿Qué significa «unverified» en el stream?

Un mensaje temprano, escrito antes de la comprobación de firma del nodo en la difusión, en un punto donde cualquier par del overlay puede inyectar bytes, así que puede ser basura o una falsificación. Los mensajes tempranos se entregan por defecto; una suscripción con "include_unverified": false recibe solo mensajes checked, que pasaron las comprobaciones de difusión del nodo pero no han sido ejecutados por un validador.

¿Cuánto cuesta el stream de mempool de TONNode?

Los planes se cobran por conexiones simultáneas de una clave: Test son 7 días con 1 conexión por $5, Start son 30 días con 1 conexión por $15, Pro son 30 días con 3 conexiones por $30 y Business son 30 días con 10 conexiones por $100. No hay cuota de mensajes, ni retardo añadido, ni plan gratuito.

Antes de conectarte

Vuelve a leer la sección de calidad de datos, decide si necesitas mensajes tempranos siquiera, haz tu procesamiento idempotente por cell_hash y confirma en la cadena antes de mover dinero. Si encaja, una clave Test cuesta $5 por 7 días en la página de precios. Si no, el acceso privado a liteservers que lee el estado confirmado es la herramienta que la mayoría de los productos necesita en realidad.