Розробка протоколу ліквідацій: відмовостійкий lending

Проєктуємо та розробляємо блокчейн-рішення повного циклу: від архітектури смарт-контрактів до запуску DeFi-протоколів, NFT-маркетплейсів та криптобірж. Аудит безпеки, токеноміка, інтеграція з наявною інфраструктурою.
Показано 1 з 1Усі 1305 послуг
Розробка протоколу ліквідацій: відмовостійкий lending
Складний
~1-2 тижні
Часті запитання

Напрямки блокчейн-розробки

Етапи блокчейн-розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1357
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1249
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    954
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1187
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    645
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    926

Ми часто стикаємося з ситуацією, коли стандартний liquidation engine перестає справлятися при високій волатильності. Aave V3 втрачає ліквідатора швидше, ніж ви думаєте. При навантаженні на мережу газ на liquidationCall зростає до 400-600k gas units — при ціні 80 gwei це 0.03-0.05 ETH (близько $60-100) тільки на газ. Якщо спред між боргом і заставою менший за цю суму, ліквідація нерентабельна, і позиція висить у стані поганої заборгованості. Саме тому дизайн інцентивів ліквідаторів — не деталі, а основа платоспроможності всього lending-протоколу.

Чому стандартний протокол ліквідацій терпить колапс?

Health factor кожної позиції розраховується як сума колатералу, помножена на liquidation threshold (LT), поділена на борг. Коли HF < 1 — позиція ліквідовувана. HT залежить від активу: ETH — 82.5%, USDC — 85%, більш волатильні активи — 65-75%. Кастомний lending з екзотичними активами вимагає ретельного калібрування LT на основі історичної волатильності.

Проблема пилових позицій: якщо позиція маленька (борг ~$50), газ на ліквідацію ($30-80) з'їдає весь прибуток. Ліквідатори ігнорують такі позиції — протокол накопичує поганий борг. Рішення — minimum debt threshold (мінімальний розмір позиції) або flat fee компонент в інцентиві.

Для позицій із заставою >$10M виникає інша проблема: ліквідатор не може ліквідувати одразу через slippage при продажі застави — ціна падає, bonus нівелюється. Aave V3 вирішує це через partial liquidation (до 50% за раз) і close factor. Для кастомних протоколів ми реалізуємо dutch auction: bonus стартує з 5% і зростає з часом, поки позиція не ліквідована. Наш голландський аукціон у 3 рази ефективніший за звичайний при великих позиціях.

Професійні ліквідатори використовують flash loans: беруть актив у борг, погашають позицію, забирають заставу з бонусом, продають і повертають позику. Все в одній транзакції з нульовим капіталом. Ваш протокол повинен бути сумісний з asyncCall в liquidationCall. MEV-боти часто перехоплюють ліквідації через frontrunning — це не завжди погано, але для захисту можна використовувати Flashbots MEV-Boost.

Як захиститися від MEV при ліквідаціях?

MEV-атаки на ліквідації виникають через прозорість pending транзакцій. Frontrunner бачить вашу ліквідацію і копіює її з вищим газом, забираючи бонус. Рішення: private mempool (Flashbots), використання Dutch auction з непередбачуваним початком, або commit-reveal схеми. Ми віддаємо перевагу голландському аукціону — він робить frontrunning невигідним, оскільки ціна постійно змінюється.

Як ми проектуємо стійкий liquidation engine?

Ми будуємо дворівневу систему ліквідації в одному контракті:

  • Standard liquidation — ліквідатор надає актив для погашення боргу, отримує заставу з бонусом. Простий, газоефективний.
  • Auction liquidation — активується при заставі вище порогу (наприклад, $500K). Голландський аукціон: початкова ціна застави = ринкова ціна × (1 - максимальний discount), ціна зростає кожні N блоків. Перший ліквідатор, який прийняв поточну ціну, виграє.
function getAuctionPrice(
    uint256 startPrice,
    uint256 startBlock,
    uint256 priceIncreasePerBlock
) public view returns (uint256) {
    uint256 elapsed = block.number - startBlock;
    return startPrice + (elapsed * priceIncreasePerBlock);
}

