> 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/kernkonzepte/token-interop.md).

# Token-Interop

Rome repräsentiert ein ERC-20-Token und sein zugrunde liegendes SPL-Token als ein gemeinsam genutztes Konto. Diese Seite erklärt, wie Tokens über EVM und Solana hinweg funktionieren.

## Das Modell des gemeinsam genutzten Zustands

Rome sperrt keine Tokens auf der einen Seite und prägt auf der anderen keine gewrappten Kopien. Ein ERC-20-Token auf Rome ist ein **transparenter Wrapper** über einem SPL-Token-Konto auf Solana — der ERC-20-Saldo *ist* der SPL-Saldo.

<figure><img src="/files/71f85e4009afc537ccf4546acc12af5bfa99b72f" alt="An ERC-20 wrapper over the same SPL token account on Solana"><figcaption></figcaption></figure>

* Keine Bridging-Verzögerung — der ERC-20-Saldo ist der SPL-Saldo
* Keine Liquiditätsfragmentierung — DeFi auf beiden Seiten sieht dieselben Tokens
* Kein Bridge-Risiko — es gibt kein separates Treuhandkonto, das ausgenutzt werden könnte

> Die Importpfade unten verwenden `@rome-protocol/rome-solidity`. Die npm-Veröffentlichung steht noch aus; heute beziehst du diese aus dem öffentlichen [`rome-solidity`](https://github.com/rome-protocol/rome-solidity) Repo (Git-Abhängigkeit oder kopierte Schnittstellen). Precompile-Schnittstellen befinden sich in [`contracts/interface.sol`](https://github.com/rome-protocol/rome-solidity/blob/master/contracts/interface.sol).

## Der Wrapper-Vertrag

`SPL_ERC20` (und seine gecachte Track-Variante `SPL_ERC20_cached`, die die Factory heute bereitstellt) bieten eine vollständige ERC-20-Schnittstelle über einen SPL-Mint:

* `balanceOf()` — liest den ATA-Saldo des Benutzers von Solana
* `transfer()` — bewegt Tokens auf Solana
* `approve()` / `allowance()` — verwenden EVM-Speicher (SPL hat keine EVM-artigen Allowances)
* `totalSupply()` — liest das Gesamtangebot des SPL-Mints

## Die Factory

`ERC20SPLFactory` stellt für jeden beliebigen SPL-Mint einen Wrapper bereit:

```solidity
import {ERC20SPLFactory} from "@rome-protocol/rome-solidity/contracts/erc20spl/erc20spl_factory.sol";

// Einen Wrapper bereitstellen und Name/Symbol aus den Metaplex-Metadaten laden
address wrapper = factory.add_spl_token_with_metadata(splMint);

// Oder Name/Symbol manuell angeben
address wrapper = factory.add_spl_token_no_metadata(splMint, "USD Coin", "USDC");
```

Live-Factory-Adressen: Hadrian `0x86149124d74ebb3aa41a19641b700e88202b6285`, Martius `0xd7aeeedca26cdd4d34eb7c21110af2e590a8c58a`. Immer gegen das [Register](https://github.com/rome-protocol/rome-registry/tree/main/chains) — es ist die Quelle der Wahrheit für bereitgestellte Adressen.

## Kanonische Mints

Es gibt keinen On-Chain-Token-Registry-Vertrag. Kanonische Wrapper und Gas-/Bridge-Tokens werden im Off-Chain- [`rome-protocol/registry`](https://github.com/rome-protocol/rome-registry); erlaubnisfreie Wrapper, die über `add_spl_token_no_metadata` erstellt werden, werden anhand des On-Chain- `TokenCreated` Ereignisses entdeckt. Dadurch wird jedes Asset einem einzigen kanonischen SPL-Mint zugeordnet, ohne die Liquidität zu fragmentieren.

## SPL-Operationen aus Solidity

Für vom Benutzer-PDA signierte SPL-Grundoperationen verwende das **HelperProgram** Precompile (`0xFF…09`) — ATA-Erstellung, SPL-Übertragungen und Gas↔Lamports-Konvertierung:

```solidity
import {IHelperProgram} from "@rome-protocol/rome-solidity/contracts/interface.sol";

IHelperProgram helper = IHelperProgram(0xFF00000000000000000000000000000000000009);

helper.create_ata(user, mint);              // ATA des Benutzers für einen Mint erstellen
helper.transfer_spl(to, tokens, mint);      // SPL vom PDA des Aufrufers übertragen
```

`transfer_spl` hat mehrere Überladungen (einschließlich einer Delegate-Variante für `transferFrom` Abläufe); siehe `interface.sol` für genaue Signaturen. Auf dem gecachten Track liegen die entsprechenden Operationen auf `ISplCached` (`0xFF…05`) und `IAssociatedSplCached` (`0xFF…06`). Ein Vertrag verwendet konsequent nur einen Track.

## Einzahlen und abheben

* **In die EVM** — die SPL-Seite schreibt dem vom Benutzer-PDA besessenen ATA Guthaben gut; der ERC-20-Wrapper spiegelt den Saldo sofort wider. Cross-Chain-Einzahlungen werden vertrauenslos über eine vom Benutzer signierte Autorisierung auf der Bridge abgewickelt.
* **Nach Solana** — rufe den `Abheben` Precompile (`0x42…16`): `withdraw_to_pda` / `withdraw_to_ata` verschiebt Tokens vom PDA des Benutzers zurück nach Solana. Der Pfad vom Umpacken von Gas zu SPL ist `withdraw_to_ata`.

## Gas-Token

Jede Chain hat ihren eigenen Gas-Token — ein beliebiger SPL-Token, bepreist über einen Meteora-DAMM-Pool (v1 oder v2, konfigurierbar). Die öffentlichen Chains (Martius, Hadrian) verwenden USDC. Es gibt keinen universellen Standard-Gas-Token.

## Beschränkungen

* SPL-Tokenbeträge sind `uint64` (max. 18.446.744.073.709.551.615)
* Allowances verwenden EVM-Speicher, nicht Solana-Delegates
* ERC-20-Wrapper-Symbole müssen pro Factory eindeutig sein

## Was kommt als Nächstes

* [Vertragsadressen](/de/referenz/contract-addresses.md) — Precompiles und Adressen je Chain
* [Rufe Solana aus der EVM auf](/de/entwicklerleitfaden/call-solana-from-evm.md) — CPI und SPL-Operationen aus Solidity


---

# 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/kernkonzepte/token-interop.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.
