Viele-zu-viele Transfer auf Solana
Gepaarte Wallet-Transfers auf Solana: eine Transaktion pro Zeile, 0,001 SOL pro Transfer, und die Rent-Regel, die eine Zeile überspringt statt sie zu kürzen.
Es gibt drei Arten, viele Zahlungen auf Solana auf einmal zu erledigen, und sie werden ständig verwechselt. Ein Multi-Sender zahlt eine Liste aus einer Wallet. Ein Collector sammelt viele Wallets in einer einzigen. Und dann gibt es den Fall, den beide nicht abbilden.
Ein Viele-zu-viele-Transfer auf Solana ordnet jeder sendenden Wallet genau einen eigenen Empfänger zu. Absender 7 zahlt an Adresse 7, Absender 8 an Adresse 8, und die beiden Zeilen berühren sich nie.
Das klingt nach einer Kleinigkeit. Es ist der Unterschied zwischen einer Quelle und vierzig unabhängigen Quellen.
- Eine Zeile ist eine Transaktion. Die sendende Wallet der Zeile signiert sie und zahlt alle Kosten dafür.
- Plattformgebühr 0,001 SOL pro Transfer, Netzgebühr 0,000005 SOL.
- Ein Empfänger, der diesen Token noch nie hielt, kostet zusätzlich 0,00149 SOL Rent-Einlage.
- Zeilen, die nicht durchgehen, werden übersprungen und nicht gekürzt.
Drei Formen von Massentransfer
Das Multi Sender Werkzeug deckt den Fall eine Wallet an viele Adressen ab: eine Wallet, eine Empfängerliste, ein Zahler. Das ist die richtige Form für einen Airdrop.
Der Batch Collector deckt den umgekehrten Fall ab, viele Wallets an eine Adresse. Vierzig Wallets, ein Ziel, und am Ende liegt alles an einer Stelle.
Many to Many ist die dritte Form und die einzige, die Paare kennt. Zeile eins hat ihre eigene Quelle, Zeile zwei eine andere. Keine gemeinsame Kasse, kein Ausgleich zwischen den Zeilen.
Was eine Zeile kostet
Auf einer Zeile können drei Posten stehen, und die sendende Wallet dieser Zeile zahlt alle drei. Es gibt kein gemeinsames Finanzierungskonto, also leiht sich eine Wallet, die ihre eigene Zeile nicht deckt, nichts von der Zeile darüber. Der Netzposten ist die Grundgebühr von 5.000 Lamports pro Signatur, die Solanas eigene Gebührendokumentation aufschlüsselt.
| Posten | SOL-Modus | Token-Modus |
|---|---|---|
| Plattformgebühr | 0,001 SOL | 0,001 SOL |
| Netzgebühr | 0,000005 SOL | 0,000005 SOL |
| Token-Konto des Empfängers | entfällt | 0,00149 SOL, nur wenn dieser Empfänger den Token noch nie hielt |
Die dritte Zeile ist die, die Leute überrascht. Einen SPL-Token an eine Adresse zu schicken, die ihn noch nie berührt hat, bedeutet, dafür ein Konto anzulegen, und Solana verlangt dafür eine Rent-Einlage. Die Einlage ist weit höher als die Netzgebühr.
Bei hundert frischen Empfängern macht die Einlage etwa 0,149 SOL aus, die Plattformgebühr dagegen nur 0,1. Die Einlage wird nicht verbrannt. Sie liegt im Token-Konto des Empfängers und geht an den zurück, der dieses Konto später schließt.
Die Zeilen, die übersprungen werden
Vor dem Signieren laufen zwei Prüfungen, und beide stoppen die Zeile, statt sie zu verändern.
Die erste ist schlichte Arithmetik. Deckt die sendende Wallet ihren Betrag plus Gebühren plus ein eventuell zu öffnendes Token-Konto nicht, wird die Zeile markiert und in Ruhe gelassen. Es wird nie ein Teilbetrag gesendet.
Die zweite ist merkwürdiger, und es lohnt sich, sie zu verstehen, weil sie beim ersten Mal wie ein Fehler aussieht. Solana akzeptiert kein Konto, dessen Guthaben über null, aber unter dem Rent-Minimum liegt. Für eine gewöhnliche Wallet sind das 0,00065 SOL, und die Zahl kommt aus der Rent-Formel in Solanas Dokumentation zu Konten.
Ein Konto ganz zu leeren ist erlaubt, 0,00005 SOL darin zu lassen dagegen nicht. Eine Zeile, die eine Wallet in diesen Bereich zwischen null und dem Minimum schiebt, wird als Rent-Dust markiert und bleibt ungesendet.
Warum nicht einfach den Betrag kürzen
Die Alternative wäre, den Betrag so lange zu kürzen, bis er passt, und das ist schlechter. Du hast eine Zahl getippt. Ein Werkzeug, das heimlich eine andere Zahl sendet, lässt sich hinterher nicht mehr mit deiner Tabelle abgleichen.
Sende stattdessen das ganze Guthaben oder senke den Betrag so weit, dass der Rest das Minimum überschreitet. Die Vorschau zeigt dir vorher, welche Zeilen betroffen sind, und das Werkzeug prüft alle Zielkonten in einem einzigen Aufruf, bevor es irgendetwas signiert.
Eine Transaktion pro Zeile, und warum das zählt
Weil jede Zeile ihre eigene Transaktion ist, scheitert bei einem Fehler nur diese eine Zeile. Packt man dagegen alles in eine einzige Transaktion, reißt ein Fehler in Zeile 30 die 29 davor mit.
Das kostet etwas: Vierzig Paare sind vierzig Signaturen mit je 0,000005 SOL Netzgebühr, und das ist nicht der Teil der Rechnung, den man optimieren sollte. Dafür steht jeder Fehler als eigene Zeile mit Begründung in der Ergebnistabelle, und wiederholen musst du nur diese Zeile. Wer wissen will, wie schnell diese Transaktionen durchgehen, findet die Rechnung in dem Beitrag zur Priority Fee auf Solana.
Wann sich ein Viele-zu-viele-Transfer auf Solana lohnt
Für die meisten läuft es auf eine Wallet-Rotation hinaus. Du hast mehrere Wallets mit einer Historie, die du hinter dir lassen willst, erzeugst mit dem Generator für neue Wallets neue und willst, dass alte Wallet 7 neue Wallet 7 finanziert und sonst nichts.
Der zweite Fall ist eine Auszahlungsliste, bei der der Zahler je Zeile wechselt. Mehrere Projekte, mehrere Kassen, eine Tabelle. Ein Multi-Sender kann das gar nicht ausdrücken, weil er genau eine Quelle hat.
Der dritte ist die Verteilung nach einem Snapshot, bei der jeder Halter aus einer ihm bereits zugeordneten Wallet bezahlt wird. Wie du die Verteilung eines Tokens vorher auswertest, steht in der Anleitung zur Token-Verteilung.
Vor dem großen Lauf
Starte den ersten Durchgang mit nur zwei Zeilen. Die Ergebnistabelle sagt dir, was eine Zeile wirklich gekostet hat, inklusive etwaiger Token-Konto-Einlagen, bevor du die ganze Liste abschickst.
Prüfe außerdem, ob deine Empfänger den Token schon halten. Bei einer Liste, die zur Hälfte aus bestehenden Haltern besteht, halbiert sich der Einlagenposten, und das ist bei hundert Zeilen der größte Einzelbetrag der Rechnung.
Und notiere dir vorher, welche Wallet welche Zeile bezahlt. Nach dem Lauf ist diese Zuordnung schwerer zu rekonstruieren, als sie jetzt klingt, besonders wenn die Sender frisch erzeugt wurden und noch keine Historie haben, an der man sie erkennt.
Häufige Fragen zum Viele-zu-viele Transfer
Worin unterscheidet es sich davon, den Multi-Sender mehrmals laufen zu lassen?
Der Multi-Sender hat pro Lauf genau eine Quelle. Vierzig Quellen bedeuten vierzig Läufe und vierzig manuelle Wallet-Wechsel. Hier ist es ein Lauf mit vierzig Zeilen.
Kostet eine fehlgeschlagene Zeile etwas?
Das hängt davon ab, wann sie scheitert. Eine Zeile, die an der Vorprüfung scheitert, wird nie signiert, also fällt weder Netz- noch Plattformgebühr an. Scheitert eine signierte Zeile erst auf der Chain, kostet sie die Netzgebühr wie jede fehlgeschlagene Solana-Transaktion. Die Plattformgebühr steckt in derselben Transaktion und wird nur fällig, wenn der Transfer durchgeht.
Dürfen sich Sender und Empfänger überschneiden?
Ja. Eine Wallet darf in einer Zeile senden und in einer anderen empfangen. Jede Zeile wird für sich geprüft.
Warum wurde meine Zeile als Rent-Dust markiert?
Weil der Rest in der sendenden Wallet zwischen null und 0,00065 SOL gelandet wäre. Sende das ganze Guthaben oder senke den Betrag.
Brauche ich SOL in einer Wallet, die nur Token sendet?
Ja. Die Netzgebühr und die Plattformgebühr werden in SOL bezahlt, auch wenn du Token sendest.
Gibt es eine Obergrenze für die Zahl der Paare?
Eine feste Obergrenze gibt es nicht, und nichts hindert dich daran, Tausende Paare einzufügen. Sie werden in Paketen zu je hundert signiert und gesendet und in Gruppen von bis zu 256 bestätigt, mit höchstens 90 Sekunden Wartezeit je Bestätigung. Ein langer Lauf dauert deshalb einige Minuten. Vorher musst du jede sendende Wallet finanziert haben. Einen Lauf, den du beobachten kannst, kannst du auch korrigieren. Eine sehr lange Liste arbeitest du darum besser in mehreren kleineren Läufen ab.
Kurz gesagt
Wenn deine Tabelle eine Spalte für den Zahler hat, ist das die Form, die du brauchst. Wenn alle Zeilen aus derselben Wallet kommen, nimm den Multi-Sender und zahle einmal statt vierzig Mal. Und wenn nach dem Lauf eine Zeile fehlt, prüfe zuerst das Rent-Minimum, bevor du einen Fehler vermutest. Mehr zu diesem Minimum steht in der Erklärung zu Insufficient funds for rent.
