SPL-Token und Token-Konten in SSP

Wer ERC-20-Token auf Ethereum genutzt hat, dem kommt Solanas Token-Modell etwa dreißig Sekunden lang vertraut vor und ergibt danach keinen Sinn mehr. Auf Ethereum führt ein Token-Vertrag ein Verzeichnis darüber, wer was besitzt, und deine Adresse taucht als Zeile darin auf. Auf Solana kommt deine Adresse in den Aufzeichnungen des Tokens überhaupt nicht vor. Stattdessen wird ein eigenes Konto angelegt, das deinen Bestand genau dieses Tokens hält — dir gehörend, aber getrennt von deiner Hauptadresse.

Diese eine Entwurfsentscheidung erklärt fast jede Überraschung, die Leute mit SPL-Token erleben: warum das Senden eines Tokens an jemanden Neues mehr kostet als an jemanden, der ihn schon hält; warum eine Wallet für eine Adresse, die den Token nie berührt hat, ein Guthaben von null anzeigen kann; und warum Dezimalstellen hier wichtiger sind als irgendwo sonst. Dieser Artikel geht das Modell so durch, wie SSP es umsetzt.

Warum Solana pro Token ein eigenes Konto braucht

Solanas Grundregel lautet: Alles ist ein Konto, und jedes Konto hat einen Eigentümer, eine Größe und eine Mietkaution proportional zu dieser Größe. Einen Vertrag, der still und leise eine interne Zuordnung wachsen lässt, sobald mehr Nutzer eintreffen, gibt es hier nicht — der Speicher muss irgendwo in einem Konto liegen, und jemand muss dafür zahlen.

Also teilt das SPL-Token-Programm die Arbeit auf. Das Mint-Konto hält die Fakten zum Token selbst: Gesamtangebot, Dezimalstellen und wer weitere ausgeben darf. Jeder Inhaber erhält sein eigenes Token-Konto, ein kleines Konto fester Größe, das genau einen Bestand für genau ein Mint verzeichnet und einen Eigentümer benennt. Dein SOL-Guthaben liegt an deiner Adresse; dein USDC-Guthaben liegt in einem Token-Konto, das deine Adresse kontrolliert.

Der Vorteil dieses Entwurfs ist Vorhersagbarkeit — jedes Token-Guthaben hat dieselbe Form und kostet dasselbe an Speicher. Der Preis dafür: Einen neuen Token zu halten erfordert, ein neues Konto ins Leben zu rufen. Solanas Token-Dokumentation ist die Primärquelle, wenn du die Spezifikation statt der Zusammenfassung willst.

Das assoziierte Token-Konto — und wer dafür zahlt

Wenn jeder Inhaber ein Token-Konto braucht und jeder Konten anlegen kann, hättest du am Ende mehrere Token-Konten pro Person und Mint und keine Möglichkeit zu wissen, an welches zu senden ist. Das assoziierte Token-Konto — ATA — ist die Konvention, die das löst: Für einen gegebenen Eigentümer und ein gegebenes Mint gibt es genau eine kanonische Adresse, deterministisch aus beiden abgeleitet. Wallets können sie berechnen, also muss sie niemand veröffentlichen.

Der Haken ist die Miete. Ein Token-Konto ist rund 165 Byte groß, was etwa 0,002 SOL als Mietkaution bedeutet, solange das Konto existiert. Diese Kaution ist beim Schließen des Kontos erstattungsfähig, muss aber im Voraus gezahlt werden — und zwar von jemandem, der SOL hat, was der Empfänger seiner allerersten Token-Überweisung per Definition womöglich nicht besitzt.

SSP löst das wie jede andere Solana-Gebühr. Sendest du einen SPL-Token an jemanden, dessen ATA nicht existiert, enthält die Transaktion eine idempotente Instruktion, sie anzulegen, und der Paymaster von SSP zahlt die Miete. Dein Vault erstattet dem Paymaster den Betrag innerhalb derselben Transaktion — deshalb kostet diese erste Überweisung an einen neuen Empfänger rund 0,0025 SOL mehr als eine erneute an dieselbe Person. „Idempotent“ ist dabei das entscheidende Wort: Existiert das Konto bereits, gelingt die Instruktion und tut nichts, statt die gesamte Überweisung scheitern zu lassen.

Beachte, dass diese Erzeugungs-Instruktion außerhalb des Multisig-Vorschlags steht. Das Token-Konto einer anderen Person anzulegen bewegt deine Mittel nicht und braucht keine Autorisierung deines Vaults, gehört also nicht in den Teil, den deine beiden Geräte signieren. Die Erstattung, die sehr wohl deine Mittel bewegt, steht innerhalb des Vorschlags.

Was SSP ab Werk unterstützt

SSP bringt natives SOL, Circles offizielles USDC-Mint und FLUX auf Solana mit. Jeder weitere SPL-Token, der in deinem Vault auftaucht, wird aufgelöst und daneben angezeigt.

Eine bewusste Grenze gehört klar gesagt: SSPs Solana-Überweisungen werden gegen das klassische SPL-Token-Programm gebaut. Token, die unter Token-2022 ausgegeben wurden — dem neueren Programm mit Transfer Hooks, vertraulichen Überweisungen und weiteren Erweiterungen —, sind heute nicht Teil des Sendepfads. Das ist eine Entscheidung über den Umfang, kein Versehen: Token-2022-Erweiterungen können verändern, was eine Überweisung tut, und Unterstützung dafür auszuliefern hieße, jede Erweiterung gegen die unten beschriebenen Dekodier-Garantien auf dem Gerät zu prüfen.

Wie eine Token-Überweisung tatsächlich aufgebaut ist

