DeFi : échanges automatisés, prêts et risques à comprendre

Dans un automate de marché, ou AMM, les utilisateurs échangent contre des réserves alimentées par des fournisseurs de liquidité. Une formule détermine les conditions de l’échange. Les modèles diffèrent : certains répartissent la liquidité sur une plage de prix choisie. Les frais peuvent rémunérer les participants, sans leur garantir un résultat positif.

Garanties et dépendances

Fournir deux actifs dans un pool modifie l’exposition lorsque leurs prix relatifs évoluent. La valeur obtenue au retrait peut être inférieure à celle d’une simple conservation des mêmes actifs, même après certains frais perçus. Cette différence est souvent appelée perte impermanente ; son nom ne signifie pas qu’elle disparaîtra automatiquement.

Les protocoles de prêt suivent d’autres mécanismes. Sur Aave, un emprunteur apporte des actifs en garantie et doit maintenir une couverture suffisante. Des paramètres définissent la capacité d’emprunt et les seuils de liquidation. Si la position devient insuffisamment couverte, des actifs peuvent être prélevés suivant les règles du marché concerné.

La dette peut augmenter avec les intérêts, tandis que la valeur de la garantie varie. Les oracles, qui apportent les prix aux contrats, deviennent alors essentiels. Une erreur de donnée, une faille technique, un actif perdant sa parité ou une gouvernance mal utilisée peuvent perturber le fonctionnement. Les risques se cumulent quand plusieurs protocoles sont combinés.

Les rendements affichés sont variables et peuvent comprendre des incitations payées en jetons. Ils doivent être distingués d’un gain effectivement réalisé après frais et variations de valeur. Une interface simple ne supprime pas la complexité sous-jacente : comprendre les contrats utilisés, les dépendances et les conditions de sortie reste indispensable.

Reconstituer la chaîne des dépendances

Une application DeFi peut utiliser plusieurs contrats et s’appuyer sur des données transmises par d’autres systèmes. L’utilisateur voit une interface unique, mais son opération traverse parfois plusieurs mécanismes. Un échange, un dépôt et un prêt n’ont pas les mêmes conditions. Les garanties de chaque composant doivent donc être examinées dans leur rôle précis. Le caractère public du code rend certaines vérifications possibles ; il ne permet pas d’affirmer que toutes les erreurs ou toutes les dépendances ont disparu.

Imaginons un emprunt adossé à un actif déposé en garantie. La valeur retenue pour ce dépôt dépend d’un mécanisme de prix, tandis que les conditions du prêt dépendent du protocole. Une évolution de cette valeur peut modifier la situation du compte sans nouvelle intervention de son utilisateur. Cette logique diffère d’une simple conservation de jetons dans un portefeuille. Le dépôt, les droits associés et les règles de liquidation constituent des éléments différents dont l’articulation explique le fonctionnement du service.

Identifier l’origine d’un rendement

Un rendement annoncé doit être relié à l’activité qui le finance. Frais d’échange, intérêts payés par des emprunteurs et distributions de jetons ne correspondent pas à la même ressource. Leur durée et leurs conditions peuvent évoluer. Le taux observé à un instant donné ne garantit donc pas un résultat futur identique. Les changements de paramètres, les droits d’administration et les possibilités de retrait comptent également. Une description complète du service doit présenter ces mécanismes plutôt que réduire l’offre à un chiffre de rémunération.