Розробка 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, який став галузевим стандартом.