> For the complete documentation index, see [llms.txt](https://docs.rome.builders/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rome.builders/de/referenz/json-rpc.md). # JSON-RPC-Unterstützung Von Rome-EVM-Endpunkten unterstützte Ethereum-JSON-RPC-Methoden plus Rome-spezifisches Verhalten — für Foundry, Hardhat, ethers, viem und MetaMask. Rome-EVM-Endpunkte sprechen standardmäßiges Ethereum JSON-RPC. Foundry, Hardhat, ethers, viem und MetaMask funktionieren gegen Rome genauso wie auf jeder anderen EVM-Chain. Diese Seite listet auf, was unterstützt wird, und die wenigen Rome-spezifischen Verhaltensweisen, die man kennen sollte. ## Unterstützte Methoden **Kernfunktionen (Status & Ausführung):** `eth_chainId`, `eth_blockNumber`, `eth_getBalance`, `eth_getCode`, `eth_getStorageAt`, `eth_getTransactionCount`, `eth_call`, `eth_estimateGas`, `eth_gasPrice`, `eth_maxPriorityFeePerGas`, `eth_feeHistory`. **Blöcke & Transaktionen:** `eth_getBlockByNumber`, `eth_getBlockByHash`, `eth_getBlockReceipts`, `eth_getTransactionByHash`, `eth_getTransactionReceipt`, `eth_sendRawTransaction`, sowie Varianten nach Block-Index/Anzahl. **Logs & Filter:** `eth_getLogs`, `eth_newFilter`, `eth_newBlockFilter`, `eth_getFilterChanges`, `eth_getFilterLogs`, `eth_uninstallFilter`. **WebSocket-Abonnements:** `eth_subscribe` / `eth_unsubscribe` (`newHeads`, `logs`). Siehe [WebSocket-Abonnements](/de/entwicklerleitfaden/websocket-subscriptions.md). **Netzwerk / web3:** `net_version`, `net_listening`, `net_peerCount`, `web3_clientVersion`. **Kleine Introspektionsmethoden:** `rpc_modules` (listet `debug`, `eth`, `net`, `rome`, `rpc`, `txpool`, `web3`), `eth_syncing` (immer `false`), `eth_accounts` (immer eine leere Liste), `eth_getUncleCountByBlockNumber`, `eth_getUncleCountByBlockHash`, `eth_getUncleByBlockNumberAndIndex` und `eth_getUncleByBlockHashAndIndex` (keine Uncles, daher sind die Zählwerte `0x0` und Abfragen geben `null`), `eth_newPendingTransactionFilter` (akzeptiert, gibt aber nie Hashes zurück, da es keinen öffentlichen Mempool gibt), und `txpool_status`, das immer `{"pending":"0x0","queued":"0x0"}` zurückgibt, da es keinen öffentlichen Mempool gibt. **Tracing:** `debug_traceRomeTransaction` nimmt einen Transaktions-Hash und gibt die Aufschlüsselung pro Sub-Call und pro CPI für eine Transaktion zurück, die mehrere Aufrufe in einem Batch bündelt. Normale Transaktionen geben `null`, ebenso wie ein Hash, der unbekannt ist oder noch nicht indexiert wurde. ### Nicht unterstützt `debug_traceTransaction` / `trace_*` (Ethereum-style Transaktions-Tracing; sie geben `-32601`), `eth_getProof`, `eth_createAccessList`, `eth_blobBaseFee` (keine Blob-Transaktionen), und die `txpool_*` -Methoden außer `txpool_status` (kein öffentlicher Mempool). `newPendingTransactions` Abonnements werden akzeptiert, lösen aber nie Ereignisse aus. ## Rome-Erweiterungsmethoden Über das standardmäßige Ethereum-RPC hinaus stellt der Proxy `rome_*` -Methoden bereit: | Methode | Zweck | | --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `rome_emulateTx` | Emuliere eine Transaktion off-chain (gibt das Solana-Ausführungsergebnis zurück) | | `rome_emulateTxWithPayer` | Emuliere mit einem bestimmten Zahler | | `rome_emulateCallAccounts` | Emuliere und gib die Solana-Konten zurück, die ein Aufruf berührt | | `rome_emulateRegRollup` | Emuliere eine Rollup-Registrierung | | `rome_getResources` | Berichte den Zustand des Proxy-Ressourcenpools (Zahler, Inhaber) | | `rome_mintId` | Löse die SPL-Mint hinter einem ERC-20-Wrapper auf | | `rome_buildInfo` | Proxy-Build- und On-Chain-Programminformationen | | `rome_isCompatible` | Proxy-/Programm-Kompatibilität prüfen | | `rome_solanaTxForEvmTx` | Hole die Solana-Transaktion(en) für einen EVM-Tx-Hash | | `rome_sendUnsignedTransaction` | Eine nicht signierte Transaktion einreichen (synthetische-Sender-Flows) | | `rome_composeUnsignedAtomicV1` | Erstelle eine einzelne Solana-v1-Transaktion für einen nicht signierten EIP-1559-Body, autorisiert durch die Ed25519-Signatur einer Solana-Wallet; die Wallet signiert sie und die App sendet sie aus. Verweigert, wenn der Aufruf nicht in eine einzige atomare Transaktion passt | | `rome_composeUnsignedIterativeV1` | Dasselbe, gibt aber jede Etappe zurück (atomar, wenn es passt, sonst die iterativen Etappen); die Wallet signiert jede und sendet sie mit `rome_submitSignedV1Plan` | | `rome_submitSignedV1Plan` | Sende einen signierten Plan (bis zu 64 Etappen); der Proxy dient nur als Transport, die Wallet bleibt Fee-Payer | | `rome_relayUnsignedV1` | Eine einzelne Wallet-Signatur, der Zahler des Proxys steuert die Etappen; der synthetische Sender bezahlt Rome-Gas (zuerst mit `rome_composeExternalDepositV1`). Gibt den EVM-Tx-Hash zurück | | `rome_composeExternalDepositV1` | Eine von der Wallet signierte einzelne Transaktion, die das native Gas-Guthaben des synthetischen Senders aus den Tokens der Wallet auflädt | ## Rome-spezifische Verhaltensweisen ### Gas wird aus Solana abgeleitet — schätzen, nicht hart codieren Rome misst die Ausführung in Solana-Compute-Units, die als EVM-Gas angezeigt werden. Der Großteil dessen, was ein Schreibvorgang kostet, ist das Erstellen von Solana-Konten: ein Empfänger, der noch nie verwendet wurde, ein neues Token-Konto, ein bereitgestellter Vertrag. Diese Konten fließen in die Schätzung ein. Praktische Konsequenzen: * **Verwenden Sie `eth_estimateGas`, und nie hart codieren `21000`.** Standard-Tools (`forge create`, `cast`, Hardhat, ethers, viem, MetaMask) rufen sie bereits auf und erhalten einen brauchbaren Wert. Für Aufrufe, die Solana-Programme berühren, füge einen Puffer hinzu (das SDK `submitRomeTx` erhöht um 1,3x) und setze ein Gas-Limit, falls die Schätzung selbst fehlschlägt. Ein hart codiertes `21000` Limit scheitert immer dann, wenn der Schreibvorgang Konten erstellt, zum Beispiel bei einer Überweisung an eine Adresse, die noch nie verwendet wurde. * **Rome berechnet das tatsächlich verwendete Gas.** In den untenstehenden Messungen war das verwendete Gas nie höher als die Schätzung, daher kostet dich eine Schätzung, die über der tatsächlich erledigten Arbeit liegt, nicht die Differenz. * **Lass den Puffer, den dein Tooling hinzufügt.** Der Zustand kann sich zwischen der Schätzung und dem Zeitpunkt, an dem die Transaktion landet, ändern, und die Schätzung für einen Aufruf, der Solana-CPIs ausführt, kann zu niedrig ausfallen. Das SDK `submitRomeTx` erhöht die Schätzung als Puffer um 1,3x. Gemessen auf Hadrian, bei einem Gaspreis von damals etwa 10,4 gwei: | Schreibvorgang | `eth_estimateGas` | Verwendetes Gas | | ------------------------------------------------------------- | ----------------- | --------------- | | Native Überweisung an eine noch nie verwendete Adresse | 1,086,961 | 1,086,961 | | Native Überweisung an eine bestehende Adresse | 21,000 | 10,001 | | wUSDC-Überweisung an eine noch nie verwendete Adresse | 2,544,921 | 2,544,921 | | Gas in wUSDC wrappen (`withdraw_to_ata`) | 21,000 | 10,001 | | Wrapper-Genehmigung (`approve_spl` auf dem Helper-Precompile) | 21,000 | 10,001 | | Einen 10-Byte-Contract bereitstellen | 1,147,921 | 1,147,921 | Das sind Einzelmessungen auf einer Chain, keine Grenzwerte. Die Zahlen hängen davon ab, welche Konten ein Aufruf erstellen muss, also schätze jeden Schreibvorgang statt sie zu übernehmen. ### `forge script --broadcast` benötigt `--skip-simulation` `forge script` setzt sein Broadcast-Gas-Limit aus einer **lokalen** Simulation fest, was bei Romes Gasmodell zu wenig angesetzt ist. Füge `--skip-simulation` also hinzu, damit Foundry stattdessen das der Chain verwendet `eth_estimateGas` stattdessen: ```bash forge script script/Deploy.s.sol:Deploy \ --rpc-url --private-key $PRIVATE_KEY --broadcast --skip-simulation ``` `forge create`, `cast send`und Hardhat sind davon nicht betroffen — sie schätzen bereits on-chain. ### `eth_getLogs` hat ein Bereichslimit (\~12.000 Blöcke) Wie Infura, Alchemy und andere Produktions-RPCs `eth_getLogs` lehnt zu breite Blockbereiche ab (Fehler `-32005`). Begrenze deine Abfragen: ```javascript const latest = await provider.getBlockNumber(); const logs = await contract.queryFilter(filter, latest - 5000, latest); ``` Eine `queryFilter` ohne Bereich durchsucht die gesamte Historie und überschreitet das Limit — übergib explizit `fromBlock`/`toBlock`. Auf Belegen basierende Event-Assertions (z. B. auf eine Tx warten und ihre Logs lesen) sind davon nicht betroffen. ### Gebühren `eth_gasPrice` gibt den echten, vom Orakel abgeleiteten Preis zurück; Wallets (einschließlich MetaMask) verwenden ihn und zeigen korrekte Gebühren an. Übermittelte Fee-Felder werden großzügig akzeptiert — sowohl Legacy- als auch EIP-1559-Transaktionen werden mit den Standardwerten der üblichen Tools angenommen. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.rome.builders/de/referenz/json-rpc.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.