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.
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 öffentlichenrome-solidityRepo (Git-Abhängigkeit oder kopierte Schnittstellen). Precompile-Schnittstellen befinden sich incontracts/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 Solanatransfer()— bewegt Tokens auf Solanaapprove()/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
AbhebenPrecompile (0x42…16):withdraw_to_pda/withdraw_to_ataverschiebt Tokens vom PDA des Benutzers zurück nach Solana. Der Pfad vom Umpacken von Gas zu SPL istwithdraw_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 — Precompiles und Adressen je Chain
Rufe Solana aus der EVM auf — CPI und SPL-Operationen aus Solidity
Zuletzt aktualisiert
War das hilfreich?