Minuit, votre nouveau protocole d'agrégation a soudainement connu une liquidation anormale. En un clin d'œil, les actifs des utilisateurs ont disparu, la communauté a explosé, mais le rapport d'audit indique que votre code de contrat « sans défaut ». Comment est-ce possible ?

Souvent, le problème ne vient pas de votre code — mais de la source de données que vous avez intégrée.

Ce n'est pas alarmiste. Les développeurs DeFi ne sont pas seulement des créateurs, ils sont aussi la première ligne de défense des actifs des utilisateurs. Dès que vous décidez d'intégrer un service d'oracle dans votre application, vous ne faites pas qu'apporter des données de prix, vous assumez aussi une responsabilité à long terme de « partage des risques ».

**Intégrer ne signifie pas se décharger**

Beaucoup de développeurs pensent à tort : en utilisant un grand service d'oracle, la responsabilité des données leur est transférée. Faux. Votre responsabilité commence dès que les données entrent dans le contrat.

Comprenez-vous vraiment le mécanisme de mise à jour de cette source de données ? Comment sont traités les valeurs aberrantes ? Le contrat prévoit-il des tolérances de délai et des vérifications d'anomalies ? Lorsque le réseau est congestionné, provoquant un retard dans les données, votre mécanisme de liquidation ne risque-t-il pas de déclencher une réaction en chaîne explosive ?

**Leçon sanglante**

Un protocole de prêt a déjà subi cette erreur. Ils n'avaient pas prévu de tolérance de délai pour les prix. Résultat : pendant une brève période de latence du réseau d'oracle, des bots d'arbitrage ont profité de l'occasion pour lancer des liquidations massives à des prix obsolètes avec peu de garanties. Des millions de dollars ont disparu en un instant, la confiance des utilisateurs s'est effondrée.

Le service d'oracle est un bon outil, mais la façon dont vous l'utilisez, jusqu'à quel point, dépend en fin de compte de votre propre jugement.