11.12.2025 00:17
Dzhagaev 0 6100 Источник

За 15 лет backend-разработки я прошёл путь от монолитных систем до распределённых архитектур. Последние годы специализируюсь на блокчейн-решениях, и security tokens — одна из самых технически интересных областей. Имплементировал оба стандарта в production: ERC-1400 для токенизации недвижимости, ERC-3643 для STO-проекта с листингом на regulated platform.

Выбор между этими стандартами — не просто техническое решение. Это архитектурный фундамент, который определит compliance-модель, gas costs, интеграционные возможности и upgradeability на годы вперёд.

В этой статье разберу оба стандарта с позиции практика: реальный код, метрики из production, конкретные рекомендации.

Почему ERC-20 не работает для security tokens

ERC-20 создавался для utility tokens с простым принципом: есть баланс — transfer проходит. Никаких ограничений, никаких проверок личности.

Security tokens — это цифровые ценные бумаги. Они подчиняются securities law. Каждый трансфер должен проверять:

  • Прошёл ли получатель KYC/AML

  • Является ли он аккредитованным инвестором (для US Reg D)

  • Не превышен ли лимит инвесторов в юрисдикции

  • Не нарушает ли трансфер transfer restrictions

  • Соблюдены ли holding periods (Rule 144)

ERC-20 не умеет ничего из этого. Поэтому индустрия разработала два подхода: ERC-3643 с on-chain compliance и ERC-1400 с hybrid-архитектурой.

Статус стандартов: критическое различие

ERC-3643 (T-REX Protocol) — разработан Tokeny Solutions, развивается с 2017 года. Предложен как EIP в 2021 году. Статус: Final (15 декабря 2023 года). Это первый и единственный permissioned token standard, официально принятый Ethereum community.

ERC-1400 — предложен в сентябре 2018 года консорциумом разработчиков (Polymath, Harbor, Securitize). Авторы: Adam Dossa, Pablo Ruiz, Stephane Gosselin, Fabian Vogelsteller. Статус: Draft. Стандарт так и не достиг Final status. Polymath, главный драйвер стандарта, мигрировал на собственный блокчейн Polymesh в 2021 году.

Это не формальность. Final status означает:

  • Код прошёл полный review процесс EIP

  • Стандарт заморожен и не будет меняться

  • Инструментарий и интеграции могут полагаться на стабильный интерфейс

Архитектурные подходы

ERC-1400: модульная библиотека стандартов

ERC-1400 — это umbrella для четырёх связанных ERC:

ERC-1400 (Security Token Standard)
    │
    ├── ERC-1410: Partially Fungible Token Standard
    │             (partitions/tranches)
    │
    ├── ERC-1594: Core Security Token Standard
    │             (issuance, redemption, transfer validation)
    │
    ├── ERC-1643: Document Management Standard
    │             (legal documents attachment)
    │
    └── ERC-1644: Controller Token Operation Standard
                  (forced transfers, recovery)

Ключевая особенность — partitions. Баланс держателя может быть разбит на подмножества с разными правилами:

// ERC-1410: Partially Fungible Token
interface IERC1410 {
    function balanceOfByPartition(
        bytes32 partition, 
        address tokenHolder
    ) external view returns (uint256);
    
    function partitionsOf(
        address tokenHolder
    ) external view returns (bytes32[] memory);
    
    function transferByPartition(
        bytes32 partition,
        address to,
        uint256 value,
        bytes calldata data
    ) external returns (bytes32);
}

Пример использования:

// Разные классы акций в одном контракте
bytes32 constant CLASS_A = keccak256("CLASS_A");  // Voting, dividends
bytes32 constant CLASS_B = keccak256("CLASS_B");  // No voting, 2x dividends
bytes32 constant FOUNDER_LOCKED = keccak256("FOUNDER_LOCKED_3Y");

// Инвестор может иметь токены в разных partitions:
// 100 tokens в CLASS_A (transferable)
// 50 tokens в FOUNDER_LOCKED (locked 3 years)
// Общий balanceOf() = 150, но transferable только 100

Transfer validation в ERC-1400 использует off-chain certificates:

function transferWithData(
    address to,
    uint256 value,
    bytes calldata data  // Certificate: salt, expiry, nonce, signature
) external;

// Certificate генерируется off-chain и подписывается issuer'ом
struct Certificate {
    bytes32 salt;
    uint256 expiry;
    uint256 nonce;
    bytes signature;  // Signed by issuer private key
}

ERC-3643: identity-centric compliance

ERC-3643 построен вокруг on-chain identity verification:

