Система автолістингу токена на DEX при досягненні капіталізації

Автоматичний лістинг DEX: що ламається на порозі капіталізації

Автоматичний лістинг DEX будується навколо однієї умови — тригера капіталізації. Це не одна цифра, а обчислюване значення: котирування з пулу або оракула множиться на кількість випущених монет і порівнюється із зафіксованим порогом. Поки значення нижче, торгів немає, а ціна живе в позабіржових угодах.

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

Якщо умова перевіряється за однією парою і без захисту від короткочасного відхилення, запуск пулу ліквідності виходить у роботу за ціною, якої вже немає.

Технічно спрацювання — це одна транзакція: створити пару, внести обидві сторони, зафіксувати права на LP-токени, відкрити торги.

Реверт на будь-якому кроці — не той порядок викликів, застаріле значення оракула, нестача газу — дає найгірший сценарій: умову виконано, торгівлю не відкрито, а стан змінено частково.

Звідси й ризики ручного запуску торгів. Поки транзакцію збирають вручну, ціна змінюється, ліквідність вноситься за неактуальним котируванням, глибина пулу виявляється нижчою за розрахункову, перші угоди йдуть із прослизанням, а знімають його найшвидше автоматичні боти.

Розбираємо, як це закривається на рівні архітектури: детерміноване спрацювання тригера, ідемпотентні повтори викликів і перевірка глибини пулу перед публікацією торгів.

П'ять вимірюваних результатів: час торгів, відмови, ліквідність

Перше, що змінюється після впровадження, — час виходу в торги. Умову «капіталізація досягла порогу» перевіряє контракт-тригер, а додавання пари в пул іде в мережу тією самою транзакцією, без паузи на ручну підготовку виклику й підпис. Вікно між спрацюванням умови та першою угодою скорочується з годин до одного блоку.

Друге — частка усунених відмов запуску. Ручний сценарій ламається на неправильно заданому співвідношенні активів, неузгоджених дозволах на списання або друкарській помилці в адресі контракту; перевірки виконуються до відправлення, тому такі запуски просто не доходять до мережі.

Залишаються відмови зовнішні — нестача ресурсу на виконання й перевантаження мережі, і вони видні в логах із точною причиною.

Третє — простій між сигналом і угодою. Черга завдань і повторні спроби з наростаючим інтервалом означають, що тимчасовий збій вузла не скасовує лістинг, а лише зсуває його.

Простій вимірюється не «в середньому», а за кожним запуском: на панелі моніторингу видно, скільки часу минуло від події до підтвердження.

Четверте — передбачувана ліквідність пулу. Обсяг і початкова ціна задаються політикою до запуску, а не підбираються в момент події, тому глибина тримається в обумовленому коридорі й перший великий продаж не обнуляє ціну. Доливання за розкладом згладжує просідання в перші години торгів.

П'яте — зниження ручних помилок: із процесу зникають копіювання адрес, звірка таблиць і підпис транзакцій «на око». Залишається один оператор із правом зупинити запуск, і це усвідомлена дія, а не аварійне втручання.

Режими запуску торгів: порівняння за умовами й обмеженнями

Режим запуску — це не кнопка в панелі, а політика: хто і на якій підставі знімає паузу з торгів. Нижче — три робочі варіанти, між якими вибирають на практиці, з чесними обмеженнями кожного.

Спільна точка відмови в усіх трьох — джерело ціни токена. Якщо тригер читає один пул, маніпуляція на тонкому ринку доводить ціну до порогу за лічені транзакції.

Усереднення за кількома джерелами з часовим вікном прибирає одиничну маніпуляцію, але додає затримку в хвилини й вимагає явної обробки розходження котирувань.

Тому будь-який режим спочатку проганяємо на тестовій мережі: перевіряємо спрацювання тригера, повторний запуск, паузу й відкат. Так само поводиться еталонна реалізація Uniswap — перехід у торгований стан незворотний, отже сценарій має бути відрепетируваний до основного запуску.

Як ми впроваджуємо: від аудиту токеноміки до передачі регламентів

