Design des AMM en 2026 : quand la courbe devient l’oracle

Un teneur de marché automatisé (AMM) a un métier officiel : laisser n’importe qui échanger deux actifs contre une courbe, sans carnet d’ordres ni contrepartie humaine. Mais il en exerce un second, qu’il n’a jamais demandé. À chaque instant, le rapport des réserves d’un pool définit un prix, et ce prix est public, lisible par n’importe quel autre contrat. Un protocole de prêt veut estimer votre garantie ? Il peut lire la courbe. Un dérivé a besoin d’un cours de référence ? La courbe est là. L’AMM est ainsi devenu, presque par accident, l’une des sources de prix les plus consultées de la finance on-chain.

Le problème, c’est que la courbe n’a pas été pensée pour ce rôle. Un prix spot d’AMM bouge dès qu’on le pousse, et le pousser ne coûte parfois presque rien. Depuis 2020, le même schéma revient : on gonfle un actif peu liquide, on le fait lire par un oracle naïf, puis on emprunte contre une valeur fictive. Le code change, le motif ne change pas. Cet article ne raconte pas ces casses une par une ; il prend le problème par l’autre bout, celui du concepteur. Pourquoi une courbe fait un mauvais oracle, et comment la DeFi l’a durcie, mécanisme après mécanisme. C’est le prolongement naturel de notre analyse de la formation du prix on-chain : une fois le prix formé, encore faut-il que d’autres puissent s’y fier.

Le second métier d’un AMM : devenir une source de prix

Rappelons la mécanique de base. Un pool Uniswap V2 détient deux actifs, disons de l’ether et de l’USDC, et maintient l’invariant x fois y égale k : le produit des deux réserves reste constant à chaque échange. Le prix marginal de l’ether, à un instant donné, n’est rien d’autre que le rapport des réserves. Si le pool contient 1 000 ETH et 2 155 000 USDC, l’ether y vaut 2 155 USDC. Ce nombre n’est écrit nulle part ; il se déduit des soldes du contrat, que tout le monde peut lire. L’ether cote justement autour de 2 155 euros à la mi-octobre 2026, et des milliers de contrats s’appuient, directement ou non, sur ce type de rapport.

La composabilité a fait le reste. Dès lors qu’un prix est disponible on-chain, gratuitement et sans permission, les développeurs s’en servent. Un marché de prêt a besoin de valoriser des garanties ; un protocole de stablecoin, de savoir si son ancrage tient ; un dérivé, de calculer un gain ou une perte. Construire son propre oracle coûte cher et introduit des dépendances externes. Lire le pool le plus profond de l’actif concerné paraît plus simple, plus décentralisé, plus dans l’esprit du code qui se suffit à lui-même. Uniswap a d’ailleurs documenté ce rôle très tôt : dès la V2, en mai 2020, le protocole a ajouté un oracle de prix cumulé, puis un oracle en moyenne géométrique en V3, précisément pour que les autres contrats puissent consommer son prix de façon plus robuste, selon la documentation d’Uniswap.

Le résultat est un glissement de responsabilité silencieux. L’AMM a été conçu pour une seule chose : échanger au prix du marché, quel qu’il soit. Servir de référence de prix pour le compte d’un tiers est une mission différente, qui exige une propriété que la courbe ne garantit pas d’elle-même : résister à quelqu’un qui aurait intérêt à la fausser. Uniswap traite aujourd’hui plus de 70 milliards de dollars de volume mensuel, davantage que ses trois poursuivants réunis selon crypto.news ; sa courbe est donc, de facto, une infrastructure de prix de premier plan. Ce qui rend sa robustesse d’oracle d’autant plus importante.

Pourquoi un prix spot se manipule presque gratuitement

Voici le défaut de naissance. Comme le prix spot est le rapport des réserves, toute transaction le déplace. Une grosse transaction le déplace beaucoup. Et rien n’empêche d’exécuter cette grosse transaction dans le seul but de fausser le prix pendant un instant, puis de défaire la position. Sur un pool profond, le déplacement coûte cher, car il faut avaler une part énorme de la liquidité. Sur un pool mince, il ne coûte presque rien : quelques dizaines de milliers de dollars suffisent à doubler ou décupler un cours.

