Rome Protocol enthüllt Details zur Solana-EVM-Zugänglichkeit, während Kreditdemos im Testnet laufen

Rome Protocol hat Verbindungsdaten für sein Hadrian-Testnet veröffentlicht und Entwicklern damit eine mit USDC finanzierte Umgebung bereitgestellt, um Ethereum-ähnliche Anwendungen innerhalb von Solana auszuprobieren; die Dokumentation listet zudem separat ein Mainnet namens Rubicon auf.

Zusammenfassung

• Romes Hadrian-Testnet läuft auf Solana Devnet; die Dokumentation nennt Rubicon separat als Mainnet.

• Die Implementierungen von Compound v3 und Aave v3 bleiben Referenzanwendungen; offizielle Protokoll-Migrationen sind nicht bestätigt.

• Hadrian nutzt Test-USDC für Gas; die Transaktionspreise werden über konfigurierbare Operator-Einstellungen gesteuert.

• Rome berichtet über ein Audit durch Halborn; die Dokumentation nennt Ethereum-Kompatibilität und Ausführungsbeschränkungen.

Der Beitrag vom 18. Oktober benennt Hadrian als Testnet auf Solana Devnet mit Chain-ID 200010, einem RPC-Endpunkt, einem Explorer und Anweisungen zum Bezug von Test-USDC. Der beigelegte Screenshot verweist Entwickler auf den Faucet von Circle und eine Bridge-Schnittstelle, um ihre Wallets zu füllen.

Die Entwicklerdokumentation listet Rubicon separat als Mainnet mit Chain-ID 7531 und einem anderen RPC-Endpunkt auf. Die Einführungsseite beschreibt Rubicon als Nutzung echter USDC und unterscheidet damit die Produktionsumgebung von Hadrians Test-Assets.

Rome EVM führt Solidity-Code innerhalb von Solana aus

Romes Ausführungs-Dokumentation beschreibt eine als Solana-Programm implementierte Ethereum Virtual Machine. Ein Proxy empfängt signierte Ethereum-ähnliche Transaktionen, prüft sie über einen Offchain-Emulator und verpackt ihre Anweisungen für die Ausführung durch Solana-Validatoren.

Gemäß der vom Projekt beschriebenen Architektur können Solidity-Verträge native Solana-Programme über Cross-Program-Invocation (CPI) aufrufen. Entwickler können vertraute Ethereum-Tools nutzen, während ihre Verträge in Solanas Runtime ausgeführt werden.

Das könnte Sie auch interessieren: Lighter startet EVM-Devnet mit 1-Sekunden-Blöcken und Vertrags-Handel

Die Dokumentation beschreibt einen gemeinsamen Anwendungsstatus zwischen EVM- und Solana-Nutzern. Die Aussage, dass keine Bridge benötigt wird, bezieht sich auf Interaktionen innerhalb dieser Umgebung; Hadrians Finanzierungsanleitungen verweisen Nutzer jedoch separat auf eine Bridge, um Test-USDC ins Netzwerk zu bringen.

Romes Ausführungsleitfaden unterscheidet zwei Verarbeitungsmodi: Operationen, die in eine einzige Solana-Transaktion passen, erfolgen atomar – d. h., die gesamte Transaktion wird entweder vollständig ausgeführt oder komplett rückgängig gemacht.

Für anspruchsvollere Operationen beschreibt derselbe Leitfaden eine iterative Ausführung über mehrere Solana-Transaktionen. Konten werden während der Verarbeitung gesperrt, und zwischengespeicherte Effekte werden am Ende festgeschrieben. Das Projekt nennt ein Session-Limit von 160 Schritten sowie Einschränkungen, welche Solana-Programmaufrufe diesen Modus nutzen dürfen.

Solanas Transaktionskapazität war Gegenstand separater Netzwerkänderungen. In einem Bericht vom 30. August skizzierte Jacob Creech die geplante Umstellung von 1.232-Byte- auf 4.096-Byte-Transaktionen, wie crypto.news zuvor berichtete. Die Ankündigung datierte Transaction V1 auf den 9. September und behandelte Slot-Zeit-Reduktionen sowie Alpenglow als getrennte Upgrades.

Compound- und Aave-Implementierungen bleiben Referenzanwendungen

Romes Hadrian-Leitfaden nennt Uniswap, Compound und Aave als erste auf dem Testnetz validierte Referenzanwendungen.

Das Aerarium-Repository des Projekts beschreibt eine Compound-v3-Kreditanwendung mit zwei Wallet-Routen, die einen gemeinsamen Kreditpool nutzen. Eine Route akzeptiert Ethereum-kompatible signierte Transaktionen über MetaMask; die andere nutzt Phantom und eine Solana-basierte Identität ohne Ethereum-Schlüssel.

