Розробка RWA платформи: токенізація реальних активів на блокчейні

Розробка RWA платформи: токенізація реальних активів на блокчейні

Токенізація реальних активів (RWA) — це перенесення права власності на нерухомість, боргові інструменти або сировину в блокчейн-токени. Ми стикалися з ситуаціями, коли команди витрачали пів року на розробку, а потім виявляли, що їхні смарт-контракти не проходять compliance через відсутність on-chain KYC. У цій статті розбираємо архітектуру RWA-платформ, яка працює в production і успішно проходить audit. Наша команда має багаторічний досвід у блокчейн-розробці, понад 50 проєктів у DeFi та токенізації. Ми проєктуємо системи, де юридичні обмеження визначають технічні рішення, а не навпаки.

Класи активів та їх специфіка

Кожен тип RWA вимагає свого підходу до токенізації, верифікації та compliance.

Боргові інструменти (Treasury bills, corporate bonds, кредити). Найактивніший сегмент: BlackRock BUIDL ($500M+), Ondo Finance (USDY, OUSG), Maple Finance. Актив — фіксована доходність. Токен представляє право на періодичні виплати та повернення номіналу. Ключові питання: як передати право на виплати on-chain, як забезпечити KYC/AML (Reg D/S для США, AIFMD для Європи).

Нерухомість. Найскладніший клас. Право власності регулюється національним земельним законодавством, реєструється в державних реєстрах. Повна токенізація (зміна власника = on-chain транзакція) можлива лише в обмеженій кількості юрисдикцій (ОАЕ починає, деякі штати США експериментують). Практичний підхід — SPV (Special Purpose Vehicle): компанія володіє нерухомістю, токени представляють частки в компанії.

Сировина та фізичні активи (золото, нафта, commodities). Актив зберігається у ліцензованого кастодіана, токен представляє право на physical delivery або cash settlement. Paxos Gold (PAXG), Tether Gold (XAUT).

Акції непублічних компаній. Equity токенізація — найбільш регуляторно чутливий сегмент у більшості юрисдикцій.

Як забезпечити compliance в RWA токенах?

Ключовий елемент — стандарт ERC-3643 (T-REX Protocol), розроблений Tokeny. Він включає Identity Registry, Compliance Contract і Token Contract. На відміну від звичайного ERC-20, тут кожен transfer проходить перевірку обох сторін: верифікація on-chain identity, юрисдикція, accredited investor status.

contract AssetToken is ERC3643 {
    IIdentityRegistry public identityRegistry;
    ICompliance public compliance;

    function transfer(address to, uint256 amount) public override returns (bool) {
        // Проверка identity обох сторін
        require(identityRegistry.isVerified(msg.sender), "Sender not verified");
        require(identityRegistry.isVerified(to), "Recipient not verified");

        // Compliance перевірка (обмеження по юрисдикції, ліміти, lock-up періоди)
        require(compliance.canTransfer(msg.sender, to, amount), "Transfer not compliant");

        return super.transfer(to, amount);
    }

    // Force transfer — для court orders та регуляторних вимог
    function forcedTransfer(address from, address to, uint256 amount) external onlyAgent returns (bool) {
        _transfer(from, to, amount);
        emit ForcedTransfer(from, to, amount);
        return true;
    }

    // Recovery при втраті ключів
    function recoveryAddress(address lostWallet, address newWallet, address onchainId) external onlyAgent {
        require(identityRegistry.contains(lostWallet), "Not registered");
        uint256 balance = balanceOf(lostWallet);
        _transfer(lostWallet, newWallet, balance);

        // Оновлення identity registry
        identityRegistry.updateIdentity(lostWallet, newWallet, onchainId);
    }
}

Функції forcedTransfer та recoveryAddress відсутні в стандартному ERC-20. Вони необхідні для відповідності реальним правовим вимогам: суд може зобов'язати заморозити або примусово перевести активи.

Identity та KYC шар

У T-REX архітектурі кожен participant має on-chain Identity (ONCHAINID — ERC-734/735). Це смарт-контракт, який зберігає claims — верифіковані твердження про власника (KYC статус, юрисдикція, accredited investor status).

interface IIdentityRegistry { // Перевірка, що адреса пройшла KYC і може тримати токени даної юрисдикції
    function isVerified(address _userAddress) external view returns (bool); // Країна проживання користувача (з KYC документів)
    function investorCountry(address _userAddress) external view returns (uint16);
}

// Compliance: перевірка обмежень по юрисдикції
contract JurisdictionCompliance is ICompliance {
    mapping(uint16 => bool) public restrictedCountries; // ISO 3166-1 numeric

    function canTransfer(address _from, address _to, uint256) external view returns (bool) {
        uint16 fromCountry = identityRegistry.investorCountry(_from);
        uint16 toCountry = identityRegistry.investorCountry(_to);
        return !restrictedCountries[fromCountry] && !restrictedCountries[toCountry];
    }
}

Oracle для pricing та yield distribution

Для токенів з фіксованою доходністю (Treasury bills, bonds) — автоматичне розподілення yield. Chainlink для on-chain ціни базового активу, off-chain trigger для yield payments.