Le flash loan a supprimé la dernière barrière, celle du capital. Dans une même transaction atomique, un attaquant emprunte des dizaines de millions sans garantie, pousse le prix d’un pool mince, laisse un contrat tiers lire ce prix gonflé, encaisse, puis rembourse le prêt ; si une étape échoue, toute la transaction est annulée. Autrement dit, un flash loan transforme n’importe qui en baleine le temps d’un bloc, sans en détenir le patrimoine. Qui contrôle vraiment le capital on-chain reste une autre question, que nous avons creusée dans notre dossier sur les baleines ; mais pour manipuler un oracle, il n’est même pas nécessaire d’en être une.

Un exemple chiffré fixe les idées. Reprenons le pool de 1 000 ETH et 2 155 000 USDC. Un attaquant qui y déverse 2 155 000 USDC supplémentaires fait passer les réserves à environ 1 000 ETH contre 4 310 000 USDC d’un côté de l’opération : le prix marginal de l’ether y double presque instantanément, bien au-delà de son cours réel sur le reste du marché. Si un protocole de prêt lit ce pool pour estimer une garantie libellée en ether, il la surestime d’autant, et laisse emprunter contre du vent. Le flash loan ne crée pas la faille ; il n’est que l’amplificateur. La vraie faille, c’est qu’un contrat ait traité un prix spot ponctuel, sur une seule source, comme une vérité.

Ce schéma n’a rien d’exotique. L’OWASP le classe désormais parmi les dix principaux risques des contrats intelligents, sous l’intitulé explicite de manipulation d’oracle de prix, dans son référentiel 2026. C’est dire si le défaut est connu. Reste à comprendre pourquoi il survit, et ce que les concepteurs opposent.

La petite histoire des courbes qu’on a fait mentir

Le même scénario se rejoue depuis cinq ans, à des échelles croissantes, et chaque incident a corrigé une génération de concepteurs. En février 2020, les deux attaques bZx, environ un million de dollars au total, furent les premières à combiner flash loan et prix spot d’AMM : un actif pompé sur un pool mince, lu tel quel par le protocole, décrit en détail par CoinDesk. En octobre 2020, Harvest Finance a perdu de l’ordre de 24 millions de dollars parce qu’un flash loan avait déséquilibré un pool Curve servant à valoriser ses parts, d’après The Block.

Deux cas méritent une mention particulière, car ils encadrent le débat de conception. Inverse Finance, en avril 2022, a perdu environ 15,6 millions de dollars sans même recourir à un gros flash loan : l’attaquant a manipulé un oracle en moyenne de temps sur un pool INV peu profond de Sushiswap, sur une fenêtre courte, poussant le jeton à des sommets absurdes avant d’emprunter contre, comme l’a rapporté CoinDesk. La leçon est cruciale : même une moyenne de temps, censée protéger, cède si le pool sous-jacent est trop mince. À l’autre extrême, Mango Markets, en octobre 2022, a vu son oracle MNGO bondir de plus de treize fois en une trentaine de minutes, selon la plainte de la CFTC ; l’attaquant a emprunté plus de 100 millions de dollars contre cette valeur gonflée. Fabriquer de la valeur à partir de rien n’est d’ailleurs pas propre aux oracles : c’est aussi le ressort du mint infini qui a vidé certains ponts, un mécanisme voisin que nous avons disséqué dans cette autopsie.

Le fil conducteur n’est pas la sophistication croissante des attaquants. C’est au contraire la persistance d’une erreur simple : traiter un prix d’AMM, par nature local et poussable, comme s’il reflétait un consensus de marché. Tout le travail de conception des six dernières années consiste à combler l’écart entre ces deux choses.

Le TWAP : transformer la manipulation en facture de temps

La première parade est la plus élégante, et la plus citée. Plutôt que de lire le prix à l’instant t, on lit sa moyenne sur une fenêtre, par exemple trente minutes : c’est le time-weighted average price, ou TWAP. Uniswap V2 l’a implémenté en accumulant le prix à chaque bloc, de sorte qu’un consommateur peut lire la moyenne entre deux instants quelconques ; V3 a raffiné le procédé en accumulant les ticks, ce qui donne une moyenne géométrique, plus robuste et moins gourmande en stockage, toujours selon la documentation d’Uniswap.

