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

Чому перехід має значення

STON.fi надає роутер, який агрегує ліквідність між кількома DEX у блокчейні TON. Проєкти, які хочуть запропонувати користувачам обмін в один клік, зазвичай викликають роутер через фронтенд або обгортку смарт-контракту. У тестовому середовищі адреса роутера є статичною, графік комісій відомий, а пісочниця допускає помилкові транзакції. Однак у mainnet роутер може бути оновлений, параметри комісій можуть змінюватися, а одна неправильна адреса відправить реальні токени на неіснуючий контракт. Отже, фінансові ризики полягають у різниці між безперебійним користувацьким досвідом і втратою, яка може миттєво зашкодити репутації проєкту.

Найпоширеніша помилка: хардкодування значень

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

Покроковий чек-лист безпеки

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

  • Валідуйте змінні оточення на ранніх етапах. Під час тестування спрямовуйте endpoint WebSocket та базовий URL REST API на пісочницю; перед запуском перемкніть їх на вузли mainnet. Помилка в написанні тут може перенаправити реальний своп на тестовий роутер, назавжди заблокувавши токени.

  • Ніколи не вбудовуйте адреси контрактів. Виконуйте запит на симуляцію через 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 створює зайве навантаження і що вручну створене навантаження (payload) у форматі BOC може бути меншим і дешевшим за газом. У посібнику визнається ця точка зору, але зазначається, що SDK також містить оновлення адреси роутера та схеми комісій. Це означає, що вручну створене навантаження доведеться переглядати після кожного оновлення STON.fi. Отже, вибір стоїть між незначною економією газу та ризиком прихованої поломки.

На що звернути увагу далі

  • Оголошення про оновлення роутера. STON.fi публікує інформацію про майбутні зміни роутера у своєму каналі для розробників. Підписка на ці канали дозволить вам заздалегідь протестувати нову адресу в пісочниці перед переходом у mainnet.
  • Перегляди параметрів комісій. Оскільки відсотки комісій можуть коригуватися відповідно до ринкових умов, інтегруйте періодичне отримання даних з endpoint конфігурації в будь-яку службу моніторингу.
  • Релізи версій SDK. Нові релізи SDK часто містять виправлення помилок для граничних випадків, виявлених після запуску в mainnet. Підтримання SDK в актуальному стані є таким же важливим, як і оновлення адреси роутера.

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

Джерело: https://dev.to/web3kd/the-last-mile-taking-a-stonfi-integration-from-test-network-to-real-users-2ho0