Розробка NFT-оренди (ERC-4907)

Розробка NFT-оренди (ERC-4907)

До появи ERC-4907 NFT-оренда реалізовувалась через костилі: передавання токена в escrow-контракт, доручені off-chain угоди або кастомне маппування ролей без єдиного стандарту. Будь-який протокол, що хотів використовувати чужий NFT (гра, метавсесвіт, лендинг), мав писати інтеграцію під кожний проект окремо. EIP-4907, прийнятий у 2022 році, вирішує це чисто: додає другу адресу — user — з тимчасовими правами використання, не торкаючись власника.

Як працює ERC-4907

Стандарт розширює ERC-721 двома функціями та однією подією:

interface IERC4907 {
    event UpdateUser(uint256 indexed tokenId, address indexed user, uint64 expires);

    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);
}

Ключовий момент: user автоматично скидається в address(0) після expires. Ніякого cron-job, ніякого keeper — просто перевірка в userOf():

function userOf(uint256 tokenId) public view virtual returns (address) {
    if (uint256(_users[tokenId].expires) >= block.timestamp) {
        return _users[tokenId].user;
    }
    return address(0);
}

owner зберігає повний контроль: може передавати токен, отримувати royalty, встановлювати нового user. При трансфері токена user та expires автоматично скидаються — це захист від ситуації, коли орендатор залишається з правами після смены власника.

Архітектура rental-маркетплейсу

Сам ERC-4907 — це лише стандарт на рівні токена. Повнофункціональна система оренди вимагає rental-контракту поверх нього.

Escrow-free та escrow підходи

Escrow-free (рекомендований): власник одобряє rental-контракт через approve(), орендатор сплачує, контракт вызывает setUser() від імені власника. Токен залишається в гаманці власника весь час оренди. Ніякого custodial ризику.

Escrow: токен блокується в контракті. Потрібен лише для випадків, коли власник хочет гарантовано не використовувати токен сам протягом оренди — рідкий use case.

Структура rental-ордеру

struct RentalOrder {
    address tokenContract;
    uint256 tokenId;
    address lender;
    uint256 pricePerDay;    // у wei
    uint64 minDuration;     // у секундах
    uint64 maxDuration;
    uint64 deadline;        // до кінця коли ордер валідний
    bytes signature;        // EIP-712 підпис лендера
}

Off-chain книга ордерів (як 0x protocol) + on-chain settlement. Лендер підписує ордер off-chain — немає газових витрат на листинг. Орендатор вызывает rent(order, duration) — одна транзакція, оплата + setUser().

Автоматичне продовження та дострокове завершення

ERC-4907 не передбачає дострокового завершення оренди орендодателем — expires незмінюємий після setUser(). Для collateral-based оренди (захист від пошкодження активів у грі) потрібна додаткова логіка: депозит орендатора + можливість для орендодателя вызвать slash з on-chain доказом порушення умов.

Інтеграція в ігри та протоколи

Протоколи мають замінити перевірку ownerOf() на userOf():

// Було:
require(IERC721(nft).ownerOf(tokenId) == msg.sender, "Not owner");

// Стало:
address user = IERC4907(nft).userOf(tokenId);
require(user == msg.sender, "Not authorized user");

Для зворотної сумісності з контрактами, що не підтримують ERC-4907: wrapper-контракт, який обертає звичайний ERC-721 в ERC-4907. Власник депозирует оригинальний токен, отримує wrapped-версію з rental-функціональністю.

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

• ERC-4907 контракт (якщо колекція створюється з нуля) або wrapper для існуючої
• Rental-маркетплейс контракт: off-chain ордера з EIP-712 підписами, on-chain settlement
• Логіка ціноутворення: фіксована ціна/день, Dutch auction для зниження ціни за часом
• Frontend: листинг, пошук доступних токенів, one-click оренда
• Інтеграція з протоколом-споживачем: заміна ownerOf на userOf

Орієнтири по строкам

Тільки ERC-4907 контракт + базова оренда — 2 дні. З off-chain ордербуком, frontend та інтеграцією в ігровий контракт — 4-5 днів.