TLDR : ERC-4626 est la norme pour les coffres-forts à jetons.
Avant l'introduction de l'ERC-4626, chaque coffre avait ses propres spécifications et détails de mise en œuvre. Cela rend l'intégration difficile, sujette aux erreurs et gaspilleuse de ressources.
ERC-4626 tente de résoudre ce problème avec une spécification standard pour réduire l'effort d'intégration et créer un modèle d'implémentation plus cohérent et robuste, tout comme ERC-20.
Qu'est-ce que l'ERC-4626 ?
ERC-4626 est une norme qui améliore les paramètres techniques des chambres fortes. Il fournit une API standard pour les coffres de rendement représentant les parts d'un seul jeton ERC-20 sous-jacent.
Les coffres-forts tokenisés sont devenus un modèle extrêmement courant dans DeFi. Les agrégateurs de rendement, les marchés de prêt, les dérivés de jalonnement et de nombreux autres dApps tirent parti et s'appuient sur des coffres-forts à jetons. Yearn et Balancer sont des exemples de coffres-forts à jetons. En tant qu'agrégateur de rendement, Yearn Vault permet aux utilisateurs de déposer des actifs numériques et de gagner du rendement. Balancer est un gestionnaire de portefeuille automatisé et un fournisseur de liquidités qui s'appuie sur des coffres-forts au cœur de sa logique métier. Ces coffres gèrent les jetons dans différents pools. En même temps, ils séparent la gestion des jetons de la logique du pool lui-même.
Le protocole améliore la liquidité et la flexibilité en tokenisant ses coffres. Les coffres-forts tokenisés facilitent les transactions et l'utilisation des actifs sur les plates-formes DeFi. De plus, ils permettent la création de produits financiers divers et interconnectés. L'industrie s'est fait le champion de ce paradigme, souvent appelé « l'argent Lego ».
Cependant, la composabilité sans adaptabilité ou standardisation appropriée présente des défis. Non seulement il est difficile pour les développeurs de se conformer aux normes de l'industrie comme ERC-20, mais cela peut également dérouter les nouveaux développeurs. Sans adaptation ou normalisation appropriée, il est difficile d'examiner les nouveaux changements et de vérifier les détails de mise en œuvre des intégrations.
L'ERC-4626 a donc été proposé pour résoudre ce problème et simplifier l'intégration, tout en permettant aux participants DeFi d'adopter enfin une spécification de coffre-fort unifié plus sécurisée et robuste. Cela réduira à son tour la surface d'attaque possible du protocole tout en intégrant des jetons sur plusieurs protocoles.
Quels problèmes de sécurité l'ERC-4626 peut-il prévenir ?
En fournissant une norme unifiée, ERC-4626 accélère la construction de l'intégration interprotocole. Des normes familières et cohérentes sont également plus faciles à comprendre pour les développeurs, ce qui réduit la probabilité d'erreurs de codage. Cela permet d'éviter les problèmes de composabilité. La normalisation empêche également la duplication des efforts, car la communauté n'a besoin de concevoir le coffre qu'une seule fois, plutôt qu'individuellement pour chaque protocole. Étant donné que cet effort de conception est souvent sujet aux erreurs, il permet d'éviter la duplication de défauts de conception établis mais omniprésents.
Nous présenterons ici deux études de cas pour montrer quels problèmes ERC-4626 peut prévenir.
#### Événement Capitale Rari
Environ 11 millions de dollars de jetons ont été volés à Rari Capital, ce qui équivaut à 60 % de tous les fonds des utilisateurs du pool Rari Capital Ethereum.
Dans l'ensemble, Rari Capital a été piraté en raison d'une mise en œuvre non sécurisée de protocoles croisés. Son pool Ethereum prend ETH dans le contrat de jeton ibETH d'Alpha Finance en tant que stratégie de sortie. Cette stratégie spécifique suit la valeur de son taux de change ibETH/ETH à travers certains contrats et formules (en particulier, la fonction ibETH.totalETH / ibETH.totalSupply), qui peuvent avoir des sorties erronées dans ce scénario d'attaque, par exemple, lors de l'appel à ibETH.work ( ) fonction, les valeurs de la dette peuvent être artificiellement gonflées.
Un attaquant peut épuiser le Rari Fund Manager simplement en appelant à plusieurs reprises les fonctions de dépôt et de retrait dans le contrat RariFundManager. Les fonctions de dépôt et de retrait ont besoin d'obtenir le solde du pool pour calculer le nombre de jetons REPT à émettre à l'appelant, ou le montant d'ETH à émettre à l'appelant.Cette opération appellera la fonction getBalance du pool Alpha , appelez le contrat ibETH et sa fonction totalETH . Rari n'est pas au courant de la possibilité de manipuler cette fonction.
Il existe une autre fonction dans le contrat ibETH : ibETH.work. Cette fonction peut appeler n'importe quel contrat spécifié par l'utilisateur. Cela permet aux fonctions de dépôt et de retrait de Rari d'être réentrantes et d'être appelées plusieurs fois.
La fonction de travail est une fonction payante, ce qui signifie que l'utilisateur peut contrôler le montant d'ETH dans le contrat ibETH via la fonction de travail, modifiant ainsi la valeur renvoyée par la fonction totalETH. Pour aggraver les choses, la fonction de travail prend également en charge l'appel de tout autre contrat, tel que RariFundManager.
Grâce à cette fonction, l'attaquant peut envoyer à nouveau des ETH et augmenter le montant total d'ETH dans le contrat ibETH, et en même temps appeler le retrait dans le contrat RariFundManager pour racheter plus d'actifs.
Cet incident met en évidence les risques importants posés par une intégration insuffisante et des conceptions incompatibles dans les contrats DeFi. Il souligne comment des normes comme ERC-4626 peuvent empêcher de telles attaques en ajoutant une couche critique de sécurité et de prévisibilité, et promouvoir un comportement uniforme et une compréhension mutuelle.
Cas de financement de la crème
Cream Finance a subi une attaque sophistiquée qui a exploité deux faiblesses fondamentales de la plate-forme : un oracle de mélange manipulé et une offre de jetons non plafonnée. Un élément clé de l'attaque a été la manipulation de l'oracle de mixage, qui a affecté la valeur perçue du jeton yUSD. Lorsque l'attaquant a envoyé une grande quantité de jetons Yearn 4-Curve au coffre-fort yUSD, il a modifié le taux de change signalé par le coffre-fort et a donc également affecté la valeur perçue des jetons yUSD pour l'oracle.
La leçon clé ici est qu'un oracle de prix robuste et inmanipulable est essentiel à la stabilité d'un protocole DeFi. Les oracles de prix moyen pondéré dans le temps (TWAP) peuvent aider à prévenir de tels piratages, car ils sont plus résistants à la manipulation soudaine des prix.
Ces problèmes, ainsi que d'autres modèles de conception fragiles, peuvent être atténués par une adoption et une mise en œuvre prudentes de l'ERC-4626.
Risques de sécurité potentiels dans ERC-4626
Il y a toujours des compromis avec l'utilisation d'un nouveau protocole. Pour les coffres à jetons, il peut y avoir des problèmes potentiels pour les intégrer dans des contrats intelligents qui nécessitent une attention particulière.
Gérer les jetons feeOnTransfer
Si le coffre est conçu pour prendre en charge les jetons feeOnTransfer, vérifiez que le montant et les parts dans le coffre sont dans la plage attendue lors du transfert d'actifs.
Utilisation appropriée de la variable décimales
Bien que la fonction convertTo n'ait pas besoin d'utiliser la variable décimales du coffre EIP-4626, il est toujours fortement recommandé de refléter les décimales du jeton sous-jacent lorsque cela est possible. Cette pratique permet d'éliminer les sources potentielles de confusion et simplifie l'intégration pour divers utilisateurs frontaux et hors chaîne.
arrondi
Selon la spécification, les implémenteurs de coffre doivent être conscients que des directions d'arrondi spécifiques et opposées sont requises dans différentes méthodes mutables et d'affichage, car il est plus sûr de donner la priorité au coffre lui-même par rapport à ses utilisateurs lors des calculs :
S'il calcule le nombre d'actions à émettre à un utilisateur pour le montant d'un jeton sous-jacent qu'il offre, ou s'il opère pour transférer une part spécifique du jeton sous-jacent à un utilisateur, il doit être arrondi.
S'il calcule le nombre de partages qu'un utilisateur doit donner pour obtenir un certain nombre de jetons de base, ou s'il calcule le nombre de jetons de base qu'un utilisateur doit donner pour obtenir un certain nombre de partages, il devrait être arrondi.
Lorsque la direction d'arrondi préférée sera ambiguë, c'est la fonction convertTo. Pour assurer la cohérence entre toutes les implémentations de coffre EIP-4626, spécifiez que ces fonctions doivent toujours arrondir vers le bas. Les intégrateurs peuvent imiter eux-mêmes la version récapitulative, par exemple en ajoutant un Wei au résultat.
Le montant des actifs sous-jacents qu'un utilisateur reçoit en rachetant sa participation dans le coffre-fort (previewRedeem) peut varier considérablement par rapport au montant qui devrait être payé pour émettre le même montant de participation (previewMint). Ces différences peuvent être faibles (par exemple en raison d'erreurs d'arrondi) ou importantes (par exemple, un coffre-fort applique des frais de retrait ou de dépôt). Par conséquent, les intégrateurs doivent veiller à utiliser les fonctions de prévisualisation qui conviennent le mieux à leur cas d'utilisation et ne jamais supposer qu'elles sont interchangeables.
Remplacer la fonctionnalité principale
Afin d'implémenter ou d'étendre la fonctionnalité prévue, il est recommandé d'utiliser les crochets existants au lieu de modifier la fonctionnalité de base. Cette pratique garantit une piste plus gérable pour un test et un audit de code efficaces.
Partage zéro
La spécification d'origine pour ERC-4626 n'indiquait pas comment gérer le cas d'absence de partage dans le coffre-fort, et si le coffre-fort devait se comporter normalement ou revenir en arrière. Cela peut être une source potentielle de confusion et d'erreurs.
Les coffres-forts comme oracles de prix
En ce qui concerne le risque d'attaques de manipulation de prix oracle, les valeurs renvoyées par ces méthodes de prévisualisation sont aussi précises que possible. En tant que tels, ils peuvent fonctionner en modifiant les conditions de la chaîne et ne sont pas toujours sûrs à utiliser comme oracles de prix. La spécification ERC-4626 inclut une méthode convert et une méthode totalAssets qui permettent des imprécisions et peuvent donc être implémentées comme un oracle de prix puissant. Par exemple, lors de la conversion entre actifs et actions, il est correct d'utiliser le prix moyen pondéré dans le temps pour mettre en œuvre la méthode de conversion.
Problèmes concrets de mise en œuvre
Les intégrateurs doivent examiner toute implémentation de coffre à jetons avant toute intégration, car il peut y avoir des implémentations malveillantes qui semblent conformes à la spécification de l'interface, mais dont les fonctions principales consistent en des spécifications de conception complètement différentes.
Accès direct EOA
Si un coffre-fort doit être accessible directement, sa mise en œuvre doit avoir des fonctionnalités qui peuvent être utilisées pour tenir compte des pertes par glissement ou des limites de dépôt/retrait accidentel. Contrairement aux contrats intelligents, EOA ne dispose pas d'un mécanisme de sécurité pour l'annulation des transactions. Si la sortie précise n'est pas obtenue lors de l'appel de la fonction principale, il n'y a aucun moyen d'annuler.
Coffre-fort étendu
Au fur et à mesure que de plus en plus de joueurs commenceront à adopter la norme ERC-4626, nous verrons davantage d'extensions mises en œuvre pour la norme. Par exemple, Superform a développé une extension expérimentale Multi Vault qui prend en charge l'utilisation de différents calculs dans un seul contrat Vault. Naturellement, plus l'implémentation s'écarte de la norme d'origine, plus la possibilité d'introduire de nouvelles vulnérabilités est élevée. Les développeurs et les auditeurs peuvent trouver leur meilleure option en fonction du cas d'utilisation pour déterminer la valeur réelle à risque.
Il est important de noter que ce n'est pas le plus petit ajout de chaque protocole qui conduit à des événements catastrophiques, mais la somme de ceux-ci une fois intégrés.
Les vecteurs d'attaque potentiels mentionnés ci-dessus font partie des problèmes les plus discutés concernant la norme ERC-4626. Au fur et à mesure que l'adoption augmentera, nous explorerons certainement plus de cas d'utilisation d'implémentation et des scénarios plus appropriés pour l'intégration avec les coffres-forts ERC-4626.
Voir l'original
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Comprendre ERC-4626 dans un article : la nouvelle norme pour les coffres-forts tokenisés DeFi
TLDR : ERC-4626 est la norme pour les coffres-forts à jetons.
Avant l'introduction de l'ERC-4626, chaque coffre avait ses propres spécifications et détails de mise en œuvre. Cela rend l'intégration difficile, sujette aux erreurs et gaspilleuse de ressources.
ERC-4626 tente de résoudre ce problème avec une spécification standard pour réduire l'effort d'intégration et créer un modèle d'implémentation plus cohérent et robuste, tout comme ERC-20.
Qu'est-ce que l'ERC-4626 ?
ERC-4626 est une norme qui améliore les paramètres techniques des chambres fortes. Il fournit une API standard pour les coffres de rendement représentant les parts d'un seul jeton ERC-20 sous-jacent.
Les coffres-forts tokenisés sont devenus un modèle extrêmement courant dans DeFi. Les agrégateurs de rendement, les marchés de prêt, les dérivés de jalonnement et de nombreux autres dApps tirent parti et s'appuient sur des coffres-forts à jetons. Yearn et Balancer sont des exemples de coffres-forts à jetons. En tant qu'agrégateur de rendement, Yearn Vault permet aux utilisateurs de déposer des actifs numériques et de gagner du rendement. Balancer est un gestionnaire de portefeuille automatisé et un fournisseur de liquidités qui s'appuie sur des coffres-forts au cœur de sa logique métier. Ces coffres gèrent les jetons dans différents pools. En même temps, ils séparent la gestion des jetons de la logique du pool lui-même.
Le protocole améliore la liquidité et la flexibilité en tokenisant ses coffres. Les coffres-forts tokenisés facilitent les transactions et l'utilisation des actifs sur les plates-formes DeFi. De plus, ils permettent la création de produits financiers divers et interconnectés. L'industrie s'est fait le champion de ce paradigme, souvent appelé « l'argent Lego ».
Cependant, la composabilité sans adaptabilité ou standardisation appropriée présente des défis. Non seulement il est difficile pour les développeurs de se conformer aux normes de l'industrie comme ERC-20, mais cela peut également dérouter les nouveaux développeurs. Sans adaptation ou normalisation appropriée, il est difficile d'examiner les nouveaux changements et de vérifier les détails de mise en œuvre des intégrations.
L'ERC-4626 a donc été proposé pour résoudre ce problème et simplifier l'intégration, tout en permettant aux participants DeFi d'adopter enfin une spécification de coffre-fort unifié plus sécurisée et robuste. Cela réduira à son tour la surface d'attaque possible du protocole tout en intégrant des jetons sur plusieurs protocoles.
Quels problèmes de sécurité l'ERC-4626 peut-il prévenir ?
En fournissant une norme unifiée, ERC-4626 accélère la construction de l'intégration interprotocole. Des normes familières et cohérentes sont également plus faciles à comprendre pour les développeurs, ce qui réduit la probabilité d'erreurs de codage. Cela permet d'éviter les problèmes de composabilité. La normalisation empêche également la duplication des efforts, car la communauté n'a besoin de concevoir le coffre qu'une seule fois, plutôt qu'individuellement pour chaque protocole. Étant donné que cet effort de conception est souvent sujet aux erreurs, il permet d'éviter la duplication de défauts de conception établis mais omniprésents.
Nous présenterons ici deux études de cas pour montrer quels problèmes ERC-4626 peut prévenir.
#### Événement Capitale Rari
Environ 11 millions de dollars de jetons ont été volés à Rari Capital, ce qui équivaut à 60 % de tous les fonds des utilisateurs du pool Rari Capital Ethereum.
Dans l'ensemble, Rari Capital a été piraté en raison d'une mise en œuvre non sécurisée de protocoles croisés. Son pool Ethereum prend ETH dans le contrat de jeton ibETH d'Alpha Finance en tant que stratégie de sortie. Cette stratégie spécifique suit la valeur de son taux de change ibETH/ETH à travers certains contrats et formules (en particulier, la fonction ibETH.totalETH / ibETH.totalSupply), qui peuvent avoir des sorties erronées dans ce scénario d'attaque, par exemple, lors de l'appel à ibETH.work ( ) fonction, les valeurs de la dette peuvent être artificiellement gonflées.
Un attaquant peut épuiser le Rari Fund Manager simplement en appelant à plusieurs reprises les fonctions de dépôt et de retrait dans le contrat RariFundManager. Les fonctions de dépôt et de retrait ont besoin d'obtenir le solde du pool pour calculer le nombre de jetons REPT à émettre à l'appelant, ou le montant d'ETH à émettre à l'appelant.Cette opération appellera la fonction getBalance du pool Alpha , appelez le contrat ibETH et sa fonction totalETH . Rari n'est pas au courant de la possibilité de manipuler cette fonction.
Il existe une autre fonction dans le contrat ibETH : ibETH.work. Cette fonction peut appeler n'importe quel contrat spécifié par l'utilisateur. Cela permet aux fonctions de dépôt et de retrait de Rari d'être réentrantes et d'être appelées plusieurs fois.
La fonction de travail est une fonction payante, ce qui signifie que l'utilisateur peut contrôler le montant d'ETH dans le contrat ibETH via la fonction de travail, modifiant ainsi la valeur renvoyée par la fonction totalETH. Pour aggraver les choses, la fonction de travail prend également en charge l'appel de tout autre contrat, tel que RariFundManager.
Grâce à cette fonction, l'attaquant peut envoyer à nouveau des ETH et augmenter le montant total d'ETH dans le contrat ibETH, et en même temps appeler le retrait dans le contrat RariFundManager pour racheter plus d'actifs.
Cet incident met en évidence les risques importants posés par une intégration insuffisante et des conceptions incompatibles dans les contrats DeFi. Il souligne comment des normes comme ERC-4626 peuvent empêcher de telles attaques en ajoutant une couche critique de sécurité et de prévisibilité, et promouvoir un comportement uniforme et une compréhension mutuelle.
Cas de financement de la crème
Cream Finance a subi une attaque sophistiquée qui a exploité deux faiblesses fondamentales de la plate-forme : un oracle de mélange manipulé et une offre de jetons non plafonnée. Un élément clé de l'attaque a été la manipulation de l'oracle de mixage, qui a affecté la valeur perçue du jeton yUSD. Lorsque l'attaquant a envoyé une grande quantité de jetons Yearn 4-Curve au coffre-fort yUSD, il a modifié le taux de change signalé par le coffre-fort et a donc également affecté la valeur perçue des jetons yUSD pour l'oracle.
La leçon clé ici est qu'un oracle de prix robuste et inmanipulable est essentiel à la stabilité d'un protocole DeFi. Les oracles de prix moyen pondéré dans le temps (TWAP) peuvent aider à prévenir de tels piratages, car ils sont plus résistants à la manipulation soudaine des prix.
Ces problèmes, ainsi que d'autres modèles de conception fragiles, peuvent être atténués par une adoption et une mise en œuvre prudentes de l'ERC-4626.
Risques de sécurité potentiels dans ERC-4626
Il y a toujours des compromis avec l'utilisation d'un nouveau protocole. Pour les coffres à jetons, il peut y avoir des problèmes potentiels pour les intégrer dans des contrats intelligents qui nécessitent une attention particulière.
Gérer les jetons feeOnTransfer
Si le coffre est conçu pour prendre en charge les jetons feeOnTransfer, vérifiez que le montant et les parts dans le coffre sont dans la plage attendue lors du transfert d'actifs.
Utilisation appropriée de la variable décimales
Bien que la fonction convertTo n'ait pas besoin d'utiliser la variable décimales du coffre EIP-4626, il est toujours fortement recommandé de refléter les décimales du jeton sous-jacent lorsque cela est possible. Cette pratique permet d'éliminer les sources potentielles de confusion et simplifie l'intégration pour divers utilisateurs frontaux et hors chaîne.
arrondi
Selon la spécification, les implémenteurs de coffre doivent être conscients que des directions d'arrondi spécifiques et opposées sont requises dans différentes méthodes mutables et d'affichage, car il est plus sûr de donner la priorité au coffre lui-même par rapport à ses utilisateurs lors des calculs :
S'il calcule le nombre d'actions à émettre à un utilisateur pour le montant d'un jeton sous-jacent qu'il offre, ou s'il opère pour transférer une part spécifique du jeton sous-jacent à un utilisateur, il doit être arrondi.
S'il calcule le nombre de partages qu'un utilisateur doit donner pour obtenir un certain nombre de jetons de base, ou s'il calcule le nombre de jetons de base qu'un utilisateur doit donner pour obtenir un certain nombre de partages, il devrait être arrondi.
Lorsque la direction d'arrondi préférée sera ambiguë, c'est la fonction convertTo. Pour assurer la cohérence entre toutes les implémentations de coffre EIP-4626, spécifiez que ces fonctions doivent toujours arrondir vers le bas. Les intégrateurs peuvent imiter eux-mêmes la version récapitulative, par exemple en ajoutant un Wei au résultat.
Le montant des actifs sous-jacents qu'un utilisateur reçoit en rachetant sa participation dans le coffre-fort (previewRedeem) peut varier considérablement par rapport au montant qui devrait être payé pour émettre le même montant de participation (previewMint). Ces différences peuvent être faibles (par exemple en raison d'erreurs d'arrondi) ou importantes (par exemple, un coffre-fort applique des frais de retrait ou de dépôt). Par conséquent, les intégrateurs doivent veiller à utiliser les fonctions de prévisualisation qui conviennent le mieux à leur cas d'utilisation et ne jamais supposer qu'elles sont interchangeables.
Remplacer la fonctionnalité principale
Afin d'implémenter ou d'étendre la fonctionnalité prévue, il est recommandé d'utiliser les crochets existants au lieu de modifier la fonctionnalité de base. Cette pratique garantit une piste plus gérable pour un test et un audit de code efficaces.
Partage zéro
La spécification d'origine pour ERC-4626 n'indiquait pas comment gérer le cas d'absence de partage dans le coffre-fort, et si le coffre-fort devait se comporter normalement ou revenir en arrière. Cela peut être une source potentielle de confusion et d'erreurs.
Les coffres-forts comme oracles de prix
En ce qui concerne le risque d'attaques de manipulation de prix oracle, les valeurs renvoyées par ces méthodes de prévisualisation sont aussi précises que possible. En tant que tels, ils peuvent fonctionner en modifiant les conditions de la chaîne et ne sont pas toujours sûrs à utiliser comme oracles de prix. La spécification ERC-4626 inclut une méthode convert et une méthode totalAssets qui permettent des imprécisions et peuvent donc être implémentées comme un oracle de prix puissant. Par exemple, lors de la conversion entre actifs et actions, il est correct d'utiliser le prix moyen pondéré dans le temps pour mettre en œuvre la méthode de conversion.
Problèmes concrets de mise en œuvre
Les intégrateurs doivent examiner toute implémentation de coffre à jetons avant toute intégration, car il peut y avoir des implémentations malveillantes qui semblent conformes à la spécification de l'interface, mais dont les fonctions principales consistent en des spécifications de conception complètement différentes.
Accès direct EOA
Si un coffre-fort doit être accessible directement, sa mise en œuvre doit avoir des fonctionnalités qui peuvent être utilisées pour tenir compte des pertes par glissement ou des limites de dépôt/retrait accidentel. Contrairement aux contrats intelligents, EOA ne dispose pas d'un mécanisme de sécurité pour l'annulation des transactions. Si la sortie précise n'est pas obtenue lors de l'appel de la fonction principale, il n'y a aucun moyen d'annuler.
Coffre-fort étendu
Au fur et à mesure que de plus en plus de joueurs commenceront à adopter la norme ERC-4626, nous verrons davantage d'extensions mises en œuvre pour la norme. Par exemple, Superform a développé une extension expérimentale Multi Vault qui prend en charge l'utilisation de différents calculs dans un seul contrat Vault. Naturellement, plus l'implémentation s'écarte de la norme d'origine, plus la possibilité d'introduire de nouvelles vulnérabilités est élevée. Les développeurs et les auditeurs peuvent trouver leur meilleure option en fonction du cas d'utilisation pour déterminer la valeur réelle à risque.
Il est important de noter que ce n'est pas le plus petit ajout de chaque protocole qui conduit à des événements catastrophiques, mais la somme de ceux-ci une fois intégrés.
Les vecteurs d'attaque potentiels mentionnés ci-dessus font partie des problèmes les plus discutés concernant la norme ERC-4626. Au fur et à mesure que l'adoption augmentera, nous explorerons certainement plus de cas d'utilisation d'implémentation et des scénarios plus appropriés pour l'intégration avec les coffres-forts ERC-4626.