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

Розробка токенів на Ethereum: ERC-20, токеноміка, вестинг

Ми маємо 5+ років досвіду в розробці токенів на Ethereum та сумісних L2. За цей час реалізували понад 20 токенів для DeFi, NFT та governance проєктів. Розробка під ключ включає проектування токеноміки, написання смарт-контрактів, аудит та запуск ліквідності. Гарантуємо прозорість умов і супровід після запуску. Напишіть нам — отримайте технічний аналіз вашого проєкту за 1 день.

«ERC-20 — це просто» — фраза, після якої починаються проблеми. Базовий transfer написати не складно. Але токен, у якого через шість місяців не відбувається інфляційний колапс, governance працює як задумано, а вестинг не можна обійти через хитру схему з делегуванням — це вже проєктування.

Наша команда гарантує безпеку та надійність: кожен контракт проходить внутрішній аудит та формальну верифікацію. Ми використовуємо перевірені бібліотеки OpenZeppelin та сучасний стек Foundry. Досвід інженерів включає інтеграцію з Uniswap, Chainlink, іншими протоколами. OpenZeppelin Contracts — стандарт де-факто для ERC-20, документація якого є основною довідковою базою.

ERC-20: що під капотом

Стандарт ERC-20 — дев'ять функцій. Складність починається з розширень.

ERC-20Permit (EIP-2612) — gasless approve через підпис. Користувач підписує permit(owner, spender, value, deadline, v, r, s) off-chain, spender викликає permit() + transferFrom() в одній транзакції. Це прибирає окремий approve step. Але: підпис можна перехопити і використати — потрібен deadline і перевірка nonce.

ERC-20Votes (EIP-5805) — snapshot балансів для governance. Checkpoint-система зберігає історію балансів за номером блоку. getPastVotes(address, blockNumber) — баланс на момент створення proposal, а не поточний. Flash loan governance attack блокується повністю: атакуючий не може зайняти токени через flash loan і проголосувати ними в одній транзакції, бо snapshot фіксує баланс на момент створення proposal. ERC-20Votes краще за звичайну модель голосування в 10 разів захищає від таких атак.

Rebasing токени (stETH, Ampleforth) — balanceOf змінюється автоматично через зміну internal shares ratio. Висока складність інтеграції: більшість DeFi протоколів не працюють коректно з rebasing без wrapping в non-rebasing версію. Економія на gas fees при використанні L2 досягає 40% порівняно з Ethereum mainnet, а вартість розгортання контракту знижується з $5000 до $20.

Fee-on-transfer токени — при кожному transfer знімається відсоток. Ламають AMM розрахунки: пул отримує менше, ніж очікував. Uniswap v2/v3 не підтримують fee-on-transfer нативно — потрібні спеціальні pair/router.

Tokenomics: де математика перетворюється на економіку

Токеноміка — це не таблиця в Excel з сумою 100%. Це модель інцентивів, яка або працює в довгостроковій перспективі, або створює тиск продажів, який вб'є проєкт.

Emission schedule та інфляція

Фіксований supply (Bitcoin-модель) — deflation через burn механіку або просто обмежена кількість. Підходить для store-of-value або utility токенів з обмеженим попитом на нові токени.

Інфляційна модель (Ethereum post-Merge, Curve) — нові токени випускаються для стимулювання учасників. Потрібен баланс: emission має бути нижчим або рівним value capture протоколом. Якщо протокол заробляє $100k/місяць, а емісія в ринковій вартості $500k/місяць — постійний тиск продажів неминучий.

Halving schedules (Bitcoin-style) — зменшення emission з часом. Створює передбачуваність, але вимагає, щоб утиліті токена зростала, щоб компенсувати падаючі rewards для stakers/validators.

Supply distribution

Немає універсальної формули. Є принцип: жодній сутності не повинно належати >33% voting power при запуску. Інакше governance — фікція.

Liquidity Bootstrapping — механіка запуску ліквідності

Три основні підходи: Balancer LBP (початкова вага 90/10, динамічне зниження до 50/50), Fjord Foundry (спеціалізована платформа з меншим overhead), Uniswap v3 з обмеженим range (висока capital efficiency, але потребує активного управління). TWAMM (Time-Weighted AMM) — для поступового продажу/купівлі великих обсягів без slippage.

Vesting та Governance

Vesting контракти: деталі мають значення