┌─────────────────────────────────────────────────────────────┐
│                    Token Contract (ERC-3643)                │
└─────────────────────┬───────────────────────────────────────┘
                      │
        ┌─────────────┼─────────────┬─────────────┐
        ▼             ▼             ▼             ▼
┌───────────────┐ ┌─────────────┐ ┌───────────┐ ┌──────────────┐
│   Identity    │ │Claim Topics │ │  Trusted  │ │  Compliance  │
│   Registry    │ │  Registry   │ │  Issuers  │ │   Contract   │
└───────┬───────┘ └─────────────┘ └───────────┘ └──────────────┘
        │
        ▼
┌───────────────┐
│  ONCHAINID    │  ← Децентрализованная идентификация
│  (per user)   │     инвестора (ERC-734/735)
└───────────────┘

Компоненты:

  • ONCHAINID — смарт-контракт идентификации пользователя. Хранит claims и ключи. Один ONCHAINID используется для всех ERC-3643 токенов.

  • Identity Registry — связывает wallet address с ONCHAINID и country code (ISO-3166).

  • Claim Topics Registry — список требуемых claim topics (KYC, accreditation, jurisdiction).

  • Trusted Issuers Registry — адреса доверенных claim issuers (KYC-провайдеры).

  • Compliance Contract — модульные правила: лимиты по странам, max holders, holding periods.

Transfer validation — полностью on-chain:

function transfer(address _to, uint256 _amount) 
    public override whenNotPaused returns (bool) 
{
    require(!_frozen[_to] && !_frozen[msg.sender], "Wallet frozen");
    require(_amount <= balanceOf(msg.sender) - _frozenTokens[msg.sender], 
            "Insufficient balance");
    
    // On-chain identity check
    require(_tokenIdentityRegistry.isVerified(_to), 
            "Identity not verified"); 
    
    // On-chain compliance check
    require(_tokenCompliance.canTransfer(msg.sender, _to, _amount), 
            "Compliance failure");
    
    _transfer(msg.sender, _to, _amount);
    _tokenCompliance.transferred(msg.sender, _to, _amount);
    return true;
}

Сравнение ключевых механизмов

Transfer Validation

Аспект

ERC-1400

ERC-3643

Подход

Off-chain certificate

On-chain validation

Где логика

Certificate server

Smart contracts

Single point of failure

Signing key

Trusted Issuers Registry

Гибкость изменений

Высокая (off-chain)

Требует contract update

Прозрачность

Низкая

Полная (on-chain audit trail)

Compliance Rules

ERC-1400 не стандартизирует compliance. Каждая имплементация решает по-своему. ConsenSys UniversalToken использует extension hooks:

interface IERC1400TokensValidator {
    function tokensToValidate(
        address token,
        bytes calldata payload,
        bytes32 partition,
        address operator,
        address from,
        address to,
        uint value,
        bytes calldata data,
        bytes calldata operatorData
    ) external;
}

ERC-3643 стандартизирует модульный Compliance contract:

// Пример: Country Restrictions Module
contract CountryRestrictionsModule is IModule {
    mapping(uint16 => bool) public restrictedCountries;
    
    function moduleCheck(
        address from,
        address to,
        uint256 amount,
        address compliance
    ) external view override returns (bool) {
        IToken token = IToken(IModularCompliance(compliance).getToken());
        uint16 receiverCountry = token.identityRegistry().investorCountry(to);
        
        return !restrictedCountries[receiverCountry];
    }
}

// Пример: Max Balance Module
contract MaxBalanceModule is IModule {
    uint256 public maxBalance;
    
    function moduleCheck(
        address from,
        address to,
        uint256 amount,
        address compliance
    ) external view override returns (bool) {
        IToken token = IToken(IModularCompliance(compliance).getToken());
        return token.balanceOf(to) + amount <= maxBalance;
    }
}

ERC-20 Compatibility

ERC-1400: Частичная совместимость. Стандартные transfer() и transferFrom() работают, но используют default partition. Wallets видят общий баланс, но не partitions.

ERC-3643: Полная backward compatibility с ERC-20. Все функции работают, но трансферы revert если compliance не пройден. Стандартные wallets и DEX работают корректно.

Controller Operations (Forced Transfers)

Оба стандарта поддерживают forced transfers для регуляторных требований:

// ERC-3643: Agent role
function forcedTransfer(
    address from,
    address to,
    uint256 amount
) external onlyAgent returns (bool) {
    // Agent может переводить без compliance checks
    _transfer(from, to, amount);
    emit ForcedTransfer(from, to, amount, msg.sender);
    return true;
}

