Prêt flash sur Solana : définition et fonctionnement
Un prêt flash sur Solana emprunte sans collatéral et rembourse dans la même transaction. Comment les prêteurs le vérifient, son coût et ses limites.
Un prêt flash sur Solana vous prête des tokens sans collatéral ni vérification de solvabilité, à une seule condition : l'argent revient avant la fin de la transaction. Si le remboursement manque ou échoue, le réseau rejette toute la transaction, et le prêt n'a jamais existé. Rien ne reste jamais dû, et c'est pour cela qu'un protocole de prêt peut proposer un prêt flash à n'importe quel portefeuille.
On dirait une faille. Ce sont en fait deux règles ordinaires qui travaillent ensemble : une transaction réussit en entier ou pas du tout, et un programme peut lire les autres instructions de la transaction dans laquelle il s'exécute. Tout ce que fait un prêt flash sur Solana, y compris ses points de rupture, découle de ces deux faits.
Comment fonctionne un prêt flash dans une seule transaction
Solana exécute une transaction comme une liste d'instructions, dans l'ordre. La documentation Solana sur les transactions pose la règle sans détour : si une instruction échoue, toute la transaction échoue et chaque changement d'état est annulé. Un prêt flash est une liste construite autour de cette règle.
- Emprunter. Le programme de prêt déplace des tokens de son coffre (vault) vers votre compte de token.
- Utiliser. Vos propres instructions les dépensent : un swap, une liquidation, un dépôt ailleurs.
- Rembourser. Le programme de prêt reprend le même montant, plus ses frais s'il en facture.
Si l'étape trois ne peut pas s'exécuter, par exemple parce qu'un swap a rendu moins que prévu, l'étape un est annulée avec tout le reste, et le coffre revient exactement à son point de départ. C'est aussi pour cela qu'aucun collatéral n'est nécessaire. Un prêt ordinaire en exige un parce que du temps passe entre l'emprunt et le remboursement. Ici, il n'en passe pas.
Comment le prêteur sait que le remboursement arrive
L'emprunt s'exécute en premier, il doit donc décider avant que le remboursement ait eu lieu. Il lit la suite : Solana expose chaque instruction de premier niveau de la transaction en cours à travers un compte spécial, le sysvar des instructions. Le guide Solana sur l'introspection des instructions décrit précisément cet usage : vérifier qu'une instruction donnée figure dans la même transaction.
Kamino Lend publie le code source de son programme, et la vérification s'y lit noir sur blanc. Son emprunt flash parcourt chaque instruction placée après la sienne et refuse de prêter s'il ne trouve pas exactement un remboursement correspondant :
- le remboursement indique le même montant ;
- il liste les mêmes comptes, dans le même ordre ;
- il renvoie à la position de l'emprunt ;
- aucun second emprunt flash ne suit.
Comme les deux autres prêteurs présentés plus bas, Kamino refuse un emprunt appelé depuis un autre programme, parce que le sysvar ne liste que les instructions de premier niveau. marginfi encadre le prêt autrement : une instruction de début vérifie qu'une instruction de fin figure plus loin dans la transaction, et la fin exécute le contrôle de santé du compte.
Les détails comptent. Chez Kamino, le remboursement porte la position de l'emprunt sous forme de numéro. Un portefeuille qui insère sa propre instruction de protection avant l'emprunt fait donc pointer le remboursement vers la mauvaise instruction, et celui-ci est refusé. Le remboursement de Jupiter Lend ne porte aucune position, et c'est l'une des raisons pour lesquelles l'outil Flash Volume emprunte là.
Quels prêteurs Solana proposent des prêts flash
Trois protocoles de prêt documentent les prêts flash sur Solana dans leur propre documentation pour développeurs.
| Prêteur | Frais du prêteur |
|---|---|
| Jupiter Lend | Aucun selon sa documentation, mais son administrateur dispose d'un réglage de frais |
| Kamino Lend | Fixés par réserve ; une réserve peut désactiver les prêts flash |
| marginfi (documentation désormais sous le nom Project 0) | Aucun selon sa documentation |
À quoi servent les prêts flash
Chacun de ces usages demande un gros montant pour quelques instructions, et plus rien ensuite.
- Arbitrage. Acheter là où un token est bon marché, vendre là où il est cher, rembourser. Si l'écart s'est refermé, la vente ne couvre pas le remboursement et la transaction est annulée.
- Liquidations. Le prêt rembourse la dette d'un emprunteur en mauvaise santé. Le collatéral reçu avec une décote, échangé en retour, rembourse le prêt.
- Échange de collatéral et refinancement. Rembourser un prêt avec des tokens empruntés, retirer le collatéral, l'échanger ou le transférer chez un autre prêteur, emprunter à nouveau, rembourser.
- Auto-liquidation. Réduire sa dette avec son propre collatéral évite la prime qu'un liquidateur prélèverait. Le parcours de remboursement par le collatéral de Kamino fait exactement cela.
- Bouclage (looping). Emprunter, échanger vers l'actif de collatéral, le déposer, emprunter dessus, rembourser. Le produit Multiply de Kamino repose sur ce principe.
- Volume de trading. Acheter un token et le revendre dans le même pool ; le portefeuille ne paie que l'aller-retour.
Ce dernier cas, c'est ce que fait l'outil Flash Volume. Il emprunte des SOL à Jupiter Lend, achète votre token dans un pool de PumpSwap, Raydium, Orca ou Meteora, le revend, rembourse et paie ses frais sous une seule signature, avec le prix complet de l'opération affiché avant l'ouverture de votre portefeuille. Quiconque lit la transaction voit un emprunt, un achat et une vente depuis un seul portefeuille. Pour garder les tokens, passez plutôt par un swap de tokens routé par Jupiter.
Combien coûte un prêt flash sur Solana
Le principal n'est pas un coût : il revient dans la même transaction. Vous payez tout ce qui l'entoure.
Les frais du prêteur. Jupiter Lend et marginfi documentent des prêts flash sans frais, et Kamino fixe des frais par réserve. L'administrateur de Jupiter Lend peut malgré tout modifier son réglage de frais. Flash Volume le lit donc avant chaque prêt et refuse de construire la transaction s'il n'est pas à zéro.
Frais de swap et impact sur le prix. Chaque swap à l'intérieur du prêt paie les frais de son pool, et un gros montant face à un pool peu profond fait bouger le prix contre vous deux fois, à l'entrée et à la sortie. Notre guide sur la profondeur d'un pool de liquidité montre pourquoi. Fixez un montant minimum reçu sur chaque swap, car un remboursement qui arrive trop court fait tout échouer ; le réglage du slippage sur Solana détaille ce compromis.
Frais de réseau. Les frais de base sont de 5 000 lamports par signature, plus des frais de priorité facturés par unité de calcul (compute unit) demandée, et un prêt flash demande bien plus de calcul qu'un simple transfert. Combien payer en frais de priorité explique comment les dimensionner.
Un prêt raté coûte peu, mais il n'est pas gratuit : une transaction incluse dans un bloc puis annulée paie quand même ses frais de réseau, comme le disent la documentation de Solana et le guide des prêts flash de Jupiter. Une transaction qui échoue en simulation et qui n'est jamais envoyée ne coûte rien.
Simulez avant de signer. Un prêt flash qui échouerait apparaît comme une simulation échouée, et à ce stade il ne vous a rien coûté.
Limites : taille de transaction, calcul et ce que détient le prêteur
Un prêt flash ne peut pas déborder d'une transaction. Les transactions v0 qu'utilisent ces prêts contiennent au plus 1 232 octets et 1 400 000 unités de calcul. L'emprunt, le remboursement, les swaps et leurs comptes doivent tous y tenir, d'où le recours des développeurs aux tables de correspondance d'adresses (address lookup tables).
Il ne peut pas non plus s'étendre sur deux transactions. Le sysvar ne liste que la transaction en cours : un remboursement placé dans une seconde transaction reste invisible pour l'emprunt, même à l'intérieur d'un seul bundle Jito. Ce que garantit un bundle Jito est une autre question.
Reste ce que détient le prêteur. Un prêt puise dans son coffre, certains prêteurs ajoutent un plafond par prêt, et les prêts peuvent être mis en pause. La taille maximale est donc une valeur à relever sur le moment, pas une constante. Kamino et marginfi n'autorisent en outre qu'un seul prêt flash par transaction.
Risques : alertes du portefeuille et attaques d'oracle
Attendez-vous à une alerte du portefeuille. Phantom avertit quand il ne parvient pas à simuler proprement une transaction, et cite parmi les causes une taille proche de la limite et des transactions qui échouent. Un prêt flash est volumineux et appelle à la fois un prêteur et un DEX. Quand un prix a trop bougé, sa simulation échoue : c'est le portefeuille qui vous dit que le prêt ne serait pas remboursé.
Chaque prêt flash est aussi public. N'importe qui peut ouvrir la transaction dans un explorateur, et l'analyse groupée de Wallet Scope montre les trades et le PnL des portefeuilles qui se trouvent derrière.
L'histoire plus sombre appartient à d'autres protocoles. Une attaque par prêt flash fausse un prix à l'intérieur d'une seule transaction : le montant emprunté pousse un pool peu profond, et un protocole qui lit ce pool comme source de prix agit sur un chiffre manipulé. La documentation de Kamino présente les prix pondérés dans le temps et les bandes de prix comme parade. Vos propres montants minimums limitent aussi les attaques sandwich autour d'un gros swap.
Prêt flash, prêt classique ou marge
| Prêt flash | Prêt avec collatéral | Marge | |
|---|---|---|---|
| Collatéral | Aucun | Supérieur au montant prêté | Votre dépôt plus la position |
| Durée | Une transaction | Jusqu'au remboursement | Tant que le compte reste en bonne santé |
| Sans remboursement | La transaction est annulée | Le collatéral est liquidé | La position est liquidée |
| Vous payez | Frais du prêteur s'il y en a, frais de swap et de réseau | Des intérêts tant qu'il court | Intérêts plus frais de trading |
Les prêts avec collatéral et la marge portent un risque dans la durée, parce que les prix bougent tant qu'ils restent ouverts. Un prêt flash sur Solana ne connaît pas de « tant que ». Vous pouvez perdre les frais d'une transaction annulée, plus toute perte de trading couverte par votre propre solde.
Cet article explique le fonctionnement des prêts flash et ne constitue pas un conseil financier, d'investissement, juridique ou fiscal. Les opérations menées à l'intérieur d'un prêt peuvent perdre de l'argent, et les prêteurs peuvent modifier leurs conditions ou suspendre les prêts.
Questions fréquentes sur le prêt flash
Un prêt flash sur Solana est-il gratuit ?
Le prêt lui-même peut l'être : Jupiter Lend et marginfi documentent des prêts flash sans frais, tandis que Kamino fixe des frais par réserve. Vous payez quand même les frais de swap, les frais de réseau et les éventuels frais de l'outil que vous utilisez.
Faut-il un collatéral ou une vérification de solvabilité ?
Non. Le remboursement doit seulement figurer dans la même transaction et réussir. Votre portefeuille a quand même besoin de SOL pour les frais de réseau et pour tout manque laissé par les opérations.
Que se passe-t-il si le prêt ne peut pas être remboursé ?
Toute la transaction est rejetée et chaque changement qu'elle contient est annulé, emprunt compris. Une transaction incluse dans un bloc paie quand même ses frais de réseau. Celle qui a échoué en simulation et n'a jamais été envoyée ne paie rien.
Un prêt flash peut-il couvrir deux transactions ou un bundle Jito ?
Non. Le prêteur trouve le remboursement grâce au sysvar des instructions, qui ne liste que la transaction en cours. Un remboursement placé ailleurs ne compte pas, même dans le même bundle.
Pourquoi les prêts flash apparaissent-ils dans les rapports d'attaques ?
Ils permettent à n'importe qui de disposer d'un gros montant le temps d'une transaction. Les attaques ont visé des protocoles qui se fiaient au prix spot d'un pool peu profond, que le montant emprunté pouvait faire bouger. Les prix moyennés dans le temps rendent cela bien plus difficile.
