> 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/from-home.md).

# Von zu Hause aus: Rome von einer anderen Chain aus erreichen

Lass Nutzer auf einer anderen Chain deine Rome-App erreichen, ohne ihr Zuhause zu verlassen — Vermögenswerte hineinbringen, handeln und wieder herausnehmen.

Ihre Nutzer müssen nicht nach Rom wechseln. Von ihrer Heimat-Chain — einem L2 wie Arbitrum oder Monad oder Solana — bringen sie Vermögenswerte ein, nutzen Ihre Rome-App und nehmen Vermögenswerte wieder heraus. Die Bridge läuft on-chain und ist durch die eigene Signatur des Nutzers autorisiert; Sie binden Ihre App über eine einzige API daran an.

## Wie es funktioniert

* **Inbound (Heimat → Rome):** auf dem Gas-Token-USDC-Pfad über CCTP, die `settle_inbound_bridge_v2` Anweisung des Rome-Programms schreibt dem Nutzer unter einer signierten **EIP-712** `SettleAuthorization`, sodass es keinen privilegierten Settler gibt. Die anderen Inbound-Pfade verwenden diese Anweisung oder Signatur nicht. Wrapper-USDC, ETH über Wormhole und SOL landen direkt als Wrapper-Token im Konto des Nutzers. Solana-USDC auf einer Chain, deren Gas-Token USDC ist, benötigt noch eine weitere, vom Nutzer signierte Transaktion, um den Wrapper in Gas umzuwandeln. Das Quote sagt Ihnen, welche Signaturen ein Pfad benötigt.
* **Outbound (Rome → Heimat):** `RomeBridgeWithdraw` (in [`rome-solidity`](https://github.com/rome-protocol/rome-solidity))
* **Transport:** Circle **CCTP** für USDC und den **Wormhole** Token-Bridge für ETH. Solana-Home-Chains verwenden einfache SPL-Transfers hinein und einen Rome-Withdraw hinaus. Wormhole ist die Inbound-Transportstrecke nur für ETH. Es gibt einen generischen Wormhole-Pfad nur für Outbound, und jeder Asset darauf muss zuerst von den Rome-Operatoren aktiviert werden.
* **Orchestrierung:** der Off-Chain- [`rome-bridge-api`](https://github.com/rome-protocol/rome-bridge-api) gibt ein Angebot für einen Pfad ab, verifiziert die Transaktion auf der Quell-Chain und übernimmt die Gebühr für das Abwickeln. Es hält weder Gelder noch Schlüssel. Es kann nur auslösen, was der Nutzer bereits signiert hat.

## Erstellen Sie es

Die API ist auf dem Devnet öffentlich unter `https://bridge-api.devnet.romeprotocol.xyz`. `GET /v1/routes` listet jede aktive Route auf (Asset, Transportstrecke, Richtung, Quell-Chain, Rome-Chain, Geschwindigkeiten). Die untenstehenden Aufrufe sind dieselben vier, die das SDK in `@rome-protocol/sdk/bridge` (`requestQuote`, `registerTransfer`, `getTransfer`, `reportStep`). Die CLI führt den gesamten Ablauf für Sie aus: `rome fund` und `rome bridge` für die Transfers und `rome verify --path from-home` für einen Hin- und Rückweg, wie auf der [Rome CLI](/de/produkte/rome-cli.md) Seite.

### Vermögenswerte einbringen

1. **Den Pfad veranschlagen.** Senden Sie die Quell-Chain, das Asset, den Betrag und die Adressen des Nutzers. Chains werden als CAIP-2-IDs angegeben, etwa `eip155:84532`; `romeChainId` ist Ihre Rome-Chain. Die älteren Namen `ethereum` und `solana` werden weiterhin akzeptiert, sind aber veraltet, und die API markiert diese Antworten mit einem `Sunset` Header. Die vollständigen Request- und Response-Strukturen finden Sie in der [API-Referenz](https://github.com/rome-protocol/rome-bridge-api/blob/main/docs/API.md).

   ```bash
   curl -X POST https://bridge-api.devnet.romeprotocol.xyz/v1/quote \\
     -H 'Content-Type: application/json' \\
     -d '{
       "asset": "USDC",
       "direction": "to-rome",
       "sourceChain": "eip155:84532",
       "romeChainId": "200010",
       "amount": "1000000",
       "sender": { "ethereum": "0xUSER" },
       "recipient": "0xUSER"
     }'
   ```

   Beträge sind Ganzzahlen in Basiseinheiten als Strings (`"1000000"` ist 1 USDC). ETH-Beträge sind in wei und müssen auf dem Weg hinaus ein Vielfaches von 10.000.000.000 wei sein (der Wrapper hat 8 Dezimalstellen); die API lehnt alles Feinere ab. Die Antwort listet die `Schritte`. Der Nutzer signiert die Transaktionen jedes Schritts, der mit `userSigns: true`, in der Reihenfolge der Schritte: EVM-Transaktionen stehen in `unsignedTxs`, Solana-Anweisungen in `unsignedTx`. Signieren Sie sie exakt so, wie sie zurückgegeben werden. Schritte, bei denen nichts zu signieren ist, werden vom Sponsor ausgeführt, sobald Circle oder Wormhole den Transfer bestätigt hat. Der Outbound-Claim ist die Ausnahme, beschrieben unten: Der Nutzer erstellt ihn.
2. **Lassen Sie den Nutzer signieren.** Für ein CCTP-Quote ist das die USDC-Freigabe und das Burnen auf der Quell-Chain. Wenn das Quote einen Eintrag in `signatureRequests`, signiert der Nutzer außerdem diese EIP-712- `SettleAuthorization` sobald der Burn-Hash bekannt ist; fügen Sie den Burn-Hash ein und übergeben Sie das Ergebnis in der nächsten Aufruf als `userSettleSig` mit. Nur der CCTP-Pfad für das Gas-Token hat einen. Wormhole-ETH, Wrapper-Intent-USDC und Solana-Pfade haben keinen.
3. **Den Transfer registrieren.** `POST /v1/transfers` mit dem vollständigen Quote und `step1TxHash`dem Hash der letzten Transaktion im ersten Schritt (dem Burn). Die API prüft, dass die Transaktion auf der Quell-Chain zum Quote passt, und gibt eine Transfer- `ID`.
4. **Abfragen** `GET /v1/transfers/{id}` alle paar Sekunden, bis `Ergebnis` ist `abgeschlossen`. Der Nutzer ist dann auf Rome finanziert und kann Ihre App verwenden.

Solana-Home-Chains folgen derselben Form mit anderen Schritten. Der Nutzer sendet eine SPL-Überweisung an das Token-Konto seines Rome-Kontos. SOL kommt nach dieser einen Überweisung als gewrapped SOL an. Auf einer Chain, deren Gas-Token USDC ist, wie Hadrian, braucht USDC einen zweiten Schritt: eine Rome-Transaktion, die der Nutzer signiert und die den gelandeten Wrapper in natives Gas umwandelt. Jeder andere SPL-Token läuft über die `spl-solana-to-rome` Route, die das Mint in `splAsset`.

### Vermögenswerte wieder herausnehmen

Das Bridging hinaus ist nicht der Inbound-Fluss rückwärts. Es erfordert mehr als eine Signatur, und der Nutzer schließt es auf der Home-Chain ab. Veranschlagen Sie es mit `direction` gesetzt auf `from-rome`. `sourceChain` bezeichnet die Nicht-Rome-Seite und `destinationChainId` wählt die Chain aus, auf der der Nutzer den Anspruch geltend macht. Übergeben Sie beides: `destinationChainId` legt fest, welche Chain für den Claim verwendet wird, und ein Quote ohne sie verwendet standardmäßig Ethereum Sepolia, was auch immer `sourceChain` sagt:

```bash
curl -X POST https://bridge-api.devnet.romeprotocol.xyz/v1/quote \\
  -H 'Content-Type: application/json' \\
  -d '{
    "asset": "USDC",
    "direction": "from-rome",
    "sourceChain": "eip155:84532",
    "destinationChainId": 84532,
    "romeChainId": "200010",
    "amount": "1000000",
    "sender": { "rome": "0xUSER" },
    "recipient": "0xUSER"
  }'
```

Für USDC über CCTP gibt das Quote zwei Schritte zurück, und der Nutzer signiert beide:

1. **Auf Rome, zwei Transaktionen in dieser Reihenfolge.** Die erste gewährt `RomeBridgeWithdraw` Delegationsrechte über das wUSDC des Nutzers auf Solana (`approve_spl`). Die Gewährung deckt genau den Betrag dieses Burns ab, daher enthält das Quote sie jedes Mal, und der Nutzer signiert sie vor jedem Burn. Die zweite brennt das wUSDC über `RomeBridgeWithdraw`wodurch der CCTP-Transfer gestartet wird. Registrieren Sie den Transfer mit dem Hash des Burns. Der Burn verbraucht wUSDC, das Token, das das Quote als `burnToken`angibt, nicht das native Gas-USDC. Mittel, die als Gas hereinkamen, sind nicht das, was geburnt wird, also bringen Sie für einen Hin- und Rückweg USDC mit `intent: "wrapper"`.
2. **Auf der Ziel-Chain der Claim.** Abfragen `GET /v1/transfers/{id}` bis Schritt 2 `bereit`. Er trägt dann die `Nachricht` und `Attestierung`. Der Nutzer ruft `receiveMessage(message, attestation)` auf dem Message-Transmitter von Circle auf der Ziel-Chain auf (das Quote nennt den Transmitter und die CCTP-Domain). Hier wird nichts gesponsert, daher benötigt der Nutzer dort Gas. Melden Sie den Claim-Hash mit `POST /v1/transfers/{id}/steps/2`.

ETH über Wormhole hat dieselbe Form. Der Nutzer gewährt dieselben Delegationsrechte über wETH, brennt wETH auf Rome und wartet darauf, dass die Wormhole-Guardians signieren. Dann löst der Nutzer auf Ethereum mit seiner eigenen Transaktion ein: `completeTransferAndUnwrapETH` auf der Token-Bridge, die das Quote nennt (`claimTokenBridge`), mit der signierten Nachricht (`vaa`) aus Schritt 2.

Das Abheben auf eine Solana-Adresse hat keinen Claim-Schritt. USDC ist eine einzige Rome-Transaktion, die auf das Solana-Konto des Nutzers auszahlt. SOL ist ein Rome-Schritt mit drei Transaktionen: dieselbe Delegationsgewährung über wSOL, die optionale Erstellung des wSOL-Token-Kontos des Empfängers auf Solana (übersprungen, wenn es bereits existiert), und der Withdraw über `RomeBridgeWithdraw`.

**Erster Outbound-Transfer braucht ein aktiviertes Konto.** Ein CCTP-Burn erstellt ein Message-Konto auf Solana, und das Konto des Nutzers auf Rome muss genügend Lamports haben, um es zu bezahlen. Eine neue Wallet hat das nicht, daher schlägt der erste Outbound-Transfer fehl, bis der Nutzer es einmal aktiviert. Die Prüfung ist, dass das Konto mindestens 15.000.000 Lamports hält. Lesen Sie sie mit `account_lamports(bytes32)` auf dem CPI-Precompile bei `0xff00000000000000000000000000000000000008`, wobei Sie das externe Auth-Konto des Nutzers auf Solana übergeben (die CLI liest dies für Sie aus). Die Aktivierung ruft `activate()` auf dem `SimpleActivator` Vertrag auf, der im [Registry](https://github.com/rome-protocol/rome-registry) für Ihre Chain aufgeführt ist, und der Aufruf enthält eine Zahlung im Gas-Token der Chain. Auf Hadrian sind das 2 USDC. Die CLI macht das mit `rome activate <chain>`, und `rome bridge --to` hält an und sagt Ihnen, dass Sie es ausführen sollen, wenn das Konto nicht bereit ist. Die Reserve deckt einen Burn ab, und die Miete kommt zurück, nachdem Circle den Burn attestiert hat, was etwa 30 Minuten dauert. Ein zweiter Burn davor oder ein Konto, das seit der Aktivierung leergeräumt wurde, braucht `topUpUserPda(lamports)` auf demselben Vertrag, weil `activate()` abgelehnt wird, sobald das Konto aktiviert wurde. `rome activate` wählt den richtigen Aufruf. Inbound-Transfers brauchen keine Aktivierung. Das Quote enthält die Aktivierung nicht als Schritt, daher muss Ihre App das Konto prüfen und sie vor dem ersten Outbound-Quote anbieten.

## Lesen Sie den Code

* [appia](https://github.com/rome-protocol/appia) — eine From-Home-App: Nutzer bringen USDC von ihrer Home-Chain und nutzen Rome-seitiges DeFi, ohne es zu verlassen.
* [rome-bridge-api](https://github.com/rome-protocol/rome-bridge-api) — der Orchestrator (Quote → verify → sponsor).

## Was als Nächstes kommt

* [Finanzierung erhalten](/de/ressourcen/faucets.md) — derselbe Bridge-Pfad finanziert eine frische Dev-Wallet.
* [Solidity deployen](/de/entwicklerleitfaden/deploy-solidity.md) — platzieren Sie Ihre App auf Rome.


---

# 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/from-home.md?ask=<question>&goal=<user_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.
