# Meta-Hook Router

Der Meta-Hook Router ist ein Token-2022 Transfer-Hook-Multiplexer. Er löst eine grundlegende Einschränkung: Token-2022 erlaubt nur **einen** Transfer-Hook pro Mint. Der Meta-Hook Router sitzt in diesem einzigen Slot und leitet an bis zu 8 Sub-Hooks weiter — sowohl native Solana-Programme als auch Solidity-Verträge auf Rome EVM.

## Das Problem

Token-2022 Transfer Hooks sind leistungsstark — sie werden bei jedem `transfer_checked` Aufruf ausgelöst und ermöglichen Compliance, Royalties, Analysen und mehr. Aber jeder Mint erhält genau ein Hook-Programm. Wenn ein Stablecoin-Emittent KYC-Prüfungen UND Sanktionsscreening UND Durchsetzung von Royalties braucht, kann er nicht drei separate Hook-Programme verwenden.

## Die Lösung

Der Meta-Hook Router registriert sich als einziger Transfer-Hook des Mints und leitet dann in Prioritätsreihenfolge an mehrere Sub-Hooks weiter:

```
SPL-Transfer (Jupiter, Raydium, Wallet)
    ↓
Token-2022 transfer_checked
    ↓
Meta-Hook Router (einziger Hook-Slot)
    ├── Sub-Hook 1: KYC-Compliance (Solidity auf Rome EVM)
    ├── Sub-Hook 2: Sanktionsprüfung (Solidity auf Rome EVM)
    ├── Sub-Hook 3: Transfer-Analytik (natives Solana-Programm)
    └── Sub-Hook 4: Royalty-Durchsetzung (Solidity auf Rome EVM)
    ↓
Erster Fehler stoppt alles — Transfer wird rückgängig gemacht
```

## Wesentliche Eigenschaften

**Multi-Hook-Weiterleitung** — Bis zu 8 Sub-Hooks pro Mint, sequenziell in Prioritätsreihenfolge weitergeleitet.

**Native + EVM Sub-Hooks** — Native Solana-Programme und Solidity-Verträge in einer Weiterleitungskette mischen.

**Erster-Fehler-stoppt-alles** — Wenn ein Sub-Hook den Transfer ablehnt, wird der gesamte Transfer rückgängig gemacht. So wird sichergestellt, dass Compliance nicht umgangen werden kann.

**ExtraAccountMetaList-Aggregation** — Der Router verkettet zusätzliche Kontenmetadaten aller Sub-Hooks, damit Token-2022 die richtigen Konten an jeden einzelnen übergeben kann.

**Admin-Anweisungen** — `registerSubHook`, `removeSubHook`, `reorderSubHooks`, `pauseSubHook` — vollständiges Lifecycle-Management.

**Nur Single-State-Modus** — Transfer-Hooks werden innerhalb von Solana-Transaktionen ausgeführt. OP-Geth ist von diesem Kontext aus nicht erreichbar, daher müssen alle EVM-Sub-Hooks den Single-State-(Proxy-)Modus verwenden.

## Architektur

### Zwei-Ebenen-Compliance

Der Meta-Hook Router ermöglicht Compliance auf zwei Ebenen:

**SPL-Ebene (Solana)** — Der Router wird bei jedem `transfer_checked` Aufruf ausgelöst. Wenn jemand auf Jupiter einen konformen Token tauscht, ihn von Phantom sendet oder mit einem beliebigen Solana-DeFi-Protokoll interagiert, wird der Compliance-Hook ausgelöst.

**ERC-20-Ebene (EVM)** — Innerhalb von Rome EVM kann der ERC-20-Wrapper-Vertrag seine eigenen Transferbeschränkungen implementieren (ERC-3643-kompatibel). Alle EVM-internen Transfers werden auf Compliance geprüft.

**Bridge-Ebene** — Der Hook wird ausgelöst, wenn Tokens Rome EVM betreten oder verlassen. Der Bridge-Tresor ist im Compliance-Vertrag auf der Whitelist, um Ein- und Auszahlungen zu erlauben.

**Gemeinsames Register** — Beide Ebenen lesen aus demselben `KYCRegistry.sol` Vertrag. Eine KYC-Freigabe deckt sowohl Solana als auch EVM ab.

### Compute-Budget

| Hook-Typ                    | CU-Kosten  |
| --------------------------- | ---------- |
| Basis-Transfer-Overhead     | 100.000 CU |
| Pro nativem Sub-Hook        | 50.000 CU  |
| Pro EVM-Sub-Hook            | 200.000 CU |
| Empfohlen für EVM-Transfers | 800.000 CU |

## Sub-Hook-Lösungen

### P0 — Zuerst liefern

**S1: KYC/Sanktions-Compliance-Hook** — Solidity-Compliance-Verträge als Transfer-Hook-Handler. Namensraum pro Mint, Whitelisting von Protokoll-Vaults (Jupiter/Kamino/Orca + Rome-Bridge-Tresor), Adressverknüpfung für Cross-Chain-KYC.

