Meta-Hook Router

Meta-Hook Router — это мультиплексор Token-2022 Transfer Hook. Он устраняет фундаментальное ограничение: Token-2022 позволяет только один transfer hook на один mint. Meta-Hook Router занимает этот единственный слот и распределяет вызовы до 8 подхуков — как нативных программ Solana, так и Solidity-контрактов в Rome EVM.

Проблема

Token-2022 Transfer Hooks — мощный механизм: они срабатывают при каждом только вызове, обеспечивая соблюдение требований, роялти, аналитику и многое другое. Но на каждый mint приходится ровно один hook-программный модуль. Если эмитенту стейблкоина нужны проверки KYC, проверка санкций И обеспечение соблюдения роялти, он не может использовать три отдельных hook-программы.

Решение

Meta-Hook Router регистрируется как единственный transfer hook mint'а, а затем распределяет вызовы по нескольким подхукам в порядке приоритета:

SPL Transfer (Jupiter, Raydium, wallet)
    ↓
Token-2022 transfer_checked
    ↓
Meta-Hook Router (единственный слот hook)
    ├── Подхук 1: Compliance KYC (Solidity в Rome EVM)
    ├── Подхук 2: Проверка санкций (Solidity в Rome EVM)
    ├── Подхук 3: Аналитика переводов (нативная программа Solana)
    └── Подхук 4: Обеспечение роялти (Solidity в Rome EVM)
    ↓
Первая ошибка останавливает всё — перевод откатывается

Ключевые свойства

Распределение по нескольким хукам — До 8 подхуков на один mint, последовательный вызов в порядке приоритета.

Нативные + EVM подхуки — Смешивайте нативные программы Solana и Solidity-контракты в одной цепочке вызовов.

Первая ошибка — остановка всего — Если какой-либо подхук отклоняет перевод, весь перевод откатывается. Это гарантирует, что требования compliance нельзя обойти.

Агрегация ExtraAccountMetaList — Маршрутизатор объединяет дополнительные метаданные аккаунтов от всех подхуков, чтобы Token-2022 мог передать каждому нужные аккаунты.

Административные инструкции — registerSubHook, removeSubHook, reorderSubHooks, pauseSubHook — полное управление жизненным циклом.

Только режим Single-State — Transfer hooks выполняются внутри транзакций Solana. Из этого контекста OP-Geth недоступен, поэтому все EVM-подхуки должны использовать режим single-state (proxy).

Архитектура

Двухуровневое соблюдение требований

Meta-Hook Router обеспечивает compliance на двух уровнях:

SPL-уровень (Solana) — Маршрутизатор срабатывает при каждом только вызове. Когда кто-то обменивает compliant-токен на Jupiter, отправляет его из Phantom или взаимодействует с любым DeFi-протоколом Solana, срабатывает compliance-hook.

ERC-20-уровень (EVM) — Внутри Rome EVM контракт-обёртка ERC-20 может реализовывать собственные ограничения на переводы (совместимые с ERC-3643). Все внутренние переводы EVM проходят проверку compliance.

Bridge-уровень — Хук срабатывает, когда токены входят в Rome EVM или выходят из него. Хранилище моста whitelisted в compliance-контракте, чтобы разрешить депозит/вывод.

Общий реестр — Оба уровня читают из одного и того же KYCRegistry.sol контракта. Одобрение KYC покрывает и Solana, и EVM.

Бюджет вычислений

Тип хука	Стоимость CU
Базовые накладные расходы на перевод	100 000 CU
На каждый нативный подхук	50 000 CU
На каждый EVM-подхук	200 000 CU
Рекомендуется для EVM-перевода	800 000 CU

Решения подхуков

P0 — выпустить в первую очередь

S1: Hook для compliance KYC/санкций — Контракты compliance на Solidity в роли обработчиков Transfer Hook. Пространство имён на уровне mint, whitelisting protocol vaults (Jupiter/Kamino/Orca + хранилище моста Rome), связывание адресов для cross-chain KYC.