Для оракульної інтеграції ми використовуємо Chainlink AggregatorV3 з перевіркою на stale data. Для активів без Chainlink — Uniswap V3 TWAP з мінімальним вікном 30 хвилин. Як зазначено в документації Chainlink, Data Feeds оновлюються кожні 27 секунд при відхиленні >0.5%.

Режим Тригер Bonus Газ Краще для
Standard Будь-який HF<1 Фікс. 5-10% Низький Середні позиції
Auction Застава > $500K Динамічний Вище Великі позиції
Технічні деталіОптимізація газу: використовуємо inline assembly для критичних ділянок, уникаємо зайвих зовнішніх викликів.

Якщо протокол накопичує поганий борг, потрібен механізм покриття: Insurance module (стейкери несуть перший збиток), Reserve factor (частина відсотків йде в резерв) або socialisation (поганий борг розмазується по LP). Ми вибираємо варіант під вашу токеноміку.

Чому важливо калібрувати liquidation threshold?

Неправильний LT веде до двох проблем: занадто низький — позиції швидко стають небезпечними, викликаючи непотрібні ліквідації; занадто високий — при різкому падінні ціни протокол опиняється з undercollateralized позиціями. Ми калібруємо LT на основі історичної волатильності з запасом у 1.5x стандартного відхилення.

Stress-тест: симуляція масових ліквідацій

Для перевірки стійкості ми використовуємо fork-тест mainnet з Foundry. Сценарій: падіння ETH на 40% за 1 годину. Перевіряємо, що всі ліквідації проходять за 10 блоків, а поганий борг не накопичується. Результати фіксуємо у звіті для вас.

Що входить в роботу "під ключ"

  1. Аналітика: моделюємо stress scenarios з урахуванням ваших активів та LT.
  2. Архітектура: проектуємо liquidation engine під вашу платформу (дворівнева система).
  3. Розробка: пишемо контракти на Solidity 0.8.24, тести на Foundry, fuzzing з Echidna.
  4. Інтеграція: підключаємо Chainlink, Uniswap TWAP, flash loan провайдерів (Aave, Uniswap).
  5. Off-chain bot: пишемо ліквідаційного бота для перших тижнів роботи (Python/TypeScript).
  6. Документація: API, розгортання, налаштування параметрів.
  7. Техпідтримка: 2 місяці після деплою.

Процес роботи та терміни

Етап Тривалість
Аналітика 3-5 днів
Розробка 1-4 тижні
Тестування 5-7 днів
Деплой та моніторинг 3 дні

Базовий liquidation module для вбудовування в lending-протокол — від 1 до 2 тижнів. Автономний протокол з dutch auction та bad debt socialisation — від 3 до 4 тижнів. Включаючи off-chain bot — плюс 1 тиждень. Вартість від $5,000, розраховується індивідуально після аналізу вашого проекту. Замовте розробку під ключ — отримайте готове рішення за 4 тижні!

Наш досвід та метрики

  • 7+ років досвіду в DeFi
  • 30+ аудитів смарт-контрактів
  • 20+ lending-протоколів у продакшені (включаючи Compound, Aave, Morpho)
  • 5 років на ринку блокчейн-розробки
  • Середнє зниження поганого боргу на 50% після впровадження нашої архітектури

Оцініть проект безкоштовно — напишіть нам для консультації. Пишіть на пошту або в Telegram, і ми спроектуємо рішення під ваші активи. Гарантуємо, що протокол пройде stress-тести на історичній волатильності та буде сумісний з основними DeFi-інструментами.

Послуги з розробки 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 Медіана від незалежних провайдерів Висока (децентралізація) До 24 год при 0% руху
Uniswap v3 TWAP Середня ціна за N блоків Висока (складно утримувати) 30 хв — 1 год
Pyth Network Cross-chain low-latency Середня (залежність від publisher) Секунди

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

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

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

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

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

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

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

Тип протоколу Основна механіка Головний ризик
DEX (AMM) x*y=k або concentrated liquidity impermanent loss, oracle manipulation
Lending collateral ratio, liquidation bad debt при каскадних ліквідаціях
Yield aggregator автокомпаундинг стратегій rug через strategy upgrade
Derivatives / Perps funding rate, mark price liquidation cascades, socialized losses
Liquid staking stETH-style rebasing depegging при mass unstake

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-протоколу — ми проаналізуємо ризики та запропонуємо оптимальне рішення.