Порядок робіт фіксуємо до першої транзакції: умова автолістингу — це код, який розпоряджається ліквідністю, і помилка в ньому коштує дорожче за будь-яку затримку релізу.

Тому складанню контракту передує розбір токеноміки й джерел ціни, а запуску — прогін повного сценарію на тестовій мережі з тими самими параметрами, що підуть в основну.

1. Аудит токеноміки й джерел ціни — звіряємо графік розблокування, розподіл часток і те, з яких пулів береться котирування; фіксуємо, які пари вважаємо репрезентативними, а які відкидаємо як тонкі.
2. Схема оркестрації запуску — описуємо послідовність цілком: спрацювання умови, резерв ліквідності, створення пари, зняття обмежень на торгівлю, повідомлення відповідальних.
3. Налаштування умови спрацювання — капіталізацію рахуємо за медіаною кількох джерел за вікно часу, а не за одним котируванням; задаємо поріг, період усереднення й захист від короткочасних викидів.
4. Ролі й доступи — операції з ліквідністю та параметрами умови виводимо на мультипідписний гаманець із затримкою виконання, щоб запуск не міг статися за рішенням однієї людини.
5. Перевірка на тестовій мережі — проганяємо сценарій на копії основної мережі з реальним станом пулів, включно з граничними випадками: ціна не дійшла до порогу, джерело котирування зникло, умова спрацювала повторно.
6. Контрольований запуск — вмикаємо умову з обмеженим обсягом ліквідності, спостерігаємо за першими спрацюваннями й поведінкою пари, потім знімаємо ліміти.
7. Передача регламентів — документація: як змінювати поріг, що робити при відмові спрацювання, як передавати доступи й як відкочувати лістинг.

Що залишається в замовника: конфігурації, схеми, регламенти

Комплекс автолістингу передається не як «працює — і добре», а як набір артефактів, за якими ваша команда може його запустити, перевірити й зупинити без нас. Нижче — що саме залишається в замовника після впровадження автоматичного лістингу DEX.

• Робочі конфігурації — файли параметрів: поріг капіталізації, вікно усереднення ціни, розмір першої позиції ліквідності й ліміти на угоду. Значення винесено в конфіг, а не зашито в код, тому правка не потребує перезбирання.
• Схеми інтеграцій — карта зв'язків між контрактом токена, DEX-роутером, джерелом ціни, казначейським гаманцем і пулом ліквідності: напрямки потоків даних і точки відмови позначено явно.
• Політики доступу — матриця ролей: хто змінює поріг і ціну, хто підписує транзакцію, хто лише читає журнал. Критичні дії проходять через мультипідпис з апаратними ключами.
• Технічна документація — логіка тригерів, формати вхідних даних, список змінних середовища й порядок розгортання на чистому середовищі з нуля.
• Регламенти реагування — покрокові сценарії на аномалію ціни, невдалу транзакцію й спорожнілий пул: хто діє, який скрипт запускає, як зупинити систему цілком.
• Журнал подій і оповіщення — де зберігаються рішення системи, як відрізнити спрацювання від збою джерела ціни і які повідомлення приходять у ваш канал.
• Комплект перевірок — тести на сухому прогоні та сценарії відкату, щоб зміну конфігурації перевіряли до бойового запуску.

Усе передається у вашому репозиторії з історією змін: правки конфігурації й коду залишаються у вашій зоні контролю, а не в листуванні з підрядником.

Кейс: поріг спрацював без ручного втручання

Проєкт виходив у лістинг на Uniswap після досягнення порогу капіталізації, і до впровадження тригер тримався на людині: оператор стежив за капіталізацією через оглядач блоків і вручну підписував транзакцію створення пари.

Час від порогу до перших угод становив 4-6 годин, у нічні зміни — до ранку; із десяти запусків два-три зривалися — ціна йшла, параметри ліквідності доводилося перераховувати й починати заново.

Що перенесли в контракт

Модуль читає ціну з оракула, порівнює її з порогом і після досягнення сам створює пару та вносить ліквідність. Поріг, обсяг і адреса пари лежать у параметрах і змінюються без перевипуску контракту.

