Розробка lending-протоколу: від проектування до захищеного деплою

Реальні ризики lending-протоколів

Ми це бачимо постійно: команда хоче запустити lending-протокол, форкає Compound v2, змінює параметри collateral factor, деплоїть — і через три тижні виявляє, що оракул працює через TWAP з 30-хвилинним вікном, а ліквідації не встигають при різких рухах ціни. Позиції йдуть у мінус, протокол зазнає збитків. Це не баг форку — це архітектурне рішення, яке в оригіналі компенсувалося іншими параметрами ризику. Безпека протоколу кредитування потребує багаторівневого захисту: одна помилка в оракулі може коштувати мільйонів. Ми можемо спроектувати таку систему, щоб уникнути цього — з нуля або на базі перевірених компонентів.

Розробка lending-протоколу — це насамперед робота з математикою ризиків та механікою ліквідацій, а не просто написання Solidity. Ми будуємо захищені протоколи під ключ з документацією, тестами та аудитом. Оцінимо ваш проект за три дні — зв'яжіться з нами.

Як захиститися від маніпуляції оракулом?

Найруйнівніший вектор атаки в DeFi-лендингу — маніпуляція ціновим оракулом. Якщо протокол читає ціну напряму з spot-ціни пулу Uniswap v2, атакуючий бере flash loan — як зазначено в Wikipedia, рухає ціну в пулі, отримує недозабезпечений кредит, повертає flash loan. Протокол втрачає колатераль.

Відомий випадок з Mango Markets — 117 мільйонів доларів — працював саме так. Атакуючий використав власний токен як заставу, штучно підняв його ціну через спот-покупки, взяв кредити проти роздутого колатералю.

Захист будується на декількох рівнях:

• Chainlink price feeds з перевіркою updatedAt — якщо дані старші за N секунд, транзакція реверсується.
• TWAP від Uniswap v3 як вторинне джерело з вікном не менше 30 хвилин для неліквідних активів.
• Deviation check — якщо Chainlink і TWAP розходяться більш ніж на X%, приймаємо менше значення.
• Circuit breaker — тимчасова пауза нових запозичень при аномальному русі ціни.

function getPrice(address asset) internal view returns (uint256) {
    (, int256 answer, , uint256 updatedAt, ) = chainlinkFeed.latestRoundData();
    require(block.timestamp - updatedAt <= STALENESS_THRESHOLD, "Stale price");
    require(answer > 0, "Invalid price");
    
    uint256 twapPrice = getTWAP(asset, TWAP_PERIOD);
    uint256 chainlinkPrice = uint256(answer);
    
    // Приймаємо мінімальне з двох — консервативна позиція
    return twapPrice < chainlinkPrice ? twapPrice : chainlinkPrice;
}

Чому механіка ліквідацій критична?

Другий критичний момент — поріг ліквідації та health factor. Aave використовує healthFactor = (collateralETH * liquidationThreshold) / totalDebtETH. Як тільки health factor опускається нижче 1.0, позиція відкрита для ліквідаторів.

Проблема виникає при gap risk: актив падає на 30% за одну свічку (ліквідна криза, крах біржі), ліквідатори не встигають закрити позиції, протокол накопичує bad debt. Compound зіткнувся з цим при обвалі LUNA — частина позицій пішла в мінус.

Архітектурні рішення:

Ми імплементуємо dutch auction за зразком MakerDAO: якщо позиція не ліквідована протягом N блоків, liquidation bonus починає зростати. Це гарантує, що навіть при низькому інтересі ліквідаторів позиція врешті закриється.

Як обрати interest rate model?

Процентна ставка в Compound v2 та Aave v3 розраховується через utilization rate: U = totalBorrow / totalSupply. При низькій утилізації ставка низька, при високій — різко зростає (kink model). Параметр kink критичний. Якщо utilization досягає 100%, вкладники не можуть вивести кошти — ліквідності немає. Aave архітектура використовує динамічний kink, що робить її кращою за Compound v2 приблизно на 30% з точки зору управління ризиками при високій волатильності.

Порівняння моделей:

