> 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/call-evm-from-solana.md).

# EVM von Solana aus aufrufen

Das Gegenstück zu [Solana von EVM aus aufrufen](/de/entwicklerleitfaden/call-solana-from-evm.md): Eine Solana-Wallet (z. B. Phantom) ruft direkt einen beliebigen EVM-Contract auf Rome auf, mit **ohne Ethereum-Schlüssel**. So [Aerarium](/de/apps-auf-rome/apps.md) und [Rome DEX](/de/apps-auf-rome/apps.md) ermöglichen es Solana-nativen Nutzern, dieselben Contracts wie EVM-Nutzer zu nutzen.

Der Einmalaufruf-Weg ist die des SDKs `submitRomeTxSolanaLane`; diese Seite erklärt, was es tut.

## Synthetische Adressen

Die EVM-Identität einer Solana-Wallet ist ihre **synthetische Adresse** — die letzten 20 Bytes des `keccak256` ihres 32-Byte-Solana-Public-Keys:

```
synthetic_evm_address = keccak256(solana_pubkey)[12:]
```

Dies ist der `msg.sender` wenn die Wallet einen Contract aufruft, und die stabile Identität, unter der ihr Nonce und ihr Speicher liegen. Die Ableitung ist im Protokoll fest verankert, sodass eine Wallet immer derselben Adresse zugeordnet wird.

```javascript
import { syntheticAddress } from "@rome-protocol/sdk";
const from = syntheticAddress(solanaPubkey); // 0x… 20 Bytes
```

## Das Synthetic ist nur ein Durchleiter — es hält im Ruhezustand keine Tokens

Das ausgebbare Guthaben eines Solana-nativen Nutzers liegt in seiner **Solana-Wallet** (als SPL-Token), auf der EVM-Seite 1:1 als **ERC20SPL-Wrapper** (z. B. `wUSDC`). Das Synthetic hält im Ruhezustand nichts, sodass der Wert fließt *durch* es — jeder Schritt von der Solana-Wallet signiert:

1. **Bereitstellung (einmalig).** Das externe Auth-PDA eines brandneuen Synthetic existiert nicht, bis `create_pda` ausgeführt wird — und die untenstehenden Transfers von diesem PDA signiert werden. `submitRomeTxSolanaLane` stellt es bei der ersten Verwendung automatisch bereit (oder rufe `provisionSynthetic` für einen expliziten „Aktivieren“-Schritt auf; prüfe mit `isSyntheticProvisioned`).
2. **Finanzierungspfad (Wallet → Synthetic).** Verschiebe den Token aus dem ATA der Wallet in den des Synthetic — der `ActivateAta` Schritt, erstellt von `buildFundLeg`. Jetzt `wrapper.balanceOf(synthetic)` liest dieses Guthaben, sodass der Synthetic es als gewöhnlichen ERC-20 ausgibt (`transfer` / `transferFrom`) — **nicht** als nativer `msg.value`, den er nicht hält.
3. **Der/die Aufruf(e) (`DoTxUnsigned`).** Das Synthetic führt die EVM-Transaktion(en) aus — z. B. `approve` dann ein Vault `deposit` das zieht über `transferFrom`.
4. **Sweep-Pfad (Synthetic → Wallet).** Nachdem ein withdraw / borrow / claim Tokens im Synthetic landen lässt, `buildSweepLeg` schiebt sie zurück in das ATA der Wallet des Nutzers (`HelperProgram.transfer_spl`), sodass das Synthetic netto auf null kommt.

## Wie der Aufruf gebaut wird

`submitRomeTxSolanaLane` erledigt all das. Die Mechanik:

1. **Erstelle eine unsignierte EIP-1559-Transaktion** mit `von` = der synthetischen Adresse — keine secp256k1-Signatur.
2. **Konten ermitteln** — rufe [`rome_emulateCallAccounts`](/de/referenz/json-rpc.md) mit dem `von`, `to`, `Daten`, **und `Wert`** (wenn der Aufruf payable ist). Das Übergeben von `Wert` ist wichtig: Der Proxy emuliert den *echten* Aufruf, sodass jeder wertabhängige Speicher-Schreibvorgang — z. B. ein neuer Mapping-Slot — angelegt wird und sein Solana-Konto zurückgegeben wird. Lässt du es weg, fehlt dieses Konto, und die Transaktion schlägt fehl mit *"instruction modified data of a read-only account."*
3. **Stelle die Solana-Transaktion zusammen:** zwei **ComputeBudget** Anweisungen (Rome's EVM benötigt ein erhöhtes CU-Limit von ca. 1,35 Mio. und einen großen Heap-Frame von ca. 250 KB — Solanas Standardwerte führen zu einem Fehler) + die **`DoTxUnsigned`** Anweisung (das unsignierte RLP + die ermittelten Konten) + der kettenbezogene **Treasury-Wallet** (die Ausführung zahlt ihr eine kleine Gebühr; die Ermittlung lässt sie weg, daher hängt das SDK sie an).
4. **Die Wallet signiert und sendet ab.** Die **Solana-Wallet signiert die Solana-Transaktion (Ed25519) und sendet sie an das Solana-RPC — nicht an den Proxy.** Die Solana-Runtime überprüft die Signatur; on-chain leitet das Programm `msg.sender` daraus den entsprechenden Wert ab. Die Autorität ist die Solana-Signatur, nicht eine Ethereum-Signatur. (Der Proxy wird nur für die Emulation/Ermittlung in Schritt 2 verwendet.)

Das PDA des Nutzers (`["EXTERNAL_AUTHORITY", synthetic_address]`) besitzt seine Token-Konten und signiert SPL-CPIs in ihrem Namen — sodass ein Solana-Nutzer vollständig aus Phantom heraus bereitstellen, leihen, tauschen und Liquidität bereitstellen kann.

## Referenzimplementierungen

* **Aerarium** — steuert Compound v3 (supply / borrow) aus Phantom heraus über `DoTxUnsigned`.
* **Rome DEX** — die Solana-Lane handelt und stellt Liquidität im selben Pool wie die EVM-Lane bereit.

Beide sind Solana-nativ, ohne Bridge oder zweite Wallet — die synthetische Adresse macht einen Phantom-Schlüssel zu einem vollwertigen EVM-Konto.

## Wie geht es weiter

* [Solana von EVM aus aufrufen](/de/entwicklerleitfaden/call-solana-from-evm.md) — die andere Richtung, via CPI
* [Token-Interop](/de/wichtige-konzepte/token-interop.md) — wie Guthaben zwischen EVM und Solana geteilt werden


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.rome.builders/de/entwicklerleitfaden/call-evm-from-solana.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.