**S1b: ERC-20-Compliance-Wrapper** — Ergänzung zu S1 für die EVM-Seite. ERC-3643-kompatible Transferbeschränkungen auf der ERC-20-Darstellung innerhalb von Rome EVM.

**S2: Multi-Hook-Multiplexer (nicht-EVM)** — Der Router selbst, wertvoll für jeden Token-2022-Emittenten auch ohne EVM. Löst das Problem „ein Hook pro Mint“ für das gesamte Ökosystem.

**S3: GENIUS-Act Stablecoin-Compliance** — Regulatorische Hooks für Stablecoins: Sanktionslisten, Jurisdiktionen, Reporting.

### P1 — Als Nächstes liefern

**S4: Transferlimits & Geschwindigkeitskontrollen** — Maximalbetrag pro Transfer, tägliche/wöchentliche Geschwindigkeitslimits, Cooldown-Phasen.

**S5: Jurisdiktionsbasierte Transferregeln** — Länder-Blocklisten, Prüfung akkreditierter Investoren, Haltefristen je Jurisdiktion.

**S6: Royalty-Durchsetzung** — Nicht umgehbare Creator-Royalties bei jedem SPL-Transfer.

**S7: On-Chain-Transfer-Analytik** — Nur-Lese-Hook, der Events ausgibt. Einstiegspunkt für die Free-Tier-Nutzung.

### P2 — Markterweiterung

**S8: Erlaubtes L2 über Bridge Gate** — Compliance an den Grenzen von Bridge-Ein- und -Auszahlungen.

**S9: Dynamische Fee-Weiterleitung** — Programmierbare Gebührenerhebung pro Transfer.

**S10: Treue-/Belohnungspunkte** — Punktevergabe ausgelöst durch Transfers.

**S11: Vesting-/Lockup-Durchsetzung** — Verhindert Transfers, die Vesting-Zeitpläne verletzen.

## Anwendungsfall: End-to-End-RWA-Compliance

```
Der Emittent (z. B. Securitize) deployt:
  1. ComplianceHook.sol auf Rome EVM (KYC-Register, Sanktionslisten, Jurisdiktionsregeln)
  2. Registriert ihn als EVM-Sub-Hook im Meta-Hook Router
  3. Mintet RWA-Token als Token-2022 mit transfer_hook = Meta-Hook Router

Solana-Nutzer tauscht RWA-Token auf Jupiter:
  Jupiter ruft transfer_checked auf
    → Token-2022 ruft den Meta-Hook Router auf
    → Router leitet per CPI an Rome EVM weiter
    → ComplianceHook prüft KYC und Sanktionsstatus von Sender/Empfänger
    → Erfolgreich: Transfer wird abgeschlossen
    → Fehler: gesamter Transfer wird rückgängig gemacht

EVM-Nutzer bridgt RWA-Token in Rome EVM:
  SPL-Transfer zum Bridge-Tresor
    → Hook wird ausgelöst (Compliance-Prüfung beim Eintritt)
    → ERC-20 wird innerhalb der EVM gemintet
    → ERC-20 hat eigene Transferbeschränkungen (ERC-3643)
    → Alle EVM-Transfers werden auf ERC-20-Ebene auf Compliance geprüft
```

## Bekannte Einschränkungen

1. **Nur Single-State-Modus** — OP-Geth ist von innerhalb einer Solana-Transaktion aus nicht erreichbar
2. **nur transfer\_checked** — Hooks werden nur bei `transfer_checked`ausgelöst, nicht bei einfachem `transfer`nicht ausgelöst. Die Rome-Bridge MUSS `transfer_checked`
3. **Mint/Burn nicht gehookt** — Token-2022-Hooks werden bei Mint-/Burn-Operationen nicht ausgelöst. Steuerung über Mint Authority
4. **Max. 8 Sub-Hooks** — Limit pro Mint
5. **Umgehung durch Token-Wrapping** — Nutzer könnten Tokens wrappen, um Hooks zu umgehen. Gemildert durch Wrapper-Blacklist + PermanentDelegate-Erweiterung
6. **EVM-Adressmodell** — Hooks sehen von Rome abgeleitete EVM-Adressen, nicht Ethereum-Adressen. Das SDK stellt ein Ableitungs-Utility bereit

## Status

**In Arbeit** — Router-Kern und KYC-Hook-(S1)-Implementierung aktiv. 9 Pakete, 13 harte Einschränkungen, 24 dokumentierte Edge Cases.

## Verwandt

* [Transfer Hooks](/de/grundlegende-konzepte/transfer-hooks.md) — wie Token-2022 Transfer Hooks in Rome funktionieren
* [Token-Interop](/de/grundlegende-konzepte/token-interop.md) — ERC-20 ↔ SPL-Token-Modell
* [Stablecoin-Emittenten](/de/anwendungsfalle/stablecoin-issuers.md) — Multi-Hook-Compliance für Stablecoins


---

# 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/de/produkte/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.