Attaque inflationniste du premier dépôt ERC-4626 : comment l'arrondi peut effacer les parts

Découvrez comment un don direct peut manipuler le taux de change d'un coffre ERC-4626 vide, arrondir à zéro les parts d'un déposant et comment les implémentations et les utilisateurs peuvent limiter le risque.

À des fins éducatives uniquement ; ceci ne constitue pas un conseil en investissement. Investir peut entraîner des pertes.

Réponse directe

Une attaque inflationniste du premier dépôt cible un coffre ERC-4626 vide ou presque vide. L’attaquant dépose une très petite quantité pour recevoir les premières parts, puis transfère directement les actifs sous-jacents au coffre. Ce don augmente totalAssets() sans augmenter totalSupply(), ce qui accroît la valeur de chaque part existante.

Si le dépôt de la victime est converti à ce taux de change manipulé, la division entière peut arrondir le résultat à très peu de parts, voire à zéro. Les actifs de la victime restent dans le coffre tandis que l’attaquant, détenteur des parts en circulation, peut racheter le droit gonflé. Il s’agit d’un problème de manipulation du taux de change et de glissement, et non d’un défaut de l’interface ERC-4626 elle-même.

Fonctionnement

Dans un coffre simple sans frais ni décalages de protection, les parts créées pour un dépôt valent approximativement assets * totalSupply / totalAssets. ERC-4626 exige que le calcul des parts pour un montant d’actifs donné favorise le coffre en arrondissant vers le bas. Avec des taux de change normaux, la perte d’arrondi est minime, mais un dépôt valant moins d’une part peut perdre 100 % par arrondi lorsque le prix de la part a été gonflé.

L’attaque dépend des détails de l’implémentation. Un transfert ERC-20 direct peut augmenter les actifs comptabilisés par le coffre sans créer de parts, en particulier lorsque totalAssets() lit le solde de jetons du coffre. L’attaquant doit également passer devant la victime lorsque l’offre de parts est très faible. Les coffres qui utilisent une autre comptabilité ou des défenses explicites peuvent ne pas être vulnérables de la même manière.

Exemple

Supposons qu’un coffre vide vulnérable commence à un taux de 1:1. L’attaquant dépose 1 unité d’actif et reçoit 1 part, puis donne directement 999 unités. Le coffre contient alors 1,000 actifs pour garantir 1 part. La victime dépose 999 unités ; le calcul naïf donne 999 * 1 / 1,000 = 0 part après l’arrondi entier.

Le coffre détient ensuite 1,999 actifs alors que seule la 1 part de l’attaquant existe. Si le dépôt autorise un résultat de zéro part et qu’il n’y a ni frais ni autre contrainte, l’attaquant peut racheter cette part contre la totalité des 1,999 actifs : la 1 unité déposée à l’origine, le don de 999 unités et le dépôt de la victime de 999 unités. Son bénéfice brut correspond aux 999 unités de la victime, avant les coûts de transaction.

Risques et protections

Les implémenteurs peuvent réduire le risque en apportant une liquidité initiale significative, en brûlant ou en verrouillant les parts initiales, en imposant un résultat minimal d’au moins une part ou en utilisant un taux de change avec actifs et parts virtuels. L’implémentation d’OpenZeppelin ajoute des montants virtuels et prend en charge une précision supplémentaire grâce à un décalage des décimales ; dans le modèle documenté, les parts virtuelles capturent une partie de chaque don, rendant la manipulation non rentable ou beaucoup plus coûteuse. Chaque défense repose sur des hypothèses et doit être testée contre les transferts directs, les limites d’arrondi, les frais, les pertes et les comportements inhabituels des jetons.

Les utilisateurs et intégrateurs doivent considérer previewDeposit() comme une cotation, et non comme un minimum garanti. Envoyez les dépôts via une fonction ou un routeur qui impose un nombre minimal de parts acceptable et annule la transaction si cette limite n’est pas atteinte. Avant de déposer dans un coffre nouveau ou faiblement approvisionné, vérifiez totalAssets(), totalSupply(), la formule de conversion de l’implémentation et l’effet éventuel des transferts de jetons non sollicités sur la comptabilité. Une cotation favorable du front-end ne protège pas une transaction dont l’ordre d’exécution peut être réorganisé.

Idées fausses courantes

Mythe 1 : ERC-4626 garantit lui-même un taux de change sûr. La norme définit une interface commune et un comportement d’arrondi ; elle ne rend pas toutes les implémentations immunisées contre la manipulation du taux de change.
Mythe 2 : appeler previewDeposit() juste avant deposit() garantit ce résultat. L’état de la chaîne peut changer entre les appels ou avant l’exécution. Le parcours de dépôt doit imposer une limite minimale de parts.
Mythe 3 : refuser uniquement les dépôts produisant zéro part élimine l’attaque. Cela évite le résultat le plus extrême, mais un attaquant peut encore réduire un dépôt à quelques parts et provoquer une forte perte d’arrondi. Les défenses doivent encadrer le glissement acceptable, et pas seulement exiger un résultat non nul.

Sujets connexes

Sources

ERC-4626 : coffres tokenisés - Ethereum Improvement Proposals (consulté le : 2026-08-20)
Norme des coffres tokenisés ERC-4626 - OpenZeppelin (consulté le : 2026-08-20)
Implémentation ERC4626 d’OpenZeppelin - OpenZeppelin (consulté le : 2026-08-20)