Розробка DeFi-протоколу з аудитом та gas-оптимізацією

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

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

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

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

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

Розробка DeFi-протоколу

Команда запускає лендинг-протокол, натхненний Aave v3. На етапі тестування все працює. Після деплою на mainnet через 48 годин оракул Chainlink повертає застарілу ціну — liquidation threshold пробиває безпечні позиції. Ліквідатори дренують заставний пул на значну суму, поки команда розбирається в чому справа. Проблема не в самому Chainlink — у відсутності staleness check: контракт не перевіряв updatedAt з latestRoundData(). Наша команда стикалася з подібними інцидентами та виробила системний підхід до розробки DeFi-протоколів, включаючи смарт-контракти для lending protocol, AMM, cross-chain bridge, а також liquidity pool для yield farming.

Розробка DeFi-протоколу — це не просто Solidity-код. Це система інваріантів, які повинні триматися за будь-яких ринкових умов, MEV-атак та форс-мажорів на рівні інфраструктури. Ми використовуємо формальні специфікації та property-based тести для виявлення вразливостей на ранніх етапах. Гарантуємо прозорість на кожному етапі.

Чому DeFi-протоколи ламаються на етапі дизайну

Oracle manipulation через flash loan

Типова схема: атакуючий бере flash loan на значну суму в Aave, маніпулює ціною в Uniswap v2 пулу з низькою ліквідністю, використовує цей пул як ціновий оракул, займає під завищену заставу, не повертає позику. Протоколи, які використовують token.balanceOf(pool) або spot price з AMM як оракул — вразливі за визначенням.

Захист працює на кількох рівнях:

  • TWAP замість spot price. Uniswap v3 надає OracleLibrary.consult() для розрахунку time-weighted average price. Вікно в 30 хвилин робить flash loan маніпуляцію економічно невигідною — потрібно утримувати позицію кілька блоків, кожен з ризиком арбітражу.

  • Chainlink з fallback. Primary source — Chainlink, fallback — Uniswap v3 TWAP. Якщо Chainlink повертає ціну з updatedAt старшим за 3600 секунд або answer < 0 — перемикання на TWAP з emit події для моніторингу.

  • Circuit breaker на відхилення. Якщо ціна за один блок змінилася більш ніж на 15% — транзакція реверсується. Параметр налаштовується через governance з timelock.

Reentrancy в cross-protocol взаємодіях

AMM-протокол викликає токен при swap. Якщо токен реалізує ERC-777 з tokensReceived хуком — атакуючий контракт отримує управління в середині swap, до оновлення внутрішніх балансів пулу. Це не теорія: атака на Uniswap v1 через ERC-777 була однією з перших публічних експлойтів на DEX. Докладніше про reentrancy можна прочитати на Wikipedia.

У сучасних протоколах проблема ускладнюється: callback-патерни (uniswapV3SwapCallback, flashLoanReceiver) навмисно передають управління зовнішньому коду. Захист будується через invariant check: перед callback фіксується стан, після — перевіряється що інваріанти дотримані.

Liquidation mechanics та bad debt

При різкому падінні ринку на 40%+ за один блок (Ethereum у кризовий період впав на 50% за кілька годин) ліквідація може не встигнути. Залог коштує менше боргу — протокол отримує bad debt. Compound v2 зіткнувся з цим, MakerDAO ввів механізм Emergency Shutdown саме як останній рубіж.

Параметри ліквідації вимагають математичного моделювання: loan-to-value ratio, liquidation threshold, liquidation bonus, close factor — всі ці параметри повинні бути відкалібровані під волатильність конкретного активу. WBTC та мем-токен не можуть мати однаковий LTV. Погана gas-оптимізація може спричинити значні щомісячні витрати, а оптимізація на етапі розробки знижує ці витрати на 30-50%. Неоптимізовані контракти — понад 2000 рядків коду, що збільшує час аудиту в 3 рази.

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

Застосовуємо багаторівневу стратегію: первинний оракул Chainlink з TWAP-резервом, circuit breaker на аномальні рухи ціни, та обов’язкову валідацію свіжості даних. Додатково використовуємо keepers на Tenderly для автоматичного перемикання джерел при збоях.

Ризик Контрзаходи Інструменти
Маніпуляція оракулом TWAP, circuit breaker, fallback оракули Chainlink, Uniswap v3 TWAP
Reentrancy Reentrancy guard, invariant checks після callback OpenZeppelin ReentrancyGuard
Неправильна ліквідація Моделювання параметрів, stress test Власні скрипти на Foundry

Архітектура протоколу

Модульна структура контрактів

Монолітний контракт на 3000 рядків — перша помилка в DeFi-протоколі. Не через естетику, а тому що:

  • Перевищує ліміт байткоду EVM (24 KB)
  • Неможливо замінити окремий модуль без повного редеплою
  • Аудит займає в 3x довше і коштує відповідно

Використовуємо Diamond Pattern (EIP-2535) для протоколів з багатою функціональністю: окремі facets для lending, liquidation, oracle, governance. Сховище — спільний Diamond Storage через keccak256-слоти (ERC-7201). Докладніше про Diamond Pattern можна прочитати на GitHub.

