Avec ArbOS 61, Arbitrum fait descendre le filtrage de conformité des applications vers son moteur. Sur One et Nova, il est livré éteint.

Sur une blockchain publique, le moteur qui exécute les transactions ne regarde pas qui les envoie. Quand une règle impose d'écarter quelqu'un, le tri se fait donc au-dessus du moteur : dans le site web, dans le portefeuille, chez l'opérateur qui met les transactions en file d'attente. Et parce que cet opérateur pourrait abuser de sa position, ces réseaux gardent tous une porte de secours. L'utilisateur ignoré dépose sa transaction directement sur le réseau parent, attend un délai fixé d'avance qui se compte en heures, puis appelle une fonction publique qui la fait entrer sans l'accord de personne. C'est cette porte, bien plus que l'indifférence du moteur, qui fait qu'on dit d'un tel réseau qu'il peut retarder quelqu'un mais pas l'exclure.

Sur Arbitrum, la documentation fixe ce délai à vingt-quatre heures. Le 20 août 2026 à 17h00 UTC, la mise à niveau ArbOS 61, nom de code Elara, s'est activée sur Arbitrum One et Arbitrum Nova. Elle apporte quatre briques d'ingénierie. Une seule touche à la porte.

Ce que la mise à niveau met exactement dans le moteur

La documentation d'Arbitrum décrit un dispositif à deux étages, et c'est le second qui compte.

Le premier étage vit dans le séquenceur, la pièce qui ordonne les transactions. Il simule chaque transaction avant de la placer, et rejette celle qui viole une règle de conformité : elle n'entre jamais dans un bloc. Rien de nouveau sous le soleil, des opérateurs privés font ce tri depuis des années.

Le second étage est ailleurs. Il vit dans la fonction de transition d'état, c'est-à-dire dans le calcul qui produit le nouvel état de la chaîne. La documentation pose le problème : les transactions déposées par la voie de secours ne peuvent pas être filtrées au seul niveau du séquenceur, puisqu'elles deviennent éligibles à l'inclusion forcée une fois le délai écoulé. Deux composants sont donc ajoutés, un précompilé nommé Transaction Guardian et une sentinelle placée sur la boîte aux lettres du réseau parent. Résultat : sur une chaîne dont le propriétaire a activé le filtre, la transaction forcée entre bien dans le bloc, et y échoue, en consommant le gaz payé.

Là où le filtre tourne, la porte reste ouverte. Elle ne mène plus nulle part.

La documentation reconnaît elle-même un effet de bord. Si une adresse restreinte dépose des fonds depuis le réseau parent, ces fonds entrent dans le contrat de pont avant que le moindre filtrage n'intervienne de l'autre côté. Ils peuvent alors rester immobilisés dans le pont, sans contrepartie sur la chaîne.

Les notes de version d'ArbOS 61 détaillent les trois autres briques, qui n'ont pas cette portée : la limite de code compressé pour les contrats Stylus passe de 24 Ko à 96 Ko, un facteur quatre qui lève une contrainte réelle pour les applications lourdes, un mécanisme de frais de priorité permet à une chaîne de collecter des pourboires, et une interface enfichable ouvre la porte à des couches alternatives de disponibilité des données. De l'ingénierie utile, sans ambiguïté.

Livré n'est pas activé

Ce point n'est pas un détail de bas de page, c'est le dossier lui-même.

Le filtrage de conformité est livré désactivé. La documentation précise que la fonction est disponible via la mise à niveau ArbOS 61, mais éteinte par défaut. Et la proposition de gouvernance approuvée par l'Arbitrum DAO va plus loin, en précisant que cette fonction n'est ni prévue ni proposée pour Arbitrum One ou Nova, et que son inclusion vise à simplifier la base de code et à canoniser la fonction dans le logiciel de nœud.

Arbitrum One ne filtre pas. Arbitrum Nova non plus. La destination annoncée, ce sont les chaînes Orbit, ces réseaux séparés que n'importe qui peut lancer avec la même technologie, et dont certains opérateurs sont soumis à des obligations réglementaires dans leur juridiction.

Qui peut allumer, alors. Le propriétaire de la chaîne, et lui seul. Selon la réponse d'Offchain Labs à L2BEAT dans le fil de gouvernance, la fonction est verrouillée derrière un appel qui lui est réservé, et son activation comporte un délai de sept jours. C'est aussi lui qui choisit le service externe définissant les adresses restreintes, la documentation citant TRM et Chainalysis en exemples, les listes étant manipulées sous forme hachée.

La mise à niveau est passée par un vote constitutionnel en chaîne, tenu du 16 au 30 juillet 2026, et approuvé. Depuis la version Nitro 3.11.3, publiée le 12 août, une transaction écartée renvoie un message explicite : rejetée par la politique de la chaîne.

L'objection a été enregistrée, puis rangée

Le fil de gouvernance contient un échange qui va au fond du sujet.

L2BEAT, l'observatoire qui classe les couches 2 selon leur degré de décentralisation, a relevé l'inclusion du filtrage dans Nitro et formulé une réserve précise : même si la fonction n'est pas destinée à être activée sur Arbitrum One ou Nova, son intégration au cœur de la pile pourrait créer des difficultés pour les chaînes qui cherchent à satisfaire certains standards de décentralisation.

L'objection ne porte pas sur l'activation. Elle porte sur la présence dans le code.

