# 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](/ru/osnovnye-koncepcii/transfer-hooks.md) — как работают Token-2022 Transfer Hooks в Rome
* [Взаимодействие токенов](/ru/osnovnye-koncepcii/token-interop.md) — модель токенов ERC-20 ↔ SPL
* [Эмитенты стейблкоинов](/ru/scenarii-ispolzovaniya/stablecoin-issuers.md) — мультихук-compliance для стейблкоинов


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.rome.builders/ru/produkty/meta-hook-router.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.