Энергия TRON в Telegram: весь заказ, не выходя из чата

Боты, которые продают энергию в TRON, устроены одинаково: меню, кнопка «купить», сумма, оплата — а дальше вы сидите в чате и гадаете, пришёл ресурс или нет.

Аренда энергии TRON в Telegram у Rentron собрана иначе. Бот @rentron_energy_bot — не облегчённая копия сайта, а тот же аккаунт с другого входа. Экран, на который вы смотрите, перерисовывает сервер, когда заказ меняет стадию. Кнопка «Обновить» под заказом в работе есть, но экран не ждёт нажатия — он меняется сам.

Одну оговорку стоит поставить в начало, потому что именно её обычно перевирают. Так ведёт себя бот. У публичного API вебхуков и колбэков нет вовсе: в Telegram экран обновляется сам, в коде вы спрашиваете сами, по своему графику.

Ниже — что бот умеет, чем он связан с сайтом и где живое обновление заканчивается. Цен здесь нет: сумму называет котировка в момент заказа.

Что бот умеет на самом деле?

Всю аренду целиком и аккаунт вокруг неё.

Заказ идёт в четыре шага: объём и срок, адрес, с которого уйдёт USDT, котировка, создание заказа. Параметры и их значения бот берёт оттуда же, откуда сайт, — урезанного набора у него нет.

Рядом лежит всё, ради чего обычно приходится выходить из чата. Экран баланса показывает доступную сумму и удержанную под заказы, постоянный адрес пополнения — строкой с копированием и QR-кодом. Сохранённые адреса можно добавлять, переименовывать и удалять, а каждый — открыть и посмотреть ресурсы, которые на нём сейчас есть.

История постраничная, заказы и депозиты — отдельными списками. Открытый заказ показывает прогресс по стадиям. В настройках — язык интерфейса, те же шесть, что и на сайте. Поддержка вынесена на отдельный экран, и начатая там переписка передаётся дальше, а не упирается в меню.

Отдельно стоит выделить просмотр ресурсов по конкретному адресу. Он разворачивает частый порядок действий обратно: сначала заказать, а потом выяснить, что Energy на адресе уже есть или что адрес выбран не тот. Сохранённый адрес открывается из списка, и текущие ресурсы видно до оформления заказа.

На главном экране есть кнопка, которая открывает Rentron как Mini App, — на случай, когда полноценная страница читается лучше сообщения.

Баланс в боте — отдельный?

Нет. Это главный факт страницы.

Вход на сайте и запуск бота приводят к одной и той же записи контакта. Дальше оба читают один аккаунт: та же доступная сумма, та же удержанная под заказы, тот же постоянный адрес пополнения. Кошелька «для бота» не существует, и перекладывать между ними нечего.

Следствие небольшое и удобное. Пополнить с компьютера, заказать с телефона — или наоборот. TRX, отправленные на постоянный адрес, видны с любой стороны, а заказ из чата списывается с того же баланса, который пополняли на сайте.

Адрес пополнения из-за этого не нужно копировать заново под каждую поверхность: он закреплён за аккаунтом, а не за экраном, который его показал.

Здесь же видно, чего в боте нет, — отдельной регистрации. Вход и там, и на сайте опирается на подтверждённую учётную запись Telegram, поэтому второй пары логина с паролем не появляется ни на одной стороне.

Как оформить заказ, не выходя из чата?

Пять шагов, по порядку:

1. Открыть экран аренды — из меню или по ссылке, которая ведёт прямо туда.
2. Выбрать объём и срок. Energy продаётся фиксированными порциями по 65 000, максимум в одном заказе — 1 300 000, то есть двадцать порций. Сроки: 15 минут, 1 час, 4 часа и 24 часа.
3. Указать адрес, с которого уйдёт USDT. Сохранённый выбирается одним касанием, новый добавляется и называется здесь же.
4. Запросить котировку ровно на этот заказ. Списания при этом нет.
5. Создать заказ. Сумма фиксируется на этом шаге, по той самой котировке.

О четвёртом шаге стоит сказать прямо. Котировка ничего не резервирует и не удерживает цену на потом — это число на сейчас, а списывается то, что зафиксировано при создании заказа. Сам объём считается ещё раньше: как рассчитать Energy для перевода USDT разбирает, сколько нужно конкретному вызову, а сама аренда описана на главной.

Фиксированные порции — не ограничение ради ограничения. Объём всегда кратен 65 000, поэтому выбирается количество порций, а не произвольное число, и ошибиться на порядок в поле ввода не получится. Обратная сторона у этого тоже есть: потолок в двадцать порций на один заказ.

Срок тоже выбирается из списка, а не вводится. Пятнадцати минут хватает, когда перевод готов к отправке прямо сейчас. Более длинные сроки нужны в обратном случае — когда между заказом и подписью остаётся работа: согласовать сумму, дождаться подтверждения, свериться с получателем.

Нужно ли нажимать «Обновить»?

Нет. Кнопка есть — она стоит под заказом, пока заказ в работе, — но экран подписан, а не нарисован один раз, и статус доходит без неё.

Его кормят два потока событий. Первый — статус конкретного заказа, пока этот заказ у вас открыт. Второй — зачисления депозитов; он привязан к аккаунту, а не к отдельному заказу. Пришёл сигнал — экран перерисовывается на том же месте.

Сигналы публикует сервер. По таймеру в боте никто не спрашивает, изменилось ли что-нибудь. Поэтому «Обновить» остаётся запасным вариантом — для тех, кому проще переспросить, чем ждать, — а интервала, который надо пересидеть, нет вовсе.