L’idée profonde est économique, pas cryptographique. Un TWAP ne rend pas la manipulation impossible ; il la rend chère. Pour tirer vers le haut une moyenne sur trente minutes, il ne suffit pas de pousser le prix une seconde : il faut le maintenir gonflé pendant toute la fenêtre. Or chaque bloc où le prix est faux est un bloc où des arbitragistes peuvent acheter l’actif sous-évalué de l’autre côté, remettant le pool d’aplomb et facturant la différence à l’attaquant. Le TWAP convertit donc la manipulation en un coût de maintien dans le temps, proportionnel à la profondeur du pool et à la durée de la fenêtre. Plus le pool est profond et la fenêtre longue, plus la facture grimpe.

Mais la parade a deux angles morts, et l’histoire les a trouvés tous les deux. Le premier : si le pool est trop mince, le coût de maintien reste faible même sur une fenêtre, et le TWAP cède, exactement comme sur Inverse Finance. Une moyenne de temps n’est jamais plus solide que la liquidité qu’elle moyenne. Le second angle mort est plus subtil, et il est apparu avec un changement d’architecture d’Ethereum lui-même.

Le passage au Proof-of-Stake a fragilisé le TWAP

Toute la solidité du TWAP repose sur une hypothèse : l’attaquant ne contrôle pas qui produit le prochain bloc, donc il ne peut pas garantir que son prix gonflé survivra sans être arbitré. C’était vrai sous Proof-of-Work, où le prochain mineur était imprévisible. Ce l’est beaucoup moins sous Proof-of-Stake, où les validateurs connaissent leurs créneaux de production à l’avance, parfois plusieurs minutes avant.

Uniswap a documenté le risque sans détour. Un validateur qui se voit attribuer deux blocs consécutifs peut, résume le protocole dans son billet sur les oracles V3, déplacer fortement le prix d’un pool dans le premier bloc puis le ramener dans le second, sans jamais s’exposer à un arbitrage entre les deux, puisque personne d’autre n’intercale de transaction. La manipulation d’un TWAP de courte fenêtre redevient alors envisageable pour un acteur bien doté en stake. Les ordres de grandeur avancés par Uniswap sont parlants : sur un pool USDC/WETH profond à 5 points de base, il faudrait de l’ordre de 710 milliards de dollars pour déplacer le prix de 20 % sur deux blocs, un montant prohibitif, mais seulement de l’ordre de 978 millions sur trois blocs consécutifs. Et un validateur qui détient 10 % du stake obtient trois blocs d’affilée environ 181 fois par mois.

La leçon n’est pas que le TWAP est inutile. Il reste une excellente défense contre la manipulation en un seul bloc, qui était la menace dominante. Mais il n’est plus une garantie absolue : sa solidité dépend désormais de la profondeur du pool, de la longueur de la fenêtre et de la distribution du stake sur le réseau sous-jacent. Un paramètre de sécurité qui dépend de la concentration des validateurs n’est plus un paramètre purement local. C’est précisément pour fermer cet angle mort qu’une nouvelle génération d’oracles d’AMM a vu le jour, dont nous parlerons plus loin.

Le paradoxe de l’efficacité du capital

Il existe une tension plus profonde, presque philosophique, entre les deux métiers de l’AMM. Tout ce qui rend une courbe meilleure pour échanger la rend souvent plus fragile comme oracle. L’exemple canonique est la liquidité concentrée introduite par Uniswap V3. En permettant aux fournisseurs de concentrer leur capital dans une bande de prix étroite, V3 a rendu l’échange beaucoup plus efficace : moins de capital immobilisé pour la même profondeur près du prix courant. Mais hors de cette bande, la liquidité peut être très mince, et pousser le prix au-delà des bornes concentrées coûte alors nettement moins cher. Un oracle qui lit un tel pool est donc plus facile à faire sortir des rails qu’un oracle lisant une courbe V2 uniformément peuplée.