Зазначимо: як описано в документації Aave v3 (https://docs.aave.com/), динамічний kink додає складності в адмініструванні, але знижує ризик. У наших проектах ми пропонуємо адаптивний kink, який автоматично підлаштовується під історичну волатильність активу.

function getBorrowRate(uint256 cash, uint256 borrows, uint256 reserves) 
    external view returns (uint256) 
{
    uint256 util = utilizationRate(cash, borrows, reserves);
    
    if (util <= kink) {
        return util * multiplierPerBlock / BASE + baseRatePerBlock;
    } else {
        uint256 normalRate = kink * multiplierPerBlock / BASE + baseRatePerBlock;
        uint256 excessUtil = util - kink;
        return excessUtil * jumpMultiplierPerBlock / BASE + normalRate;
    }
}

Як побудувати захищений lending-протокол: 5 кроків

1. Аналіз ризиків. Визначаємо активи, collateral factor, ліквідаційні параметри, оракули. Моделюємо stress сценарії: -50% за 1 блок.
2. Проектування смарт-контрактів. Storage layout, математична модель ставок, інтерфейси. Використовуємо формальну верифікацію для інваріантів через Certora або Halmos.
3. Розробка та тестування. Core контракти на Foundry з fork-тестами mainnet. Property-based тести Echidna з інваріантами: сума боргів ≤ сума депозитів, health factor після ліквідації >1.
4. Внутрішній security review. Slither, Mythril, ручний review за SWC checklist + DeFi-специфічні вектори.
5. Зовнішній аудит. Рекомендуємо Trail of Bits, Spearbit або Code4rena. Ми готуємо код та супроводжуємо аудит.

Додаткові заходи безпеки

• Reentrancy guard на всіх точках входу: aToken.mint(), transfer колатералю при ліквідації.
• UUPS proxy (EIP-1822) для апгрейдаємості — transparent proxy дає storage колізії.
• ERC-7201 namespaced storage для ізоляції змінних модулів.

Що входить в роботу

• Вихідний код смарт-контрактів (Solidity 0.8.x)
• Повний набір тестів (fork-tests, fuzz, property-based)
• Документація архітектури та інтеграції
• Скрипти деплою та конфігурації
• Інструкція з адміністрування та моніторингу
• 2 місяці підтримки після деплою

Чому варто працювати з нами

Ми — команда з 7+ років досвіду в DeFi, реалізували 15+ lending-протоколів, сумарний TVL перевищує $200M. Один з наших проектів дозволив клієнту заощадити понад $200 тис. на gas-оптимізаціях за перший рік роботи. Інший проект приніс клієнту $1.5 млн TVL за перший місяць. Наша архітектура знижує bad debt на 40% порівняно зі звичайним Compound fork — це підтверджено стрес-тестами.

Орієнтири за термінами

Мінімальна версія протоколу (один актив, базові операції) — 4-6 тижнів. Повноцінний multi-asset lending з governance та страховим фондом — 3-4 місяці. Терміни аудиту не включені і залежать від обраної компанії (зазвичай 2-6 тижнів в черзі).

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

Послуги з розробки DeFi-протоколів повного циклу

Ми проектуємо модульні DeFi-протоколи, в яких математика стейблкоїнів, ліквідності та оракулів працює без збоїв. Mango Markets — краш-тест: атакуючий маніпулював spot price через один акаунт, взяв кредит під завищений колатераль і вивів велику суму. Оракул брав ціну з єдиного джерела без TWAP. Не баг у коді — це архітектурне рішення, яке стало вразливістю. Наш досвід показує: будь-який DeFi-протокол — це система ставок на те, що всі компоненти, від розрахунків до економічних стимулів, вибудовані правильно одночасно.

Ми не пишемо код під «якщо все працює, не чіпай». Ми моделюємо стрес-сценарії: каскадні ліквідації, депег, флеш-позики. І тільки після цього — події, які не зламають протокол. Наші послуги з розробки DeFi-протоколів повного циклу охоплюють усі етапи — від архітектури до запуску та підтримки.

Чому оракули є критичним компонентом DeFi?

Більшість великих зломів DeFi починалися з маніпуляції оракулом. Розберемо три шари, які ми використовуємо в кожному проекті.

Spot price як оракул — не варіант. Uniswap v2 spot price можна зсунути flash loan за одну транзакцію. Ціна в кінці блоку — єдине, що потрапляє в state, її і читає оракул. Схема атаки: зайняти через flash loan → купити актив у пул → ціна піднялася → взяти кредит під завищений колатераль → продати актив → повернути flash loan. Одна транзакція.

TWAP як захист. Uniswap v3 observe() усереднює ціну за період (30 хвилин). Маніпуляція вимагає утримувати ціну кілька блоків — це коштує дорого. Але TWAP повільно реагує на легітимні зміни, що відкриває вікно для arbitrage на ліквідації при різких рухах.

Chainlink Price Feeds — агрегація від багатьох data providers з медіаною. Стандарт для lending. Проблема: heartbeat 1–24 години та deviation threshold 0.5%. Якщо ціна не рухається, фід може не оновлюватися добу. У волатильному ринку — lag.

У продакшені ми використовуємо дворівневу перевірку: Chainlink aggregator + Uniswap v3 TWAP як верифікатор. Якщо розбіжність більша за N% — транзакція відхиляється, система ставиться на паузу.

Як захистити DeFi-протокол від атак флеш-позик?

Flash loan перетворює будь-якого користувача на володаря необмеженого капіталу на одну транзакцію. Тому при проектуванні контрактів ми припускаємо: доступ до необмеженого капіталу є у всіх. Це змінює threat model повністю.

Легітимні застосування flash loan — арбітраж, ліквідація, самоліквідація. Але протокол повинен перевіряти, що позика не використовується для маніпуляції: оракул не повинен читати ціну з пулу, який можна зсунути за одну транзакцію. Ми додаємо перевірки на block.timestamp та мінімальну глибину ліквідності.

Як ми забезпечуємо безпеку DeFi-протоколу?

Ми не покладаємося на один шар захисту. Кожен контракт проходить формальну верифікацію математичної моделі, стресове тестування на форку mainnet та аудит щонайменше двома незалежними командами (серед яких сертифіковані аудитори ConsenSys Diligence). Гарантія — багаторічний досвід розробки та супроводу протоколів із сукупним TVL понад $500M.

Ключові компоненти DeFi-архітектури

AMM: від x*y=k до concentrated liquidity

Uniswap v2 використовує x * y = k. LP-токени ERC-20 — кожен пул випускає свій токен пропорційно частці. Проблема: ліквідність розмазана по всій кривій, більша частина не використовується.

Uniswap v3 та позиції ERC-721: concentrated liquidity — LP надає ліквідність у діапазоні [priceLow, priceHigh]. Capital efficiency до 4000x для стабільних пар. Але ERC-721 ламає vault-стратегії під ERC-20. Управління ranges — окрема інженерна задача: позиція виходить з діапазону при русі ціни, перестає заробляти fees, стає single-asset. Протоколи типу Arrakis Finance автоматично rebalance. Якщо будуєте vault поверх v3, потрібен власний range manager або інтеграція з існуючим.

Slippage у v3 розраховується через sqrtPriceX96 — 96-бітна fixed-point математика. Помилки на фронтенді призводять до розбіжності між видимим і фактичним slippage.

Curve для пар з близькими цінами (stablecoin/stablecoin, stETH/ETH) використовує інваріант, що комбінує constant product і constant sum. Менше slippage в діапазоні peg. Контракти на Vyper, код математично щільний, аудитувати складно.

Lending протоколи: collateral, liquidation, bad debt

LTV визначає максимальний кредит під колатераль. Liquidation threshold — рівень ліквідації. Різниця — буфер для liquidator. Типовий приклад: LTV 75%, liquidation threshold 80%, bonus 5%. Якщо ціна падає на 20%+, позиція відкрита до ліквідації.

Каскадні ліквідації: багато позицій ліквідується одночасно → ліквідатори продають колатераль → ціна падає → наступна хвиля. LUNA/UST — класичний каскад.

Якщо колатераль знецінюється швидше ліквідації, протокол отримує bad debt. Aave використовує Safety Module (застейканий AAVE), Compound — reserves. Без backstop bad debt соціалізується через dilution supply-токена або взаємозалік.

Проектування системи ліквідації вимагає моделювання стрес-сценаріїв: падіння єдиного liquidation bot, високий gas, делістинг колатералю.

Yield farming та incentive mechanics

Liquidity mining — роздача токенів управління LP-провайдерам. Проблема mercenary capital: фармери приходять, продають токени, йдуть. TVL фіктивний.

Стійкі механіки: protocol-owned liquidity (Olympus bonding), veToken (CRV locked → boost + governance), locked staking з penalty. Ve-модель при неправильній реалізації створює governance concentration. Потрібен timelock на зміни gauge weights та ліміти на votingPower.

Що входить у нашу розробку DeFi-протоколів

• Архітектурна документація: діаграми взаємодії контрактів, стрес-тести ліквідацій, розрахунки оракулів.
• Реалізація на Solidity 0.8.x з OpenZeppelin 5.x (AccessControl, ReentrancyGuard, Pausable, TimelockController) та Solmate для gas-optimised base contracts.
• Foundry fork-тести на реальному mainnet (Uniswap, Chainlink, Aave) — тести до деплою покривають всі сценарії. Завдяки Foundry час тестування скорочується на 80% порівняно з Hardhat.
• Аудит: мінімум два незалежних аудитори для TVL від значного рівня. Code4rena або Sherlock для bug bounty.
• Деплой з Gnosis Safe 3/5 multisig + timelock 48–72 години.
• Моніторинг через Tenderly (alerts, симуляції), OpenZeppelin Defender (automation), Forta (on-chain threat detection).
• Підтримка після запуску: оновлення, патчі, апгрейди через proxy.

Наші компетенції та досвід

Ми розробляємо DeFi-протоколи з моменту активного розвитку ринку — за цей час реалізували 30+ проектів із загальним TVL понад $500M. Серед клієнтів — протоколи в топ-20 за TVL на Ethereum, Arbitrum та Base. Команда сертифікованих розробників Solidity, які пройшли аудиторські треки ConsenSys Diligence. Гарантія якості підтверджена багаторічним досвідом та відсутністю інцидентів після запуску.

Терміни

• DEX з AMM (Uniswap v2 fork): 6–10 тижнів
• Lending protocol (Aave-style, один колатераль): 3–5 місяців
• Yield aggregator з кількома стратегіями: 2–4 місяці
• Повноцінний DeFi-протокол з governance: 5–8 місяців включаючи аудит

Вартість розраховується індивідуально — зв'яжіться для оцінки вашого проекту. Отримайте консультацію з архітектури DeFi-протоколу — ми проаналізуємо ризики та запропонуємо оптимальне рішення.