Подписка живёт 30 дней, а переход к другому заказу переводит поток на него, вместо того чтобы копить вторую подписку поверх первой. Выигрыш узкий, но ощутимый: меняется то сообщение, на которое вы смотрите, а не уезжает вверх, как только заказ сдвинулся.

Чат вообще плохое место для состояния, которое меняется. Прочитанное сообщение застывает, новое уезжает вниз, и через десять минут переписки заказ приходится искать заново. Подписка снимает именно это: заказ живёт в одном экране, а не в ленте своих прошлых состояний.

Присылает ли API такие же обновления?

Нет. Перепутать это дорого.

У публичного API нет ни вебхуков, ни колбэков. Состояние заказа читается запросом самого заказа. Рекомендованный ритм — через 1, 2 и 5 секунд после создания, дальше каждые 10 секунд, с небольшим джиттером, когда заказов в работе несколько.

Что делать с ответом, решают три флага. energy_usable — тот, по которому действуют: он становится true в статусе available, примерно за минуту до delivered, и означает, что Energy уже на адресе — можно отправлять свой перевод. Ждать delivered — тратить оплаченное время аренды.

Останавливаться нужно по delivery_final и lifecycle_final, и только когда оба true. Остановка по одному флагу или по статусу обрывает цикл раньше времени. Песочницы тоже нет, поэтому первый вызов интеграции приходится на боевой баланс. Матрица повторов — на странице опрос и безопасные повторы.

Разница видна и в том, чем заканчивается ожидание. В боте оно заканчивается само: пришёл сигнал — экран изменился. В коде его закрывает ваш цикл опроса, и решение об остановке принимает тоже он: по флагам, а не по внешнему событию.

Что делают диплинки?

Их два, и оба нужны, чтобы передать задачу в чат откуда-то ещё.

Стартовый параметр, начинающийся с rent_, открывает сценарий аренды сразу, минуя меню. Стартовый параметр с идентификатором заказа открывает этот заказ: стадию, прогресс и ту же подписку, что и у любого другого экрана заказа.

Смысл виден сразу. Ссылка из переписки с поддержкой или переход с сайта приводят человека на обсуждаемый заказ, а не в меню, по которому потом ещё надо идти.

Второе применение — возврат к незакрытому заказу. Ссылка с идентификатором ведёт прямо на его экран, и не приходится вспоминать, на какой странице истории он остался.

Какая поверхность под какую задачу?

Три вопроса, и первый обычно закрывает тему.

Перевод делает человек, руками, с телефона, и ему удобнее, когда состояние показывают, а не приходится за ним ходить? Это бот, и открывать браузер незачем. Как он выглядит на фоне рынка — отдельная страница: семь сервисов аренды без рекламы.

Заказы ставит программа — пакет выплат, очередь выводов, всё, что работает, пока никто не смотрит? Это API: свой цикл опроса, своя политика повторов и обязательный ключ идемпотентности на каждом заказе. Сигналы, о которых шла речь выше, сюда не приходят.

Меняет ли выбор что-то с деньгами? Нет. Один аккаунт, один баланс, один адрес пополнения; поверхности отличаются входом, а не содержимым. Посмотреть текущее состояние адреса перед заказом всё равно стоит: как проверить баланс Energy в TRON.

Из этого следует и третий ответ — обе сразу. Аккаунт один, поэтому история заказов в боте остаётся историей аккаунта, а не историей чата: она не зависит от того, с какой стороны заказ был поставлен.

Одна граница держится везде. Energy делегируется на публичный адрес TRON, и делегирование не даёт права ничего подписывать, — перевод USDT вы по-прежнему подписываете в своём кошельке. У этого вопроса своя страница: безопасна ли аренда Energy в TRON.

Итоги

Бот @rentron_energy_bot — не витрина с кнопкой. Вся аренда идёт внутри чата: объём и срок, адрес отправки, котировка, создание заказа. Рядом — баланс с копируемым адресом пополнения и QR-кодом, сохранённые адреса с добавлением, переименованием и удалением, постраничная история заказов и депозитов, прогресс по стадиям, язык интерфейса в шести вариантах и отдельный экран поддержки, откуда переписка передаётся дальше.

Второго аккаунта у бота тоже нет. Вход на сайте и запуск бота приводят к одной записи контакта, за которой стоит один аккаунт: одна доступная сумма, одна удержанная под заказы, один постоянный адрес пополнения. Пополнили с компьютера — заказали с телефона; переносить между ними нечего.

Чего нет у соседних поверхностей: экран подписан. Его кормят два потока, которые публикует сервер, — статус открытого заказа и зачисления на аккаунт, — а подписка живёт 30 дней. «Обновить» под заказом в работе при этом остаётся — как запасной вариант, а не как механизм: меняется то сообщение, которое уже перед вами.

Читать этот факт нужно узко: он про бота. У публичного API вебхуков и колбэков нет, поэтому интеграция опрашивает — через 1, 2 и 5 секунд, дальше каждые 10 с джиттером. Действовать по energy_usable, а не ждать delivered; останавливаться, только когда delivery_final и lifecycle_final оба true; и рассчитывать на то, что песочницы для репетиции нет.

Выбирать поверхность стоит по тому, кто ставит заказ. Человеку в чате здесь лучше. Программе — нет, и строить её надо в расчёте на то, что спрашивать придётся самой.