contract YieldDistributor {
    IERC20 public immutable token;
    IERC20 public immutable stablecoin; // USDC
    AggregatorV3Interface public priceFeed;
    uint256 public lastDistribution;
    uint256 public annualYieldBps; // yield в basis points (500 = 5%)

    function distributeYield() external {
        require(block.timestamp >= lastDistribution + 1 days, "Too soon");
        uint256 totalSupply = token.totalSupply();
        // Денний yield = annualYield / 365
        uint256 dailyYield = (totalSupply * annualYieldBps) / (10000 * 365);
        // Поповнення контракту stablecoin з treasury повинно відбуватися заздалегідь
        require(stablecoin.balanceOf(address(this)) >= dailyYield, "Insufficient USDC");
        // Розподіл через snapshot — всі власники на момент snapshot
        bytes32 snapshotId = _snapshot(); // ERC-20Snapshot
        _distributeToSnapshot(snapshotId, dailyYield);
        lastDistribution = block.timestamp;
    }
}

Для ефективного розподілу великій кількості власників — Merkle distribution (один snapshot → Merkle tree → кожен власник клеймить самостійно) замість push-розподілу.

Чому стандарт ERC-3643 став промисловим стандартом?

ERC-3643 у 2 рази швидше у впровадженні, ніж ERC-1400, за рахунок модульної архітектури. У таблиці нижче — ключові відмінності:

Як налаштувати yield distribution для RWA токенів?

1. Задеплоїти контракт токена (ERC-3643) з підтримкою snapshot (ERC-20Snapshot).
2. Розгорнути YieldDistributor з прив'язкою до токена та stablecoin.
3. Встановити annualYieldBps відповідно до умов випуску.
4. Налаштувати off-chain job для поповнення контракту stablecoin з treasury.
5. Включити функцію distributeYield за розкладом (наприклад, раз на день через keeper).
6. Налаштувати Merkle root для claim: кожен власник викликає claim з proof.

SPV та юридичний шар

Для більшості юрисдикцій токенізація реального активу відбувається через наступний ланцюжок:

Фізичний актив (нерухомість, облігації)
↓ передається в SPV/LLC (зареєстрована компанія)
↓ компанія випускає Securities (equity або debt notes)
↓ права токенізуються On-chain токени (ERC-3643)
↓ торгуються на Regulated marketplace або DeFi з compliance

Смарт-контракт повинен відображати цю структуру: в документах токена (ERC-1643 document management) зберігаються посилання на юридичні документи — Operating Agreement SPV, проспект емісії, аудиторські звіти.

// ERC-1643: зберігання посилань на юридичні документи
function setDocument(bytes32 _name, string calldata _uri, bytes32 _documentHash) external onlyOwner {
    // _name: "SUBSCRIPTION_AGREEMENT", "OPERATING_AGREEMENT", "AUDIT_REPORT_CURRENT"
    // _uri: IPFS CID або HTTPS посилання
    // _documentHash: keccak256 файлу для верифікації цілісності
    _setDocument(_name, _uri, _documentHash);
}

Вторинний ринок та ліквідність

Одна з головних ціннісних пропозицій RWA токенізації — ліквідність для традиційно неліквідних активів. Але тут регуляторні обмеження:

• Restriction periods. Lock-up після initial offering (типово 6–12 місяців для Reg D offerings у США). Реалізується через compliance module з перевіркою timestamp покупки.
• Accredited investor only trading. На вторинному ринку можуть торгувати лише verified accredited investors. Compliance hook не пропустить transfer до неверифікованої адреси.
• ATS (Alternative Trading System). У США вторинна торгівля security токенами вимагає роботи через ліцензованого ATS. Ряд платформ (tZero, Securitize Markets) мають ATS ліцензію.

Для DeFi-ліквідності (AMM пули з RWA токенами) — compliance-aware AMM: кожен swap проходить перевірку identity та compliance обох сторін. Проєкти типу Centrifuge (RWA в MakerDAO), Ondo Finance інтегрують RWA в DeFi через спеціальні пули з whitelist.

Redemption та корпоративні події

Redemption — погашення токена, користувач отримує базовий актив або його cash-еквівалент. Має бути вбудовано в контракт з можливістю:

• Primary redemption у емітента (через KYC процес)
• Secondary redemption через AMM або order book

Корпоративні події (dividends, stock splits, rights offerings для equity токенів): смарт-контракт повинен підтримувати mechanics для розподілу додаткових токенів або стейблкоїнів пропорційно holdings на дату record date.

Процес роботи над RWA платформою

Ми використовуємо покроковий підхід з паралельною юридичною та технічною роботою з самого початку.

Загальний термін технічної розробки — 4–6 місяців. Регуляторний процес може зайняти від 1 до 12 місяців. Ми керуємо ризиками за допомогою спринтів та щотижневих демо.

Що входить у розробку RWA платформи

• Документація: архітектурний опис, специфікація смарт-контрактів, керівництво з аудиту.
• Вихідні коди: смарт-контракти, скрипти деплою, тести.
• Інтеграція з KYC провайдером та юридичним шаром.
• Запуск у тестовій мережі, потім у mainnet.
• ACCESS до приватного репозиторію та CI/CD пайплайну.
• Навчання команди замовника роботі з системою.
• Гарантія: 6 місяців підтримки після запуску.

Понад 50 проєктів, сумарний обсяг токенізації перевищує $150M. Економія на юридичних витратах до 50% за рахунок автоматизації compliance. Замовте консультацію по вашому проєкту — ми розповімо, як токенізувати активи з compliance і пройти аудит.

ERC-3643: Permissioned Token Standard — визначає токен з compliance hooks, який став галузевим стандартом.