Розробка платформи в стилі pump.fun: бондинг-крива, міграція, фабрика

Чому запуск токена на готовій фабриці ламається на бондинг-кривій

Бондинг-крива токена — це не «формула ціни», а стан: резерви пулу, сумарна емісія в обігу та поріг міграції мають сходитися в одній транзакції.

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

На папері розходження в одиницях, на практиці — перші покупці отримують ціну нижче за розрахункову, а продати за очікуваною не можуть.

Другий типовий збій — зависла міграція ліквідності.

Досягнення порогу та переведення коштів у пул ідуть двома кроками, і якщо другий не проходить (не вистачило газу на дорогий виклик, реверт за лімітом прослизання, відкликаний доступ), токен залишається в стані «крива закрита, пул порожній».

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

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

Закривається це прив'язкою до блоку, приватною відправкою та лімітом на першу покупку — але тільки якщо закладено в контракт заздалегідь, а не дописано після інциденту.

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

Як влаштована платформа: крива, міграція, фабрика

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

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

Бондинг-крива: ціна без зовнішнього маркет-мейкера

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

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

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

Міграція в пул ліквідності: стійкість переходу

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

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

Фабрика токенів: випуск за одну транзакцію

Фабрика розгортає контракт токена за шаблоном із заданими параметрами і одразу прив'язує його до кривої. Шаблон фіксує стандарт токена, права та логіку комісій, тому кожен новий випуск не потребує ручного складання й аудиту з нуля.

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

Логіку розрахунку кривої та порогів міграції зручно звіряти з відкритими реалізаціями — ми спираємося на перевірені підходи OpenZeppelin для стандартів токена та контролю доступу.

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

Етапи збірки платформи: від схеми до передачі

Розробка платформи в стилі pump.fun — це не «написати контракт токена», а зібрати зв'язку: крива ціни, фабрика запусків, механізм міграції на зовнішній пул і захист від типових атак.

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

1. Аудит вимог та економіки. Фіксуємо параметри: крок ціни, стартову пропозицію, комісію протоколу та творця, поріг виходу на пул. Рахуємо сценарії — різкий викуп, злив, sniper-атаку в першому блоці. На виході — специфікація з формулами, а не «приблизно як у конкурентів».
2. Проєктування бондинг-кривої. Обираємо тип кривої (лінійна, степенева, сигмоїда) і перевіряємо її на симуляціях: як поводиться ціна при рівномірному та панічному попиті, де точка беззбитковості для ранніх покупців. Формулу затверджуємо до написання коду.
3. Розробка смарт-контрактів. Збираємо токен, криву, фабрику та казну як роздільні модулі з чіткими правами. Фабрика створює пари за шаблоном, тому новий запуск не потребує ручного втручання і не тягне за собою помилку копіпасти.
4. Тестування міграції. Прогоняємо перехід на зовнішній пул у форку реальної мережі: перевіряємо, що ліквідність іде повністю, власники не втрачають баланс, а ціна не стрибає на стику. Окремо — сценарії з частковим викупом і скасуванням.
5. Аудит контракту. Зовнішні аудитори та внутрішній фаззинг шукають reentrancy, маніпуляції з оракулом, обхід лімітів. Зауваження закриваємо до деплою, а не після.
6. Деплой і передача платформи. Розгортаємо в основній мережі, передаємо ключі управління, документацію за параметрами, скрипти моніторингу та інструкцію з екстреної паузи.

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

Чим бондинг-крива відрізняється від пулу з ліквідністю?

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

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

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

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

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

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

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

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

Кейс: платформа з фабрикою та міграцією під навантаженням

Замовник прийшов із працюючим прототипом: фабрика випускала токени, бондинг-крива розраховувала ціну, але на пікових запусках майданчик деградував.

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

Що було до переробки

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

Що змінили

Звели випуск до однієї транзакції: фабрика створює контракт токена, ініціалізує параметри бондинг-кривої та реєструє його в реєстрі атомарно.

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

Метрики до та після

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

Solidity

Сумніви перед стартом: сумісність, відкат, доступи

Перед стартом розробки pump.fun замовник зазвичай ставить три питання: як контракт ляже на обрану мережу, що буде з уже створеними токенами при оновленні логіки і хто отримає права на управління після здачі. Розберемо кожен предметно.

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

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

Що якщо потрібен відкат змін контракту? Контракт у блокчейні незмінний, тому відкат проєктується до деплою: логіка виноситься за проксі-шар, критичні параметри (крок кривої, поріг міграції, комісія фабрики) тримаються в окремому сховищі й змінюються без перевипуску. Це дає кероване оновлення і передбачуваний шлях назад при помилці в розрахунках.

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

Що якщо знадобиться доопрацювання пізніше? Модульна структура й документація дозволяють розширювати фабрику й криву без переписування ядра — новий функціонал додається окремими модулями.

На руки замовник отримує:

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

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