Розробка платформи токенізації нерухомості

Розроблення платформи токенізації нерухомості

Токенізація нерухомості — одна з небагатьох областей Web3, де технічна складність поступається юридичній. Смарт-контракт можна написати за тиждень. Але щоб цей контракт мав юридичну силу — потрібна правова структура, яка пов'язує on-chain токени з правами на реальний актив. Без цього зв'язку володіння токеном означає абсолютно нічого з точки зору права. Проектування починається з юридичної архітектури, а не з Solidity.

Правові моделі токенізації

SPV (Special Purpose Vehicle) модель

Найпоширеніший підхід: створюється юридична особа (SPV — ООО або аналог) спеціально для володіння конкретним об'єктом нерухомості. Токени представляють частки в цьому SPV.

Реальна нерухомість → юридично належить SPV (ООО)
SPV видає токени → токени = частки в SPV
Покупець токена → стає співвласником SPV → непрямий власник нерухомості

Переваги: юридично зрозуміла конструкція, дохід від оренди розподіляється через SPV, при продажі об'єкта — продається SPV або його активи.

Складність: кожен об'єкт потребує окремого SPV, що збільшує адміністративні витрати. Управління десятками SPV — окрема операційна задача.

REIT-токенізація

Один токен представляє частку в фонді, що володіє кількома об'єктами. Ближче до традиційного REIT, але з on-chain ліквідністю. Складніше юридично (потребує статусу інвестиційного фонду в більшості юрисдикцій), але простіше операційно при масштабуванні.

Боргові токени (Debt-backed)

Токен представляє не частку власності, а право вимоги по іпотечному займу. Нерухомість залишається у позичальника, власники токенів отримують процентний дохід. Юридично простіше (борговий інструмент, не equity), але інший профіль ризику.

Смарт-контракти: токен з compliance

Ключова вимога до токена нерухомості — обмеження передачі. На відміну від звичайного ERC-20, токени нерухомості не можна вільно передавати: тільки верифікованим KYC/AML користувачам, тільки до дозволених юрисдикцій, з дотриманням обмежень на кількість акціонерів (наприклад, у США Rule 506(b) — максимум 35 неакредитованих інвесторів).

Стандарт для security tokens — ERC-1400 (або його компонент ERC-1594 для partitioned tokens). Альтернативи: ERC-3643 (T-REX протокол), використовується більшістю європейських платформ security tokens.

Реалізація ERC-3643 / T-REX

// T-REX Identity Registry — зберігає статуси верифікації інвесторів
interface IIdentityRegistry {
    function isVerified(address _userAddress) external view returns (bool);
    function identity(address _userAddress) external view returns (IIdentity);
    function investorCountry(address _userAddress) external view returns (uint16); // ISO 3166
}

// Контракт Compliance — правила для цього токена
interface ICompliance {
    function canTransfer(
        address _from,
        address _to,
        uint256 _amount
    ) external view returns (bool);
    
    function transferred(address _from, address _to, uint256 _amount) external;
}

contract RealEstateToken is ERC20 {
    IIdentityRegistry public identityRegistry;
    ICompliance public compliance;
    
    function transfer(address to, uint256 amount) public override returns (bool) {
        // Перевіряємо compliance перед кожним transfer'ом
        require(
            identityRegistry.isVerified(to),
            "Recipient not verified"
        );
        require(
            compliance.canTransfer(msg.sender, to, amount),
            "Transfer not compliant"
        );
        
        bool success = super.transfer(to, amount);
        if (success) {
            compliance.transferred(msg.sender, to, amount);
        }
        return success;
    }
    
    // Примусовий transfer (для регуляторного забезпечення, спадщини)
    function forcedTransfer(
        address from,
        address to,
        uint256 amount
    ) external onlyOwner returns (bool) {
        // Обходить перевірку compliance — тільки для регуляторних випадків
        bool success = super.transfer(to, amount);  // Внутрішній transfer
        emit ForcedTransfer(from, to, amount);
        return success;
    }
    
    // Заморозка при regulatory hold
    mapping(address => bool) public frozen;
    
    function _beforeTokenTransfer(address from, address to, uint256 amount) 
        internal override 
    {
        require(!frozen[from], "Sender frozen");
        require(!frozen[to], "Recipient frozen");
    }
}

Контракт Compliance: обмеження за юрисдикціями

