> 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/entwicklerleitfaden/open-to-solana-users.md). # Öffne deinen Vertrag für Solana-Nutzer Stellen Sie einen Solidity-Vertrag auf Rome (Hadrian-Testnetz, Rubicon-Mainnet) bereit und öffnen Sie ihn für Solana-Wallets — was der Vertrag benötigt, wie ein Solana-Wallet-Nutzer ihn aufruft, Adressen pro Netzwerk und ein Start ch Ein Deployment, zwei Arten von Nutzern. Ein Vertrag auf Rome wird von MetaMask-Nutzern mit ihrem EVM-Schlüssel und von Solana-Wallet-Nutzern (zum Beispiel Solflare) mit ihrem Solana-Schlüssel erreicht — gleiche Adresse, gleicher Zustand. Diese Seite ist der End-to-End-Pfad: deployen, den Vertrag Solana-ready machen, die Solana-Lane in Ihre App einbinden und auf Mainnet ausliefern. ## 1. Auf dem gewünschten Netzwerk deployen Rome-Chains sind standardmäßige EVM-Ziele: Hardhat, Foundry, viem und ethers funktionieren unverändert (vollständige Anleitung in [Solidity-Verträge deployen](/de/entwicklerleitfaden/deploy-solidity.md)). | Netzwerk | Chain-ID | RPC | Explorer | Gas-Token | Wie man Gas erhält | | ------------------------------------------------- | -------- | ------------------------------------------- | ------------------------------------------------------------------------------------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [**Rubicon**](/de/netzwerke/rubicon.md) (Mainnet) | `7531` | `https://rubicon.mainnet.romeprotocol.xyz/` | [via-rubicon.mainnet.romeprotocol.xyz](https://via-rubicon.mainnet.romeprotocol.xyz/) | USDC | Bringen Sie USDC von Ethereum (CCTP) oder von Solana mit dem [Rome Bridge](https://bridge-api.mainnet.romeprotocol.xyz/); es landet als Gas | | **Hadrian** (Testnet) | `200010` | `https://hadrian.testnet.romeprotocol.xyz/` | [via-hadrian.testnet.romeprotocol.xyz](https://via-hadrian.testnet.romeprotocol.xyz/) | Test-USDC | Bringe Test-USDC von einem Testnetz ([Faucets](/de/ressourcen/faucets.md)) oder wickle von einer Solana-Devnet-Wallet in der [Rome App](https://app.devnet.romeprotocol.xyz) | Gas ist auf der EVM-Seite USDC mit 18 Dezimalstellen; es gibt auf keinem Netzwerk einen Rome-Faucet. Schreibvorgänge kosten mehr Gas, als die Ethereum-Intuition vermuten lässt, weil der Großteil der Kosten das Erstellen von Solana-Konten ist: ein noch nie verwendeter Empfänger, ein neues Token-Konto, ein deployter Vertrag. Verwenden Sie `eth_estimateGas`, was Standard-Tooling tut, und hartkodieren Sie niemals 21.000. Gemessen auf Hadrian wurden für das Deployen eines 10-Byte-Vertrags 1.147.921 Gas geschätzt und verwendet, und für eine native Überweisung an eine noch nie verwendete Adresse 1.086.961, gegenüber 21.000 für eine Überweisung an eine vorhandene Adresse. Rome berechnet das tatsächlich verbrauchte Gas, das bei diesen Messungen nie höher als die Schätzung war. Laden Sie vor dem ersten Deploy ein paar USDC auf. Verifizieren Sie die Quelle anschließend im Explorer ([Verträge verifizieren](/de/entwicklerleitfaden/verify-contracts.md); der Mainnet-Verifier ist `https://verify.mainnet.romeprotocol.xyz`). Entwickeln Sie auf Hadrian und deployen Sie dann dieselben Artefakte mit vertauschter Chain-ID und den Mainnet-Wrapper-Adressen erneut auf Rubicon; am Vertrag ändert sich zwischen den Netzwerken nichts. Rubicon ist noch nicht im öffentlichen Register, `create-rome-app` oder `rome-cli` daher können Tools, die Chain-Werte daraus lesen, es nicht ansteuern; füllen Sie die Werte von Hand aus von [Rubicon](/de/netzwerke/rubicon.md). Gas auf Rubicon ist echtes USDC zu etwa dem Zehnfachen von Hadrians Gaspreis, also kostet ein Deploy dort echtes Geld. ## 2. Was einen Vertrag Solana-ready macht Die EVM-Identität eines Solana-Nutzers ist seine **synthetische Adresse**, `keccak256(solana_pubkey)[12:]`: eine gewöhnliche `msg.sender`, mit einem gewöhnlichen Nonce. Die meisten Verträge brauchen überhaupt keine Änderung. Die drei Dinge, die zählen: * **Wert als ERC-20 annehmen, nicht `msg.value`.** Die Gelder eines Solana-Nutzers sind SPL-Token in seiner Wallet und werden auf der EVM-Seite als Wrapper des Tokens gesehen (`wUSDC`, `wETH`, `wSOL`). Der synthetische hält im Ruhezustand nichts, und die Vermögenswerte des Nutzers kommen als Wrapper an, also ziehen Sie mit `transferFrom` nach einem `Genehmigung` und geben Sie zurück mit `transfer`.[Einmalig: dem Wrapper die Erlaubnis geben](/de/entwicklerleitfaden/dual-lane-app.md#one-time-grant-the-wrapper)). Jeder Nutzer gewährt dem Wrapper sein SPL-Delegationsrecht einmal vor dem ersten Pull ( `zahlbar` Einstiegspunkt funktioniert erst, wenn dem synthetischen Konto natives Gas gegeben wurde (des Relay-Pfads `rome_composeExternalDepositV1`), was das Fund-and-Sweep-Modell nicht tut. Ein vorhandener ERC-20-Vault, AMM oder Lending-Markt hat bereits die richtige Form. * **Verwenden Sie die kanonischen Wrapper.** Jede Chain hat einen Wrapper pro Mint; die Adressen stehen in [Contract Addresses](/de/referenz/contract-addresses.md) (Hadrians auch im öffentlichen [Registry](https://github.com/rome-protocol/rome-registry)). Richten Sie Konstruktoren auf diese Adressen aus; deployen Sie nicht Ihre eigenen. * **Passen Sie das atomare Budget dort an, wo eine Wallet signiert.** Eine Solana-Wallet signiert eine Solana-Transaktion, also muss ein Solana-Lane-Call hineinpassen: etwa 1,4 Mio. Compute Units, 64 Konten, 4 KB ([Beschränkungen](/de/kernkonzepte/constraints.md)). Gemessen auf Hadrian: eine Überweisung, ein Approve und ein Aave-Supply passen hinein; ein Uniswap-V3-Swap passt mit wenig Spielraum (etwa 1,24 Mio. CU); ein Aave-Borrow passt nicht und nimmt im nächsten Abschnitt den Relay-Pfad. Messen Sie anhand des Solana-Belegs `computeUnitsConsumed`, indem Sie die Transaktion mit `maxSupportedTransactionVersion: 1` (Rome-Legs sind v1-Transaktionen; ohne sie steht im Feld 0). Was Sie nicht brauchen: ein Solana-Programm, eine Bridge, ein zweites Deployment oder irgendein Rome-spezifisches Solidity. Wenn der Vertrag über die Precompiles auch Solana-Programme aufruft, siehe [Solana aus EVM aufrufen](/de/entwicklerleitfaden/call-solana-from-evm.md). ## 3. Lassen Sie eine Solana-Wallet es aufrufen Der EVM-Pfad Ihrer App bleibt unverändert (MetaMask + `submitRomeTx`, oder einfach viem/ethers). Für den Solana-Pfad gibt es zwei Formen. **Die SDK-Lane — eine Solana-v1-Transaktion pro Aufruf.** [`@rome-protocol/sdk`](https://github.com/rome-protocol/rome-sdk-ts) (`submitRomeTxV1`) lässt den Proxy eine Solana-v1-Transaktion für Ihren EVM-Aufruf zusammenstellen (bis zu 64 Konten und 4 KB, ohne Address Lookup Table; in Ihrem Code gibt es keine ComputeBudget-Instruktion, keine Schatz-Wallet und keine Kontoerkennung). Die Wallet signiert zweimal mit demselben Schlüssel: zuerst eine lesbare Autorisierungsnachricht (`Rome authorization` in einer Zeile, `0x` und den EVM-Transaktions-Hash in der nächsten), die die Chain über das Ed25519-Programm prüft, dann die Transaktion. Die App sendet die signierte Transaktion an den Solana-RPC; der Aufruf liefert den EVM-Transaktions-Hash und dessen Beleg zurück. Bevor die Wallet die Transaktion signiert, prüft der SDK sie: Der Zahler ist der einzige Signer, es laufen nur das Rome-Programm und der Ed25519-Verifier, die Rome-Instruktion enthält genau den vom Nutzer autorisierten Aufruf, und es gibt keine Priority Fee. Alles andere wird abgelehnt. Wenn ein Aufruf nicht in eine Transaktion passt, lehnt der Composer ihn ab und der SDK reicht ihn mit derselben Autorisierungssignatur an den Proxy zum Relay weiter, sodass der Nutzer weiterhin nur eine Autorisierungsabfrage sieht. Das Ergebnis hat dann `route: "relay"`. Die Regeln für relayed Aufrufe und lange Aufrufe stehen in [Weitergeleitete Aufrufe und lange Aufrufe](/de/entwicklerleitfaden/call-evm-from-solana.md#relayed-calls-and-long-calls). Ein relayed Aufruf wird in dem nativen Gas der Chain bezahlt, also benötigt das synthetische Konto ein Gas-Guthaben: `fundSyntheticGas(deps, amountWei)` verschiebt den Gas-Token der Chain (USDC auf Hadrian und Rubicon) in einer von der Wallet signierten v1-Transaktion aus dem Token-Konto der Wallet hinein. Der Fund-Schritt (`buildFundLeg`) und das Erstellen des Wallet-Token-Kontos vor einem Sweep sind einfache Solana-Instruktionen; `submitSolanaInstructionsV1` sendet sie ebenfalls als v1-Transaktionen, signiert vom selben Wallet-Signer, ohne dass ein Proxy beteiligt ist. Der eigentliche Aufruf des Sweep (`buildSweepLeg`, `HelperProgram.transfer_spl`läuft über `submitRomeTxV1` wie jeder andere, und der Proxy findet die Token-Konten. `submitRomeTxV1` legt nicht von selbst ein neues Konto des synthetischen an: Prüfen Sie vor dem ersten wertbewegenden Aufruf `isSyntheticProvisioned(...)` und senden Sie, wenn es false ist, `buildCreatePdaCall(synthetic)` durch `submitRomeTxV1` einmal. Eine vollständige Einzahlungs-und-Abhebungs-Anleitung mit Code steht in [Eine Dual-Lane-App bauen](/de/entwicklerleitfaden/dual-lane-app.md); die Mechanik steht in [EVM aus Solana aufrufen](/de/entwicklerleitfaden/call-evm-from-solana.md). Die frühere `submitRomeTxSolanaLane`, das im Client eine Legacy-Solana-Transaktion baut, ist im SDK weiterhin als älterer Pfad vorhanden. **Woher jeder `deps` Wert kommt.** des SDKs `deps` Objekt hat fünf erforderliche Felder (der Rest, wie `fetchImpl` und die Timeouts, sind optional). Vier kommen von der Chain und eines von der Wallet: | `deps` Feld | Woher sie kommt | Registry-Getter (`@rome-protocol/registry` v0.2.0) | | ------------ | ---------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | `proxyUrl` | die RPC-URL der Chain | `getChain(chainId).rpcUrl` | | `chainId` | die Chain-ID | `getChain(chainId).chainId` | | `programId` | die Rome-Programm-ID, auf der die Chain läuft | `getChain(chainId).romeEvmProgramId` | | `connection` | ein Solana-RPC für den Cluster der Chain, an den die signierte Transaktion gesendet wird (Devnet für Hadrian, Mainnet für Rubicon) | `getChain(chainId).solana.rpc` (eine öffentliche Devnet-URL für Hadrian); für Mainnet verwenden Sie einen eigenen RPC | | `signer` | der Wallet `LaneSigner`, oder ein `Keypair` in Skripten | keine | Die Leg-Builder nehmen Werte, die nicht in `deps`. Ihr `mint` (genannt `usdcMint` in der Anleitung) ist der Solana-Mint des Gas-Tokens, aus `getTokens(chainId)` (der Eintrag mit `kind: "gas"`, Feld `mintId`). Die wUSDC-Wrapper-Adresse ist kein Eingabewert für den Leg-Builder; Sie verwenden sie für die ERC-20-Aufrufe, und es ist der Eintrag mit `kind: "spl_wrapper"` und Symbol `wUSDC` (Feld `Adresse`). Das Registry deckt Hadrian ab. Für Rubicon füllen Sie sie von Hand aus: `proxyUrl` `https://rubicon.mainnet.romeprotocol.xyz/`, `chainId` `7531`, `programId` `RomePq9X3iAoTr813HR7uRarafFDUJty6GdiEceYpzX`, `mint` `EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v`, den Wrapper aus der Tabelle im nächsten Abschnitt und einen Solana-Mainnet-RPC für `connection`. [Rubicon](/de/netzwerke/rubicon.md) enthält die vollständige Liste. **Die externen V1-Endpunkte des Proxys — dieselbe Lane ohne das SDK.** Das SDK kapselt das atomare Compose, das Relay und die Gas-Einzahlung (`fundSyntheticGas`). Die rohen RPC-Methoden bleiben für Clients erhalten, die das SDK nicht nutzen, und sie enthalten das iterative Compose, das das SDK nicht kapselt. Die Wallet signiert eine Ed25519-Nachricht über den Aufruf (die lesbare Form `Rome-Autorisierung\n0x` oder den rohen Hash), und der Proxy entweder setzt die Solana-Transaktion(en) für die Wallet zum Signieren zusammen (`rome_composeUnsignedAtomicV1`, `rome_composeUnsignedIterativeV1` + `rome_submitSignedV1Plan`) oder führt die gesamte Ausführung selbst mit einer Wallet-Signatur aus (`rome_relayUnsignedV1`, nach einem `rome_composeExternalDepositV1` (des SDKs `fundSyntheticGas`) das das Gas-Guthaben des synthetischen Kontos auffüllt; weitergeleitete Aufrufe verbrauchen daraus, also füllen Sie es nach, wenn es knapp wird). [JSON-RPC-Unterstützung](/de/referenz/json-rpc.md); die Autorisierungsregeln in [EVM aus Solana aufrufen](/de/entwicklerleitfaden/call-evm-from-solana.md#the-external-v1-endpoints). Verwenden Sie das Relay für alles Iterative und die SDK-Lane für alles, was hineinpasst. So oder so sieht der Vertrag eine normale Transaktion von der synthetischen Adresse, und der Nutzer hält niemals einen EVM-Schlüssel. ## 4. Wrapper-Adressen pro Netzwerk | Netzwerk | `wUSDC` Wrapper | Andere Wrapper | | ---------------- | -------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | Rubicon (7531) | `0x0952d233b0c254cd375f3bfb3e5869c1a906f9b3` | `wETH` `0x01e8b3573da1d4b7b4b1ce0932cf07c8af0c92e9`, `wSOL` `0xc4e29e0f726a906e93277cbbc37bf27a9848a113` | | Hadrian (200010) | `0xbce339ba4c3a8de3bb8af1c5539e6ac11da3112d` | `wETH` `0x02aeace038269f9961c93d04dcacd6fb3adfa55f`, `wSOL` `0x39f36444fcb79b3e691544aee2a832ebef54ca9f` | Der native Gas-Token erscheint als `0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee` in Tokenlisten; er ist kein ERC-20-Vertrag. Wrapper tragen die Dezimalstellen des SPL-Mints, nicht 18: wUSDC 6, wETH 8, wSOL 9. ## 5. Launch-Checkliste 1. Auf Hadrian deployt; der EVM-Pfad funktioniert mit MetaMask. 2. Jeder wertbewegende Einstiegspunkt basiert auf ERC-20 und zeigt auf den kanonischen Wrapper der Chain. 3. Eine Solana-Wallet, die v1-Transaktionen signiert (Solflare tut das heute auf Devnet; Phantom noch nicht), durchläuft den vollständigen Roundtrip auf Hadrian: das synthetische Konto bereitstellen (`create_pda`, einmal) → Fund-Schritt → Berechtigung erteilen → Approve → Aufruf → Sweep-Schritt, über die SDK-Lane; oder den Relay-Pfad, wenn der Aufruf iterativ ist. 4. Des Solana-Lane-Aufrufs `computeUnitsConsumed` wird aus dem Solana-Beleg ausgelesen und liegt unter dem atomaren Budget, oder der Aufruf wird über das Relay geleitet. 5. Die Wrapper-Erteilung befindet sich im First-Deposit-Flow Ihrer App für beide Lanes: `isEnabled(user)` wird geprüft und `approve_spl` einmal gesendet, wenn es false ist ([Einmalig: dem Wrapper die Erlaubnis geben](/de/entwicklerleitfaden/dual-lane-app.md#one-time-grant-the-wrapper)). 6. Quellcode im Explorer verifiziert. 7. Mit den Mainnet-Wrapper-Adressen auf Rubicon erneut deployt. Rubicon ist nicht im Registry, daher werden seine `deps` Werte von Hand ergänzt aus [Rubicon](/de/netzwerke/rubicon.md). Der gleiche Roundtrip wird einmal mit echten Mitteln ausgeführt, mit einer Wallet, von der Sie geprüft haben, dass sie v1-Transaktionen auf Mainnet signiert. ## Was als Nächstes kommt * [Eine Dual-Lane-App bauen](/de/entwicklerleitfaden/dual-lane-app.md) — das Vault-Beispiel, Schritt für Schritt, beide Wallets * [EVM aus Solana aufrufen](/de/entwicklerleitfaden/call-evm-from-solana.md) — synthetische Adressen, Kontenerkennung, die externen V1-Endpunkte * [Solidity-Verträge deployen](/de/entwicklerleitfaden/deploy-solidity.md) · [Verträge verifizieren](/de/entwicklerleitfaden/verify-contracts.md) · [Contract Addresses](/de/referenz/contract-addresses.md) --- # 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/entwicklerleitfaden/open-to-solana-users.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.