// Recovery mechanism для lost keys
function recoveryAddress(
    address lostWallet,
    address newWallet,
    address investorOnchainID
) external onlyAgent returns (bool);

Практические метрики

Сложность деплоя

ERC-1400:

  • Контракты: 1-3 (монолитная архитектура)

  • Reference implementation (ConsenSys UniversalToken): ~2,500 LOC

  • External dependencies: Certificate generation server (off-chain)

ERC-3643:

  • Контракты: 8-15 (модульная архитектура)

  • T-REX implementation: ~5,000 LOC

  • External dependencies: Claim issuers (могут быть on-chain)

Gas Costs

Реальные метрики зависят от конкретной имплементации и сложности compliance rules. Общие наблюдения:

  • ERC-1400 с partitions требует дополнительных storage operations

  • ERC-3643 выполняет on-chain identity checks при каждом трансфере

  • Для high-frequency операций оба стандарта рекомендуется деплоить на L2 (Polygon, Arbitrum, Base)

ABN AMRO выпустил €5 млн green bond на Polygon именно для оптимизации gas costs.

Аудит и безопасность

ERC-3643

T-REX implementation:

  • Аудит Kaspersky — без критических findings

  • Аудит Hacken — оценка 10/10

  • Развитие с 2017 года, 7+ лет в production

  • $28+ млрд токенизированных активов

Основные риски:

  • Identity Registry centralization

  • Trusted Issuers compromise

  • Compliance module bugs

ERC-1400

ConsenSys UniversalToken:

  • Нет публичных аудитов от топ-компаний

  • Используется в production (Codefi Assets, tZERO)

  • Development стагнировал после миграции Polymath на Polymesh

Основные риски:

  • Off-chain certificate signing key compromise

  • Partition logic edge cases

  • Controller key management

Production Adoption

ERC-3643

По данным на 2025 год:

  • $28-32 млрд токенизированных активов

  • 92+ членов ERC3643 Association: DTCC, ABN AMRO, Deloitte, Fireblocks, Ava Labs, Hedera Foundation, OpenZeppelin, tZERO

  • Реальные кейсы: ABN AMRO (€5M green bond на Polygon), Fasanara Capital (tokenized funds), Citi (private equity pilots)

  • Multi-chain: Ethereum, Polygon, Avalanche, Base, Hedera

ERC-1400

  • tZERO: security tokens (St. Regis Aspen — $18M raise)

  • Polymath: мигрировал на Polymesh

  • ConsenSys: UniversalToken implementation

  • Development практически остановлен с 2020-2021

Trend: проекты на ERC-1400 либо мигрируют на Polymesh, либо переходят на ERC-3643.

Когда что выбирать

Выбирайте ERC-3643 если:

  • Стандартная структура — один класс токенов, одинаковые права для всех инвесторов

  • Регуляторные требования высокие — EU MiCA, SEC compliance, полный audit trail

  • Нужна on-chain verification — автоматическая проверка без доверия к off-chain системам

  • Планируется вторичный рынок — ERC-20 совместимость, интеграция с DEX

  • Важна экосистема — активное development, institutional backing, растущий tooling

Выбирайте ERC-1400 если:

  • Нужны partitions/tranches — разные классы акций с разными правами в одном контракте

  • Сложные vesting schedules — founder shares, employee options с различными lock-up periods

  • Legacy integration — работаете с платформами на ERC-1400 (tZERO)

  • Гибкость validation — хотите менять правила без contract upgrades

Альтернативный подход

Для сложных корпоративных структур рассмотрите:

  • Несколько отдельных ERC-3643 токенов вместо одного ERC-1400 с partitions

  • Polymesh blockchain (если Polymath экосистема критична)

  • CMTAT (используется Taurus, Daura, Obligate)

Заключение

ERC-3643 стал де-факто стандартом для институциональной токенизации:

  • Единственный Final status среди security token стандартов

  • On-chain compliance без зависимости от off-chain систем

  • Сильная экосистема: 92+ членов ассоциации, включая DTCC и Deloitte

  • $28+ млрд токенизированных активов

ERC-1400 остаётся релевантным для:

  • Сложных корпоративных структур с разными классами активов

  • Интеграции с существующей off-chain инфраструктурой

  • Legacy проектов на Polymath/tZERO экосистеме

Для нового проекта в 2025 году рекомендую начинать с ERC-3643, если нет hard requirement на partitions. Экосистема, tooling и institutional support делают его более безопасным выбором.

Ресурсы:

Статья основана на официальных спецификациях, документации ERC-3643 Association и практическом опыте имплементации обоих стандартов.

Комментарии (0)