contract RealEstateCompliance {
    IIdentityRegistry public identityRegistry;
    
    // Заборонені юрисдикції (коди країн ISO 3166)
    mapping(uint16 => bool) public restrictedCountries;
    
    // Обмеження кількості акціонерів (для Reg D, Rule 506)
    uint256 public maxHolders;
    uint256 public currentHolders;
    mapping(address => bool) public isHolder;
    
    // Максимальна частка власності одного інвестора (anti-concentration)
    uint256 public maxOwnershipPercent; // у basis points
    IERC20 public token;
    
    function canTransfer(address from, address to, uint256 amount) 
        external view returns (bool) 
    {
        // Перевіряємо юрисдикцію одержувача
        uint16 country = identityRegistry.investorCountry(to);
        if (restrictedCountries[country]) return false;
        
        // Перевіряємо лімітку власників
        if (!isHolder[to] && currentHolders >= maxHolders) return false;
        
        // Перевіряємо концентрацію
        uint256 newBalance = token.balanceOf(to) + amount;
        if (newBalance * 10000 / token.totalSupply() > maxOwnershipPercent) return false;
        
        return true;
    }
    
    function transferred(address from, address to, uint256 amount) external {
        if (!isHolder[to] && token.balanceOf(to) > 0) {
            isHolder[to] = true;
            currentHolders++;
        }
        if (token.balanceOf(from) == 0 && isHolder[from]) {
            isHolder[from] = false;
            currentHolders--;
        }
    }
}

Розподіл доходу від оренди

Регулярні виплати власникам токенів — ключова функція для інвесторів. Розподіл через on-chain механізм:

contract RentalDistribution {
    IERC20 public propertyToken;
    IERC20 public paymentToken;  // USDC
    
    uint256 public totalDistributed;
    mapping(address => uint256) public lastClaimedDistributed;
    
    // Механізм O(1) на основі накопленого дивіденду на частку
    uint256 public accumulatedPerShare;
    uint256 private constant PRECISION = 1e18;
    
    function distributeRental(uint256 amount) external onlyOwner {
        require(propertyToken.totalSupply() > 0, "No token holders");
        paymentToken.safeTransferFrom(msg.sender, address(this), amount);
        
        accumulatedPerShare += (amount * PRECISION) / propertyToken.totalSupply();
        totalDistributed += amount;
        
        emit RentalDistributed(amount);
    }
    
    function pendingRewards(address holder) public view returns (uint256) {
        uint256 holderBalance = propertyToken.balanceOf(holder);
        uint256 accumulated = accumulatedPerShare - lastClaimedDistributed[holder];
        return (holderBalance * accumulated) / PRECISION;
    }
    
    function claimRewards() external nonReentrant {
        uint256 pending = pendingRewards(msg.sender);
        require(pending > 0, "Nothing to claim");
        
        lastClaimedDistributed[msg.sender] = accumulatedPerShare;
        paymentToken.safeTransfer(msg.sender, pending);
        
        emit RewardsClaimed(msg.sender, pending);
    }
}

Проблема цієї моделі: якщо користувач купив токени після початку розподілу, він повинен "синхронізувати" свій lastClaimedDistributed при transfer'і. Це робиться в _beforeTokenTransfer — при отриманні токенів накопичені награду автоматично вилучаються або встановлюється поточний accumulatedPerShare.

Оцінка вартості та цінові оракули

Вартість токена пов'язана з вартістю нерухомості. На відміну від DeFi-активів, нерухомість не має on-chain ціни. Варіанти:

Періодична оцінка: ліцензований оцінювач раз на квартал надає оцінку, яка записується on-chain через admin функцію або multisig. Найпростіший підхід, але централізований.

Chainlink Any API: оракул отримує оцінку з API агрегатора ринкових даних (Zillow, Zoopla API) та публікує on-chain. Більш автоматизовано, але залежить від якості даних.

NAV-based pricing: для REIT-подібних фондів Net Asset Value розраховується on-chain з суми оцінок усіх об'єктів. Корисно для вторинного ринку.

Маркетплейс та ліквідність

Вторинний ринок для security tokens потребує окремого compliance-aware DEX або OTC платформи. Звичайний Uniswap не підходить — немає способу перевірити KYC при swap'і.

Варіанти:

• Регульований маркетплейс: ATS (Alternative Trading System) у США, MTF в EU. Потребує ліцензії
• Permissioned AMM: кастомний AMM з перевіркою identity registry перед swap'ом. Може працювати на L2 для зниження витрат
• P2P OTC: смарт-контракт для OTC діл з атомарним swap'ом та перевіркою compliance

Управління (Governance)

Великі рішення щодо об'єкта (ремонт, продаж, зміна управління) потребують голосування власників токенів. On-chain governance через Snapshot (gas-free voting з on-chain виконанням через SafeSnap/Reality.eth) або Governor Bravo-based контракт:

contract PropertyGovernance is Governor, GovernorSettings, GovernorVotes {
    constructor(IVotes _token)
        Governor("PropertyDAO")
        GovernorSettings(
            1,      // voting delay: 1 блок
            50400,  // voting period: ~7 днів
            1e18    // quorum: 1% від пропозиції (залежить від totalSupply)
        )
        GovernorVotes(_token)
    {}
    
    function quorum(uint256) public pure override returns (uint256) {
        return 100e18; // мінімальний кворум для ухвалення рішень
    }
}

Governance-рішення з фінансовими наслідками повинні проходити через Timelock — затримка 48–72 години для можливості незгідних інвесторів вийти до виконання рішення.