Début octobre 2026, NEAR Intents a suspendu une partie de son service cross-chain après une exploitation touchant le mécanisme de dépôt et de retrait de son système Omni. Les premiers articles de presse ont évalué la perte à environ 3,8 millions de dollars. Selon ces mêmes informations, les actifs ont ensuite été restitués après identification et prise de contact avec l’auteur de l’exploitation.
La restitution des fonds est une bonne nouvelle. Mais l’enseignement architectural est plus durable : l’abstraction des blockchains ne fait pas disparaître la complexité des échanges entre réseaux. Elle la déplace derrière une interface plus simple.
Ce qui est établi publiquement
Selon les informations publiées les 1er et 2 octobre, le problème concernait l’interaction entre le système Omni de NEAR Intents et une partie de sa couche de smart contracts.
Les dépôts et retraits de plusieurs réseaux ont été restreints pendant l’enquête et l’application de correctifs. Le projet a annoncé que les utilisateurs touchés seraient indemnisés ; les actifs détournés ont ensuite été rendus, selon la presse spécialisée.
À la date de rédaction de l’article, aucun rapport technique officiel détaillant l’ensemble des chemins de code vulnérables n’était disponible dans les sources utilisées. Cette limite doit être respectée.
Il serait donc inexact d’affirmer que le consensus de NEAR, tous les solvers ou le modèle Intents dans son ensemble ont été compromis. En revanche, cet incident permet d’examiner l’architecture des flux cross-chain.
L’abstraction simplifie l’interface, pas la vérification
NEAR Intents repose sur une logique d’objectifs : l’utilisateur exprime le résultat qu’il souhaite obtenir.
Au lieu de sélectionner manuellement un bridge, un itinéraire d’exécution et une source de liquidité, il indique l’actif ou le résultat attendu. Des solvers se mettent en concurrence pour satisfaire cette intention.
Pour l’utilisateur et les équipes d’intégration, c’est une amélioration majeure de l’expérience.
Mais une question devient centrale : qui vérifie que le résultat souhaité et le chemin réel de règlement sont bien équivalents ?
Un système cross-chain peut impliquer simultanément :
- un contrat de dépôt sur la blockchain d’origine ;
- une couche de comptabilité ou de routage ;
- des solvers ou market makers hors chaîne ;
- la vérification de messages ;
- des contrats sur la blockchain de destination ;
- des mécanismes de retrait ;
- des chemins de remboursement ;
- des fonctions administratives de suspension.
L’utilisateur peut ne signer qu’une seule demande. Le système doit pourtant coordonner correctement l’ensemble de ces éléments.
Une opération en un clic peut traverser plusieurs frontières de confiance
Une opération présentée comme unique ne correspond pas nécessairement à une seule frontière de sécurité.
Les failles peuvent apparaître dans :
- l’attribution d’un dépôt au bon compte ;
- l’authentification d’un message inter-chaînes ;
- le calcul d’un remboursement ;
- l’autorisation donnée à un solver ;
- le lien entre une demande de retrait et l’état réellement constaté sur la chaîne source ;
- la réconciliation entre l’état des smart contracts et les informations conservées hors chaîne.
C’est un schéma récurrent dans les bridges et les systèmes d’intents. Plus l’interface devient simple, plus la partie cachée de l’architecture peut devenir interconnectée.
Une bonne conception produit doit réduire le risque d’erreur pour l’utilisateur. Elle ne doit pas faire oublier aux opérateurs le nombre de composants intervenant réellement.
La récupération des fonds ne supprime pas la défaillance
La restitution des actifs a réduit l’impact financier final de cet incident.
Mais elle ne transforme pas la faille en événement anodin.
Une analyse de sécurité doit distinguer trois questions :
- Une vulnérabilité était-elle exploitable ?
- A-t-elle réellement été exploitée ?
- Les fonds ont-ils finalement été récupérés ?
La troisième réponse modifie le bilan financier, pas la réalité de la défaillance initiale.
Un retour d’expérience utile doit donc étudier le chemin vulnérable, y compris lorsque les victimes sont remboursées ou que l’auteur rend les actifs.
Les questions à poser avant d’intégrer un système cross-chain
Une équipe qui dépend d’un bridge ou d’un moteur d’intents doit comprendre davantage que la documentation API.
Où la maîtrise des actifs change-t-elle de mains ?
Il faut cartographier chaque moment où les actifs passent d’un état directement contrôlé par l’utilisateur vers une représentation, une séquestration contractuelle ou une gestion par le protocole.
Qui décide qu’un retrait est légitime ?
La décision peut reposer sur un smart contract, un ensemble de validateurs, un quorum de relayers, un système de preuves ou une combinaison de mécanismes.
Que se passe-t-il si les états on-chain et off-chain divergent ?
Un système robuste doit définir comment détecter l’écart, le réconcilier et arrêter les opérations en cas d'incertitude. Une incohérence silencieuse est dangereuse.
À quelle vitesse peut-on limiter les dommages ?
Plafonds de dépôt, limites de retrait, mécanismes de coupure et suspensions par réseau peuvent réduire les pertes pendant l’investigation.
Existe-t-il un monitoring indépendant ?
La surveillance ne doit pas dépendre uniquement de la même infrastructure que celle chargée de l’exécution.
La leçon pour les architectures Web3
Les systèmes cross-chain répondent à un besoin réel : la liquidité et les utilisateurs sont répartis entre de nombreux réseaux.
Le défi de sécurité est que chaque domaine supplémentaire introduit une nouvelle étape de vérification.
Pour GLOV, la bonne question n’est pas seulement « ce bridge est-il sécurisé ? », mais : quelles garanties doivent rester vraies sur l’ensemble du parcours pour que l’objectif de l’utilisateur soit effectivement respecté ?
Une telle analyse appartient à une revue d’architecture complète, pas seulement à un audit isolé de smart contract.
GLOV Secure peut aider à cartographier ces frontières de confiance. GLOV Consulting accompagne les projets dans le choix de leurs dépendances cross-chain avant qu’elles ne deviennent critiques en production.