Le paradoxe se double d’un problème de couverture. Les actifs très liquides, l’ether, le bitcoin, les grands stablecoins, disposent d’oracles externes fiables et de pools profonds : les manipuler est coûteux. Mais ce sont justement les actifs peu liquides, les jetons de gouvernance, les actifs de longue traîne, les nouveaux listings, qui n’ont souvent aucune source de prix hors de leur propre AMM. Le protocole qui veut les valoriser n’a, littéralement, que la courbe à lire. Et c’est là, sur les actifs les plus minces, que le prix spot est le plus manipulable. La difficulté est maximale là où l’enjeu de sécurité l’est aussi.

Ce dilemme explique pourquoi la bonne réponse dépend du type d’actif. Pour une paire d’actifs corrélés, comme deux dérivés de staking, ou pour des stablecoins, la courbe peut être modelée autour d’un ancrage, ce qui change complètement le calcul de robustesse ; nous avons détaillé ce cas dans notre analyse des courbes de stablecoins. Pour un actif volatil et profond, le TWAP bien paramétré suffit souvent. Pour un actif de longue traîne, aucune astuce de courbe ne remplace la prudence du consommateur, le dernier maillon de la chaîne, sur lequel nous reviendrons.

Chainlink et Pyth : externaliser le prix

La parade la plus répandue consiste à ne pas lire la courbe du tout, ou pas seulement. Au lieu de déduire un prix d’un unique pool, le protocole le reçoit d’un réseau d’oracles qui agrège de nombreuses sources, y compris les plateformes centralisées où se forme l’essentiel du volume. Manipuler un tel prix exige de fausser le marché partout à la fois, pas seulement un pool, ce qui change radicalement le coût de l’attaque.

Deux philosophies dominent. Chainlink fonctionne en mode push : un réseau décentralisé d’opérateurs calcule une médiane de nombreuses sources hors-chaîne et la pousse sur la chaîne à intervalles réguliers ou dès qu’un seuil de déviation est franchi. Fausser ce prix suppose de corrompre une majorité d’opérateurs, pas un pool. C’est le modèle des grands marchés de prêt comme Aave et Compound ; Chainlink sécurise environ 70 % de la valeur couverte par les oracles, de l’ordre de 38 milliards de dollars selon DefiLlama. Pyth suit la logique inverse, dite pull : des fournisseurs de première main, bourses et teneurs de marché, signent leurs prix, et l’application va chercher le dernier prix signé au moment précis où elle en a besoin, avec un intervalle de confiance attaché. Né dans l’écosystème Solana, Pyth revendique une couverture d’environ 3,08 milliards de dollars sur quelque 305 protocoles, d’après la comparaison publiée par RedStone.

Externaliser le prix ne clôt pas le débat pour autant. Les oracles externes ont leurs propres modes de défaillance : clé de signataire compromise, mise à jour en retard, actif sans couverture. Et ils réintroduisent la dépendance externe que les AMM voulaient justement éviter. Surtout, ils ne résolvent pas le cas de la longue traîne : un jeton qui n’existe que dans son propre pool restera valorisé par ce pool, oracle externe ou non. Pour ces actifs, la DeFi a dû durcir la courbe elle-même.

Uniswap V4 et l’oracle tronqué : la résistance par conception

La réponse la plus aboutie à ce jour vient des hooks d’Uniswap V4, ces modules que l’on branche sur un pool pour en modifier le comportement. Parmi eux, le Truncated Oracle Hook attaque le problème à la racine : plutôt que d’enregistrer fidèlement chaque mouvement de prix, il plafonne ce qu’un seul bloc peut inscrire dans l’oracle.

Le mécanisme est simple et c’est sa force. Le hook conserve une copie du tick du pool et le compare avant chaque échange. Tant que le mouvement reste en deçà d’un seuil, il enregistre la nouvelle valeur. Mais si le tick a bougé de plus de 9 116 unités en un bloc, il ne consigne que ce plafond de plus ou moins 9 116, selon le billet d’Uniswap. Or 9 116 ticks correspondent à un facteur d’environ 2,5 sur le prix : au-delà, la manipulation reste invisible pour l’oracle. Pour qu’un prix gonflé soit réellement enregistré, l’attaquant doit le maintenir pendant de nombreux blocs, le temps que l’oracle rattrape la nouvelle valeur par paliers. Uniswap chiffre ce délai à une quinzaine de blocs, soit environ cinq minutes, une éternité pendant laquelle les arbitragistes effacent le profit.

