Разработка платформы аренды NFT
ERC-721 и ERC-1155 изначально не предусматривали аренду — токен либо принадлежит адресу, либо нет. Попытки реализовать аренду через custodial-депозит (пользователь передаёт NFT на контракт, получает wrapped-версию) создают поверхность атаки и плохой UX. Стандарт ERC-4907 закрыл этот пробел, введя роль user в дополнение к owner, с expiry timestamp. Но даже с ERC-4907 надо решать нетривиальные вещи: collateral management, revenue sharing, flash renting, cross-chain аренду.
Модели аренды: collateral vs collateral-free
Два принципиально разных подхода, и выбор зависит от usecase:
Collateral-based — арендатор блокирует залог, превышающий floor price NFT. Используется для игровых активов с высокой ликвидностью. Риск: floor price волатилен, liquidation механизм должен работать без оракулов с минимальной latency. Для этого интегрируем Chainlink Price Feeds или TWAPs из Uniswap v3 pools с достаточной глубиной.
Collateral-free (scholarship model) — владелец делегирует использование без передачи ownership. Классический кейс — Axie Infinity scholarships. Реализуется через ERC-4907 setUser() + whitelist арендаторов на уровне игрового сервера. Контракт здесь проще, но off-chain инфраструктура сложнее.
// Минимальная реализация ERC-4907 с revenue sharing
interface IERC4907 {
function setUser(uint256 tokenId, address user, uint64 expires) external;
function userOf(uint256 tokenId) external view returns (address);
function userExpires(uint256 tokenId) external view returns (uint256);
}
contract RentalMarket {
struct RentalTerms {
uint256 pricePerDay;
uint256 maxDuration;
uint256 collateralRequired;
address paymentToken; // address(0) = native
uint16 protocolFeeBps; // basis points
}
}
Смарт-контракты: что реально сложно
Expiry enforcement — ERC-4907 не вызывает callback при истечении аренды. userOf() возвращает address(0) если block.timestamp > userExpires, но сам токен не «освобождается». Игровые серверы должны polling-ить состояние или подписываться на события. Альтернатива — Gelato Automation для on-chain уведомлений по expiry.
Вложенная аренда (subletting) — владелец хочет разрешить арендатору сдавать токен дальше. Стандарт не запрещает, но нужно дерево арендных отношений и корректное распределение revenue. Реализуем через mapping rentals[tokenId][] с деревом зависимостей и reentrancy guard на каждом уровне.
Flash renting — аренда и использование в одной транзакции, аналог flash loans. Полезно для one-time actions (mint через NFT-gate, vote snapshot). Контракт принимает callback интерфейс, передаёт user права, ждёт выполнения, откатывает если flashRent не завершён корректно.
Revenue distribution — если NFT приносит in-game rewards, нужен сплиттер: owner получает X%, renter Y%, protocol fee Z%. Используем pull-payment pattern (Escrow) вместо push во избежание gas griefing.
Индексация и поиск
Граф данных для rental платформы сложнее, чем для простого marketplace. Необходимо отслеживать:
- Активные аренды с expiry timestamps
- Историю аренд на токен (для репутации арендаторов)
- Доходность по каждому NFT (APR для владельцев)
The Graph с кастомным subgraph — стандартный выбор. Схема entities:
| Entity | Ключевые поля |
|---|---|
| Rental | tokenId, owner, user, startTime, endTime, pricePerDay, collateral |
| RentalOffer | tokenId, lister, pricePerDay, minDuration, maxDuration, active |
| RenterProfile | address, totalRentals, disputeCount, reputationScore |
Для real-time обновлений (нужны при истечении аренды) — WebSocket подписка на контрактные события через Alchemy или Infura, bridge к The Graph через Apollo subscriptions.
Безопасность: специфика rental контрактов
Несколько атак, специфичных именно для rental:
Approval drain — если арендодатель выдал approval на контракт, а контракт не проверяет, что transferFrom вызывается только при активной аренде, атакующий может вывести NFT. Решение: контракт должен быть custodian (держать NFT у себя) или использовать ERC-4907 без custody.
Timestamp manipulation — validators могут манипулировать block.timestamp в пределах ~15 секунд. Не критично для аренды на дни, но для flash renting с секундной гранулярностью нужен block.number как дополнительный параметр.
Reentrancy через ERC-721 receiver — при возврате NFT контракт вызывает onERC721Received. Если owner — смарт-контракт с логикой в этом callback, возможна reentrancy. Везде ставим nonReentrant и следуем Checks-Effects-Interactions.
Oracle manipulation — для collateral-based аренды с Chainlink важно использовать latestRoundData() с проверкой updatedAt и stale threshold. Устаревший price feed = некорректная liquidation.
Frontend и UX
Rental платформа требует нестандартного UI — владелец видит «доходность портфеля», арендатор видит «доступные к аренде активы». Разрабатываем на React + wagmi v2 + viem. Ключевые компоненты:
- Portfolio dashboard — список owned NFTs с метриками: текущий статус, earned revenue, suggested rental price (on-chain данные + floor price от Reservoir API)
- Rental marketplace — фильтрация по collection, price range, duration, collateral required
- Rental management — активные аренды, time remaining (countdown), early termination flow
Wallet integration через RainbowKit с поддержкой ERC-4907-aware display (показываем userOf() vs ownerOf() в NFT viewer).
Стек и инфраструктура
- Контракты: Solidity 0.8.x, Hardhat + Foundry для тестирования, OpenZeppelin базовые компоненты
- Тестирование: Foundry fuzzing на rental edge cases (expiry == current block, collateral == 0, nested rentals)
- Indexing: The Graph hosted или self-hosted Graph Node
- Backend: Node.js / TypeScript API для off-chain логики (репутация, уведомления)
- Notifications: push уведомления через EPNS (Ethereum Push Notification Service) при истечении аренды
- Networks: Ethereum mainnet + L2 (Polygon, Arbitrum) — rental платформы чувствительны к gas costs