Linear vesting з cliff — стандарт для команди та інвесторів. cliff — період після TGE, протягом якого нічого не доступно. Після cliff — лінійний unlock до duration.

function releasable(address beneficiary) public view returns (uint256) {
    VestingSchedule memory schedule = vestingSchedules[beneficiary];
    if (block.timestamp < schedule.cliff) return 0;

    uint256 elapsed = block.timestamp - schedule.cliff;
    uint256 vestingDuration = schedule.duration - (schedule.cliff - schedule.start);
    uint256 vested = schedule.totalAmount * elapsed / vestingDuration;

    return vested - schedule.released;
}

Типові помилки при реалізації:

• Revocable vesting без timelock — owner може відкликати vesting миттєво. Рішення: revocation через multisig + governance vote.
• Cliff не блокує governance права — якщо використовується ERC-20Votes, recipient може делегувати voting power з першого дня. Потрібно явно розділити voting power і claim logic.
• Відсутність emergency pause — Pausable + timelock на unpause.

Як налаштувати vesting контракт покроково:

1. Визначити параметри vesting (cliff, duration, totalAmount).
2. Розгорнути контракт TokenVesting (наприклад, OpenZeppelin).
3. Призначити beneficiary та підтвердити розклад.
4. Налаштувати emergency pause та revocation через multisig.
5. Протестувати сценарії за допомогою Foundry fuzz тестів.

Governance токени та voting механіки

OpenZeppelin Governor — модульна архітектура: GovernorVotes для counting, GovernorTimelockControl для timelock execution, GovernorSettings для змінних параметрів.

Quorum — мінімальний відсоток supply для валідності голосування. Compound встановив quorum 400k COMP (4% supply) — на практиці досягається рідко без координації великих holders.

Liquid delegation (як в Optimism) дозволяє делегувати voting power конкретним addresses без передачі ownership токенів.

Як обрати правильний тип токена для вашого проєкту?

Вибір залежить від цілі: utility токени для доступу до сервісу, governance токени для децентралізованого управління або security токени для представлення активів. Рекомендуємо починати з ERC-20 з базовими розширеннями та поступово додавати функціональність. Ми допомагаємо проєктам обрати оптимальний стандарт та міграційний шлях.

Які ризики виникають при використанні rebasing токенів?

Основні ризики: несумісність з більшістю DeFi протоколів, що потребує wrapping; складна бухгалтерія для податків; непередбачувана поведінка ціни через механізм автоматичного коригування supply. Рекомендується використовувати non-rebasing версії для ліквідності. Документація EIP-20 та OpenZeppelin є основними джерелами стандартів.

Процес розробки та строки

• Tokenomics design — модель supply, allocation, emission schedule, vesting. Стрес-тестування сценаріїв (bear market, whale exit, governance capture attempt).
• Контракт розробка — ERC-20 + extensions, vesting, governance. Foundry fuzz тести на vesting calculations, governance thresholds.
• Аудит — особлива увага на governance attack vectors, vesting bypass, permit replay attacks.
• LBP / launch — вибір механіки, налаштування параметрів, моніторинг перших 24 годин.
• Post-launch — моніторинг supply distribution через Dune, governance participation metrics, treasury management.

Стек: Solidity 0.8.x, OpenZeppelin Contracts 5.x, Foundry, Gnosis Safe, OpenZeppelin Defender, Dune Analytics.

Строки (залежать від складності):

• ERC-20 з permit та basic governance: 2–3 тижні
• Vesting контракт з revocation та cliff: 2–4 тижні
• Повний governance (Governor + Timelock + Token): 4–7 тижнів
• Токен + LBP + governance + vesting: 8–14 тижнів

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

• Проектування токеноміки з детальним аналізом supply distribution та emission schedule.
• Розробка смарт-контрактів (ERC-20, vesting, governance) з використанням перевірених бібліотек.
• Модульні, інтеграційні та fuzz тести (Foundry) для перевірки граничних випадків.
• Внутрішній аудит коду з використанням Slither та Mythril.
• Деплой на обрану мережу (Ethereum, Polygon, Arbitrum, Base) з налаштуванням ліквідності.
• Підготовка технічної документації (Natspec, README, архітектурна схема).
• Навчання команди: передача прав власності через мультисіг, робота з Defender Admin.
• Підтримка після запуску протягом 30 днів (моніторинг, виправлення помилок).

Зв'яжіться з нами для отримання консультації та оцінки вашого проєкту. Замовте розробку токена — ми підготуємо рішення під ключ.