TRON Energy desde Telegram: el pedido completo dentro del chat

Un bot de Telegram que vende TRON Energy suele ser un formulario con botones. Elegir cantidad, pagar, recibir una línea de texto y quedarse en el chat adivinando si el recurso ha llegado.

El bot de Telegram de TRON Energy @rentron_energy_bot está montado al revés. No es una copia ligera de la web sino la misma cuenta por otra puerta, y la pantalla que tiene delante la vuelve a dibujar el servidor cuando el pedido cambia de etapa. Hay un botón Actualizar bajo el pedido mientras se procesa, pero aquí nada espera a que se pulse.

Conviene poner una advertencia arriba, porque es la mitad que se cita mal. Ese comportamiento pertenece al bot. La API pública no tiene webhooks ni callbacks: en Telegram la pantalla se actualiza sola, en el código pregunta usted, con el calendario que fije.

¿Qué hace realmente el bot dentro del chat?

El alquiler entero y la cuenta que lo rodea.

Un pedido avanza en cuatro pasos: cantidad y duración, la dirección desde la que salen los USDT, una cotización y la creación. Los valores que se ofrecen salen del mismo sitio del que los lee la web, así que el pedido no es una versión reducida de nada.

Alrededor está aquello por lo que normalmente se sale de un chat. La pantalla de saldo muestra el importe disponible y el retenido, con la dirección de depósito permanente como línea copiable y como código QR. Las direcciones guardadas se pueden añadir, renombrar y borrar, y cada una se abre con los recursos que tiene en ese momento.

El historial es paginado, con listas separadas para pedidos y depósitos. Un pedido abierto muestra su progreso etapa por etapa. En ajustes está el idioma de la interfaz, los mismos seis que publica el sitio. El soporte tiene pantalla propia y la conversación iniciada allí se traslada en lugar de acabar en un menú.

Un punto merece línea aparte: la vista de recursos por dirección. Invierte el orden más habitual, que es pedir primero y descubrir después que allí ya había Energy o que la dirección elegida no era esa.

En la pantalla principal hay además un botón que abre Rentron como Mini App, para los momentos en que una página entera se lee mejor que un mensaje.

¿El saldo del bot es un saldo aparte?

No, y este es el dato que conviene llevarse de la página.

Entrar por la web y abrir el bot llevan al mismo registro de contacto. Desde ahí ambos leen una sola cuenta: el mismo importe disponible, el mismo importe retenido, la misma dirección de depósito permanente. No existe una billetera que pertenezca al bot y no hay nada que mover de un lado a otro.

La consecuencia es pequeña y útil de verdad. Recargar en el escritorio y pedir desde el teléfono, o al revés. Los TRX enviados a esa dirección permanente cuentan se mire desde donde se mire, y un pedido hecho en el chat sale del mismo saldo que se recargó en la web.

Por eso la dirección de depósito no hay que volver a copiarla en cada superficie. Pertenece a la cuenta, no a la pantalla que la mostró.

También se nota lo que falta: un segundo registro. Ambas vías se apoyan en una cuenta de Telegram confirmada, y en ningún lado aparece otro par de usuario y contraseña.

¿Cómo se hace un pedido sin salir de Telegram?

Cinco pasos, en este orden:

1. Abra la pantalla de alquiler, desde el menú o con un enlace que lleve directamente allí.
2. Elija la cantidad y la duración. La Energy se vende en porciones fijas de 65.000, hasta 1.300.000 en un pedido, es decir veinte porciones. Las duraciones son 15 minutos, 1 hora, 4 horas y 24 horas.
3. Indique la dirección desde la que saldrán los USDT. Una guardada se elige con un toque; una nueva se añade y se nombra aquí mismo.
4. Pida una cotización para ese pedido exacto. No se cobra nada por ella.
5. Cree el pedido. El importe queda fijado en este punto, contra esa cotización.

Del paso 4 conviene decir algo claro. Una cotización no reserva nada ni guarda el precio para más tarde: es una cifra para ahora, y lo que se cobra queda fijado al crear el pedido. La cuestión de la cantidad se resuelve antes: cómo estimar la Energy de una transferencia de USDT trata lo que necesita una llamada concreta, y el alquiler en sí está descrito en la página principal.

Las porciones fijas no son una traba. La cantidad siempre es múltiplo de 65.000, de modo que se elige un número de porciones y no una cifra libre, y así no hay forma de equivocarse en un orden de magnitud. La contrapartida es el techo de veinte porciones por pedido.

La duración también se elige, no se escribe. Quince minutos bastan cuando la transferencia sale ya. Las ventanas largas sirven para el caso contrario, cuando entre el pedido y la firma queda trabajo: confirmar el importe, esperar una aprobación, revisar el destinatario.

¿Hay que pulsar Actualizar?

No. El botón existe — está bajo el pedido mientras este sigue en curso —, pero la pantalla está suscrita en lugar de dibujada una vez, así que el estado llega sin él.

La alimentan dos flujos de eventos. Uno lleva el estado de un pedido concreto, mientras ese sea el que tiene abierto. El otro lleva los depósitos acreditados y cuelga de la cuenta, no de un pedido en particular. Cuando llega una señal, la pantalla se redibuja donde está.

Esas señales las publica el servidor. Dentro del bot nada pregunta por reloj si algo ha cambiado, así que Actualizar queda para quien prefiera preguntar antes que esperar: no es la vía por la que llega el estado, y tampoco aparece un intervalo que aguantar.

