Rome Protocol hat Verbindungsdetails für sein Hadrian-Testnet veröffentlicht und bietet Entwicklern damit eine USDC-finanzierte Umgebung, um Ethereum-ähnliche Anwendungen innerhalb von Solana auszuprobieren, während seine Dokumentation separat ein Mainnet-Netzwerk namens Rubicon auflistet.
Zusammenfassung
- Romes Hadrian-Testnet läuft auf Solana Devnet, während seine Dokumentation separat Rubicon als Mainnet auflistet.
- Compound v3- und Aave v3-Implementierungen bleiben Referenzanwendungen, ohne bestätigte offizielle Protokollmigrationen.
- Hadrian verwendet Test-USDC für Gas, wobei die Transaktionspreisgestaltung über konfigurierbare Operator-Einstellungen gesteuert wird.
- Rome meldet ein Halborn-Audit, während seine Dokumentation Ethereum-Kompatibilität und Ausführungsgrenzen auflistet.
Der Beitrag von Rome Protocol vom 18. Oktober identifiziert Hadrian als ein Testnet, das auf Solana Devnet läuft, mit Chain-ID 200010, einem RPC-Endpunkt, einem Explorer und Anweisungen zum Erhalt von Test-USDC. Der bereitgestellte Screenshot verweist Entwickler auf Circles Faucet und eine Bridge-Oberfläche, um ihre Wallets zu finanzieren.
Die Entwicklerdokumentation des Projekts listet Rubicon separat als Mainnet auf, mit Chain-ID 7531 und einem anderen RPC-Endpunkt. Seine einführende Seite beschreibt Rubicon als echtes USDC verwendend und unterscheidet die Produktionsumgebung von Hadrians Testressourcen.
Rome EVM führt Solidity-Code innerhalb von Solana aus
Romes Ausführungsdokumentation beschreibt eine Ethereum Virtual Machine, die als Solana-Programm implementiert ist. Ein Proxy empfängt signierte Ethereum-ähnliche Transaktionen, prüft sie durch einen Offchain-Emulator und verpackt ihre Anweisungen zur Ausführung durch Solana-Validatoren.
Gemäß der vom Projekt beschriebenen Architektur können Solidity-Verträge native Solana-Programme durch Cross-Program Invocation, oder CPI, aufrufen. Entwickler können vertraute Ethereum-Tools verwenden, während ihre Verträge innerhalb von Solanas Runtime ausgeführt werden.
Die Dokumentation beschreibt gemeinsamen Anwendungszustand zwischen EVM- und Solana-Nutzern. Ihre Aussage, dass keine Bridge benötigt wird, betrifft Interaktionen innerhalb dieser Umgebung; Hadrians Finanzierungsanweisungen verweisen Nutzer separat auf eine Bridge, wenn sie Test-USDC in das Netzwerk bringen.
Romes Ausführungsleitfaden unterscheidet zwei Verarbeitungsmodi. Operationen, die in eine einzige Solana-Transaktion passen, verwenden atomare Ausführung, bei der die vollständige Transaktion gemeinsam erfolgreich ist oder zurückgesetzt wird.
Für anspruchsvollere Operationen beschreibt derselbe Leitfaden iterative Ausführung über mehrere Solana-Transaktionen. Konten werden während der Verarbeitung gesperrt, und zwischengespeicherte Effekte werden am Ende festgeschrieben. Das Projekt listet ein Sitzungslimit von 160 Schritten und Einschränkungen dazu auf, welche Solana-Programmaufrufe diesen Modus verwenden können.
Solanas Transaktionskapazität war Gegenstand separater Netzwerkänderungen. In einem Bericht vom 30. August skizzierte Jacob Creech einen geplanten Wechsel von 1.232-Byte-Transaktionen zu einem 4.096-Byte-Format, wie crypto.news zuvor berichtete. Die Ankündigung terminierte Transaction V1 für den 9. September und behandelte Slot-Zeit-Reduzierungen und Alpenglow als separate Upgrades.
Compound- und Aave-Implementierungen bleiben Referenzanwendungen
Romes Hadrian-Leitfaden nennt Uniswap, Compound und Aave als Referenzanwendungen, die zuerst im Testnet validiert wurden.
Das Aerarium-Repository des Projekts beschreibt eine Compound v3-Lending-Anwendung mit zwei Wallet-Routen, die einen Lending-Pool teilen. Eine Route akzeptiert Ethereum-ähnliche signierte Transaktionen über MetaMask; die andere verwendet Phantom und eine von Solana abgeleitete Identität, ohne einen Ethereum-Schlüssel zu erfordern.
Gemäß diesem Repository greifen beide Routen auf denselben Comet-Markt zu und decken USDC-Einlagen, Sicherheitseinlagen, Kreditaufnahme, Rückzahlungen und Abhebungen ab. Die aufgelistete Anwendungsadresse verwendet eine Devnet-Domain. GitHub
Romes Aave-Schnittstellen-Repository bezeichnet das Produkt ausdrücklich als Demo und verortet es auf Hadrian. Sein begleitendes Vertrags-Repository beschreibt einen Fork von Aaves Code.
Diese Materialien belegen, wie Rome seine Implementierungen präsentiert. Sie belegen nicht, dass die leitende Organisation eines der beiden Lending-Protokolle eine Produktionsbereitstellung genehmigt oder bestehende Nutzerpositionen nach Rome verschoben hat.
Rome hat über Partnerschaften weitere Finanzanwendungen verfolgt. Im März 2025 kündigte das Projekt eine Zusammenarbeit mit KiiChain zu tokenisierten Vermögenswerten und kettenübergreifender Zahlungsfinanzierung für Lateinamerika an. Führungskräfte beschrieben Pläne, die Immobilien, landwirtschaftliche Rohstoffe und den Zugang zu Solana-Liquidität umfassen.
USDC-Gaszahlungen hängen von der Betreiberkonfiguration ab
Der Netzwerkleitfaden von Hadrian legt USDC als Gas-Token fest und identifiziert Circles Solana Devnet USDC-Mint. Entwickler, die von Solana aus finanzieren, benötigen laut dem Leitfaden Test-USDC und etwas Devnet-SOL.
Circles Faucet unterstützt sowohl Solana Devnet als auch Ethereum Sepolia. Der Anbieter beschreibt Faucet-Token als Testvermögenswerte ohne realen Wert und listet derzeit eine Verteilung von 20 Test-USDC pro Anfrage, vorbehaltlich seiner Limits.
Die Dokumentation zu Romes Anwendungsketten erlaubt es einem Betreiber, ein SPL-Token für Gaszahlungen auszuwählen und Transaktionsgebühreneinnahmen an eine Anwendungsschatzverwaltung weiterzuleiten.
Dieselbe Dokumentation beschreibt einen Preisdienst, der das gewählte Gas-Token gegen SOL für die zugrunde liegenden Solana-Transaktionskosten umrechnet. Seine Konfiguration kann Preise aus Meteora-Pools oder einem Pyth/Hermes-Fallback beziehen.
Die Einschränkungsseite von Rome listet konfigurierbare Mindestgaspreise und einen Multiplikator auf Proxy-Ebene auf. Das veröffentlichte Framework beschreibt daher eine konfigurierbare Preisgestaltung, ohne einen einheitlichen Dollarbetrag für jede Anwendungstransaktion festzulegen.
Audit- und Kompatibilitätsaussagen haben definierte Grenzen
Das EVM-Repository von Rome identifiziert ein Mainnet-Programm und gibt an, dass Halborn es geprüft hat. Das Repository enthält Anweisungen zum Neuerstellen des Programms und zum Vergleich mit der bereitgestellten Binärdatei, wobei Build-Zeit- und Commit-Hash-Metadaten während des Vergleichs maskiert werden.
Die Kompatibilitätsdokumentation des Projekts listet Unterschiede zu Ethereum auf, darunter deaktivierte modulare Exponentiation und Gasverhalten, das Ethereums Pro-Operation-Zeitplan nicht reproduziert.
Die Einschränkungsseite besagt, dass Rome-Transaktionen die Solana-Konten, die sie berühren, vor der Ausführung deklarieren müssen. Sie listet eine Obergrenze von 64 Adressen pro Transaktion und etwa 1,4 Millionen Compute Units pro Transaktion auf. Der Leitfaden empfiehlt, den tatsächlichen Solana-Compute-Verbrauch aus Transaktionsbelegen zu messen, da die EVM-Gasverbrauchszahl diesen Ressourcenverbrauch nicht getreu wiedergibt.
Seine Mainnet-Bereitstellungstabelle nennt eine Squads-Multisignatur-Wallet als Upgrade-Autorität.
Separate Interoperabilitätsprojekte haben auf institutionelle Märkte abgezielt. Im August kündigte Interstice Digital eine kettenübergreifende Swap-Engine an, die Canton mit Ethereum, Solana und Robinhood Chain verbindet. FalconX stellt Liquidität bereit, während Interstice angab, keine Kundenvermögenswerte zu halten oder Transaktionen im Namen der Nutzer auszuführen.
