Разработчики, которые успешно запустили своп токенов STON.fi в песочнице, теперь получают предупреждения о том, что переход в мейннет может привести к потере средств пользователей, если в коде останутся несколько, казалось бы, безобидных упрощений. Чек-лист, составленный сообществом и опубликованный в блоге для разработчиков, описывает конкретные моменты, на которых чаще всего ломаются интеграции, и предлагает готовый рецепт для запуска в продакшн.

Почему переход имеет значение

STON.fi предоставляет роутер, который агрегирует ликвидность из нескольких DEX в блокчейне TON. Проекты, желающие предложить пользователям своп в один клик, обычно вызывают роутер через фронтенд или обертку (wrapper) смарт-контракта. В тестовой среде адрес роутера статичен, график комиссий известен, а песочница прощает ошибки в направлении транзакций. Однако в мейннете роутер может обновляться, параметры комиссий могут меняться, а один неверный адрес отправит реальные токены на «мертвый» контракт. Таким образом, финансовые ставки — это разница между бесперебойной работой сервиса и потерей средств, которая может в одночасье разрушить репутацию проекта.

Самая распространенная ошибка: хардкод значений

Повторяющимся паттерном при неудачных запусках является хардкод адреса роутера или констант комиссий, которые были актуальны во время тестирования. Когда STON.fi обновляет свой роутер — обычное событие для повышения производительности или исправления багов — захардкоженный адрес перестает указывать на функциональный контракт. Интеграция либо выдает ошибку, которую пользователи не увидят, либо, что еще хуже, незаметно направляет средства на адрес, который не может их обработать. Руководство сообщества подчеркивает одно правило: пусть STON.fi REST API решает, какой роутер использовать.

Пошаговый чек-лист безопасности

Чек-лист разделяет процесс миграции на четыре логических уровня: среда, взаимодействие с контрактом, расчет комиссий и обработка граничных случаев.

  • Заранее проверяйте переменные окружения. При тестировании направляйте эндпоинт WebSocket и базовый URL REST API на песочницу; перед запуском переключите их на узлы мейннета. Опечатка здесь может перенаправить реальный своп на тестовый роутер, навсегда заблокировав токены.

  • Никогда не вшивайте адреса контрактов. Выполните симуляционный запрос к STON.fi API, получите текущий адрес роутера из ответа и передайте его в свой dexFactory (или эквивалентный контракт-фабрику) во время выполнения. Это позволит автоматически адаптироваться к любому будущему обновлению роутера.

  • Вычисляйте комиссии «на лету». Извлекайте параметры комиссий из конфигурационной полезной нагрузки (payload) API и используйте их в своей функции расчета комиссий. Захардкоженные проценты устаревают в тот же момент, когда платформа меняет свою экономическую модель.

  • Отдавайте предпочтение официальному SDK и TonConnect. SDK самостоятельно формирует структуры BOC (Bag of Cells) и включает проверки лимитов газа, кодирования данных и валидации подписи. Ручную компиляцию BOC следует оставить только для узкоспециализированных случаев, которые не покрываются SDK.

  • Проводите тестирование сценариев сбоев. Симулируйте ситуации нехватки газа (out-of-gas), недостаточного разрешения (insufficient allowance) и некорректных ответов в песочнице. Убедитесь, что ваш контракт возвращает средства пользователю или выдает четкое событие об ошибке. Полагаться на то, что пользователи сами обнаружат эти баги в продакшене, — значит провоцировать отток клиентов.

  • Проверьте пути вывода реферальных вознаграждений. Во второй версии DEX реферальные комиссии поступают в специальный контракт Vault, а не на кошелек. Ваша интеграция должна вызывать метод вывода (withdrawal) контракта Vault и обрабатывать полученные токены перед зачислением на счет реферера.

Что обсуждают разработчики

Некоторые разработчики утверждают, что SDK создает ненужные накладные расходы и что вручную сформированная полезная нагрузка BOC может быть меньше и дешевле по газу. Руководство признает эту точку зрения, но отмечает, что SDK также включает обновления адреса роутера и схемы комиссий. Это означает, что полезную нагрузку, собранную вручную, придется пересматривать после каждого обновления STON.fi. Таким образом, выбор стоит между незначительной экономией газа и риском незаметной поломки системы.

На что обратить внимание в дальнейшем

  • Анонсы обновлений роутера. STON.fi публикует информацию о предстоящих изменениях роутера в своем канале для разработчиков. Подписка на эти каналы позволит вам превентивно протестировать новый адрес в песочнице перед переключением на мейннет.
  • Пересмотр параметров комиссий. Поскольку процентные ставки комиссий могут корректироваться в зависимости от рыночных условий, включите периодический запрос к эндпоинту конфигурации в любой сервис мониторинга.
  • Выпуски новых версий SDK. Новые релизы SDK часто содержат исправления багов для граничных случаев, обнаруженных после запуска в мейннете. Поддержание SDK в актуальном состоянии так же важно, как и обновление адреса роутера.

Вывод очевиден: своп, который «работает при тестировании», не гарантирует автоматической безопасности в основной сети (mainnet). Получая каждое критически важное значение — от адреса роутера до сетки комиссий — напрямую из работающего STON.fi API и тщательно прорабатывая сценарии ошибок до того, как пользователи увидят интерфейс, разработчики могут защитить средства пользователей и сохранить доверие при прохождении «последней мили» до запуска в продакшн.

Источник: https://dev.to/web3kd/the-last-mile-taking-a-stonfi-integration-from-test-network-to-real-users-2ho0