Розробка системи дробового володіння активами

Розроблення системи фракціонального володіння активами

Завдання: є актив вартістю $5M — комерційна нерухомість, твір мистецтва, портфель приватного equity. Один власник купити не може або не хоче. Потрібно розбити право власності на частини та продати сотням інвесторів. Кожен інвестор повинен мати верифіковані права, отримувати свою долю доходу, та мати можливість продати свою частку на вторинному ринку. Це і є фракціональне володіння — і технічно це несумірно складніше, ніж просто "видати токени".

Правова структура: токен без юридичного забезпечення — ничего

Перше, що потрібно зробити до написання строчки кода — визначити правову оболонку. Токен сам по собі не є правом власності на нерухомість або інший актив. Потрібний юридичний зв'язок між on-chain токеном та off-chain активом.

Три поширені структури:

SPV (Special Purpose Vehicle) — юридична особа володіє активом, інвесторі володіють токенами, що представляють частку в SPV. Підходить для нерухомості в більшості юрисдикцій. SPV може бути LLC, Ltd, LP. Токени — security tokens, потребують ліцензування.

Trust structure — актив у трасті, beneficiary rights токенізовані. Популярно для арт-ринку та предметів колекціонування. Trustee управляє активом, бенефіціари отримують дохід.

DAO LLC (Вайоминг, Маршаллові острови) — DAO має юридичний статус LLC. Governance токени = членські права. Інноваційно, але судова практика поки обмежена.

Без правової структури інвестори купують токен, який представляє обіцянку, а не юридично обов'язуюче право. Це або fraud, або worthless instrument при конфлікті.

Архітектура контрактів

Реєстр активів

contract AssetRegistry {
    enum AssetType { RealEstate, Art, PrivateEquity, Commodity, Other }
    enum AssetStatus { Pending, Active, Paused, Liquidating, Closed }
    
    struct Asset {
        bytes32 assetId;
        AssetType assetType;
        AssetStatus status;
        string legalEntityId;          // ID юридичної особи (SPV/Trust)
        string documentationURI;       // IPFS CID юридичних документів
        bytes32 documentationHash;     // SHA-256 хеш для верифікації
        uint256 totalValuation;        // поточна оцінка в USD (6 decimals)
        uint256 totalShares;           // загальне кількість часток
        address fractionalToken;       // ERC-20 токен частки
        address distributionContract;  // контракт для виплат
        uint256 createdAt;
        uint256 lastValuationAt;
    }
    
    mapping(bytes32 => Asset) public assets;
    
    // Тільки верифіковані asset managers можуть реєструвати
    function registerAsset(
        bytes32 assetId,
        AssetType assetType,
        string calldata legalEntityId,
        string calldata documentationURI,
        bytes32 documentationHash,
        uint256 totalValuation,
        uint256 totalShares
    ) external onlyAssetManager returns (address fractionalToken) {
        require(assets[assetId].createdAt == 0, "Asset already exists");
        
        // Деплоюємо фракціональний токен
        fractionalToken = _deployFractionalToken(assetId, totalShares);
        
        // Деплоюємо контракт дистрибуції
        address distributionContract = _deployDistribution(assetId, fractionalToken);
        
        assets[assetId] = Asset({
            assetId: assetId,
            assetType: assetType,
            status: AssetStatus.Pending,
            legalEntityId: legalEntityId,
            documentationURI: documentationURI,
            documentationHash: documentationHash,
            totalValuation: totalValuation,
            totalShares: totalShares,
            fractionalToken: fractionalToken,
            distributionContract: distributionContract,
            createdAt: block.timestamp,
            lastValuationAt: block.timestamp
        });
        
        emit AssetRegistered(assetId, fractionalToken, msg.sender);
        return fractionalToken;
    }
}

Фракціональний токен: ERC-20 з обмеженнями передачи

Це не звичайний ERC-20. Security tokens потребують обмежень передачі — не можна продавати неверифікованим адресам. Стандарт ERC-1400 (Security Token Standard) або простіший ERC-20 з whitelist.

contract FractionalToken is ERC20, ERC20Permit {
    ITransferValidator public transferValidator;
    bytes32 public immutable assetId;
    
    // Максимум 1800 власників (ліміт US Reg D Rule 504)
    uint256 public constant MAX_HOLDERS = 1800;
    uint256 public holderCount;
    mapping(address => bool) private _isHolder;
    
    modifier onlyCompliantTransfer(address from, address to, uint256 amount) {
        require(
            transferValidator.canTransfer(from, to, assetId, amount),
            "Transfer not compliant"
        );
        _;
    }
    
    function transfer(address to, uint256 amount) 
        public 
        override 
        onlyCompliantTransfer(msg.sender, to, amount) 
        returns (bool) 
    {
        _updateHolderCount(msg.sender, to, amount);
        return super.transfer(to, amount);
    }
    
    function _updateHolderCount(address from, address to, uint256 amount) internal {
        bool toIsNewHolder = !_isHolder[to] && amount > 0;
        bool fromBecomesEmpty = balanceOf(from) == amount;
        
        if (toIsNewHolder) {
            require(holderCount < MAX_HOLDERS, "Max holders reached");
            _isHolder[to] = true;
            holderCount++;
        }
        if (fromBecomesEmpty && from != address(0)) {
            _isHolder[from] = false;
            holderCount--;
        }
    }
}