S1b: Обёртка ERC-20 для compliance — Дополнение к S1 для EVM-стороны. Ограничения на переводы, совместимые с ERC-3643, для ERC-20-репрезентации внутри Rome EVM.

S2: Мультиплексор Multi-Hook (не EVM) — Сам маршрутизатор, ценный для любого эмитента Token-2022 даже без EVM. Решает проблему одного хука на mint для всей экосистемы.

S3: Compliance для стейблкоинов по GENIUS Act — Регуляторные хуки для стейблкоинов: санкции, юрисдикции, отчётность.

P1 — выпустить следующим

S4: Лимиты переводов и контроль скорости — Максимум на один перевод, дневные/недельные лимиты скорости, периоды охлаждения.

S5: Правила переводов по юрисдикциям — Чёрные списки стран, проверки accredited investor, периоды удержания по юрисдикциям.

S6: Обеспечение роялти — Невозможно обойти роялти создателя при каждом SPL-переводе.

S7: Аналитика переводов on-chain — Хук только для чтения, который эмитирует события. Входной сценарий для бесплатного тарифа.

P2 — расширение рынка

S8: Permissioned L2 через Bridge Gate — Compliance на границах депозита/вывода моста.

S9: Динамическая маршрутизация комиссий — Программируемое извлечение комиссии на каждый перевод.

S10: Баллы лояльности/вознаграждения — Начисление баллов при переводе.

S11: Обеспечение vesting/lockup — Предотвращение переводов, нарушающих графики vesting.

Сценарий использования: End-to-End compliance для RWA

Эмитент (например, Securitize) разворачивает:
  1. ComplianceHook.sol в Rome EVM (реестр KYC, санкции, правила юрисдикций)
  2. Регистрирует его как EVM-подхук в Meta-Hook Router
  3. Выпускает RWA-токен как Token-2022 с transfer_hook = Meta-Hook Router

Пользователь Solana обменивает RWA-токен на Jupiter:
  Jupiter вызывает transfer_checked
    → Token-2022 вызывает Meta-Hook Router
    → Router направляет вызов в Rome EVM через CPI
    → ComplianceHook проверяет KYC отправителя/получателя и санкции
    → Успех: перевод завершается
    → Неуспех: весь перевод откатывается

Пользователь EVM переносит RWA-токен в Rome EVM:
  SPL-перевод в хранилище моста
    → Срабатывает hook (проверка compliance на входе)
    → Внутри EVM выпускается ERC-20
    → У ERC-20 есть собственные ограничения на переводы (ERC-3643)
    → Все переводы в EVM проверяются на compliance на уровне ERC-20

Известные ограничения

1. Только однорежимное состояние — OP-Geth недоступен изнутри транзакции Solana

2. только transfer_checked — Хуки срабатывают только на только, а не на обычный transfer. Мост Rome ДОЛЖЕН использовать только

3. Mint/burn не подключены к hooks — Хуки Token-2022 не срабатывают на операции mint/burn. Управляется через mint authority

4. Максимум 8 подхуков — Лимит на один mint

5. Обход через упаковку токенов — Пользователи могут оборачивать токены, чтобы избежать хуков. Смягчается чёрным списком обёрток + расширением PermanentDelegate

6. Модель адресов EVM — Хуки видят EVM-адреса, полученные из Rome, а не Ethereum-адреса. SDK предоставляет утилиту для derivation

Статус

В процессе — Активны core маршрутизатора и реализация KYC-хука (S1). Документированы 9 пакетов, 13 жёстких ограничений, 24 крайних случая.

Связанные материалы

• Transfer Hooks — как работают Token-2022 Transfer Hooks в Rome

• Взаимодействие токенов — модель токенов ERC-20 ↔ SPL

• Эмитенты стейблкоинов — мультихук-compliance для стейблкоинов