Професійна розробка платформи токенізації активів на 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 робочі дні. Гарантуємо якість аудиту та підтримку після запуску. Отримайте консультацію — почніть з обговорення архітектури.