Интеграция
TON Connect и разница между «подключён» и «доказано, что твой»
TON Connect — стандартный протокол для подключения кошелька пользователя к Telegram Mini App или боту и для запроса транзакций. Само подключение ничего не доказывает о владении кошельком: нужно запросить подписанное подтверждение и проверить его на сервере, а этот шаг пропускают в очень многих интеграциях.
TON Connect — интеграция: доступ, лимиты и доступность
- Модель авторизации
- Подпись HMAC
- Сессии
- На приложение, восстанавливаются, но не постоянные
- Доступность в Заливе
- Протокол, а не лицензируемый сервис; подключаться в юрисдикции не нужно
- Поток данных
- 5 переходов, через воркер
As of 2025-10-01, Telegram Bot API 13.4
Зачем нужна эта интеграция
TON Connect действительно хорошо решает неудобную задачу. Пользователь внутри Telegram нажимает один раз, у него открывается кошелёк, он подтверждает — и возвращается обратно: без копирования адреса, без выбора сети, без расширения в браузере. Для криптопродуктов, живущих внутри Telegram, этот сценарий отличает работающий продукт от демонстрации, а протокол берёт на себя трудную часть — установление сессии и запрос транзакций.
Повторяющаяся ошибка — принимать подключение за аутентификацию. Адрес кошелька, пришедший от клиента, это утверждение: клиент говорит, что подключён такой-то адрес. Сам факт получения адреса никак не доказывает, что пользователь владеет соответствующим ключом, и бэкенд, выдающий права по заявленному адресу, примет любой адрес вообще — включая тот, на котором лежат токены, требуемые вашим списком допуска.
Ответ заложен в самом протоколе. В запрос на подключение можно добавить элемент подтверждения, кошелёк его подписывает, а сервер сверяет подпись с адресом и с той полезной нагрузкой, которую сгенерировал сам. Один этот шаг отделяет «клиент сообщил нам адрес» от «этот человек владеет этим кошельком». За ним обязано стоять всё, что выдаёт доступ, считает вес голоса или засчитывает платёж.
Как на самом деле движутся данные
На сервере выполняются две независимые проверки, и нужны обе. Поле `initData` из Mini App проверяется по HMAC против токена бота — так устанавливается, какой именно пользователь Telegram перед нами; подтверждение TON Connect проверяется по подписи против сгенерированной сервером нагрузки — так устанавливается, каким кошельком он владеет. По отдельности каждой недостаточно: `initData` говорит, кто в чате, подтверждение говорит, чей кошелёк, а нужна вам именно связка между ними.
Модель доступа: Запросы с подписью HMAC
Их лимиты и что они означают для вас
Сессия TON Connect устанавливается для каждого приложения и может восстанавливаться, но не является постоянной.
Пользователей периодически приходится подключать заново. Схема, рассчитанная на бессрочную сессию, даёт бота, который для вернувшихся пользователей тихо перестаёт работать, и ошибки при этом никто не видит.
Полезную нагрузку для подтверждения подключения формирует само приложение, а кошелёк возвращает её подписанной.
Это обязан быть сгенерированный сервером разовый код с коротким сроком жизни, сохранённый и погашаемый ровно один раз. Постоянная нагрузка превращает подтверждение в воспроизводимый токен, а это строго хуже, чем отсутствие проверки, потому что выглядит как защита.
Запрос транзакции возвращает результат в момент отправки кошельком, а не в момент подтверждения сетью.
Выдача товара ждёт подтверждения в блокчейне, а не ответа кошелька. То, что кошелёк сообщил об отправке, ещё не означает согласия сети с тем, что это произошло.
Поддержка необязательных возможностей протокола различается от кошелька к кошельку.
Тестируйте на тех кошельках, которыми реально пользуется ваша аудитория, а не на одном. Поведение, работающее в самом популярном кошельке, ничего не гарантирует для второго и третьего.
Как это ломается и что происходит потом
Пользователь подтвердил операцию в приложении кошелька и не вернулся в Telegram.
На мобильных обратный путь — самое слабое звено всего сценария. Состояние хранится на сервере и привязано к подключению, поэтому повторное открытие Mini App продолжает начатое, а не начинает заново.
Прислано подтверждение для адреса, которым пользователь не владеет.
Проверка подписи его отклоняет. Это ровно та атака, ради которой подтверждение и существует, и она без труда проходит против любой интеграции, принимающей заявленный адрес на слово.
Транзакция отправлена, но приложение о ней так и не узнало.
Сверка следит за блокчейном в ожидании нужных транзакций, а не полагается на отчёт кошелька. Блокчейн — источник истины и заодно единственная сторона, которая не может потерять сообщение.
Одно и то же подтверждение воспроизводят против второй сессии.
Разовые коды одноразовые и короткоживущие, поэтому повтор не проходит. Без этого одно перехваченное подтверждение аутентифицирует бесконечно.
Доступность в ОАЭ и остальных странах Залива
Глобально
TON Connect — протокол, а не лицензируемый сервис, поэтому подключаться в юрисдикции не нужно. То, что вы на нём построите, при этом вполне может регулироваться.
Объединённые Арабские Эмираты
Широко используется проектами из Дубая. Учитывайте, что хранение или перевод средств пользователей — деятельность под надзором VARA независимо от того, каким протоколом эти средства движутся.
Охват кошельков
Поддерживается основными кошельками TON, включая встроенный в Telegram. Конкретные кошельки вашей аудитории стоит зафиксировать на этапе оценки, поскольку поддержка возможностей неодинакова.
Только некастодиальные сценарии
TON Connect подключает кошелёк, которым владеет сам пользователь. Это не решение для хранения средств, и оно не снимает обязанностей, возникающих, если средства держите вы.
Когда эту интеграцию делать не нужно
- У ваших пользователей нет кошельков TON. Сценарий подключения превосходен и не достаёт никого, кто ещё не пришёл.
- Вам нужно хранить средства пользователей. TON Connect подключает кошелёк, которым владеет сам пользователь, — это другой продукт и меньший объём обязанностей.
- Вы продаёте цифровые товары обычной аудитории Telegram. Stars проще для обеих сторон и не требуют кошелька вовсе.
- Вы собираетесь пропустить проверку подписи. Тогда аутентификации у вас нет, и узнать об этом лучше до запуска, а не после.
На чём это работает
| Компонент | Версия | Зачем |
|---|---|---|
| @tonconnect/sdk | 3.x | Установление подключения и запросы транзакций внутри Mini App. |
| Cloudflare Workers | current | Выдача разовых кодов, проверка подписей и наблюдение за блокчейном. |
| Cloudflare D1 | current | Проверенные связки кошельков, разовые коды и ожидаемые транзакции. |
| Telegram Mini Apps | Bot API 9.x | Поверхность, внутри которой происходит подключение, с параллельной проверкой initData. |
Вопросы, которые возникают при оценке
Подключённый кошелёк и проверенный кошелёк — это одно и то же?
Нет, и смешение этих понятий — самая дорогая ошибка в интеграциях TON Connect. Подключение означает, что клиент сообщил адрес. Проверка означает, что кошелёк подписал сгенерированную вами нагрузку, а вы сверили подпись. Доказывает что-либо только второе.
Почему нагрузка для подтверждения обязана приходить с сервера?
Чтобы её нельзя было воспроизвести. Сгенерированный сервером одноразовый код с коротким сроком жизни делает перехваченное подтверждение бесполезным уже через мгновение. Постоянная нагрузка превращает подтверждение в предъявительский токен без срока годности.
Нужно ли проверять initData, если мы проверяем подпись кошелька?
Да. Они устанавливают разные факты: initData говорит, какой пользователь Telegram перед нами, подпись — каким кошельком он владеет. Нужна вам связка между ними, а для неё требуются обе половины.
В какой момент платёж через TON Connect можно считать завершённым?
При подтверждении в блокчейне, а не при успешном ответе кошелька. Кошелёк сообщает, что он что-то отправил; о том, что это произошло, может сказать только сеть, и именно в этом зазоре живут потери от двойной траты.
Что происходит, если пользователь не вернулся из приложения кошелька?
Состояние подключения хранится на сервере, поэтому повторное открытие Mini App продолжает сценарий, а не начинает его заново. На мобильных этот обратный путь — наименее надёжный шаг, и его стоит проектировать отдельно и осознанно.
Снимает ли использование TON Connect вопросы регулирования?
Нет. Он меняет то, у кого лежат ключи, и это действительно снижает объём ваших обязанностей, но сама деятельность с этими транзакциями вполне может регулироваться. В Дубае операции с виртуальными активами подпадают под VARA независимо от протокола.
Что почитать дальше
Наблюдение за блокчейном ради подтверждения — отдельная задача, её закрывает интеграция с TON API.
Чаще всего на этом протоколе строят витрину в Mini App.
Голосование с подписью кошелька опирается ровно на эту проверку, как описывает разбор бота для управления DAO.
Вторая половина этой пары проверок разобрана в справочнике — это проверка initData.