Wenn du einen SPL-Token aus SSP sendest, enthält die zu signierende Transaktion der Reihe nach:

1. Das ATA des Empfängers anlegen, falls nötig — idempotent, vom Paymaster bezahlt, außerhalb des Vorschlags.
2. TransferChecked — verschiebt den Bestand vom Token-Konto deines Vaults zu dem des Empfängers, autorisiert vom Vault.
3. Den Paymaster erstatten — eine schlichte SOL-Überweisung aus deinem Vault, innerhalb des Vorschlags.

All das landet als eine einzige atomare Transaktion. Es gibt keinen separaten Freigabeschritt, keinen ausstehenden Vorschlag, der on-chain herumliegt, und keinen Zustand, in dem das Konto des Empfängers angelegt, die Überweisung aber nicht erfolgt ist. Entweder läuft alles durch oder nichts.

Das Quellkonto ist das eigene ATA deines Vaults — auf dieselbe deterministische Weise abgeleitet, mit der Programmadresse des Vaults als Eigentümer. Weil der Vault eine programmabgeleitete Adresse und kein Schlüsselpaar ist, erlaubt die Ableitung ausdrücklich einen Eigentümer, der außerhalb der ed25519-Kurve liegt. Wenn du das zugrunde liegende Detail dazu willst, warum die Vault-Adresse so funktioniert: das selbstinitiierende Solana-Multisig behandelt es.

Dezimalstellen sind Teil der Signatur

Hier lohnt es sich zu bremsen, denn hier kann ein Token dich anlügen.

Ein Mint erklärt, wie viele Dezimalstellen sein Token nutzt. USDC nutzt sechs, viele Token nutzen neun, eine Regel gibt es nicht. Zeigt eine Wallet „100 USDC“ an, baut aber eine Überweisung über eine Zahl an Roheinheiten, die von falschen Dezimalstellen ausgeht, kannst du das Tausendfache senden und auf dem Bildschirm nichts Ungewöhnliches sehen.

SSP verwendet TransferChecked statt der schlichten Transfer-Instruktion. Der Unterschied: TransferChecked bettet die Mint-Adresse und das Dezimalstellen-Byte direkt in die signierten Instruktionsdaten ein. Daraus folgen drei getrennte Prüfungen:

• Deine Erweiterung dekodiert die Bytes und vergleicht sie mit dem, was sie anzeigt.
• SSP Key dekodiert dieselben Bytes unabhängig auf deinem Telefon und vergleicht sie mit den Token-Metadaten, die die Erweiterung geliefert hat.
• Das On-Chain-SPL-Token-Programm vergleicht die Dezimalstellen in der Instruktion mit den tatsächlichen Dezimalstellen des Mints und lehnt die Transaktion ab, wenn sie abweichen.

Die dritte Prüfung ist die, an der niemand vorbeiredet. Ein Mint, das andere Dezimalstellen behauptet, als es hat, erzeugt keine falsche Überweisung — es erzeugt eine gescheiterte Transaktion.

Token empfangen

Empfangen ist einfacher, mit einer Feinheit. Gib dem Absender deine Wallet-Adresse — die, die SSP im Empfangen-Bildschirm zeigt —, nicht die Adresse eines Token-Kontos. Was auch immer gesendet wird: Das richtige ATA wird aus deiner Adresse und dem Mint abgeleitet, und die Wallet des Absenders legt es bei Bedarf an.

Hat dein Vault diesen Token nie gehalten, existiert das Konto erst, wenn die erste Überweisung eintrifft, und dessen Miete zahlt derjenige, der dir sendet. Das ist normal und verlangt nichts von dir. Es heißt allerdings, dass ein Block-Explorer für einen Token, der dir zugesagt, aber noch nicht angekommen ist, kein Token-Konto zeigt — das ist das noch nicht existierende Konto, keine verlorene Überweisung.

Häufige Stolperfallen

An eine Token-Konto-Adresse statt an eine Wallet-Adresse senden. Manche Explorer stellen das ATA prominent dar. Einen Token an ein Token-Konto statt an dessen Eigentümer zu schicken ist eine bekannte Art, auf Solana Geld zu verlieren. SSP erwartet die Wallet-Adresse des Eigentümers und leitet den Rest ab.

Annehmen, ein unbekannter Token sei sicher, weil er in deiner Wallet auftaucht. Jeder kann ein Mint erzeugen und es dir schicken, und Mints können Namen tragen, die echte Token nachahmen. Dass ein Token in deinem Vault erscheint, ist keine Empfehlung. Prüfe die Mint-Adresse gegen eine offizielle Quelle, bevor du ein Guthaben als echten Wert behandelst.

Freigaben im Ethereum-Stil erwarten. SPL-Token kennen einen Delegate-Mechanismus, aber das Muster dauerhafter Freibeträge, das ERC-20-Approvals zum wiederkehrenden Risiko macht, ist nicht die Art, wie die meisten Solana-Anwendungen gebaut sind. Wenn du von Ethereum kommst, erklärt Token-Freigaben: die Berechtigungen, die du ständig erteilst die Gewohnheit, die du verlernst, und Ethereum in SSP liefert den Vergleich.

Den Aufschlag beim ersten Senden vergessen. Die zusätzlichen ~0,0025 SOL bei einer ersten Überweisung an einen neuen Empfänger sind Miete, keine Gebühr, die SSP einnimmt. Sie liegen im Token-Konto des Empfängers und sind von ihm zurückzuholen, falls er es je schließt.

Für die Schritt-für-Schritt-Mechanik einer echten Überweisung siehe Solana mit SSP senden. Dazu, wie SSP den zugrunde liegenden Vault in einem 2-von-2-Multisig ohne Ersteller hält, beginne mit Solana in SSP.