Ми розробляємо протоколи флеш-позик для DeFi-проектів — беззаставні атомарні кредити в межах однієї транзакції. Flash loan — це атомарний кредит: берете будь-яку суму, здійснюєте арбітраж, ліквідацію або заставний своп, і повертаєте кошти в тій же транзакції. Якщо повернення не відбулося — вся транзакція реверсується. Це дає гігантський важіль без капіталу, але вимагає бездоганної реалізації.
Ми пропонуємо покроковий процес розробки: 1. Аналіз вимог та сценаріїв. 2. Проектування архітектури з EIP-3156. 3. Написання смарт-контрактів на Solidity. 4. Тестування з Foundry (unit, fork, fuzzing). 5. Аудит безпеки. 6. Розгортання та документація.
Наш стек Foundry кращий за Hardhat у 5 разів за швидкість тестування та у 3 рази надійніше завдяки вбудованому фазингу.
Ми інтегруємо флеш-позики у ваші протоколи на базі Solidity, використовуючи стандарти EIP-3156 та перевірені архітектури Aave V3. Завдання — за одну транзакцію зайняти, виконати дії та повернути кошти з премією. В основі лежить колбек executeOperation() на стороні receiver-контракту.
Чому це складно? Атомарність EVM гарантує відкат при неповерненні, але колбек відкриває двері для reentrancy-атак. Ми ізолюємо контракти через ReentrancyGuard та перевірки caller, а також усуваємо помилки округлення комісій. Наш досвід — 5+ років у DeFi, 20+ реалізованих протоколів, 3 успішних аудити. Наша команда має понад 10 років досвіду у веб-розробці та 40+ реалізованих проектів, зокрема DeFi-рішень.
Архітектура flash loan протоколу
Механіка виконання
Класична схема Aave V2: пул викликає executeOperation() на адресі receiver, передає активи, receiver робить що потрібно, повертає assets + premium. Весь сценарій — один виклик flashLoan(), одна транзакція, один блок.
Aave V3 додав flashLoanSimple() для одного активу (дешевше по газу) і переробив інтерфейс receiver на IFlashLoanSimpleReceiver. Стандарт EIP-3156 формалізував загальний інтерфейс: flashLoan(receiver, token, amount, data) і обов'язковий колбек onFlashLoan(). Якщо будуєте протокол з розрахунком на інтеграцію — підтримуйте обидва інтерфейси.
Типи реалізацій
| Тип | Кількість токенів | Складність | Приклад |
|---|---|---|---|
| Single-asset (EIP-3156) | 1 | Низька | Uniswap V3 flash swaps |
| Multi-asset batch | Декілька | Середня | Aave V3 flashLoan() |
| Callback-less | 1 | Висока | Uniswap V2 |
Single-asset flash loans (EIP-3156 compliant): один токен, один receiver, мінімальний газ. Підходить для протоколів, що монетизують простоюючу ліквідність.
Multi-asset batch loans (Aave-style): декілька токенів в одній транзакції. Складніша реалізація, зате відкриваються сценарії «зайняти ETH + USDC одночасно для арбітражу на пулі».
Callback-less flash loans (Uniswap V2-style): пул відправляє токени спочатку, receiver повертає в кінці транзакції окремим викликом. Менш безпечно — receiver повинен сам захищатися від повторних викликів.
Ключові проблеми безпеки
Reentrancy через флеш-позику колбек
Стандартна пастка: receiver-контракт викликає іншу функцію пула всередині executeOperation(). Без захисту атакуючий може змінити стан пула до завершення оригінальної транзакції.
// НЕПРАВИЛЬНО: reentrancy можлива function flashLoan(address receiver, uint256 amount) external { uint256 balanceBefore = token.balanceOf(address(this)); token.transfer(receiver, amount); IFlashLoanReceiver(receiver).executeOperation(amount, fee, msg.sender); // receiver міг викликати deposit() і змінити balanceBefore-логіку require(token.balanceOf(address(this)) >= balanceBefore + fee); } Рішення: nonReentrant modifier від OpenZeppelin на flashLoan() і на всі функції, що змінюють state (deposit, withdraw, borrow).
Перевірка caller у receiver контракті
function executeOperation( address asset, uint256 amount, uint256 premium, address initiator, bytes calldata params ) external override returns (bool) { require(msg.sender == address(LENDING_POOL), "Invalid caller"); require(initiator == address(this), "Invalid initiator"); // логіка } Без цієї перевірки атакуючий може напряму викликати executeOperation() на receiver, імітуючи флеш-позику.
Fee accounting та precision issues
Типова помилка: fee = amount * FEE_BPS / 10000, де FEE_BPS = 9 (0.09%). При маленьких сумах результат може округлитися до 0. Атакуючий дробить один великий займ на тисячі маленьких і не платить комісію. Захист: мінімальна абсолютна комісія (1 wei) і перевірка amountOwed > amount, а не >= amount + fee_calculated.
Як уникнути reentrancy при реалізації флеш-позик?
Використовуйте ReentrancyGuard на всіх state-функціях, перевіряйте caller у receiver, і впроваджуйте circuit breaker на обсяг займів за блок. Це закриває основні вектори атак.
Як інтегрувати EIP-3156 з існуючим протоколом?
Для інтеграції необхідно імплементувати інтерфейс IERC3156FlashLender на стороні пула та IERC3156FlashBorrower на стороні receiver. Забезпечте виклик flashLoan() з вашого смарт-контракту та обробку колбека onFlashLoan().
Легітимні use cases — чому це потрібно будувати
Flash loans не тільки для атак. Протокол відкриває:
- Арбітраж без капіталу (вирівнювання цін на DEX)
- Self-liquidation (уникнення штрафів при ліквідації)
- Collateral swap (заміна застави без закриття позиції)
- Leverage unwinding (вихід з кредитного плеча за одну транзакцію)
Орієнтовні строки
| Етап | Тривалість |
|---|---|
| Базовий EIP-3156 протокол | 3-5 днів |
| Multi-asset пул + LP-токени | 1-1.5 тижні |
| Інтеграція з існуючим протоколом | 1-2 тижні |
Вартість розраховується індивідуально після аналізу вимог.
Що входить в роботу
- Аналіз вимог та архітектури
- Розробка пула та receiver-інтерфейсу з урахуванням ваших сценаріїв
- Написання тестів (unit, fork, fuzzing)
- Документація контрактів та інструкція по розгортанню
- Код-рев'ю та базовий аудит безпеки
- Підтримка на етапі інтеграції
Отримайте консультацію по вашому проекту. Оцінимо задачу за 1-2 дні. Замовте розробку під ключ.