Разработка протокола кредитования под залог NFT (NFTfi)
NFT-коллекция на 10 000 токенов с floor price 2 ETH — это 20 000 ETH заблокированной ценности. Продать одну NFT быстро по рыночной цене сложно: листинг, ожидание покупателя, потеря редкого актива. NFTfi-протокол позволяет занять ETH под залог NFT без продажи — держатель CryptoPunk или Bored Ape получает ликвидность, кредитор получает доходность. Задача разработки — построить систему, где и кредитор, и заёмщик защищены смарт-контрактом, а оценка NFT не позволяет выдать кредит 5 ETH под актив с floor price 1 ETH.
Ключевая проблема: как оценить NFT on-chain
Это единственная фундаментальная сложность NFTfi, которую нельзя решить стандартным образом. ERC-20 токены имеют ликвидный рынок и Chainlink Price Feed. У NFT нет единой цены — есть floor, last sale, rarity score, trait-based pricing. Все эти метрики манипулируемы при недостаточном объёме торгов.
Варианты оценки и их trade-offs
Peer-to-peer модель (NFTfi, Arcade.xyz) — кредитор и заёмщик сами договариваются о сумме, проценте и сроке. Смарт-контракт только эскроу NFT и исполняет условия. Оценка — проблема сторон, не протокола. Это устраняет риск oracle manipulation, но снижает ликвидность: заёмщику нужно ждать предложения от кредитора.
Pool-based модель (BendDAO, JPEG'd) — ликвидность в пуле, кредит выдаётся немедленно по floor price оракула. Быстро и удобно, но создаёт системный риск: если floor price коллекции падает быстрее, чем проходят ликвидации — пул уходит в убыток. BendDAO в августе 2022 столкнулся с этим: массовое падение BAYC floor price создало угрозу bad debt на 5 000 ETH, протокол был вынужден срочно менять параметры ликвидации.
Hybrid модель — peer-to-peer для крупных займов, пул для стандартных коллекций с проверенным floor. Сложнее в разработке, но более устойчива.
При pool-based подходе oracle для floor price — критический элемент. Используем медиану нескольких источников: Chainlink NFT Floor Price Feeds (доступны для топ-коллекций), Reservoir Protocol API с on-chain верификацией, TWAP последних sales из событий маркетплейсов. Один источник оракула — вектор для flash loan manipulation.
Архитектура протокола
Lifecycle займа
Заёмщик → depositsNFT() → NFT уходит в escrow контракт
Заёмщик → requestLoan(nftId, amount, duration) → создаётся LoanTerms struct
Кредитор → fundLoan(loanId) → ETH/ERC-20 отправляется заёмщику
...срок займа...
Заёмщик → repayLoan(loanId) → возврат principal + interest, NFT возвращается
ИЛИ
Кредитор → liquidate(loanId) → после expiry, NFT переходит кредитору
Ключевые смарт-контракты:
- LoanCore — основная логика, хранит состояние займов
- OriginationController — валидация условий, signature verification для P2P
- VaultFactory — создаёт индивидуальные vault для каждой NFT (изоляция активов)
- RepaymentController — расчёт interest, обработка погашений
- FeeController — протокольная комиссия
Разделение на отдельные контракты — не overengineering, а необходимость: 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 из allowlisted коллекций — принимать любой ERC-721 опасно, можно получить залог в виде мусорного токена.
Ликвидация: самый сложный момент
При pool-based модели ликвидация должна быть атомарной или защищённой от MEV. Типичный сценарий атаки: ликвидатор видит, что позиция здорова (health factor > 1), отправляет liquidate транзакцию, MEV-бот вставляет front-run с покупкой NFT на маркетплейсе по floor price и обратным листингом — классический sandwich. Решение: grace period перед ликвидацией и аукционный механизм (Dutch auction для NFT-залога), а не мгновенная передача кредитору.
Стек разработки
Контракты — Solidity 0.8.x, фреймворк — Foundry. Для P2P-части используем EIP-712 signature verification — заёмщик подписывает LoanTerms оффчейн, кредитор верифицирует подпись on-chain. Это убирает approve-транзакции для заёмщика.
Тесты включают fork-тесты на Ethereum mainnet: реальные коллекции (BAYC, Azuki), реальные маркетплейс-события для симуляции изменений floor price. Foundry's vm.warp для симуляции истечения срока займа.
Frontend (если нужен) — wagmi + viem, NFT-данные через Alchemy NFT API или Reservoir.
Процесс работы
Проектирование (1 неделя). Выбор модели (P2P/pool/hybrid), список поддерживаемых коллекций, параметры риска (max LTV, liquidation threshold), tokenomics протокольной комиссии.
Разработка (4-8 недель). Core контракты, oracle интеграция, тесты с coverage > 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 недель разработки. Pool-based с oracle интеграцией и аукционной ликвидацией — 10-16 недель. Аудит и подготовка к mainnet — ещё 4-6 недель поверх разработки.