Розробка кастомного weighted pool — задача, де помилки в математиці інваріанта коштують тисяч доларів. В одному проекті ми зіткнулися з ревертом addLiquidity при додаванні 99% одного токена в пул 80/20. Причина — бібліотека LogExpMath виходила за межі. Виправлення вимагало перегляду порядку обчислень та додавання валідації вхідних параметрів. Такі кейси — не рідкість. Ми гарантуємо, що наш код проходить фаззинг-тестування інваріанта та форк-тести на mainnet. Наша команда має понад 5 років досвіду в блокчейн-розробці та реалізувала 15+ DeFi-проектів з сумарним TVL понад $50M. Отримайте консультацію щодо вашого проекту — ми допоможемо уникнути типових помилок.
Як працює математика weighted pool?
Weighted pool тримається на інваріанті:
V = ∏(Bᵢ / Wᵢ)^Wᵢ де Bᵢ — баланс токена i, Wᵢ — його нормалізована вага. При своп-операції система вирішує це рівняння відносно вихідного балансу. Проблема — x^y при нецілих експонентах вимагає LogExpMath, бібліотеки з фіксованою точкою для обчислення натурального логарифма та експоненти в 18-decimal Solidity.
Balancer використовує LogExpMath.sol з границями: x має бути в діапазоні [0.000001e18, 2^255], експонента — не перевищувати 130e18. Вихід за межі — revert. Це не просто технічна деталь: при додаванні ліквідності з екстремальними співвідношеннями (наприклад, 99% одного активу в пул 80/20) обчислення можуть упертися в ліміти бібліотеки. Бачили це на форках, де розробники не перевіряли граничні кейси — addLiquidity реверсився при легітимних операціях.
Spot price в weighted pool визначається як:
SP = (Bᵢ / Wᵢ) / (Bⱼ / Wⱼ) Це миттєва ціна до застосування swap fee. Якщо протокол використовує getSpotPrice() як оракул — він вразливий до Flash loan маніпуляції. Атакуючий бере величезний займ, робить своп, який зсуває spot price в 10 разів, викликає вразливу функцію, повертає займ. Все в одній транзакції.
Рішення — не використовувати spot price як ціновий оракул. Для on-chain цін потрібен Chainlink або TWAP від Uniswap V3. Всередині пула spot price використовується тільки для розрахунку свопів — це коректно, тому що сам своп змінює баланси та зсуває ціну назад через swap fee.
На відміну від Uniswap V2, weighted pool дозволяє входити з довільним набором токенів або одним токеном. Single-asset join проходить через внутрішній віртуальний своп, який обкладається swap fee. Це потрібно явно пояснювати користувачам: вхід через single-asset join з великою сумою — це як зробити своп на половину суми. При вагах 80/20 ETH/USDC та вході тільки через USDC користувач неявно купує ETH.
Impermanent loss в weighted pool менший, ніж в 50/50 пулі, при тих же рухах ціни. Для пула 80/20 при рості активу A в 5 разів IL становить близько 4.4% проти 25.5% у 50/50. Іншими словами, weighted pool втрачає в 5.8 разів менше — ми додаємо в документацію графіки IL для конкретних ваг. Ця різниця перетворюється в тисячі доларів зекономлених коштів для великих LP.
Чому важливі газ-оптимізації?
Обчислення x^y з фіксованою точкою споживають багато газу. Кожен своп в weighted pool вимагає виклику LogExpMath, що може коштувати 200-300k gas. Для пулів з високою частотою свопів (наприклад, індексні фонди) це критично. Ми оптимізуємо обчислення: кешуємо ваги, використовуємо precomputed константи, зменшуємо кількість викликів. В результаті газові витрати знижуються до 30% без втрати точності. На одному проекті з 200 свопами на день це зекономило близько $12 000 на рік. Для дуже активних пулів економія може досягати $20 000 щорічно.
Безпечна зміна ваг пула
Для on-chain індексних фондів потрібна можливість міняти ваги без flash loan-вразливості. Balancer вирішує це через gradual weight update: ваги лінійно інтерполюються між стартовими та кінцевими значеннями по блоках.
function _getNormalizedWeight(IERC20 token) internal view returns (uint256) { uint256 pctProgress = _calculateWeightChangeProgress(); return _interpolateWeight(_startWeight[token], _endWeight[token], pctProgress); } Різка зміна ваг дозволяє арбітражникам вилучати цінність за рахунок LP. Градуальна зміна дає арбітражникам можливість торгувати за ринковими цінами, що мінімізує втрати. В 3 рази ефективніше для захисту LP порівняно з різкими змінами.
Архітектура на базі Balancer V2 Vault
Balancer V2 розділив зберігання токенів і логіку пула. Всі токени зберігаються в одному контракті Vault, пули — це тільки логіка розрахунків. Це дає:
- Flash loans з будь-якого токена в Vault без окремого контракту
- Batch swaps через кілька пулів в одній транзакції
- Єдина точка авторизації через
IAuthorizer
При розробці кастомного weighted pool ми реалізуємо інтерфейс IBasePool та реєструємо пул у Vault. Ключові методи: onSwap(), onJoinPool(), onExitPool(). Логіка інваріанта живе в WeightedMath.sol — ми використовуємо перевірену реалізацію Balancer, не пишемо свою математику.
Як ми проводимо розробку weighted pool: покроковий процес
- Аналіз вимог і специфікація — визначаємо кількість активів, ваги, комісії, допустимі діапазони. Будуємо математичну модель та симулюємо IL.
- Проектування архітектури — обираємо форк Balancer або повну кастомну реалізацію. Проектуємо контракти з урахуванням газ-оптимізацій та безпеки.
- Розробка смарт-контрактів — пишемо код на Solidity 0.8.x, використовуємо Foundry для unit- та fuzz-тестів. Кожен пул тестуємо на форку mainnet.
- Внутрішній аудит та рев'ю — проводимо статичний аналіз (Slither, Mythril) та фаззинг інваріанта. Виправляємо всі критичні та середні вразливості.
Докладніше про фаззинг-тестування інваріанта
Фаззинг-тестування інваріанта (invariant fuzzing) за допомогою Foundry дозволяє перевірити, що математична модель пула не порушується при будь-яких вхідних даних. Ми генеруємо випадкові послідовності свопів, додавань та видалень ліквідності і перевіряємо виконання інваріанта V = const. Це виявляє помилки округлення та граничні випадки, які не ловлять unit-тести.- Деплой та верифікація — розгортаємо через forge script, верифікуємо контракти на Etherscan. Налаштовуємо моніторинг.
- Пост-релізна підтримка — протягом місяця допомагаємо з інтеграцією, відповідаємо на питання, при необхідності патчимо.
Порівняння типів пулів
| Тип пула | IL при 5x стрибку ціни | Газ на своп (k gas) | Можливість зміни ваг |
|---|---|---|---|
| 50/50 (Uniswap V2) | 25.5% | 150 | Ні |
| 80/20 weighted pool | 4.4% | 250 | Так (gradual) |
| Кастомний з 3 активами | ~10% | 320 | Так |
Етапи розробки weighted pool
| Етап | Тривалість | Результат |
|---|---|---|
| Аналітика | 2-3 дні | Специфікація пула, ваги, fee, розрахунки IL |
| Проектування | 3-5 днів | Вибір схеми (форк Balancer або кастом), архітектура контрактів |
| Розробка | 1-2 тижні | Смарт-контракти, fuzz-тести інваріанта, інтеграція з Vault |
| Аудит та деплой | 1-2 тижні | Внутрішній аудит, верифікація, деплой (для TVL >$500K — зовнішній аудит) |
| Підтримка | 1 місяць | Технічна підтримка після запуску |
Що входить в роботу
- Документація архітектури та математики інваріанта
- Вихідні коди контрактів з unit-, fork- та fuzz-тестами
- Звіт про аудит (внутрішній або зовнішній)
- Сценарії деплою та верифікації через forge script
- Посібник з інтеграції для фронтенду та бекенду
- Технічна підтримка протягом місяця після запуску
Орієнтири по термінах
Weighted pool на базі форку Balancer V2 з кастомними вагами — від 2 до 4 тижнів. Managed Pool з градуальною зміною ваг та governance — від 4 до 6 тижнів. Повністю кастомна математика з новим інваріантом — від 6 тижнів, плюс обов'язковий зовнішній аудит. Бюджет проекту розраховується індивідуально в залежності від складності.
Якщо вам потрібен кастомний weighted pool — зв'яжіться з нами. Отримайте консультацію щодо вашого DeFi-проекту — ми підберемо оптимальну архітектуру пула під ваші завдання.