# Transfer Hooks

Token-2022 Transfer Hooks ermöglichen es einem Programm, bei jeder Token-Übertragung benutzerdefinierte Logik auszuführen. Rome ermöglicht es Solidity-Smart-Contracts, als Transfer Hooks zu fungieren — und bringt damit EVM-Programmierbarkeit zum Token-Standard von Solana.

## Wie Transfer Hooks funktionieren

Token-2022 (Solanas Token-Programm der nächsten Generation) unterstützt eine Erweiterung namens Transfer Hook. Wenn ein Mint mit einem Transfer Hook konfiguriert ist:

1. Jeder `transfer_checked` Aufruf für diesen Mint ruft das zugewiesene Hook-Programm auf
2. Der Hook erhält Übertragungsdetails (Absender, Empfänger, Betrag, Mint)
3. Der Hook kann die Übertragung genehmigen oder ablehnen
4. Wenn der Hook ablehnt (revertiert), schlägt die gesamte Übertragung fehl

## EVM-gestützte Transfer Hooks

Auf Rome kann ein Solidity-Contract als Transfer-Hook-Handler dienen:

```
Nutzer tauscht Token auf Jupiter (Solana)
    ↓
Jupiter ruft transfer_checked auf
    ↓
Token-2022 ruft das zugewiesene Hook-Programm auf
    ↓
Hook-Programm = Rome Meta-Hook Router
    ↓
Router leitet per CPI an den Solidity-Contract weiter → Rome EVM
    ↓
Solidity-Contract führt Compliance-Logik aus
    ↓
Bestanden: Übertragung wird abgeschlossen
Fehlgeschlagen: gesamte Übertragung revertiert
```

Das bedeutet **jede SPL-Token-Übertragung auf Solana** — ob auf Jupiter, Raydium, Phantom oder in einer beliebigen Wallet — kann EVM-Compliance-Logik auslösen.

## Beispiel: KYC-Compliance-Hook

```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.28;

contract ComplianceHook {
    mapping(address => bool) public kycApproved;
    mapping(address => bool) public sanctioned;

    // Wird vom Meta-Hook Router bei jeder Übertragung aufgerufen
    function onTransfer(
        address sender,
        address recipient,
        uint256 amount,
        bytes32 mint
    ) external view {
        // Prüfen, ob der Absender KYC-geprüft ist
        require(kycApproved[sender], "Absender nicht KYC-genehmigt");

        // Prüfen, ob der Empfänger KYC-geprüft ist
        require(kycApproved[recipient], "Empfänger nicht KYC-genehmigt");

        // Prüfen, dass keine der Parteien sanktioniert ist
        require(!sanctioned[sender], "Absender sanktioniert");
        require(!sanctioned[recipient], "Empfänger sanktioniert");

        // Übertragung genehmigt — Funktion kehrt ohne revert zurück
    }
}
```

## Wichtige Einschränkungen

**`transfer_checked` nur.** Hooks werden nur bei `transfer_checked` Aufrufen ausgelöst, nicht bei einfachen `transfer`. Jede Integration, die Rome-Token verwendet, muss `transfer_checked` verwenden, um die Durchsetzung der Compliance sicherzustellen.

**Einzelzustandsmodus erforderlich.** Transfer Hooks werden innerhalb von Solana-Transaktionen ausgeführt. OP-Geth ist aus diesem Kontext nicht erreichbar. Sämtliche EVM-Hook-Logik muss im Einzelzustands-(Proxy-)Modus laufen.

**CPI-Tiefenbudget.** Der Hook-Aufruf verbraucht CPI-Tiefe:

```
Ebene 0: DeFi-Protokoll → SPL Token-2022
Ebene 1: Token-2022 → Meta-Hook Router
Ebene 2: Meta-Hook Router → Rome EVM (CPI-Precompile)
Ebene 3: Rome EVM → (jede weitere CPI aus Solidity)
```

Nach der Hook-Aufrufkette bleibt nur noch eine CPI-Ebene übrig.

**Compute-Budget.** EVM-Hooks verbrauchen erhebliche CU:

* Basis-Übertragungs-Overhead: 100.000 CU
* Pro EVM-Sub-Hook: 200.000 CU
* Empfohlenes Budget für EVM-Übertragungen: 800.000 CU

## Whitelistung von DeFi-Protokollen

Vaults von DeFi-Protokollen (Jupiter, Kamino, Orca, Rome Bridge Vault) benötigen besondere Behandlung. Diese Vaults empfangen und senden Token im Rahmen normaler Abläufe — sie zu blockieren würde DeFi beschädigen.

Der Compliance-Contract verwaltet eine `protocolWhitelist` Mapping. Whitelist-Adressen (Vaults, PDAs für bekannte Protokolle) werden ohne KYC-Prüfungen genehmigt. Dies ermöglicht Token-Übertragungen über DeFi-Protokolle hinweg, während die Compliance bei Übertragungen zwischen Endnutzern weiterhin durchgesetzt wird.

## Adressmodell

Transfer Hooks sehen **von Rome abgeleitete EVM-Adressen**, nicht Ethereum-Adressen. Wenn ein Solana-Nutzer mit einem mit Rome-Hooks versehenen Token interagiert, wird sein Solana-Pubkey über PDA-Ableitung einer EVM-Adresse zugeordnet. Das Rome Solidity SDK bietet Hilfsfunktionen für diese Zuordnung.

## Verwandte Seiten

* [Meta-Hook Router](/de/produkte/meta-hook-router.md) — der Hook-Multiplexer, der mehrere Sub-Hooks pro Mint ermöglicht
* [Token-Interop](/de/grundlegende-konzepte/token-interop.md) — wie ERC-20- und SPL-Token zusammenhängen
* [Anleitung zum Erstellen von Transfer Hooks](https://github.com/rome-protocol/docs/blob/main/developer-guides/build-transfer-hook.md) — schrittweise Hook-Entwicklung


---

# 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/grundlegende-konzepte/transfer-hooks.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.