Разработка 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 для каждого action. Стандартный 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 в обёртке над 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.
Стоимость рассчитывается после анализа параметров проекта и требований к инфраструктуре.