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_checkedausgelöst, nicht bei einfachem transfernicht 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 — wie Token-2022 Transfer Hooks in Rome funktionieren

• Token-Interop — ERC-20 ↔ SPL-Token-Modell

• Stablecoin-Emittenten — Multi-Hook-Compliance für Stablecoins