Для простіших випадків — розділення на Core (незмінна логіка), Periphery (допоміжні контракти, можна оновлювати) та Governance. Цей патерн використовує Uniswap, починаючи з v2.

Upgradability: коли потрібна і коли шкодить

UUPS (EIP-1822) vs Transparent Proxy (EIP-1967): вибір залежить від того, хто платить за апгрейд. У UUPS логіка апгрейду в імплементації — дешевше для користувачів, але якщо в новій імплементації прибрати функцію upgradeTo — протокол втрачає можливість апгрейду назавжди. У Transparent Proxy логіка в proxy — трохи дорожче кожен виклик, але надійніше.

Для протоколів з TVL понад $10M апгрейдабельність через multisig без timelock — це централізований вектор атаки. Gnosis Safe 4-of-7 + 48-годинний timelock через OpenZeppelin TimelockController — мінімальний стандарт довіри.

Tokenomics на рівні контракту

Ve-модель (vote-escrowed, як в Curve) вимагає careful balance: контракт блокує токени на строк до 4 років, нараховує voting power через balanceOfAtTime() на конкретний блок. Якщо voting power розраховується неправильно — governance атака коштує дешевше, ніж повинна.

Emission schedule повинен бути immutable або керуватися через governance з супер-мажоритарним голосуванням. Зміна емісії retroactively — це саме те, що вбиває довіру до протоколу.

Стек розробки

Компонент Інструменти Призначення
Розробка Foundry, Hardhat Основне середовище, тести, деплой
Базові контракти OpenZeppelin 5.x Access control, proxy, tokens
Oracle Chainlink, Uniswap v3 TWAP Цінові дані
Тестування Foundry fuzz, Echidna Property-based тести
Статичний аналіз Slither, Mythril Автоматичний пошук вразливостей
Моніторинг Tenderly, OpenZeppelin Defender Алерти, автоматизація
Індексування The Graph Субграф для frontend

Fork-тести на Foundry дозволяють запустити весь протокол проти реального стану mainnet: vm.createFork("mainnet"), vm.rollFork(blockNumber). Це єдиний спосіб перевірити взаємодію з реальними пулами Uniswap, реальними Chainlink feeds та реальними позиціями Aave.

Що входить в процес розробки?

  1. Специфікація (1 тиждень). Формальний опис інваріантів: «сумарний борг завжди менший за сумарну заставу з урахуванням LTV», «тільки ліквідатор може закрити unhealthy позицію», «emission rate не може зрости більше ніж на X% за один governance цикл». Інваріанти стають основою для Echidna property-тестів.

  2. Архітектурний дизайн (3-5 днів). Storage layout, інтерфейси, діаграма взаємодії контрактів. Рішення щодо апгрейдабельності та governance. Цей етап дешевше змінити на папері, ніж після 2 тижнів розробки.

  3. Розробка (3-8 тижнів). Залежить від складності протоколу. Паралельно: контракти + тести в Foundry (покриття >90%), субграф на The Graph, скрипти деплою.

  4. Внутрішній аудит + підготовка до зовнішнього. Slither CI на кожен PR. Перед зовнішнім аудитом — повна Mythril-перевірка, ручний review за SWC-checklist. Мета — закрити low/medium до зовнішнього аудитора, щоб він зосередився на високорівневих векторах.

  5. Деплой. Testnet (Sepolia/Arbitrum Goerli) → staged mainnet через multisig з timelock → post-launch моніторинг через Tenderly.

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

Мінімальний AMM-протокол (xy=k, без концентрованої ліквідності) — 4-6 тижнів. Лендинг за моделлю Compound v2 — 8-12 тижнів. Повноцінний протокол з ve-токеномікою, governance та cross-chain підтримкою — від 3 до 6 місяців. Зовнішній аудит займає 2-4 тижні додатково і планується заздалегідь у топових фірм.

Вартість розраховується після технічної специфікації. Отримайте консультацію — оцінимо ваш проект безкоштовно. Наш досвід: 10+ років у блокчейн-розробці, 50+ успішних проектів, сертифіковані аудитори.

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

  • Документація: специфікація інваріантів, архітектурна діаграма, технічна документація для аудитора.
  • Доступи: репозиторій з вихідним кодом, звіти аудиту, скрипти деплою, адміністративний мультисиг-гаманець.
  • Навчання: передача знань команді замовника щодо роботи з протоколом та моніторингу.
  • Підтримка: 2 тижні post-launch підтримки, фіксація критичних багів у рамках warranty.
Додаткові заходи безпеки Ми також рекомендуємо включати в контракти механізми pause та emergency shutdown, а також використовувати формальні верифікатори, такі як Certora, для доведення інваріантів. Наші протоколи проходять зовнішній аудит з мінімальною кількістю зауважень — в середньому не більше 2 medium-вразливостей.

Замовте розробку DeFi-протоколу з перевіреною архітектурою. Якщо ви розробляєте 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-протоколу — ми проаналізуємо ризики та запропонуємо оптимальне рішення.