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 on les confond sans arrêt. Un multi-sender paie une liste depuis un seul wallet. Un collector rassemble le contenu de 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 l'adresse 7, le wallet 8 paie l'adresse 8, et ces deux lignes ne se touchent jamais.
Cela ressemble à un détail, mais 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,00149 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 correspond aux 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,00149 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 dépasse de loin les frais réseau.
Sur cent destinataires neufs, cela fait à peu près 0,149 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. Si le destinataire détient déjà le token, ce poste disparaît. L'outil interroge tous les comptes de destination en un seul appel avant de signer, donc l'estimation affichée est celle que vous payez.
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 d'exemption de rent. Pour un wallet ordinaire ce minimum vaut 0,00065 SOL, et il découle de la formule que donne la documentation des comptes de Solana.
Vider un compte entièrement reste autorisé. Y laisser 0,00005 SOL ne l'est pas. Une ligne qui pousse un wallet dans cet interstice est signalée comme rent dust et n'est pas 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 dont on ne peut plus rapprocher les résultats d'un tableur.
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.
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, donc quarante frais réseau de 0,000005 SOL, ce qui ne pèse presque rien dans la facture. 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
L'usage le plus courant est la rotation de wallets. 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, et 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'envoyer toute la liste.
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 : soit vous videz le wallet expéditeur à zéro, soit vous lui laissez au moins le minimum de rent (0,00065 SOL) après le montant et les frais. Un reste compris entre zéro et ce minimum fait écarter la ligne, et il faut refinancer.
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 ?
Cela dépend de l'endroit où elle échoue. Une ligne qui échoue au contrôle préalable n'est jamais signée, donc ni frais réseau ni frais de plateforme. Une ligne signée, diffusée puis rejetée par la chaîne paie ses frais réseau, comme toute transaction Solana qui échoue.
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 une transaction indépendante, donc l'ordre entre elles n'est pas garanti : si la ligne 2 dépense ce que livre la ligne 1, séparez-les en deux passes.
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,00065 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 ?
Il n'y a pas de maximum fixe, et rien ne vous empêche de coller des milliers de paires. Elles sont signées et envoyées par lots de cent, puis confirmées par lots de 256, avec une attente maximale de 90 secondes à chaque confirmation. En pratique, c'est la préparation qui limite : chaque wallet expéditeur doit être financé au préalable. Une passe que vous pouvez suivre est une passe que vous pouvez corriger, donc une très longue liste se gère mieux en plusieurs passes plus courtes.
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 : une seule configuration au lieu de quarante. Et si une ligne n'est pas partie, 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.


