Професійна розробка платформи токенізації активів на ERC-3643

Професійна розробка платформи токенізації активів на ERC-3643

Клієнт з портфелем комерційної нерухомості в Берліні хотів випустити 5000 токенів для фракційного продажу. Перша ідея — ERC-20 з білим списком — розсипалася при першій же перевірці регулятора: відсутність on-chain identity, немає механізму forced transfer для заморозки активів, немає модуля корпоративних дій. Довелося перебудовувати всю архітектуру на ERC-3643. За 7 років ми зробили 15+ таких платформ — для нерухомості, боргових інструментів, товарних запасів. Кожен проєкт проходив повний цикл: юридична структура, смарт-контракти, інтеграція KYC, запуск вторинного ринку.

Технічна частина — лише вершина. 60–70% зусиль йде на compliance: KYC/AML, юрисдикційні обмеження, корпоративні дії. Ми використовуємо стек ERC-3643 (T-REX) з identity-шаром ONCHAINID. Це дає економію до 30% на gas-операціях з compliance порівняно з ERC-1400. Стандарт описаний в EIP-3643.

Типи активів різні — нерухомість, акції SPV, боргові інструменти, витвори мистецтва, інтелектуальна власність — але компоненти платформи універсальні.

Чому ERC-3643 — стандарт для RWA?

Звичайний ERC-20 не підходить для регульованих активів. Потрібні спеціалізовані стандарти. ERC-1400 (Security Token Standard) — розширення ERC-20 з transfer restrictions, forced transfers, document management. Розроблений під вимоги securities регуляторів.

// ERC-1400 ключові інтерфейси interface IERC1400 is IERC20 { function canTransferByPartition( bytes32 partition, address from, address to, uint256 value, bytes calldata data ) external view returns (byte, bytes32, bytes32); function transferByPartition( bytes32 partition, address to, uint256 value, bytes calldata data ) external returns (bytes32); function operatorTransferByPartition( bytes32 partition, address from, address to, uint256 value, bytes calldata data, bytes calldata operatorData ) external returns (bytes32); function getDocument(bytes32 name) external view returns (string memory, bytes32); } 

ERC-3643 (T-REX) — більш сучасний, розроблений Tokeny Solutions. Він у 2 рази простіший в інтеграції за ERC-1400 та вигідніший по газу: до 30% економії на операціях з compliance. Включає identity layer (ONCHAINID) та automated compliance checks. Складання смарт-контрактів у Foundry в 3 рази швидше, ніж у Hardhat — прискорення циклів тестування та деплою.

// T-REX compliance check приклад contract TokenCompliance { IIdentityRegistry public identityRegistry; ICompliance public compliance; function _beforeTokenTransfer( address from, address to, uint256 amount ) internal { if (from != address(0) && to != address(0)) { require( identityRegistry.isVerified(to), "Recipient identity not verified" ); require( compliance.canTransfer(from, to, amount), "Transfer not compliant" ); } } } 

ERC-1155 підходить для фракційних активів, коли один актив ділиться на кілька видів прав (наприклад, будівля з різними типами приміщень або витвір мистецтва з різними правами використання).

Як працює on-chain KYC/AML?

Кожен власник токенів регульованого активу має бути верифікований. On-chain identity — складніше ніж просто mapping адреса → bool. Використовуємо стандарт ONCHAINID (ERC-734/735). Провайдер KYC (Sumsub, Fractal, Identix) проводить верифікацію, видає claim з підписом. Claim записується в ONCHAINID контракт користувача. При спробі transfer токена — compliance модуль перевіряє наявність потрібних claims.

// Identity контракт (один на користувача) interface IIdentity { function getClaim(bytes32 claimId) external view returns ( uint256 topic, uint256 scheme, address issuer, bytes memory signature, bytes memory data, string memory uri ); function addClaim( uint256 topic, uint256 scheme, address issuer, bytes memory signature, bytes memory data, string memory uri ) external returns (bytes32 claimId); } // Claim Topics для securities uint256 constant KYC_CLAIM = 1; uint256 constant AML_CLAIM = 2; uint256 constant ACCREDITED_INVESTOR_CLAIM = 3; uint256 constant COUNTRY_CLAIM = 4; uint256 constant PROFESSIONAL_INVESTOR_CLAIM = 5; 

Регулятори вимагають обмежити продаж в певних юрисдикціях. Наприклад, не можна продавати US-резидентам без реєстрації в SEC. Реалізуємо модуль перевірки коду країни та лімітів інвесторів. Це дозволило клієнту з Берліна запустити продаж у ЄС без обмежень, а для резидентів США — налаштувати whitelist після реєстрації.

Lifecycle токенізованого активу

Issuance (емісія)

Перед мінтингом токенів:

1. Юридична структура: SPV, траст або інша структура, яка тримає реальний актив
2. Legal opinion що токени не є незареєстрованими securities (або реєстрація)
3. Проспект/offering memorandum (залежить від юрисдикції та об'єму)
4. Custody arrangement: хто тримає документи, хто є transfer agent

function mintSecurityTokens( address investor, uint256 amount, bytes32 partition, bytes calldata data ) external onlyRole(ISSUER_ROLE) { require(identityRegistry.isVerified(investor), "Not verified"); require(compliance.canTransfer(address(0), investor, amount), "Not compliant"); _issueByPartition(partition, investor, amount, data); emit TokensIssued(investor, amount, partition, data); } 

Corporate Actions

Токенізовані акції вимагають обробки корпоративних подій: дивіденди, спліти, обернені спліти. Ми реалізуємо модулі для розподілу дивідендів (через snapshots) та сплітів з автоматичним перерахунком балансів. Приклад для дивідендів: контракт отримує USDC, фіксує snapshot власників, кожен власник клеймить свою частку.

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

Вторинний обіг — окрема проблема. Не можна просто лістинговати на Uniswap: кожен buyer має пройти KYC, покупка має проходити compliance перевірку. Будуємо permissioned DEX з вбудованим compliance-шлюзом або інтегруємося з регульованими платформами (INX, tZERO, STO Global X). Другий варіант дає готову ліквідність без побудови власного торгового майданчика.

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

Для позик під заставу токенізованих активів потрібна on-chain ціна. На відміну від криптоактивів — немає ліквідного ринку. Рішення: модель верифікованого оцінювача. Акредитований оцінювач підписує оцінку, публікує on-chain. Контракт приймає оцінки від N акредитованих оцінювачів, бере медіану:

contract AssetValuationOracle { struct Valuation { uint256 value; uint256 timestamp; address appraiser; bytes signature; } mapping(bytes32 => Valuation[]) public valuations; uint256 public constant MAX_VALUATION_AGE = 90 days; uint256 public constant MIN_APPRAISERS = 2; function getAssetValue(bytes32 assetId) external view returns (uint256) { Valuation[] storage vals = valuations[assetId]; uint256[] memory freshValues = new uint256[](vals.length); uint256 freshCount = 0; for (uint i = 0; i < vals.length; i++) { if (block.timestamp - vals[i].timestamp <= MAX_VALUATION_AGE) { freshValues[freshCount++] = vals[i].value; } } require(freshCount >= MIN_APPRAISERS, "Insufficient fresh valuations"); return median(freshValues, freshCount); } } 

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

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

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

Разом: 23–35 тижнів. Юридичний етап — змінна з найбільшим розкидом: залежить від активу, юрисдикції та наявності досвідченого securities-lawyer у команді клієнта. Орієнтовна вартість проєкту — від $80,000 до $150,000 залежно від складності.

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