Analyse approfondie de la vulnérabilité : un flux de rachat échoué qui pourrait laisser le collatéral bloqué et temporairement en dehors de son chemin de déploiement prévu. Au cours de plusieurs cycles de travail d'audit impliquant @aegis_im, un problème de gravité moyenne datant de mai 2025 a mis en évidence exactement cela. L'équipe Aegis a pris les bonnes mesures pour le résoudre, le réexaminer et le traiter complètement. La configuration Le flux d'approbation de rachat d'Aegis fonctionnait en deux étapes. Le collatéral était transféré dans AegisMinting en tant que pré-dépôt. Le gestionnaire de fonds appelait ensuite approveRedeemRequest() pour finaliser le rachat. Cela semble raisonnable. Mais cela a créé un cas limite dangereux. Si approveRedeemRequest() échouait en raison de vérifications de glissement, d'expiration ou d'une autre contrainte d'approbation, le rachat échouait, mais le collatéral qui avait déjà été déplacé n'était pas retourné. Il restait bloqué à l'intérieur d'AegisMinting. Pourquoi c'était important Ce collatéral était censé continuer à circuler à travers le déploiement et le flux de gestion des risques d'Aegis. Dans un fonctionnement normal, cela pourrait inclure la conversion du collatéral et son déploiement dans une stratégie delta-neutre pour réduire l'exposition au prix. Lorsque les fonds étaient bloqués avant l'approbation, rien de tout cela ne se produisait. Le capital de soutien a cessé de générer des rendements comme prévu. Le soutien est resté non couvert et exposé aux mouvements de prix du collatéral, y compris le risque de dépeg des stablecoins. Si ce soutien perdait de la valeur alors que l'offre de YUSD restait inchangée, la pression de dépeg augmentait. Une approbation de rachat échouée pouvait laisser le système porter un risque qu'il n'était pas censé porter. Cause profonde Conception non atomique. Le système a d'abord déplacé la garde, puis a vérifié si l'approbation pouvait réellement être complétée. Une fois le collatéral à l'intérieur d'AegisMinting, un retour ultérieur dans approveRedeemRequest() laissait le protocole dans un état intermédiaire : le rachat n'était pas approuvé, le collatéral avait déjà été déplacé, et il n'y avait pas de mécanisme de retour forcé pour annuler le dépôt. Le dépôt et l'approbation étaient séparés, et un échec dans la deuxième étape piégeait la valeur de la première. Exemple de chemin d'échec Une demande de rachat est initiée. Le collatéral est transféré dans AegisMinting. Avant l'approbation, la commande expire ou le glissement sort des limites. Le gestionnaire de fonds appelle approveRedeemRequest(). Cela revient. Le collatéral reste bloqué, non déployé et non couvert. Aucun comportement d'attaquant exotique n'était nécessaire. Cela pouvait se déclencher à travers le flux d'approbation normal. Solution La mitigation la plus propre était de rendre le flux atomique. Valider le rachat, transférer le collatéral et finaliser l'approbation en un seul chemin afin que les fonds ne bougent que si l'approbation réussit. Si une structure en deux étapes doit rester, le protocole a besoin d'un chemin de récupération clair tel que cancelRedeemRequest(), refundRedeemDeposit() ou une comptabilité de style séquestre afin que les dépôts non finalisés soient toujours récupérables par la partie légitime. Pourquoi celui-ci vaut la peine d'être étudié C'est le genre de problème qui compte dans les audits. Les systèmes financiers à plusieurs étapes ne se cassent pas tous en même temps. Ils se cassent dans des états partiels. Les fonds se déplacent, une dépendance échoue, et le protocole se retrouve à porter un risque qu'il n'était jamais censé porter. Beaucoup de conclusions solides proviennent exactement de ce genre de flux à moitié complété. Le collatéral se retrouve bloqué. Les hypothèses comptables cessent de tenir. Le soutien finit par être inactif, exposé ou en dehors du chemin qu'il était censé suivre. Un chemin propre et heureux ne protège pas un système des dommages causés par un chemin incomplet. Un grand merci à l'équipe @aegis_im de nous avoir permis de mettre en lumière ce problème et d'avoir pris les bonnes mesures pour le corriger et le réexaminer en profondeur.

Rappel amical : si votre protocole n'utilise pas l'audit AI, vous mettez votre équipe dans une situation de désavantage majeur par rapport aux équipes qui le font déjà. Ce n'est pas un changement futur. Cela se produit déjà maintenant.

Nous sommes ravis d'accueillir @Liquidity_land en tant que partenaire de sécurité Sherlock. Grâce à ce partenariat, les équipes web3 du réseau bénéficient d'avantages et de réductions sur Sherlock AI, l'audit, les programmes de récompenses pour bugs et l'offre complète de sécurité tout au long du cycle de vie de Sherlock. Liquidity Land aide les protocoles à attirer des TVL grâce à des programmes de liquidité structurés conçus pour une croissance à long terme en se connectant avec des capitaux institutionnels, des baleines et des LPs coordonnés. Nous sommes impatients d'aider davantage d'équipes à se renforcer dès le premier jour.