Una suscripción dura 30 días, y pasar a otro pedido traslada el flujo a ese en vez de apilar una segunda suscripción sobre la primera. La ganancia es estrecha y aun así se nota: cambia el mensaje que está mirando.

Un chat es de por sí mal sitio para un estado que se mueve. El mensaje leído se congela, el nuevo baja y, tras diez minutos de conversación, hay que buscar el pedido otra vez. La suscripción quita justo eso: el pedido vive en una pantalla y no en una cadena de sus estados anteriores.

¿La API envía las mismas actualizaciones?

No, y confundirlo sale caro.

La API pública no tiene webhooks ni callbacks. El estado de un pedido se lee consultando el pedido. El ritmo documentado es 1, 2 y 5 segundos tras la creación, después cada 10 segundos, con algo de jitter cuando hay varios pedidos en marcha.

Tres marcas deciden qué hacer con la respuesta. energy_usable es la de actuar: se pone en true durante el estado available, alrededor de un minuto antes de delivered, y significa que la Energy está en la dirección y se puede gastar. Esperar a delivered solo consume tiempo de alquiler ya pagado.

delivery_final y lifecycle_final son las de parar, y únicamente cuando ambas son true. Parar con una sola marca, o con un estado, corta el bucle antes de tiempo. Tampoco hay entorno de pruebas, así que la primera llamada de una integración cae sobre un saldo real. La matriz de reintentos correspondiente está en consultas y reintentos seguros.

La diferencia se ve también en cómo termina la espera. En el bot termina sola: llega una señal y la pantalla cambia. En el código la cierra su bucle, y ese mismo bucle decide cuándo parar, por las marcas y no por un aviso externo.

¿Para qué sirven los enlaces directos?

Son dos, y ambos sirven para pasar una tarea al chat desde otro sitio.

Un parámetro de inicio que empieza por rent_ abre el flujo de alquiler directamente, saltándose el menú. Un parámetro de inicio con un identificador de pedido abre ese pedido: su etapa, su progreso y la misma suscripción que recibe cualquier pantalla de pedido.

El uso se ve enseguida. Un enlace en una conversación de soporte, o un traspaso desde el sitio, deja al lector en el pedido del que se está hablando y no en un menú que tendría que recorrer después.

El segundo uso es volver a un pedido abierto. El enlace con el identificador lleva directo a su pantalla y nadie tiene que recordar en qué página del historial estaba.

¿Qué superficie encaja con cada tarea?

Tres preguntas lo resuelven, y la primera suele bastar.

¿Es una persona enviando una transferencia a mano, desde el teléfono, que prefiere que le muestren el estado a tener que buscarlo? Ese es el bot, y no hace falta abrir un navegador. Cómo queda frente al resto del mercado es otra página: siete servicios comparados sin publicidad.

¿Es un programa el que hace los pedidos: una tanda de pagos, una cola de retiradas, algo que corre mientras nadie mira? Esa es la API, con su propio bucle de consulta, su política de reintentos y una clave de idempotencia obligatoria en cada pedido. Las señales descritas arriba no llegan hasta allí.

¿La elección mueve el dinero de sitio? No. Una cuenta, un saldo, una dirección de depósito; las superficies se diferencian en el acceso, no en el contenido. Mirar el estado actual de la dirección antes de pedir sigue mereciendo el minuto: cómo consultar el saldo de TRON Energy.

De ahí sale una tercera respuesta: las dos. La cuenta es una, de modo que el historial de pedidos del bot es el historial de la cuenta y no el del chat, independientemente del lado desde el que se pidiera.

Hay un límite que se mantiene en todas las superficies. La Energy se asigna a una dirección pública de TRON, y esa asignación no lleva ninguna autoridad para firmar: la transferencia de USDT la sigue firmando usted en su propia wallet. Esa cuestión tiene página propia: ¿es seguro alquilar TRON Energy?.

Resumen

El bot @rentron_energy_bot no es un escaparate con un menú pegado. El alquiler entero ocurre en el chat — cantidad y duración, dirección de envío, cotización y pedido — junto al saldo con su dirección de depósito copiable y su código QR, direcciones guardadas que se añaden, renombran y borran, historial paginado de pedidos y depósitos, progreso por etapas, el idioma de la interfaz en seis versiones y una pantalla de soporte que traslada la conversación.

Tampoco es una segunda cuenta. La entrada por web y el bot llevan al mismo registro de contacto y, detrás, a una sola cuenta: un importe disponible, un importe retenido, una dirección de depósito permanente. Recargue en el escritorio y pida desde el teléfono; entre medias no hay nada que mover.

Lo que no tiene equivalente en otro sitio es que la pantalla esté suscrita. La alimentan dos flujos publicados por el servidor — el estado del pedido abierto y los depósitos acreditados en la cuenta — y una suscripción dura 30 días. El botón Actualizar sigue bajo el pedido en curso, como recurso manual y no como mecanismo: lo que cambia es el mensaje que ya tiene delante.

Léalo en sentido estrecho, porque pertenece al bot. La API pública no tiene webhooks ni callbacks, así que una integración consulta: 1, 2 y 5 segundos, luego cada 10 con jitter. Actúe con energy_usable en vez de esperar a delivered, pare solo cuando delivery_final y lifecycle_final sean ambos true, y cuente con que no hay entorno de pruebas donde ensayar.

Elija según quién hace el pedido. Una persona en un chat está mejor aquí. Un programa no, y conviene construirlo esperando tener que preguntar.