ERC-20, SPL und Jetton beantworten eine einzige Frage auf drei Arten: Wo wird die Zahl gespeichert, die dein Guthaben festhält? Ethereum hält die Guthaben aller Inhaber in einem einzigen gemeinsamen Token-Contract, Solana in einem separaten Token-Account pro Inhaber und TON in einem separaten Contract pro Inhaber. Dieser Unterschied erklärt Approvals, Gebühren und die meisten Fehlerfälle — und warum derselbe Ticker auf jeder Chain ein anderer Token ist. Wallets, die alle drei abdecken, etwa WATS, das EVM, Solana und TON unterstützt, Bitcoin aber nicht nativ, müssen alle drei Grammatiken beherrschen.
Was ein "Token-Standard" wirklich ist
Ein Token-Standard ist eine vereinbarte Schnittstelle: Funktionsnamen, Nachrichtenformate und Events, auf die sich Wallets und Börsen verlassen. Darunter liegt ganz gewöhnlicher Code — und wie die jeweilige Chain diesen Code ausführt, bestimmt, was ein Token überhaupt sein kann.
ERC-20, SPL und Jettons sind nicht drei Dialekte derselben Sache. Sie beantworten eine einzige Frage auf drei Arten: Wo liegt eigentlich die Zahl, die sagt "dir gehören 500 Token"? Ethereum hält sie in einem einzigen gemeinsamen Contract, Solana in einem separaten Account pro Inhaber, TON in einem separaten Contract pro Inhaber — Speichermodelle, die fast jede praktische Eigenheit erklären, aufbauend auf der Architektur, die in EVM, Solana und TON verglichen wird.
ERC-20 auf Ethereum: Ein Contract hält die Guthaben aller
Ein ERC-20-Token ist ein Smart Contract an einer Adresse, der ein Ledger führt, das Adressen auf Zahlen abbildet. Du "hältst" den Token nicht; der Contract hält einen Vermerk, dass deiner Adresse ein Betrag zusteht.
Ein Transfer ist ein Aufruf an den Token-Contract, der eine Zeile verringert und eine andere erhöht. Deine Adresse braucht keinerlei Vorbereitung: Du kannst jeden beliebigen ERC-20 an einer Adresse empfangen, die diesen Token noch nie berührt hat.
Das erklärt, warum du ein Vermögen in einem Token halten und es trotzdem nicht bewegen kannst: Ein Contract-Aufruf kostet Gas, standardmäßig beglichen im nativen Token der Chain. Stand 2026 ist dieser Standard nicht absolut — ein ERC-4337-Paymaster erlaubt es, dass jemand anderes als der Account-Inhaber zahlt, und EIP-7702 erlaubt es einer dritten Partei, die Typ-4-Transaktion einzureichen und zu bezahlen, die die Delegation eines Accounts setzt; ob danach gesponsert wird, hängt allerdings davon ab, was der delegierte Code implementiert. Das Netzwerk berechnet die Arbeit weiterhin; es ändert sich nur, wer zahlt.
SPL auf Solana: Token-Accounts, Rent und der Mint
Solana teilt die Aufgabe in zwei Teile. Ein Mint-Account definiert den Token — Supply, Nachkommastellen und welche Authority prägen oder einfrieren darf. Die Guthaben liegen in separaten Token-Accounts. Das Token Program besitzt diese Account-Daten, während der Account einen Inhaber als Owner und Verfügungsberechtigten benennt; nichts begrenzt dich auf einen Account pro Mint.
Wallets standardisieren deshalb auf das Associated Token Account, abgeleitet aus deiner Wallet-Adresse, dem Mint und der Token-Program-ID. Es muss existieren und finanziert sein: Die Rent-Exemption sperrt einen kleinen, erstattbaren SOL-Betrag im Account, um ihn am Leben zu halten.
Ein neuer SPL-Token zu empfangen ist damit ein On-Chain-Ereignis, auch wenn die meisten Transfers die Account-Erstellung gleich mitbündeln. Stand 2026 ergänzt Token-2022 optionale Transfergebühren, vertrauliche Guthaben und Transfer-Hooks; da seine Program-ID ein Ableitungs-Seed ist, leiten seine Mints ein anderes Associated Token Account ab als die klassischen.
Jettons auf TON: Jeder Inhaber bekommt seinen eigenen Contract
TON treibt die Aufteilung am weitesten. Ein Jetton hat einen Master-Contract, der Metadaten und Supply hält, und jeder Inhaber bekommt seinen eigenen Jetton-Wallet-Contract, der ausschließlich sein Guthaben für genau diesen Token speichert.
Transfers sind asynchrone Nachrichten, keine Aufrufe in ein gemeinsames Ledger: Dein Jetton-Wallet-Contract schickt eine Nachricht an den des Empfängers, der das Guthaben gutschreibt. Weil TON gesharded ist, geschieht das über aufeinanderfolgende Blöcke hinweg statt in einem einzigen atomaren Schritt.
Jede Nachricht muss genug TON für die Berechnung mitbringen, die sie nachgelagert auslöst — inklusive der Bereitstellung des Jetton-Wallets des Empfängers, falls nötig; hängst du zu wenig an, kann sie zurückspringen oder hängen bleiben. Diese Ausrichtung (TEP-74, Stand 2026) erlaubt TON horizontale Skalierung — und bringt naiven Transfer-Code zu Fall, der für EVM geschrieben wurde.
Approvals, Gebühren und Fehlerfälle: Wo die drei auseinandergehen
Approvals sind der schärfste Unterschied. ERC-20 kennt das Allowance-Muster: Du erteilst einem Contract die Erlaubnis, bis zu einem bestimmten Betrag deiner Token zu bewegen, und sie besteht bis zum Widerruf fort — deshalb kann eine einzige unbedachte Signatur eine Wallet noch Monate später leerräumen; siehe Token-Approvals und Permit erklärt sowie wie man Token-Approvals widerruft.
Solana ist nicht das Gegenmittel: Ein SPL-Approve setzt einen Delegate auf deinem Token-Account, der die Transaktion überdauert, und setAuthority kann den Account komplett neu zuweisen — beides bekannte Drainer-Vektoren. Eine Solana-Transaktion listet jeden Account auf, den sie berührt, aber das begrenzt nur die signierte Transaktion, nicht dauerhafte Berechtigungen. TON hat keine Allowance im ERC-20-Stil.
Auch die Gebühren gehen auseinander: EVM bepreist Gas pro Recheneinheit, Solana eine pauschale Basisgebühr pro Signatur plus optionale Priority Fee, TON pro Nachricht. Ebenso die Fehlerfälle: auf EVM Token, die in einem Contract stranden, der nicht mit ihnen umgehen kann; auf Solana ein fehlendes Token-Account; auf TON zu wenig angehängter Wert.
Warum derselbe Ticker über Chains hinweg nicht derselbe Token ist
Zwei Assets, die sich einen Ticker teilen, teilen technisch nichts. USDC auf Ethereum ist eine Contract-Adresse, auf Solana eine Mint-Adresse; auf TON steht hinter einem nativ ausgegebenen Stablecoin wie USDT ein eigener Jetton-Master. Jedes ist ein eigenständiges On-Chain-Objekt mit eigenem Supply, und eine gebridgte Version ist wiederum ein anderer Anspruch.
Über Ökosystemgrenzen hinweg zu senden — ein EVM-Token an eine Solana- oder TON-Adresse — ist meist nicht mehr rückholbar; Krypto ins falsche Netzwerk gesendet: wie man es zurückholt legt dar, was sich noch retten lässt. EVM zu EVM verzeiht dagegen oft: Ein Externally Owned Account, auch ein per EIP-7702 delegierter, wird auf jeder Chain vom selben Key an identischer Adresse kontrolliert, und ein Smart Account im ERC-4337-Stil, der auf der Ziel-Chain noch nicht deployed ist, lässt sich dort normalerweise mit identischer Factory und identischem Init-Code erneut deployen. Adressformate sind ein Hinweis, behandelt in Krypto-Adressformate erklärt; ob ein kanonischer Supply bewegt oder ein neuer Anspruch geprägt wird, ist der Unterschied zwischen Omnichain-Token und Wrapped- bzw. Bridged-Token.
Was das für deine Wallet bedeutet (und wie WATS damit umgeht)
Eine Multi-Chain-Wallet muss alle drei Grammatiken beherrschen, und du solltest den Unterschied nie zu sehen bekommen — aber die Gebühren dringen durch, weil jede Chain ihren eigenen nativen Gas-Token erwartet. Stand 2026 ist diese Erwartung verhandelbar, sofern die Wallet dafür gebaut ist.
Genau das tut die WATS Hot Wallet: Jede Aktion — Transfers, Swaps, Staking — wird in einem einzigen Token abgerechnet, ATS, statt im nativen Gas der Chain, über einen ERC-4337-Paymaster auf EVM und einen äquivalenten Fee-Payer und Relayer auf Solana und TON, da ERC-4337 nur auf EVM existiert. ATS ist ein LayerZero OFT, sodass ein Guthaben über EVM, Solana und TON hinweg funktioniert. Das ändert nichts daran, was das Netzwerk berechnet — die ATS-Gebühr folgt den aktuellen Netzwerkkosten —, es ändert nur, in welchem Token diese Kosten beglichen werden. Eingenommenes ATS wird verbrannt, von 100 Millionen in Richtung einer Untergrenze von 30 Millionen. Es bleibt non-custodial: Du hältst deine Keys, und WATS hält niemals einen Key. WATS ist die erste und einzige Wallet, die ERC-4337 und OFT-Einzeltoken-Gebühren, erhoben statt nativem Gas, mit diesem Burn kombiniert.
Häufig gestellte Fragen
Warum kostet der Empfang eines SPL-Tokens auf Solana etwas, auf Ethereum aber nicht?
Auf Ethereum ist dein Guthaben nur eine Zeile im Contract des Tokens selbst, der Empfang ist für den Empfänger also kostenlos und erfordert keine Einrichtung. Auf Solana muss beim ersten Empfang eines bestimmten Mints ein Token-Account dafür existieren, und dieses Account on-chain zu halten erfordert eine kleine Rent-Exemption-Einlage in SOL, die beim Schließen des Accounts wieder frei wird. In der Praxis erstellt und finanziert die Transaktion des Senders dieses Account meist im selben Schritt, sodass die Kosten beim Sender liegen und der Empfänger sie nie zu sehen bekommt.
Was unterscheidet einen TON-Jetton-Transfer von einem ERC-20-Transfer?
Ein Jetton gibt jedem Inhaber einen eigenen Smart Contract, der ausschließlich dessen Guthaben speichert. Ein Transfer ist eine asynchrone Nachricht von deinem Jetton-Wallet-Contract an den des Empfängers, die über aufeinanderfolgende Blöcke hinweg abgeschlossen wird statt in einem einzigen atomaren Aufruf. Jede Nachricht muss genug TON mitbringen, um die ausgelöste Arbeit zu bezahlen, sonst kann sie zurückspringen.
Ist USDC auf Ethereum derselbe Token wie USDC auf Solana?
Nein. Es sind eigenständige On-Chain-Objekte mit eigenen Adressen, eigenem Supply und eigenen Standards, auch wenn sie sich Ticker und Herausgeber teilen. Eines davon an eine Adresse auf der jeweils anderen Chain zu senden ist normalerweise nicht rückholbar, und gebridgte Versionen eines Tickers sind von nativ ausgegebenen verschieden.