Offchain Labs a répondu sur le verrou du propriétaire et sur le délai de sept jours. Ces deux garde-fous traitent la facilité d'accès à la fonction. Ils ne traitent pas la question posée, qui était sa présence dans la pile commune. Et le 30 juillet, L2BEAT a voté pour, en indiquant que la proposition tenait globalement la route.

Ce n'est pas une controverse. C'est un désaccord enregistré, puis rangé. L'acteur dont c'est le métier a vu le point, l'a nommé, n'a pas été contredit dans le fil, et a voté pour quand même.

CDR avait déjà croisé cette famille de questions. En juin, à propos des bitcoins vulnérables à l'informatique quantique, la même question posée sur Bitcoin opposait le gel, l'inaction et les mesures intermédiaires, avec ce constat qui vaut ici mot pour mot : aucune de ces options n'est neutre. En août, la permission était déjà entrée chez les validateurs d'une chaîne destinée aux institutions. En juillet, Uniswap plaçait un contrôle de conformité placé dans le pool, avec une liste blanche tenue par l'émetteur.

Cette dernière comparaison est la plus utile, parce qu'elle marque la frontière. Un exclu d'un pool Uniswap reste un utilisateur ordinaire de la chaîne : la restriction s'arrête aux portes de l'application. Ce qu'Elara rend possible descend d'un étage et vaut pour tout ce qui tourne sur la chaîne, y compris les applications qui n'ont rien demandé.

La question qui change pour qui détient un actif

Ce qui s'est passé le 20 août n'est pas l'état d'une chaîne, c'est le contenu d'un logiciel que des dizaines de chaînes font tourner.

Un opérateur déterminé pouvait déjà modifier ce logiciel dans son coin pour trier les transactions. La possibilité existait. Ce qui change, c'est son statut : ce bricolage privé et non audité devient une pièce standard, maintenue par l'éditeur, à un appel de propriétaire et sept jours près.

Le défaut s'est renversé. Hier, ne pas filtrer était le comportement par défaut, et trier demandait de construire. Aujourd'hui, ne pas filtrer est une décision, prise par une personne identifiable, sur une fonction déjà présente dans le code.

Deux lectures tiennent ensemble.

En faveur du dispositif, la demande est réelle. Des acteurs régulés veulent une chaîne dédiée conforme, et la construire seuls se fait cher et mal. Qu'une telle fonction vive dans un logiciel commun, passé par un vote public, verrouillé et retardé, vaut mieux qu'elle vive bricolée en privé, sans revue, sur cinquante chaînes différentes. Ce constat porte sur l'endroit où le code réside, et sur rien d'autre : il ne dit rien de la légitimité d'une capacité d'exclusion, que CDR a déjà qualifiée, à propos des stablecoins, d'une capacité d'exclusion à distance retournable contre celui qui détient l'actif.

À charge, ce qui entre dans une pile finit généralement par servir. Le verrou du propriétaire protège contre un tiers, pas contre le propriétaire lui-même. Et ni la documentation d'Arbitrum ni le fil de gouvernance ne recensent, au 21 août 2026, les chaînes Orbit qui auraient effectivement allumé la fonction. Un produit livré avant que sa demande ne soit observable, c'est un signal, dans un sens comme dans l'autre.

Pour qui détient un actif, la question se déplace. Elle ne porte plus sur le fait de savoir si le réseau censure, la réponse est négative sur les chaînes publiques d'Arbitrum. Elle porte sur l'identité de celui qui détient l'appel réservé au propriétaire, sur la chaîne où vit l'actif, et sur l'usage qu'il en fait. Le délai de sept jours est justement ce qui rend cette vérification possible : toute mise en service se voit une semaine avant de produire ses effets.

C'était une question qu'on ne se posait presque jamais. Elle devient une ligne de diligence ordinaire.

Questions fréquentes

Une blockchain peut-elle bloquer une adresse ?
Sur une chaîne publique, non : le moteur d'exécution ne regarde pas qui envoie la transaction, et le tri se fait au-dessus, dans les applications ou chez l'opérateur. ArbOS 61 Elara, activée le 20 août 2026, ajoute au logiciel Arbitrum une fonction optionnelle qui permet ce blocage dans le moteur lui-même. Elle est livrée désactivée.

Arbitrum One filtre-t-il les transactions ?
Non. Le filtrage de conformité est désactivé par défaut sur Arbitrum One comme sur Arbitrum Nova, et la proposition de gouvernance approuvée par l'Arbitrum DAO précise qu'il n'y est pas destiné à être utilisé. La fonction est présente dans le logiciel, elle n'y est pas allumée.

Qui peut activer ce filtrage, et comment le sait-on ?
Le propriétaire de la chaîne, et lui seul, par un appel qui lui est réservé. Selon la réponse d'Offchain Labs à L2BEAT dans le fil de gouvernance, l'activation comporte un délai de sept jours, ce qui rend toute mise en service visible une semaine avant qu'elle ne produise ses effets.

Qu'est-ce que ça change pour quelqu'un qui détient un actif sur une de ces chaînes ?
La question de diligence se déplace. Elle ne porte plus sur le fait de savoir si le réseau censure, mais sur l'identité de celui qui détient l'appel réservé au propriétaire de la chaîne où vit l'actif, et sur l'usage qu'il en fait. Ni la documentation d'Arbitrum ni le fil de gouvernance ne recensent, au 21 août 2026, les chaînes Orbit ayant effectivement activé la fonction.

Crypto Deep Research, 21 août 2026. Cet article est une analyse d'infrastructure et ne constitue ni un conseil en investissement ni une recommandation d'achat ou de vente.