Розробка протоколу кредитування під залог NFT (NFTfi)
NFT-колекція з 10 000 токенів з floor price 2 ETH — це 20 000 ETH заблокованої вартості. Продати одну NFT швидко за ринковою ціною складно: листинг, очікування покупця, втрата рідкісного активу. NFTfi-протокол дозволяє запозичити ETH під залог NFT без продажу — власник CryptoPunk або Bored Ape отримує ліквідність, кредитор отримує дохід. Завдання розробки — побудувати систему, де і кредитор, і позичальник захищені smart contract, а оцінка NFT запобігає видачі кредиту 5 ETH під актив з floor price 1 ETH.
Ключова проблема: як оцінити NFT on-chain
Це єдина фундаментальна складність NFTfi, яку неможливо вирішити стандартним способом. ERC-20 токени мають ліквідний ринок та Chainlink Price Feeds. У NFT немає єдиної ціни — є floor, остання продаж, рідкісність, цінування на основі ознак. Всі ці метрики можна маніпулювати при недостатньому обсязі торгів.
Варіанти оцінки та їхні компроміси
Peer-to-peer модель (NFTfi, Arcade.xyz)—кредитор і позичальник самі договариваються про суму, відсоток і термін. Smart contract тільки тримає NFT в escrow та виконує умови. Оцінка — питання сторін, а не протоколу. Це усуває ризик маніпуляції oracle, але зменшує ліквідність: позичальник повинен чекати пропозицію від кредитора.
Модель на основі пулу (BendDAO, JPEG'd)—ліквідність у пулі, кредит видається миттєво за floor price oracle. Швидко й зручно, але створює системний ризик: якщо floor price колекції падає швидше, ніж відбуваються ліквідації — пул іде у збиток. BendDAO у серпні 2022 року зіткнувся з цим: масовий спад BAYC floor price створив загрозу bad debt на 5000 ETH, протокол був змушений терміново змінювати параметри ліквідації.
Гібридна модель—peer-to-peer для великих кредитів, пул для стандартних колекцій з перевіреним floor. Складніше у розробці, але стійкіша.
При пулі-базованому підході oracle для floor price — критичний елемент. Використовуємо медіану кількох джерел: Chainlink NFT Floor Price Feeds (доступні для топ-колекцій), Reservoir Protocol API з on-chain верифікацією, TWAP останніх продажів із подій маркетплейсів. Один джерело oracle — вектор для flash loan маніпуляції.
Архітектура протоколу
Життєвий цикл кредиту
Позичальник → depositsNFT() → NFT йде в escrow контракт
Позичальник → requestLoan(nftId, amount, duration) → створює LoanTerms struct
Кредитор → fundLoan(loanId) → відправляє ETH/ERC-20 позичальнику
...період кредиту...
Позичальник → repayLoan(loanId) → повернення principal + interest, NFT повертається
АБО
Кредитор → liquidate(loanId) → після закінчення, NFT переходить кредитору
Ключові smart контракти:
- LoanCore—основна логіка, зберігає стан кредитів
- OriginationController—валідація умов, signature verification для P2P
- VaultFactory—створює індивідуальний vault для кожної NFT (ізоляція активів)
- RepaymentController—розрахунок интересу, обробка погашень
- FeeController—протокольна комісія
Поділ на окремі контракти — не overa, а необхідність: LoanCore оновлюється через UUPS, OriginationController можна замінити без міграції даних кредитів.
Обробка ERC-721 та ERC-1155
ERC-1155 додає складність: токен може бути fungible (якщо supply > 1) або semi-fungible. Для кредитування потрібно визначити, приймаємо ми часткову заставу (100 з 1000 токенів одного ID). Більшість протоколів обмежуються ERC-721 та ERC-1155 з supply = 1. Якщо потрібна часткова ERC-1155 з улогом — логіка оцінки і ліквідації ускладнюється кратно.
Прийняття NFT в заставу через safeTransferFrom з onERC721Received хуком. Хук верифікує, що NFT з дозволених колекцій — приймати будь-який ERC-721 небезпечно, можна отримати мусорний токен як заставу.
Ліквідація: найскладніший момент
При моделі на основі пулу ліквідація повинна бути атомарною або захищеною від MEV. Типовий сценарій атаки: ліквідатор бачить, що позиція здорова (health factor > 1), відправляє транзакцію ліквідації, MEV-бот front-runs, купивши NFT на маркетплейсі за floor price й переліставши її — класичний sandwich. Рішення: період благодаті перед ліквідацією та аукціонний механізм (Dutch auction для NFT-заставу), а не миттєва передача кредитору.
Стек розробки
Контракти: Solidity 0.8.x, фреймворк: Foundry. Для P2P-частини використовуємо EIP-712 signature verification — позичальник підписує LoanTerms off-chain, кредитор верифікує підпис on-chain. Це усуває approve-транзакції для позичальника.
Тести включають fork-тести на Ethereum mainnet: реальні колекції (BAYC, Azuki), реальні события маркетплейсів для моделювання змін floor price. Foundry's vm.warp для моделювання закінчення терміну кредиту.
Frontend (якщо потрібен): wagmi + viem, дані NFT через Alchemy NFT API або Reservoir.
Процес роботи
Проектування (1 тиждень). Вибір моделі (P2P/пул/гібридна), список підтримуваних колекцій, параметри ризику (max LTV, liquidation threshold), tokenomics протокольної комісії.
Розробка (4-8 тижнів). Core контракти, інтеграція oracle, тести з покриттям > 95%, fuzz-тести на loan math.
Аудит (2-4 тижні). Обов'язковий для протоколів з TVL. Мінімум один зовнішній аудитор. Рекомендуємо Spearbit, Trail of Bits або Code4rena contest для peer-review.
Деплой. Спочатку testnet з реальними користувачами, потім mainnet через Gnosis Safe multisig. Параметри ризику через governance або timelocked admin.
Орієнтири по срокам
P2P-протокол без пулу — 6-8 тижнів розробки. Пул-базований з інтеграцією oracle та аукціонною ліквідацією — 10-16 тижнів. Аудит та підготовка до mainnet — ще 4-6 тижнів поверх розробки.