Je viens de finir de traduire un cas d’audit lié à un oracle, et j’ai quelques réflexions.

Les oracles qui servent de “prix” pour les messages inter-chaînes de LayerZero sont en réalité assez fragiles. Dès qu’il y a un décalage, même à l’échelle de la milliseconde, dans la synchronisation des horodatages de bloc, ou qu’un nœud est attaqué, tu vois, la fenêtre de liquidation peut être passée avant même que tu clignes des yeux. L’article de Haseeb Qureshi sur les fenêtres de temps le dit assez clairement : ce n’est pas que la technique soit très compliquée, c’est surtout un jeu d’écosystème où celui qui court le plus lentement finit par payer.

Ces derniers temps, les “AI agents” font beaucoup de bruit partout : trading automatisé, automatisation des opérations on-chain… ça a l’air vachement cool. Mais quand je j’ai parcouru certains codes de contrats d’agents, en gros, c’est juste un modèle de langage qui a été “enfilé” par-dessus de vieux MEV bots. Leur réaction face au retard de l’alimentation en prix n’est pas vraiment meilleure que celle des humains ; parfois c’est même plus rigide. Le contrat verrouille un intervalle de prix : quand le marché on-chain bouge d’un coup, ça déclenche immédiatement un gros mouvement, puis tu les regardes se liquider eux-mêmes en boucle.

Du coup, j’ai pris l’habitude d’ajouter une étape de validation manuelle : croiser le volume de transactions dans la fenêtre de temps autour d’une adresse d’oracle, puis lancer une simulation locale pour vérifier l’écart de cotation avant d’agir. C’est plus pénible, mais au moins ça évite d’être remis à zéro par une simple “précision de prix à cause du retard”.

La sécurité, c’est juste accepter de passer un peu plus de temps pour ne pas perdre d’argent. Pas de blabla.