Розробка Liquidity Bootstrapping Pool (LBP)
Проект виходить на ринок з новим токеном. Команда хоче справедливий запуск: без снайперів-ботів, без whale-захвату на старте, без мгновенного дампу від ранніх інвесторів. Стандартний AMM pool тут не працює — хто перший додав ліквідність, той і встановив ціну. LBP вирішує цю проблему через динамічні ваги, але його реалізація вимагає розуміння механіки Balancer V2 до рівня внутрішніх інваріантів.
Чому стандартний IDO ломається, а LBP — ні
Механіка атаки на звичайний запуск
Типова схема: проект створює пул на Uniswap V2, додає ліквідність у співвідношенні 50/50 ETH/TOKEN. У першому ж блоці MEV-боти через flashbots bundle захоплюють максимальну кількість токенів по стартовій ціні, після чого негайно виставляють sell-ордера на 20-30% вище. Реальні покупці платять уже завищену ціну, боти фіксують прибуток. Проект отримує репутаційний ущерб у перші хвилини торгів.
LBP працює інакше: стартовий вага TOKEN/USDC встановлюється, наприклад, 96/4. Ціна токена штучно висока, що робить негайну покупку невигідною. У течение 48-72 годин ваги плавно зміщуються до 50/50 або 20/80 — ціна знижується за заздалегідь заданою кривою. Боту нема сенсу купувати на старті: кожен наступний блок пропонуватиме токен дешевше.
Математика за кривою LBP
Балансиуючий інвариант Balancer заснований на взвешеному творі:
∏(Bᵢ ^ Wᵢ) = k
де Bᵢ — баланс кожного токена, Wᵢ — його вага. При змінені ваг зі часом k перераховується, і spot price змінюється без реальних торгів. Зміщення ваги на 1% на годину — передбачувано зниження ціни, яке розробник встановлює в конфігу пулу при деплої.
Критичний параметр — swapFee. Занадто низька комісія (<1%) робить арбітраж дешевим та розмиває криву. Занадто висока (>5%) відлякує легітимних покупців. Для більшості LBP оптимальний діапазон — 1-3%.
Що ми будуємо всередину LBP-проекту
Пул на Balancer V2 Weighted Pool Factory
Деплой через WeightedPoolFactory з параметрами normalizedWeights та тимчасовим контролером ваг. Ми не використовуємо managed pool без вагомих причин — він складніший у аудиті та вимагає whitelist для кожної дії. Стандартний weighted pool з updateWeightsGradually() закриває 90% завдань LBP.
// Приклад вызова через IWeightedPool
IWeightedPool(poolAddress).updateWeightsGradually(
startTime,
endTime,
endWeights // [endWeight_token, endWeight_collateral]
);
Права на вызов updateWeightsGradually — тільки у poolController, який деплоїмо з multisig (Gnosis Safe) або з timelock. Прямий доступ команди проекту до цієї функції — критична уразливість: rug pull через мгновенне зміщення ваг.
Контракт управління правами
Окремий LBPController.sol з ролевою моделлю через AccessControl OpenZeppelin:
-
OWNER_ROLE— мультисиг команди, управляє параметрами -
PAUSER_ROLE— можливість екстрено зупинити торги (Balancer vault дозволяє) -
WITHDRAW_ROLE— вивід ліквідності після завершення LBP
Без явного розділення ролей в контракті управляючий ключ стає єдиною точкою відмови. Компрометація одного приватного ключа = втрата всієї ліквідності пулу.
Допоміжна інфраструктура
Frontend-інтеграція — через Balancer SDK (@balancer-labs/sdk) або напрямки через viem з ABI Vault контракту. Показуємо поточні ваги, spot price та залишок часу LBP у реальному часі.
Мониторинг — Chainlink Automation (бувший Keeper) або власний off-chain bot для вызова updateWeightsGradually за розкладом, якщо команда хоче ручний контроль над кривою.
The Graph субграф — індексуємо подіï WeightsUpdated, Swap, PoolBalanceChanged для історичного графіка ціни та об'єму.
Типічні проблеми, які закриваємо заздалегідь
| Проблема | Наслідок | Рішення |
|---|---|---|
| Нема обмеження на max buy | Whale захоплює 30% supply | maxTokensOut per transaction в wrapper над vault |
| Занадто швидко знижуються ваги | Ціна падає швидше ніж очікується, FUD | Симуляція кривої на Python перед деплоєм |
| Нема whitelist на старті | MEV-боти все рівно беруть участь | Перші 1-2 години — тільки whitelist адреса |
| Ліквідність застрягла після LBP | Команда не може вивести | Явна функція exitPool з таймлоком |
Whitelist-механізм на старті — окремий Merkle proof контракт. Root завантажується при деплої, адреса з листа підтверджують участь через proof. Gas-ефективно навіть для 10 000 адрес.
Процес роботи над LBP
Аналіза токеноміки (2-3 дні). Розбираємо: початковий supply, алокації, cliff/vesting інсайдерів. Якщо 40% токенів у команди розлочиться у день LBP — крива не врятує. Моделюємо сценарії в таблиці та узгоджуємо параметри пулу.
Проектування кривої (1 день). Python-скрипт симулює поведінку ціни при різних параметрах startWeights, endWeights, duration, swapFee. Клієнт бачить три варіанти кривої до початку розробки.
Розробка контрактів (3-5 днів). LBPController.sol, скрипти деплоя через Foundry, інтеграційні тести на mainnet fork Ethereum. Fork-тест критичен: перевіряємо реальне взаємодію з Balancer Vault 0xBA12222222228d8Ba445958a75a0704d566BF2C8.
Frontend та мониторинг (3-5 днів). Дашборд з реальним графіком, таймер, поточна ціна. Алерти у Discord/Telegram при аномальних свапах.
Аудит та деплой. Внутрішній аудит через Slither + ручний review. Деплой на Goerli/Sepolia для тестування з реальним Balancer. Після підтвердження — mainnet через Gnosis Safe multisig.
Орієнтири за строками
Базовий LBP без whitelist та дашборду — 1 тиждень. Повний пакет з whitelist-механізмом, мониторингом, субграфом та кастомним frontend — 2-3 тижні. Строки залежать від складності токеноміки та вимог до UI.
Вартість рассчитується після аналізу параметрів проекту та вимог до інфраструктури.