On retrouve la même philosophie que le TWAP, portée un cran plus loin : rendre la manipulation non pas impossible, mais si lente qu’elle devient économiquement absurde. La différence tient à ce que la résistance est désormais inscrite dans le mécanisme de l’oracle lui-même, et non déléguée à une fenêtre de moyenne que le consommateur doit bien paramétrer. C’est la manipulation conçue pour échouer, plutôt que découragée après coup.

L’OEV : quand même un prix juste fait fuir de la valeur

Il existe une forme de fuite plus insidieuse, qui n’exige aucune manipulation. Dès qu’un oracle publie un nouveau prix, il crée une opportunité : une position devient liquidable, un arbitrage s’ouvre, un seuil est franchi. La valeur captée par le premier qui réagit à cette mise à jour porte un nom, l’oracle extractable value, ou OEV, un cousin on-chain du MEV. Ici, le prix est parfaitement correct ; c’est le simple fait de sa publication qui laisse de l’argent sur la table, le plus souvent lors de liquidations.

L’ampleur n’est pas anecdotique. Selon The Block, Aave et Compound ont chacun engendré plus de 100 millions de dollars d’OEV depuis leur lancement, une valeur longtemps captée par des bots au détriment des protocoles et de leurs utilisateurs. D’où une vague d’inventions visant à la recapturer. UMA a lancé Oval, qui met aux enchères le droit d’exécuter une liquidation et reverse l’essentiel du produit au protocole concerné, comme l’explique l’annonce d’UMA. Chainlink a répliqué avec son Smart Value Recapture (SVR), une enchère scellée documentée dans ses pages techniques, qui revendique aujourd’hui près de 99 % du marché de la recapture d’OEV.

Hart Lambur, cofondateur de Risk Labs, à l’origine d’UMA, résume l’enjeu : une part importante de la valeur extraite tient simplement au fait que les protocoles ont besoin de mises à jour de prix, et Oval, selon lui, répond à un vrai problème en aidant ces protocoles à récupérer l’OEV plutôt que de l’abandonner à des tiers. Pour le concepteur d’AMM et d’oracle, la leçon est que la frontière entre extraction légitime et manipulation est parfois mince : les deux exploitent la même fenêtre, celle où un prix on-chain change. La différence, c’est qu’un prix faux relève du vol, tandis qu’un prix juste exploité au bon moment relève d’une mécanique de marché que l’on peut encadrer, voire monétiser au bénéfice du protocole.

Le consommateur du prix doit se discipliner

Toute la discussion précédente porte sur la fabrication du prix. Mais la moitié de la sécurité se joue chez celui qui le consomme. Un prix peut être parfaitement exact et rester dangereux à utiliser tel quel. C’est la formule la plus juste entendue en 2026, de la bouche de Marcin Kazmierczak, cofondateur de RedStone, après l’affaire Tectonic : rapporter un prix et valider qu’un prix est sûr pour prêter dessus sont deux métiers différents, a-t-il déclaré à crypto.news. L’oracle de Tectonic ne s’était pas trompé ; il avait fidèlement rapporté le prix du TONIC sur le pool qu’il lisait. L’erreur de conception était en amont : avoir accepté un jeton de gouvernance mince comme garantie, et lui avoir accordé un facteur de garantie non négligeable.

Le consommateur dispose pourtant d’un arsenal. Des facteurs de garantie prudents pour les actifs volatils ou peu liquides ; des plafonds sur la vitesse à laquelle un prix dérivé peut croître, comme le mécanisme CAPO d’Aave pour les actifs à rendement ; le recours à deux oracles indépendants dont on prend le minimum, ou un disjoncteur qui gèle un marché si le prix s’écarte trop vite. Aucune de ces défenses ne vit dans l’oracle ; toutes vivent dans le contrat qui lit l’oracle. Le tableau ci-dessous récapitule ce que chaque couche protège, et ce qu’elle laisse passer.