Dem Repository zufolge greifen beide Routen auf denselben Comet-Markt zu – für USDC-Einzahlungen, Sicherheiten, Kreditaufnahmen, Rückzahlungen und Auszahlungen. Die angegebene Anwendungsadresse nutzt eine Devnet-Domäne. GitHub

Romes Aave-Schnittstellen-Repository bezeichnet das Produkt ausdrücklich als Demo und platziert es auf Hadrian. Das zugehörige Vertrags-Repository beschreibt einen Fork von Aaves Code.

Diese Unterlagen zeigen, wie Rome seine Implementierungen darstellt. Sie belegen jedoch nicht, dass die jeweilige Governance-Organisation eines der Kreditprotokolle eine Produktivbereitstellung genehmigt oder bestehende Nutzerpositionen nach Rome migriert hat.

Rome verfolgt weitere Finanzanwendungen mittels Partnerschaften. Im März 2025 kündigte das Projekt eine Zusammenarbeit mit KiiChain zu tokenisierten Vermögenswerten und grenzüberschreitenden Zahlungsfinanzdiensten für Lateinamerika an. Führungskräfte skizzierten Pläne zu Immobilien, landwirtschaftlichen Rohstoffen und Zugang zur Solana-Liquidität.

USDC-Gaszahlungen hängen von der Operator-Konfiguration ab

Hadrians Netzwerk-Leitfaden benennt USDC als Gas-Token und identifiziert Circles Solana-Devnet-USDC-Mint. Entwickler benötigen laut Leitfaden zum Aufladen Test-USDC sowie etwas Devnet-SOL.

Circles Faucet unterstützt sowohl Solana Devnet als auch Ethereum Sepolia. Der Anbieter kennzeichnet Faucet-Tokens als Testvermögen ohne reellen Wert und gibt derzeit 20 Test-USDC pro Anfrage an – unter Vorbehalt seiner Limits.

Romes Anwendungs-Chain-Dokumentation ermöglicht es einem Operator, ein SPL-Token für Gaszahlungen auszuwählen und die Transaktionsgebühren-Einnahmen an eine Anwendungskasse weiterzuleiten.

Dasselbe Dokument beschreibt einen Preis-Dienst, der das gewählte Gas-Token in SOL umrechnet, um zugrundeliegende Solana-Transaktionskosten zu ermitteln. Die Konfiguration kann Preise aus Meteora-Pools oder als Pyth/Hermes-Fallback abrufen.

Romes Einschränkungsseite listet konfigurierbare Mindestgaspreise und einen Proxy-Multiplikator auf. Der veröffentlichte Rahmen beschreibt daher konfigurierbare Preise, ohne einen universellen Dollarbetrag pro Anwendungstransaktion festzulegen.

Audit- und Kompatibilitätsaussagen unterliegen definierten Grenzen

Romes EVM-Repository identifiziert ein Mainnet-Programm und nennt Halborn als Auditor. Das Repository enthält Anweisungen zum Neuerstellen des Programms und zum Vergleich mit der bereitgestellten Binärdatei – wobei Build-Zeit und Commit-Hash bei diesem Vergleich maskiert werden.

Die Kompatibilitätsdokumentation des Projekts listet Abweichungen vom Ethereum-Standard auf, darunter deaktivierte Modular-Exponentiation und ein Gasverhalten, das Ethers per-Operation-Plan nicht reproduziert.

Die Einschränkungsseite besagt, dass Rome-Transaktionen vor der Ausführung die berührten Solana-Konten deklarieren müssen. Sie nennt eine Obergrenze von 64 Adressen pro Transaktion und etwa 1,4 Millionen Recheneinheiten pro Transaktion. Die Anleitung empfiehlt, den tatsächlichen Solana-Rechenverbrauch aus Transaktionsquittungen zu ermitteln, da die EVM-Gas-Angabe diese Ressourcennutzung nicht korrekt widerspiegelt.

Die Mainnet-Bereitstellungstabelle nennt eine Squads-Multisignatur-Wallet als Upgrade-Autorität.

Separate Interoperabilitätsprojekte zielen auf institutionelle Märkte ab. Im August kündigte Interstice Digital eine cross-chain-Swap-Engine an, die Canton mit Ethereum, Solana und Robinhood Chain verbindet. FalconX stellt Liquidität bereit, während Interstice betont, keine Kundenvorräte zu halten oder Transaktionen im Auftrag der Nutzer auszuführen.

Mehr dazu: Bitmine fügt 12.535 ETH hinzu, während der Ethereum-Kurs unter 2.500 USD bleibt