TransferValidator перевіряє:

1. Обидва адреси пройшли KYC та мають статус accredited investor (для US Reg D)
2. Жоден не у OFAC SDN списку
3. Не порушуються lock-up періоди (зазвичай 12 місяців для Reg D)
4. Кількість власників не перевищує лімітку

Дистрибуція доходу: паттерн ERC-4626 vault

Актив генерує дохід: рента від нерухомості, дивіденди від equity. Потрібно розподіляти пропорційно без О(N) ітерації.

Рішення — dividend-per-share tracker (алгоритм з dividend-bearing stocks):

contract DistributionVault {
    IERC20 public immutable fractionalToken;
    IERC20 public immutable distributionToken; // USDC
    
    uint256 public dividendPerShare;           // накопленний дивіденд на частку (масштабований на 1e18)
    mapping(address => uint256) public lastDividendPerShare;
    mapping(address => uint256) public pendingDividends;
    
    // Вызывается коли поступає новий дохід (рента, дивіденди)
    function distributeIncome(uint256 amount) external onlyAssetManager {
        distributionToken.transferFrom(msg.sender, address(this), amount);
        
        uint256 totalShares = fractionalToken.totalSupply();
        require(totalShares > 0, "No shares");
        
        // Збільшуємо dividendPerShare пропорційно
        dividendPerShare += (amount * 1e18) / totalShares;
        
        emit IncomeDistributed(amount, dividendPerShare);
    }
    
    // Накопичуємо pending дивіденди при кожному русі токена
    function _updateDividend(address account) internal {
        uint256 owed = (
            (dividendPerShare - lastDividendPerShare[account]) 
            * fractionalToken.balanceOf(account)
        ) / 1e18;
        
        pendingDividends[account] += owed;
        lastDividendPerShare[account] = dividendPerShare;
    }
    
    // Власник вилучає накопичені дивіденди
    function claimDividends() external {
        _updateDividend(msg.sender);
        uint256 amount = pendingDividends[msg.sender];
        require(amount > 0, "Nothing to claim");
        
        pendingDividends[msg.sender] = 0;
        distributionToken.transfer(msg.sender, amount);
        
        emit DividendsClaimed(msg.sender, amount);
    }
}

Алгоритм O(1) per claim — неважливо скільки власників. Hook в фракціональному токені: при кожному transfer вызывает _updateDividend для обох сторін. Паттерн з Synthetix staking rewards, battle-tested на мільярдах TVL.

Вторинний ринок

Інтеграція з DEX та orderbook

Для торгівлі фракціональними токенами потрібен комплаєнтний DEX — звичайний Uniswap не перевіряє KYC покупців.

Варіанти:

Permissioned AMM — форк Uniswap v3 з whitelist перевіркою у swap hook:

// Uniswap v4 Hook для transfer compliance
contract ComplianceHook is BaseHook {
    ITransferValidator public validator;
    
    function beforeSwap(
        address sender,
        PoolKey calldata key,
        IPoolManager.SwapParams calldata params,
        bytes calldata
    ) external override returns (bytes4) {
        // Визначаємо: sender купує або продає токен
        address buyer = params.zeroForOne ? sender : sender; // спрощення
        bytes32 assetId = poolToAsset[PoolId.toId(key)];
        
        require(
            validator.isCompliantBuyer(buyer, assetId),
            "Buyer not compliant"
        );
        return BaseHook.beforeSwap.selector;
    }
}

OTC orderbook — off-chain matching з on-chain settlement. Ефективніше для неліквідних активів, де AMM мав би високий slippage.

tZERO, RealT, Securitize Markets — готові регульовані торговельні платформи для security tokens. Інтегруємо свої токени там замість побудови власного DEX.

Оцінка активів (оновлення оцінок)

Для real estate та інших non-liquid активів потрібні періодичні переоцінки. Впливають на:

• Відображення вартості портфеля інвестора
• Розрахунок collateral ratio якщо токени використовуються у DeFi lending
• Регуляторну звітність

contract ValuationOracle {
    struct Valuation {
        uint256 value;           // USD, 6 decimals
        uint256 timestamp;
        address appraiser;       // ліцензований оцінювач
        bytes32 reportHash;      // IPFS hash звіту про оцінку
    }
    
    mapping(bytes32 => Valuation[]) public valuationHistory;
    mapping(address => bool) public certifiedAppraisers;
    
    // Мінімум 2 з 3 сертифікованих оцінювачів повинні погодитися
    // для оновлення оцінки — захист від маніпуляції
    function submitValuation(
        bytes32 assetId,
        uint256 value,
        bytes32 reportHash
    ) external onlyCertifiedAppraiser {
        pendingValuations[assetId].push(Valuation({
            value: value,
            timestamp: block.timestamp,
            appraiser: msg.sender,
            reportHash: reportHash
        }));
        
        if (_hasConsensus(assetId)) {
            _finalizeValuation(assetId);
        }
    }
}

Технологічний стек

Регуляторні вимоги за юрисдикціями

Розклад

Реалістичний розклад до першого токенізованого активу на платформі: 9–14 місяців. Більшість затримок — не розроблення, а юридична due diligence, регуляторне узгодження та робота з кастодіанами.