Transfert plusieurs vers plusieurs sur Solana
Transferts appairés sur Solana : une transaction par ligne, 0,001 SOL par transfert, et la règle de rent qui saute une ligne au lieu de la rogner.
Il existe trois façons de faire beaucoup de paiements d'un coup sur Solana, et elles se confondent sans arrêt. Un multi-sender paie une liste depuis un seul wallet. Un collector ramasse plusieurs wallets dans un seul. Puis vient le cas qu'aucun des deux ne sait exprimer.
Un transfert plusieurs vers plusieurs sur Solana garde chaque expéditeur avec son propre destinataire. Le wallet 7 paie le wallet 7, le 8 paie le 8, et aucun des deux ne sait que l'autre existe.
Cela ressemble à un détail. C'est la différence entre une source et quarante sources indépendantes.
- Une ligne est une transaction. Le wallet expéditeur de cette ligne paie tout ce qui s'y trouve.
- Frais de plateforme 0,001 SOL par transfert, frais réseau 0,000005 SOL.
- Un destinataire qui n'a jamais détenu ce token ajoute 0,00203928 SOL de dépôt de rent.
- Les lignes qui ne passent pas sont sautées, pas rognées.
Trois formes de transfert en masse
L'outil d'envoi multiple fait un vers plusieurs. Un wallet, une liste de destinataires, un payeur. C'est la forme d'un airdrop.
Le collecteur par lots fait plusieurs vers un. Vingt wallets, une destination, et à la fin tout se retrouve au même endroit.
L'outil plusieurs vers plusieurs est la troisième forme, et la seule qui connaisse les paires. La ligne un a sa propre source, la ligne deux en a une autre. Pas de caisse commune, pas de compensation entre les lignes.
Ce que coûte une ligne
Trois postes peuvent apparaître sur une ligne, et le wallet expéditeur de cette ligne les paie tous les trois. Il n'y a pas de compte de financement partagé, donc un wallet qui ne couvre pas sa propre ligne n'emprunte rien à celle du dessus. Le poste réseau est le frais de base de 5 000 lamports par signature que détaille la documentation des frais de Solana.
| Poste | Mode SOL | Mode token |
|---|---|---|
| Frais de plateforme | 0,001 SOL | 0,001 SOL |
| Frais réseau | 0,000005 SOL | 0,000005 SOL |
| Compte de token du destinataire | sans objet | 0,00203928 SOL, et seulement si ce destinataire n'a jamais détenu ce token |
Relisez la troisième ligne, parce que c'est celle qui surprend. Envoyer un token SPL à une adresse qui n'y a jamais touché revient à créer un compte pour le stocker, et Solana facture un dépôt de rent pour ce compte. Le dépôt vaut environ deux cents fois les frais réseau et deux fois les frais de plateforme.
Sur cent destinataires neufs, cela fait à peu près 0,204 SOL de la facture, quand les frais de plateforme s'arrêtent à 0,1. Le dépôt n'est pas brûlé : il reste dans le compte de token du destinataire et revient à celui qui fermera ce compte plus tard.
Les lignes qui sont sautées
Deux contrôles tournent avant la signature, et tous deux arrêtent la ligne au lieu de la modifier.
Le premier relève de l'arithmétique. Si le wallet expéditeur ne couvre pas son montant plus les frais plus un éventuel compte de token à ouvrir, la ligne est marquée et laissée tranquille. Rien de partiel ne part.
Le second est plus étrange et mérite d'être compris, car la première fois il ressemble à un bug. Solana refuse de laisser un compte avec un solde au-dessus de zéro mais sous le minimum exempté de rent. Pour un wallet ordinaire ce minimum vaut 0,00089088 SOL, et il sort de la formule que donne la documentation des comptes de Solana.
Vider un compte entièrement reste autorisé. Y laisser 0,0005 SOL ne l'est pas. Une ligne qui pousse un wallet dans cet interstice est signalée comme rent dust et reste non envoyée.
Pourquoi ne pas simplement rogner le montant
L'autre option serait de rogner le montant jusqu'à ce qu'il passe, et c'est pire. Vous avez tapé un chiffre. Un outil qui envoie un autre chiffre sans le dire est un outil contre lequel aucun tableur ne se rapproche ensuite.
Envoyez plutôt le solde entier, ou baissez le montant pour que le reste dépasse le minimum. L'aperçu indique à l'avance quelles lignes sont concernées, et l'outil interroge tous les comptes de destination en un seul appel avant de signer quoi que ce soit.
Une transaction par ligne, et pourquoi cela compte
Comme chaque ligne est sa propre transaction, une ligne en échec tombe seule. Dans un lot qui empile tout dans une transaction, une erreur à la ligne 30 emporte les 29 précédentes.
Cela a un prix : quarante paires font quarante signatures et quarante frais de plateforme. En échange, le résultat se lit ligne par ligne. Pour savoir à quelle vitesse ces transactions passent, les chiffres sont dans l'article sur les frais de priorité.
Quand un transfert plusieurs vers plusieurs sur Solana est la bonne forme
La rotation de wallets est la réponse honnête pour la plupart des gens. Vous avez un jeu de wallets dont l'historique vous gêne, vous en générez un neuf avec le générateur de wallets en lot, et vous voulez que l'ancien wallet 7 finance le nouveau wallet 7, rien d'autre.
Le deuxième cas est une liste de paiements où le payeur change à chaque ligne. Plusieurs projets, plusieurs trésoreries, un seul tableau. Un multi-sender ne peut pas l'exprimer, puisqu'il a exactement une source.
Le troisième est la redistribution après un snapshot, où chaque détenteur est payé depuis un wallet qui lui a déjà été attribué. Comment lire cette répartition avant de distribuer se trouve dans le guide sur la répartition des détenteurs.
Préparer la liste
Faites la première passe avec deux lignes. Le tableau de résultats dit ce qu'une ligne a réellement coûté, dépôts de compte de token compris, avant d'en envoyer deux mille.
Vérifiez aussi si vos destinataires détiennent déjà le token. Sur une liste à moitié composée de détenteurs existants, le poste des dépôts est divisé par deux, et sur cent lignes c'est le plus gros montant de la facture.
Notez enfin quel wallet paie quelle ligne. Après la passe, cette correspondance se reconstitue moins facilement qu'il n'y paraît, surtout si les expéditeurs viennent d'être générés et n'ont encore aucun historique qui les distingue.
Un dernier point sur le solde : laissez dans chaque expéditeur un peu plus que son montant. Ajusté au centime près, le contrôle de rent écarte la ligne et il faut refinancer, ce qui prend plus de temps que d'avoir gardé une marge.
Questions fréquentes sur le transfert appairé
En quoi est-ce différent de lancer le multi-sender plusieurs fois ?
Le multi-sender a exactement une source par passe. Quarante sources font quarante passes et quarante changements manuels de wallet. Ici, une passe et quarante lignes.
Une ligne en échec coûte-t-elle quelque chose ?
Non. Une ligne qui échoue au contrôle préalable n'est jamais signée, donc ni frais réseau ni frais de plateforme.
Les expéditeurs et les destinataires peuvent-ils se chevaucher ?
Oui. Un wallet peut envoyer sur une ligne et recevoir sur une autre. Chaque ligne est contrôlée séparément.
Pourquoi ma ligne est-elle marquée rent dust ?
Parce que le reste dans le wallet expéditeur serait tombé entre zéro et 0,00089088 SOL. Envoyez tout le solde ou baissez le montant.
Faut-il du SOL dans un wallet qui n'envoie que des tokens ?
Oui. Les frais réseau et de plateforme se paient en SOL même quand le transfert porte sur un token.
Y a-t-il un nombre maximum de paires ?
En pratique c'est la préparation qui limite, pas l'outil : chaque wallet expéditeur doit être financé au préalable.
Décider en une ligne
Si votre tableau comporte une colonne pour le payeur, c'est cette forme qu'il vous faut. Si toutes les lignes partent du même wallet, prenez le multi-sender et payez une fois plutôt que quarante. Et s'il vous manque une ligne, regardez d'abord le minimum de rent avant de conclure à un bug. Ce minimum est détaillé dans l'explication des fonds insuffisants pour le rent.
