# Bekannte Einschränkungen

Ehrliche Dokumentation der aktuellen Einschränkungen des Rome-Protokolls und ihrer Auswirkungen.

## Ausführungseinschränkungen

**Modexp-Precompile deaktiviert.** Das Precompile für modulare Exponentiation (0x05) ist standardmäßig deaktiviert. Verträge, die auf RSA-Verifikation oder andere Modexp-Operationen angewiesen sind, schlagen fehl. Kann über ein Feature-Flag aktiviert werden.

**SELFDESTRUCT entfernt.** Der SELFDESTRUCT-Opcode wird nicht unterstützt, entsprechend Ethereums Dencun-Abkündigung. Verträge, die SELFDESTRUCT verwenden, werden zurückgesetzt.

**256 Speicher-Slots pro Speicherkonto.** Der Vertrags-Speicher ist über Solana-Konten mit jeweils 256 Slots aufgeteilt. Verträge mit großem Speicherbedarf verwenden mehrere Konten, was sich auf die CU-Kosten auswirkt.

**CPI-Tiefenlimit von 4.** Tief verschachtelte CPI-Aufrufe schlagen fehl. Entwerfen Sie Verträge mit flachen Aufrufbäumen.

## Token-Einschränkungen

**Transfer-Hooks werden nur bei `transfer_checked`.** einfachen `transfer` Aufrufen ausgelöst, umgehen Hooks vollständig. Alle Rome-Bridge-Operationen verwenden `transfer_checked`, aber Integrationen von Drittanbietern müssen sich dessen bewusst sein.

**Mint- und Burn-Operationen sind nicht mit Hooks versehen.** Token-2022-Transfer-Hooks werden bei Mint/Burn nicht ausgelöst. Gesteuert über die Mint-Authority, nicht über Hooks.

**Token-Umgehung durch Wrapping.** Benutzer können Token-2022-Token potenziell in Standard-SPL-Token wrappen, um Transfer-Hooks zu umgehen. Abgemildert durch Wrapper-Blacklists und die PermanentDelegate-Erweiterung, aber nicht vollständig beseitigt.

## Oracle-Einschränkungen

**Keine historischen Rundendaten.** Oracle-Gateway-Adapter unterstützen nur `latestRoundData()`. Historische Preisabfragen über `getRoundData(roundId)` lösen einen Revert aus.

**Parser-Offsets werden empirisch validiert.** Pyth- und Switchboard-Kontodaten werden mithilfe fest codierter Byte-Offsets geparst. Wenn Pyth oder Switchboard ihr Kontolayout ändern, liefern die Adapter falsche Daten, bis die Offsets erneut validiert wurden.

## Infrastruktureinschränkungen

**Einzelbetreibermodell.** Jede Rome-Bereitstellung wird von einer einzigen Entität betrieben (dem Betreiber des Payer-Pools). Es gibt kein dezentrales Betreiber-Set.

**Iteratives Modus-Locking.** Während der iterativen Ausführung werden Konten für 3–4 Sekunden gesperrt. Dies kann bei stark genutzten Konten zu Konflikten führen.

**Risiko der OP-Geth-Abweichung.** Die Zustandsabweichung zwischen Rome EVM und OP-Geth bleibt eine anhaltende technische Herausforderung. Die Footprint-Validierung mindert dieses Risiko, beseitigt es jedoch nicht.

## Was kommt als Nächstes

* [Verantwortungsvolle Offenlegung](/de/sicherheit/responsible-disclosure.md) — wie man Probleme meldet


---

# 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/sicherheit/known-limitations.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.