For the complete documentation index, see llms.txt. This page is also available as Markdown.

Token-Interop

Wie ERC-20- und SPL-Token auf Rome denselben zugrunde liegenden Account darstellen.

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.

An ERC-20 wrapper over the same SPL token account on Solana
  • 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 Repo (Git-Abhängigkeit oder kopierte Schnittstellen). Precompile-Schnittstellen befinden sich in 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:

Live-Factory-Adressen: Hadrian 0x86149124d74ebb3aa41a19641b700e88202b6285, Martius 0xd7aeeedca26cdd4d34eb7c21110af2e590a8c58a. Immer gegen das Register — 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; 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:

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

Zuletzt aktualisiert

War das hilfreich?