Поруч — перевірка свіжості котирування, затримка проти маніпуляції ціною всередині одного блоку й подія-повідомлення в зовнішній моніторинг.

Після запуску час від порогу до перших угод — 6-9 хвилин, і майже все це йде на підтвердження мережі. Частка запусків, що пройшли без оператора, — 22 з 23.

Відмов запуску одна: контракт зупинився на застарілому котируванні, транзакція не пішла, лістинг пройшов після оновлення ціни.

Ручне втручання залишилося ручним вимикачем — пауза, зміна порогу, обсяг ліквідності. Лістинг перестав залежати від чергування й від того, хто опинився біля термінала в потрібну хвилину.

Чим відрізняється лістинг за порогом капіталізації від ручного запуску пулу

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

Під час ручного запуску пулу рішення ухвалює оператор — він же вибирає курс ініціалізації, розмір першої позиції й момент.

Поріг — не одне число, а набір перевірок. Ціну беруть не з останньої угоди, а усереднюють за вікном: на тонкому ринку одинична угода дає хибне спрацювання. Додають мінімальний обсяг торгів і затримку між підтвердженням умови та дією.

Гібридний режим закриває випадок, коли токен уже розгорнуто й частина інфраструктури існує. Перезбирати контракт не потрібно: тригер і ролі доступу виносимо в окремий керувальний модуль, який ініціалізує пул у форматі, сумісному з Uniswap, і вносить першу позицію ліквідності.

Оператор зберігає право паузи, повторний запуск пулу закрито за кодом, а інваріанти перевіряємо на форку мережі до виведення в основну.

Часті технічні сумніви перед запуском

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

Чи можна скасувати запуск, якщо рішення змінилося?

Так, до відправлення транзакції працює пауза: умова переперевіряється, ініціювальний виклик знімається. Після підтвердження в мережі відкат неможливий, тому вікно підтвердження задається заздалегідь.

Звідки береться ціна до створення пулу?

Своєї ціни в токена ще немає, тому основа — незалежне джерело: зважена медіана за кількома майданчиками з відсіканням викидів. На момент спрацювання фіксується саме значення, а не «остання побачена» цифра.

Що робити, якщо транзакція запуску не пройшла?

Відправлення повторюється з тим самим ідентифікатором і підвищеною комісією, про помилку надходить повідомлення команді. Проміжних станів немає: пул або створено, або ні, тому повтор не дублює пару.

Які права залишаються у виконавця?

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

Обговоримо задачу й повернемося з планом впровадження

Щоб повернутися з планом впровадження, а не із загальними міркуваннями, потрібен мінімум вхідних даних. Розбір контракту, доступів та інфраструктури — наша частина роботи. Нижче те, що варто підготувати, і те, що ми перевіримо самі.

• Параметри токена: стандарт, емісія, права власника, наявність заморозок і комісій на переказі.
• Мережа й майданчик: де планується пул, торгова пара, хто і як забезпечує стартову ліквідність.
• Умова спрацювання: поріг капіталізації, вікно перевірки, поведінка при короткому проколі рівня, захист від повторного запуску.
• Джерело ціни: чи рахується капіталізація за котируванням пулу, за агрегатором або за кількома джерелами зі звіркою.
• Ролі й доступи: які гаманці підписують операції, чи потрібен мультипідпис, хто тримає ключі й як вони ротуються.
• Інфраструктура: вузли доступу до мережі, резервні провайдери, запас за комісією, моніторинг транзакцій і оповіщення при збої.
• Сценарії відмов: що робимо при невдалій транзакції, як відкочуємо стан і кого повідомляємо.
• Супровід після запуску: хто реагує на інциденти, у які терміни, і в якому вигляді передаємо систему вашій команді.

Опишіть задачу своїми словами: мережа, поточний стан токена, бажана поведінка системи. Повернемося з планом впровадження за етапами, оцінкою термінів, схемою ролей і доступів, а також порядком супроводу після запуску й передачі системи.