Розробка Omnichain-токена: де ламається один блокчейн
Актив живе в одній мережі. Поки тримачеві потрібно лише зберігати та переказувати його всередині неї, усе працює. Щойно токен потрібен в іншій мережі — починається обхідний шлях: загорнуті копії, кожна зі своїм контрактом, своїм пулом і своєю ціною.
Звідси фрагментація ліквідності між мережами. Глибина ринку ділиться на кілька дрібних пулів, різниця цін між копіями зростає, а відкритий арбітраж з'їдає дохідність тримачів.
Перенесення активу вручну додає друге коло: користувач іде на сторонній обмінник, платить комісію двічі, чекає підтвердження й ризикує завислою операцією.
Окрема проблема — права. Обгорнутий токен часто не дає того самого, що вихідний: голосування, нарахування й облік залишаються на першій мережі, а міст тримає консолідовану заставу й стає єдиною точкою відмови.
Розробка Omnichain-токена знімає це на рівні контракту. Мультичейн-стандарт OFT описує один актив: спільна емісія, випуск у цільовій мережі під спалювання у вихідній, без обгорток і проміжної застави. Транспорт — LayerZero, повідомлення перевіряється на обох сторонах. Розбираємо, як це закривається і що змінюється в архітектурі.
Що змінюється після виведення активу в кілька мереж
Перенесення активу в кілька мереж змінює не лише охоплення, а й саму модель обліку.
Замість окремого контракту й окремого пулу в кожній мережі з'являється єдиний реєстр балансів: випуск відбувається в одній точці, а перенесення між мережами фіксується як подія, а не як емісія другої копії.
Звідси — збіжна сумарна емісія на всіх маршрутах: звірити її можна одним запитом, а не порядковим зіставленням виписок із п'яти мереж.
Швидкість розрахунків між мережами перестає залежати від того, де лежить ліквідність. Маршрут «спалювання в джерелі — випуск у призначенні» проходить через транспорт LayerZero, який підтверджує доставку повідомлення, а не чекає виведення із спільного пулу.
Розрахунок займає хвилини й не потребує ручного втручання, тоді як класичний міст із зовнішнім забезпеченням розтягує ту саму операцію на години, а при перевантаженні — на дні.
Усунений клас відмов тут цілком конкретний: зникають розбіжності між мережами, завислі в мості залишки й подвійний облік однієї й тієї самої позиції.
Якщо мережа-одержувач недоступна, повідомлення не втрачається — воно підтверджується пізніше або відкочується за заданим правилом, а баланс у джерелі залишається узгодженим.
Вартість простою змінюється в розрахунку: раніше недоступність моста зупиняла розрахунки цілком, тепер відмова однієї мережі не блокує інші маршрути, а облік продовжує сходитися.
Для власника активу це вимірно — передбачуваний строк зарахування, одна точка випуску й відсутність звірок між мережами наприкінці періоду.
Варіанти перенесення: замок-і-мінт, пул, обгортка
Схему перенесення визначають два питання: де зараз лежить ліквідність активу й у кого право на його випуск. Якщо емісія наша, цінність переноситься повідомленням і резерви не потрібні; якщо актив зовнішній, доводиться або замикати оригінал, або добирати ліквідність пулом. Від цього залежить, які ризики залишаються в тримача після перенесення.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Замок і мінт | Актив уже обертається в одному контурі, права на випуск є | Оригінал замкнено в сховищі — єдина точка відмови, ліквідність зв'язана на стороні-джерелі |
| Нативний випуск | Токен наш, емісія керується контрактом | Потрібні права випуску в кожній мережі, при додаванні мережі — перенесення ролей емітента |
| Пул ліквідності | Права на випуск немає, актив зовнішній, потрібен вхід без переговорів з емітентом | Ціна перенесення не фіксована: прослизання й розсинхрон балансу пулу |
| Обгорнутий актив | Потрібен швидкий вихід у нову мережу без свого емітента | Залежність від тримача резерву: розсинхрон обгортки й оригіналу дає вторинний ризик |
На практиці режими комбінують: токен може спалюватися на одній стороні й випускатися на іншій, а на третій бути представленим обгорткою.
Ми перевіряємо, як схема лягає на вже розгорнуті контракти, чи зберігається коректність при повторній доставці повідомлення і чи залишається шлях відкату, якщо мережа-одержувач недоступна.
Етапи робіт: від аудиту конфігурації до запуску
Перед запуском omnichain-токена ми розбираємо поточний стан: які мережі підключені, як влаштовані права і що вже налаштовано в маршрутах LayerZero. Далі йдемо кроками, де кожен спирається на результат попереднього — так запуск не перетворюється на відладку в основній мережі.
Послідовність кроків
-
Аудит конфігурації мереж. Дивимося підключені мережі, зв'язки між контрактами, ліміти на переказ і адреси довірених відправників. Підсумок — карта розбіжностей і список того, що перебудовуємо до запуску.
-
Схема ролей випуску. Розводимо права: власник контракту, налаштування маршрутів, випуск і спалювання токена — різні адреси. Рутинні операції перестають вимагати головного ключа.
-
Налаштування маршрутів. Прописуємо шляхи між мережами, ліміти на один переказ і на добу, комісію за доставку повідомлення, порядок підтвердження. Перевіряємо рух в обидві сторони.
-
Перевірка на тестових мережах. Прогоняємо випуск, переказ, приймання й відкат невдалого повідомлення — включно з випадком, коли коштів на доставку не вистачило. Фіксуємо час проходження й місця можливих зависань.
-
Передача управління. Права переходять на мультипідпис, пишемо регламент змін та інструкції з аварійних сценаріїв для команди.
-
Моніторинг після запуску. Оповіщення щодо затримок доставки, відмов і залишків на рахунках доставки — відхилення видно раніше, ніж про нього повідомить користувач.
Реєстри емісії токена, політики прав і документація
Працюючий омнічейн-токен — це не лише контракт, а й шар управління: хто і скільки може випускати, на якому контурі, що робити при збої маршруту. Після запуску цей шар залишається в замовника, і без письмових правил він тримається на пам'яті двох інженерів. Тому ми передаємо комплект артефактів, за якими команда працює самостійно.
- Реєстр емісії — зведення по кожному контуру: скільки випущено й спалено, як сходиться загальний обсяг токена, які адреси брали участь в операціях.
- Політики доступу до випуску — які ролі можуть випускати й спалювати токени, ліміт на одну операцію і добовий ліміт, затримка на великі випуски.
- Передача адміністративних прав — переведення володіння на гаманець із кількома підписами, розподіл ролей між відповідальними, процедура ротації ключів при зміні співробітника.
- Конфігурації маршрутів — параметри кожного напрямку: кількість підтверджень, ліміти, запас на комісію, поведінка при недоступності контуру.
- Регламенти та інструкції — покрокові сценарії випуску, призупинення переказів і відновлення після збою, із зазначенням, хто ухвалює рішення.
- Матриця доступу — таблиця «роль → дія → контур», щоб права не видавалися «про всяк випадок» і не накопичувалися з часом.
Кожен пункт перевіряємо на тестовому контурі до передачі: сценарії випуску, призупинення й відкату виконує ваша команда, а не наша. Документація описує те, що реально працює, — а не те, що планувалося на старті.
Кейс: прибрали подвійний облік при перенесенні активу
Що було
Клієнт випускав токен у двох мережах: емісія велася в кожній окремо, а перенесення між ними йшли через кастодіальний міст із ручною звіркою реєстрів.
За квартал накопичувалося до 40 розбіжностей балансів — частина на завислих переказах, частина на повторному зарахуванні однієї й тієї самої операції. Кожен випадок розбирали вручну, до двох днів на інцидент, і до кінця звітного періоду реєстр жодного разу не сходився повністю.
Що змінили і що стало
Ми звели емісію й облік у єдиний реєстр: спалювання у вихідній мережі та випуск еквівалента в цільовій ідуть однією операцією через LayerZero.
Проміжного стану «списано тут, не зараховано там» більше не виникає — обмін або підтверджується цілком, або відкочується й не змінює баланси.
За дев'ять місяців роботи в новому контурі розбіжностей балансів — нуль, а ручну звірку замінено автоматичним звітом, який сходиться за побудовою.
Звірка займала в команди до восьми годин на тиждень, тепер це перегляд звіту на кілька хвилин; перенесення активу між мережами замість днів на розбір займає хвилини.
Змінився й клас відмов: замість «завислий переказ плюс подвійний облік плюс ручний розбір» залишився один сценарій — відхилена операція, яка не чіпає стан і не потребує втручання. Повернення до попередньої конфігурації робиться на рівні політик, без зупинки емісії.
Чим відрізняється міст від нативного випуску в двох мережах?
Міст не створює новий актив: він блокує токен у контракті-сховищі вихідної мережі та видає його обгортку в цільовій.
Нативний випуск — це той самий актив, що живе в кількох мережах через спільний контролер: в одній мережі токен спалюється, в іншій випускається, а сумарна пропозиція залишається незмінною.
Звідси й різниця в ризиках. Міст тримає ліквідність у пулі й цілком залежить від того, хто підтверджує перенесення: помилка або компрометація підписантів залишає обгортку без забезпечення, і її курс розходиться з вихідним токеном.
Плюс обгортка живе в окремому реєстрі — пули, лістинги та інтеграції доводиться збирати заново, а разом із ними заново пояснювати тримачам, що в активу тепер дві різні адреси.
Нативний випуск прибирає прошарок: у токена єдина логіка, спільний ліміт емісії та одна роль управління на всі мережі.
Так влаштовано стандарт нативного мультичейн-токена в актуальній гілці LayerZero — курс не розходиться, бо арбітраж працює з одним активом, а ліквідність не замкнена в чужому контракті.
Ціна рішення — плата за перенесення між мережами й дисципліна: якщо випуск десь не обмежений, ліміт пропозиції ламається у всій системі одразу.
Вибір схеми диктує сценарій, а не мода. Якщо актив уже торгується і його потрібно один раз довезти до нової мережі — достатньо моста.
Якщо токен лише запускається й буде жити в кількох мережах одночасно, потрібен нативний випуск зі спільним управлінням, інакше кожен перехід доведеться пояснювати заново.
Ми починаємо з моделі емісії: хто і в яких межах випускає, де стоїть пауза, як розподілені ролі і що відбувається при збої перенесення. Далі обираємо схему під задачу й фіксуємо її в конфігурації — щоб рішення можна було перевірити, а не просто повірити в нього.
Технічні сумніви перед інтеграцією: що уточнюють
Інженерні заперечення майже завжди одні й ті самі: де враховується баланс, хто володіє правами випуску і що станеться з уже випущеним активом.
Розбираємо їх до початку робіт — відповіді визначають структуру контрактів, порядок підключення мереж і схему розгортання омнічейн-токена поверх шару міжмережевих повідомлень (LayerZero). Змінювати ці рішення після запуску помітно дорожче, ніж закласти одразу.
Що буде, якщо мережа-джерело недоступна в момент переказу?
Повідомлення стає в чергу й обробляється після відновлення — актив не втрачається й не дублюється. Закладаємо ідемпотентну обробку та ліміти на обсяг переказу, щоб зависла операція не блокувала інші, плюс сценарій ручного завершення.
Як додати нову мережу після запуску?
Як ще один адаптер до наявного контракту: ідентифікатор мережі, правила конвертації, права випуску. Логіка токена не переписується, оновлення йде за описаною процедурою через тестовий контур.
Кому належать права випуску і як їх розмежувати?
Права роздаються за ролями: випуск, ліміт на випуск, підключення мереж — різні адреси. Єдину точку контролю виключено, один ключ не може змінити правила цілком.
Чи можна перевести вже наявний актив без перевипуску?
Так, при заблокованому вихідному контракті: тримачі обмінюють актив один до одного, снапшот балансів фіксується заздалегідь. Вікно обміну описуємо до старту, щоб не з'явилося двох версій одного активу в обігу.
Обговоримо задачу: які дані надіслати для оцінки
Щоб оцінка була предметною, а не «на око», нам потрібні вхідні дані за чотирма осями: що вже deployed, куди масштабуємо, хто керує правами і які перевірки обов'язкові. Нижче — мінімальний набір; якщо чогось ще немає, так і напишіть, це теж впливає на план робіт.
- Перелік мереж, де токен має обертатися, із позначкою, які з них EVM-сумісні, а які ні.
- Поточний контракт токена: адреса, стандарт, наявність mint/burn, паузи й власник прав.
- Модель емісії: фіксована пропозиція або довипуск, хто і за якою процедурою його ініціює.
- Схема ліквідності та міграції: де токен торгується, чи потрібен зріз балансів тримачів.
- Політика безпеки: мультипідпис, ліміти на переказ і на добу, ролі адміністраторів, кому вони видані.
- Сценарії використання: перекази між мережами, оплата комісії, що робити при збої доставки повідомлення.
- Оточення: доступ до репозиторію, тестові мережі, ключі для розгортання, поточний моніторинг.
- Вимоги до звітності: події для аналітики, формат документації для тримачів, готовність до аудиту.
Цього достатньо, щоб повернутися з оцінкою, планом робіт і межами відповідальності. Опишіть задачу у вільній формі — уточнювальні питання поставимо самі.
