Base Déploie Cobalt Pour Ordres Conditionnels Tokenisés

Et si un ordre de swap pouvait rester invisible jusqu’au moment précis où le pool atteint le prix visé, puis s’évaporer sans trace si ce moment ne vient jamais ? C’est exactement le pari que Base a rendu possible sur son réseau principal le 30 septembre 2026, en activant Cobalt, sa troisième mise à jour majeure. Le Layer 2 incubé par Coinbase ne se contente plus d’accélérer les transactions Ethereum. Il cherche désormais à faire entrer dans le protocole ce que les carnets d’ordres des places traditionnelles appellent une condition, et ce que les émetteurs d’actifs tokenisés appellent une règle de conformité. Deux publics, deux problèmes, une même fournée logicielle.

L’annonce n’a rien d’un simple patch cosmétique. Cobalt introduit les Validity Transactions et prolonge B20, le standard de jetons lancé en juin avec la mise à jour Beryl. D’un côté, un trader peut signer un échange qui ne devient éligible que si le solde, le stockage, le numéro de bloc ou l’index des Flashblocks remplit des critères fixés à l’avance. De l’autre, un émetteur de stablecoin ou de titre tokenisé peut combiner des listes d’autorisation, refléter un fractionnement d’action, voire déclencher une saisie administrative dont la trace reste inscrite on-chain. Le séquenceur vérifie. Le protocole encadre. L’exécution, elle, n’est toujours pas promise.

Ce que Cobalt change vraiment sur le réseau principal

Base présente Cobalt comme une étape de maturité, pas comme une rupture de consensus. Les applications construites avec Beryl restent compatibles. Les nouvelles fonctions sont déjà actives. Le calendrier compte : Beryl le 25 juin, Cobalt le 30 septembre. Entre les deux, le réseau a eu le temps de voir comment les émetteurs s’emparaient d’un standard pensé pour des jetons assortis de règles, et comment les traders continuaient de subir le mempool public dès qu’un ordre un peu trop lisible apparaissait.

Le message officiel tient en deux usages distincts. Les traders veulent définir précisément les conditions d’exécution. Les émetteurs de stablecoins ou d’actifs tokenisés veulent coller à des obligations réglementaires sans recopier, à chaque mise à jour, des listes d’adresses entières. Cobalt répond aux deux sans les mélanger dans le même contrat. C’est important. Un ordre conditionnel n’est pas une politique de conformité, et une saisie administrative n’est pas un take-profit. Les confondre serait le meilleur moyen de mal lire cette mise à jour.

Cette liste suffit à comprendre l’intention. Elle ne suffit pas à comprendre le risque. Un outil qui attend le bon moment peut aussi attendre trop longtemps. Un outil qui autorise une saisie peut rassurer un régulateur et inquiéter un détenteur. Le reste de cet article démêle les deux couches, en partant du trader pour arriver à l’émetteur, puis aux suites déjà annoncées hors de Cobalt.

Pourquoi Base choisit le protocole plutôt que l’application

Depuis des années, les ordres conditionnels vivent au-dessus de la chaîne. Un bot surveille un pool, un keeper relance une transaction, un contrat d’intention stocke une signature. Ça fonctionne, jusqu’au jour où le relais est saturé, le keeper est en retard, ou le mempool révèle l’intention avant même que le bloc ne soit construit. Base déplace une partie de cette logique dans le chemin d’inclusion. Le séquenceur ne se contente plus de classer des transactions payantes. Il vérifie d’abord si elles ont le droit d’exister à cet instant.

Le choix n’est pas neutre. Un Layer 2 incubé par une plateforme d’échange a un intérêt évident à rendre le trading on-chain moins hostile. Les utilisateurs de Coinbase qui descendent vers Base comparent, même sans le dire, l’expérience à celle d’un carnet centralisé. Un stop, un palier, une expiration : ces gestes sont banals hors chaîne. Les reproduire sans intermédiaire unique est plus difficile. Cobalt n’imite pas un carnet. Il offre une brique plus basse, que les applications pourront habiller.

Du côté des actifs, le même raisonnement s’applique. Une politique de liste blanche collée dans chaque contrat duplique les données, multiplie les frais de mise à jour et crée des écarts entre émetteurs. B20, étendu par Cobalt, propose de réutiliser des politiques déjà déployées. L’émetteur compose. Il ne recopie pas. C’est moins spectaculaire qu’un nouveau jeton, et souvent plus utile.

Le calendrier court qui mène de Beryl à Cobalt

Beryl, le 25 juin, a introduit B20, un standard compatible avec ERC-20 pensé pour des jetons qui ne se transfèrent pas à n’importe qui. Cobalt, trois mois plus tard, ne remplace pas ce socle. Il l’étend. Les intégrations existantes restent valables. C’est le signe d’une feuille de route qui ajoute des capacités plutôt qu’elle ne casse les contrats déjà en production. Pour un émetteur qui a déjà émis un stablecoin ou une part de fonds sur B20, la question n’est pas de migrer dans l’urgence. Elle est de savoir quelles options nouvelles méritent d’être activées.

Base indique aussi que d’autres chantiers restent distincts de Cobalt. Des blocs natifs de 200 millisecondes, des smart accounts intégrés au protocole, et certaines améliorations de l’EVM attendues avec Glamsterdam sont à l’essai ou à l’horizon. Ils ne font pas partie de la mise à jour déjà active. Les mélanger dans une même lecture donnerait l’impression d’un big bang. Il s’agit plutôt d’une succession de couches. Cobalt est la couche disponible aujourd’hui.

Deux publics, une seule activation

Le trader qui prépare un swap conditionnel et le fonds qui exige une double liste n’utilisent pas les mêmes objets. Ils partagent pourtant le même réseau, le même séquenceur, et la même promesse de règles lisibles. Cette coexistence est le vrai sujet politique de Cobalt. Base veut être à la fois un terrain de trading plus propre et un rail pour des actifs qui ne peuvent pas circuler librement. Les deux ambitions se renforcent commercialement. Elles peuvent aussi se contredire culturellement, entre une communauté attachée à la résistance à la censure et des émetteurs qui ont besoin, précisément, de pouvoir bloquer un transfert.

Rien dans Cobalt n’oblige un jeton classique à adopter seizeWithMemo. Rien n’oblige un swap à passer par une Validity Transaction. L’optionalité est le point de passage. Elle permet à Base d’accueillir des usages régulés sans réécrire les règles de tous les contrats déjà déployés. Elle laisse aussi à chacun la charge de lire ce qu’il signe.

Validity Transactions, l’ordre qui attend son état

Une Validity Transaction se signe, puis se soumet avec des conditions portant sur l’état du réseau. Base prend actuellement en charge des critères liés au solde, au stockage, au numéro de bloc ou à l’index des Flashblocks. Le séquenceur vérifie ces conditions avant toute inclusion. Si elles ne sont jamais réunies pendant la période prévue, la transaction expire sans être exécutée. Elle n’a donc pas « raté » un bloc. Elle n’a jamais eu le droit d’y entrer.

L’exemple le plus parlant est celui du swap. Un trader prépare un échange qui ne devient éligible que si le prix d’un pool atteint un niveau donné avant un bloc déterminé. Tant que le pool n’a pas franchi ce seuil, l’ordre reste inéligible. Dès que le seuil est touché, et si la fenêtre de blocs n’est pas close, l’ordre peut être inclus. Le « peut » est essentiel. L’éligibilité n’est pas une réservation. Des frais trop bas, une file trop longue, un réseau qui n’inclut pas à temps : la transaction devenue valide peut encore rester en attente.

Cette mécanique se rapproche d’un ordre conditionnel. Elle n’en est pas le clone. Sur une place centralisée, un ordre limite occupe une place dans un carnet, et le moteur d’appariement promet une exécution selon des règles publiées. Ici, aucune place n’est réservée dans un bloc. Le protocole dit seulement : cette transaction a le droit d’être considérée. Le marché des frais dit ensuite si elle le sera vraiment.

Une transaction devenue éligible peut encore rester en attente si ses frais sont insuffisants ou si le réseau ne l’inclut pas à temps. L’ordre conditionnel de Cobalt ouvre une porte. Il ne garde pas la place derrière.

Les conditions de validité sont envoyées séparément de la transaction signée. Elles n’apparaissent pas dans l’opération finalement inscrite on-chain. C’est un détail de conception qui change la lecture publique de l’historique. Quelqu’un qui regarde le bloc voit le swap. Il ne voit pas forcément le seuil de prix ou la fenêtre de blocs qui l’a rendu possible. La documentation de Base recommande néanmoins de ne placer aucune information secrète dans les données d’appel ou les critères utilisés. La séparation n’est pas un coffre-fort.

Ce que le séquenceur vérifie, et ce qu’il ignore

Les critères annoncés restent modestes : solde, stockage, numéro de bloc, index des Flashblocks. On est loin d’un langage arbitraire où n’importe quelle formule de marché pourrait être exprimée. Un solde peut servir de proxy pour une condition de trésorerie. Un emplacement de stockage peut refléter un prix déjà écrit par un oracle ou par un pool. Un numéro de bloc borne le temps. L’index des Flashblocks affine cette borne à l’intérieur du rythme de production de Base.

Cette sobriété est une force et une limite. Une force, parce qu’un petit ensemble de prédicats est plus facile à vérifier, à auditer et à expliquer. Une limite, parce qu’un trader sophistiqué voudra souvent une condition sur un prix median, un volume, ou l’état d’un autre protocole. Il devra alors faire écrire cet état quelque part que Cobalt sait lire. L’intelligence reste en partie hors du prédicat, dans les contrats qui préparent le stockage.

Le séquenceur ignore aussi, par construction, tout ce qui n’est pas dans les critères supportés. Il ne « comprend » pas une stratégie. Il coche des cases. Si la case est fausse, l’ordre n’entre pas. Si elle est vraie, l’ordre rejoint la compétition ordinaire pour l’inclusion. Cette humilité évite de survendre Cobalt comme un moteur de trading complet.

Flashblocks, fenêtres courtes et ordres qui expirent

L’index des Flashblocks mérite une pause. Base ne produit pas seulement des blocs au sens classique. Elle découpe le temps plus finement. Pouvoir conditionner une transaction à cet index, c’est accepter de travailler sur des fenêtres courtes. Utile pour un arbitrage qui n’a de sens que dans un intervalle précis. Dangereux si l’on croit avoir « jusqu’à la fin du bloc » alors que le critère vise une sous-fenêtre déjà passée.

L’expiration sans exécution est l’autre moitié du contrat moral. Un ordre qui ne se déclenche pas ne doit pas laisser un engagement fantôme. Cobalt traite ce cas en laissant la transaction mourir hors chaîne, au sens où elle n’est jamais incluse. Pour l’utilisateur, le résultat pratique est simple : les fonds n’ont pas bougé, parce que l’opération n’a pas eu lieu. Encore faut-il que l’interface le dise clairement. Un portefeuille qui affiche « en attente » pendant toute la fenêtre, puis plus rien, créera plus de tickets support que de confiance.

Privé jusqu’à l’inclusion, pas invisible pour toujours

Base indique que les soumissions restent privées jusqu’à leur inclusion. Cette confidentialité limite l’exposition dans le mempool public. Elle réduit le risque qu’un robot anticipe l’ordre pour l’encadrer d’un achat et d’une revente. La pratique a un nom : l’attaque sandwich. Le robot voit une transaction assez grosse, achète juste avant, laisse la victime pousser le prix, revend juste après. Le profit sort de l’écart. La victime paie un prix pire que celui qu’elle croyait signer.

Rendre la soumission privée jusqu’au bloc coupe une partie de ce canal. Un robot qui ne voit pas l’ordre ne peut pas le précéder dans le mempool public. C’est un progrès réel pour les swaps conditionnels, précisément parce que ces ordres sont souvent préparés à l’avance. Un ordre visible pendant des minutes est une invitation. Un ordre révélé au moment de l’inclusion laisse moins de temps pour s’installer devant.

Base ne présente pas cette confidentialité comme une protection absolue. Elle ne couvre pas toutes les formes de réorganisation ni toutes les formes d’extraction de valeur. Un acteur qui construit le bloc, ou qui observe l’état juste avant l’inclusion, conserve des leviers. Une réorganisation peut aussi rejouer l’ordre des opérations après coup. Cobalt réduit une surface. Il n’abolit pas le métier de ceux qui extraient de la valeur de l’ordre des transactions.

Ce qu’un trader peut raisonnablement attendre

Imaginons un seuil sur un pool de stablecoins. Le trader signe un swap qui n’est éligible que si un emplacement de stockage, mis à jour par le pool, franchit un niveau, et seulement avant un bloc donné. Il fixe des frais qu’il juge suffisants pour une période calme. Si le prix arrive dans la fenêtre, l’ordre peut passer sans avoir traîné des heures dans un mempool lisible. Si le prix n’arrive pas, rien ne s’exécute. Si le prix arrive pendant un pic de demande, l’ordre éligible peut perdre la course aux frais.

Ce scénario est déjà plus propre qu’un bot qui republie la transaction en clair à chaque bloc. Il reste moins propre qu’un ordre limite sur une place qui garantit l’appariement. Les interfaces vont devoir traduire cette nuance. « Votre ordre est armé » n’est pas « votre ordre sera exécuté ». « Votre ordre a expiré » n’est pas « votre ordre a échoué on-chain ». Le vocabulaire compte autant que le bytecode.

Les stratégies qui gagnent le plus sont celles qui ont une fenêtre, un seuil observable, et une tolérance à l’échec silencieux. Un achat programmé si un solde de trésorerie dépasse un plancher. Une sortie si un stockage de prix casse un niveau avant une date de bloc. Un rééquilibrage qui n’a de sens que dans un Flashblock donné. Les stratégies qui exigent une place garantie, un prix d’exécution ferme, ou une priorité absolue sur les autres transactions devront encore chercher ailleurs, ou empiler des enchères de frais par-dessus Cobalt.

Pourquoi l’absence de garantie n’est pas un détail

Sur les marchés traditionnels, la déception classique est le glissement de prix. On est exécuté, mais moins bien. Avec une Validity Transaction, la déception peut être l’absence totale d’exécution au moment où la condition devient vraie. Le trader a eu raison sur le marché, et tort sur l’enchère. Cette asymétrie va produire des récits frustrants. Elle est pourtant cohérente avec un séquenceur qui ne vend pas de capacité réservée.

Les constructeurs d’applications ont une marge de manœuvre. Ils peuvent surenchérir automatiquement quand la condition approche. Ils peuvent découper l’ordre. Ils peuvent prévenir l’utilisateur que la fenêtre est courte. Ils ne peuvent pas, avec Cobalt seul, promettre le remplissage. Quiconque écrira « exécution garantie » sur une landing page mentira, ou s’appuiera sur un mécanisme supplémentaire qui n’est pas dans la mise à jour.

B20, le standard qui devait déjà porter la conformité

B20 est arrivé avec Beryl comme un ERC-20 compatible, enrichi pour des actifs qui ne circulent pas sans règles. L’enjeu n’était pas d’inventer un nouveau ticker. Il était de donner aux émetteurs un vocabulaire commun : qui peut recevoir, qui peut envoyer, quelles politiques s’appliquent. Cobalt ne jette pas ce vocabulaire. Il lui ajoute la composition, le multiplicateur d’affichage, et une fonction de saisie avec mémo.

La compatibilité ERC-20 reste le pont vers les portefeuilles, les pools et les comptabilités existantes. Un jeton que les outils ne savent pas lire est un jeton qui ne circule pas, même si sa politique est parfaite. B20 tente de garder ce pont tout en ajoutant des garde-fous. Cobalt poursuit le même équilibre. Les intégrations Beryl restent compatibles, ce qui évite à un émetteur déjà en production de tout redéployer pour profiter des nouveautés optionnelles.

Politiques composites : et, ou, sans recopier les listes

La nouveauté la plus structurante pour les émetteurs s’appelle les Composite Policies. Elles permettent d’associer deux à quatre listes d’autorisation ou de blocage, avec une logique ET ou OU. Un fonds peut exiger qu’un destinataire figure à la fois sur une liste de connaissance client et sur un registre d’investisseurs accrédités. Si l’adresse disparaît de l’une des deux sources, le transfert échoue. Pas de délai de synchronisation manuelle. Pas de copie locale à maintenir.

Le gain opérationnel est concret. Aujourd’hui, beaucoup d’émetteurs dupliquent des listes : une chez le prestataire de vérification, une dans le contrat, parfois une troisième chez l’agent de transfert. Chaque mise à jour est une transaction, un risque d’oubli, un écart temporaire. Cobalt propose de réutiliser les politiques existantes sans recopier leurs membres ni maintenir une synchronisation hors chaîne. La liste vit là où elle est déjà tenue. Le jeton se contente de la consulter selon une formule.

La logique OU ouvre un autre cas. Un destinataire autorisé par l’une ou l’autre de deux listes, par exemple un registre européen et un registre d’un autre cadre, pourrait recevoir le jeton sans que l’émetteur fusionne les bases. La logique ET est plus stricte, donc plus naturelle pour un fonds qui cumule des obligations. Quatre listes au plus : la borne évite des formules illisibles, elle oblige aussi à concevoir des politiques déjà agrégées en amont si le cas réel est plus touffu.

Ce dessin sert surtout les stablecoins et les titres tokenisés soumis à des règles de sanctions, de résidence ou de statut d’investisseur. Il ne rend pas un jeton « conforme » par magie. Il donne un endroit on-chain où la conformité déjà décidée peut s’appliquer sans duplication. La qualité du dispositif reste celle des listes. Une liste fausse, tardive ou incomplète produira des blocages faux, tardifs ou incomplets.

Multiplicateur de solde, fractionnement et dividende

Cobalt permet aussi de programmer une modification du multiplicateur utilisé pour afficher les soldes. La fonction s’aligne sur le standard ERC-8056. Elle sert notamment à refléter un fractionnement d’action ou le réinvestissement d’un dividende, sans modifier les soldes bruts ni la valeur économique détenue. L’adresse garde le même nombre d’unités internes. L’affichage, et donc la lecture économique, change selon le multiplicateur.

Sur les marchés d’actions, un fractionnement est un geste banal. Dix titres à 100 deviennent cent titres à 10, la position vaut toujours 1 000. Sur une chaîne, réécrire chaque solde serait coûteux et risqué. Un multiplicateur évite ce balayage. Les portefeuilles et les explorateurs doivent toutefois comprendre le standard, sinon l’utilisateur verra un chiffre brut qui ne correspond plus à ce que l’émetteur communique. L’enjeu est autant d’interface que de contrat.

Le réinvestissement d’un dividende pose un problème voisin. On veut que la position grossisse sans transfert individuel vers chaque détenteur. Le multiplicateur peut porter cette augmentation d’affichage. Il ne remplace pas la décision économique : d’où vient le dividende, comment il est financé, qui l’a voté. Il évite seulement de transformer cette décision en milliers de transferts. Pour un titre tokenisé, c’est souvent la différence entre une opération viable et une opération trop chère.

seizeWithMemo, la saisie qui laisse une trace

Cobalt ajoute enfin seizeWithMemo aux actifs B20 et aux stablecoins. Lorsqu’un émetteur active cette possibilité et configure les autorisations nécessaires, un administrateur peut transférer le solde d’un compte désigné vers une autre adresse. L’opération enregistre l’émetteur de la saisie, l’adresse d’origine, la destination, le montant et un mémo de 32 octets. Ce mémo peut servir de référence. Il ne garantit pas qu’une justification détaillée soit rédigée en clair.

Le geste est optionnel. Un émetteur qui ne l’active pas ne donne pas ce pouvoir. Un émetteur qui l’active doit avoir configuré qui peut s’en servir. La nuance compte, parce que le mot « saisie » déclenche immédiatement le débat sur la censure et le contrôle administratif. Ici, le contrôle n’est pas une propriété magique de Base sur tous les jetons. C’est une fonction qu’un émetteur choisit d’exposer, dans un cadre qu’il définit.

L’inscription on-chain change néanmoins la nature de l’acte. Une saisie hors chaîne peut rester dans un mail et un tableur. Une saisie via seizeWithMemo laisse une trace : qui a déclenché, depuis quelle adresse, vers où, pour quel montant, avec quel mémo. Trente-deux octets ne contiennent pas un jugement. Ils peuvent contenir une référence de dossier. La transparence porte sur l’opération, pas sur le raisonnement juridique complet.

Le mémo de 32 octets peut pointer vers un dossier. Il ne rédige pas le dossier. La chaîne retient le geste, pas forcément le motif.

Pour un stablecoin soumis à des obligations de gel, la fonction répond à une demande ancienne : pouvoir immobiliser ou déplacer des fonds désignés sans bricoler un transfert opaque. Pour un détenteur, elle rappelle qu’un jeton à politique administrative n’est pas un bearer asset. Lire le contrat, ou au moins la documentation de l’émetteur, redevient une étape de prudence, pas un hobby d’auditeur.

Ce que l’émetteur doit configurer avant d’activer

Activer seizeWithMemo sans clarifier le rôle d’administrateur, c’est créer un bouton rouge dont personne ne connaît le titulaire. La mise à jour parle d’autorisations nécessaires. En pratique, l’émetteur doit décider qui signe, selon quelle procédure interne, et comment le mémo sera normé. Un mémo libre, rempli au hasard, détruit l’intérêt de la trace. Un mémo qui pointe vers un identifiant de dossier permet un audit ultérieur, à condition que le dossier existe vraiment hors chaîne.

Les politiques composites demandent le même soin. Associer une liste KYC et un registre d’accrédités n’a de sens que si les deux sources sont tenues, datées, et capables de retirer une adresse. Une liste qui n’oublie jamais personne n’est pas une liste de conformité. C’est une archive. Cobalt ne corrige pas la gouvernance des listes. Il la rend plus directement conséquente, puisque le transfert échoue dès qu’une source requise ne contient plus l’adresse.

Stablecoins, titres et le marché que Base vise

Le Layer 2 ne cache pas sa cible. Les Validity Transactions parlent aux traders. B20 parle aux émetteurs de stablecoins et d’actifs tokenisés. Les deux marchés se croisent. Un stablecoin mieux encadré devient le collatéral des ordres conditionnels. Un titre tokenisé qui sait gérer fractionnement et listes peut vivre à côté des pools sans improviser la conformité dans chaque application.

Cette convergence explique pourquoi Coinbase met en avant Cobalt comme une amélioration de réseau, pas comme un produit de trading isolé. Le réseau devient le lieu où l’ordre et la règle cohabitent. Pour une plateforme qui distribue déjà des cryptos au grand public et qui regarde les actifs financiers tokenisés, le calcul est lisible. Moins de sandwichs, plus de règles d’émetteur, même socle.

Il serait excessif d’en conclure que Base devient une chambre de compensation. Cobalt n’apporte ni carnet central, ni garantie de règlement, ni statut juridique automatique. Il apporte des primitives. Les chambres, les agents de transfert et les émetteurs restent responsables de ce qu’ils construisent dessus. La technique baisse le coût de certaines obligations. Elle ne les invente pas.

Ce que les intégrations Beryl n’ont pas à refaire

La compatibilité annoncée est le point le plus rassurant pour les équipes déjà en production. Une intégration bâtie sur Beryl continue de fonctionner. Les nouvelles fonctions se greffent. Un émetteur peut donc tester une politique composite sur un nouveau jeton, ou activer le multiplicateur, sans réécrire tous les adaptateurs de portefeuille. Cette continuité est rare dans un écosystème où chaque standard « mieux » casse le précédent.

Elle a une contrepartie. Les utilisateurs ne verront pas Cobalt d’un coup. Ils verront des applications qui, un jour, proposent un ordre armé, et des jetons qui, un jour, refusent un transfert parce qu’une liste composite a changé. L’adoption sera inégale. C’est le sort des primitives. Elles ne créent pas l’usage. Elles le rendent possible pour ceux qui ont une raison de s’en servir.

Glamsterdam, blocs courts et comptes intelligents restent à part

Base prévoit de tester des blocs natifs de 200 millisecondes, des smart accounts intégrés au protocole, et certaines améliorations de l’EVM attendues avec Glamsterdam. Ces développements sont explicitement distincts de Cobalt. Les citer dans la même phrase que les Validity Transactions est utile pour la feuille de route. Les présenter comme déjà actifs serait faux.

Des blocs plus courts changeraient pourtant la texture des ordres conditionnels. Une fenêtre exprimée en numéros de blocs devient plus fine si les blocs durent 200 millisecondes. Les Flashblocks, déjà utilisés comme critère, montrent que Base pense le temps en sous-unités. Accélérer le bloc natif rendrait certaines conditions plus précises, et certaines courses aux frais plus nerveuses. Ce n’est pas le présent de Cobalt. C’est son voisinage.

Les smart accounts intégrés au protocole intéressent un autre public : celui qui veut des règles de session, de récupération, de limites de dépense, sans empiler des couches fragiles. Combinés plus tard à des ordres conditionnels, ils pourraient donner des expériences proches d’un mandat de gestion. Là encore, Cobalt ne livre pas cette combinaison. Il livre les conditions et les politiques de jeton. Le reste est annoncé comme suite, pas comme contenu de la mise à jour du 30 septembre.

Où Cobalt s’arrête face à l’extraction de valeur

Réduire l’exposition au mempool public est un levier classique contre le sandwich. Ce n’est pas le seul levier, et ce n’est pas le dernier mot. Un ordre privé jusqu’à l’inclusion peut encore être mal exécuté si le prix bouge dans le même bloc, si la liquidité est fine, ou si un autre flux, lui aussi privé, est placé juste devant. La protection annoncée vise l’anticipation par un robot qui lit le mempool. Elle ne vise pas toute forme de réordonnancement.

Les réorganisations restent un cas à part. Si l’ordre des blocs peut être rejoué, une transaction déjà incluse peut se retrouver dans un contexte différent. Base ne prétend pas que Cobalt ferme ce chapitre. Le lire ainsi serait transformer une amélioration de confidentialité en promesse de règlement définitif. Le règlement définitif, sur un Layer 2, dépend encore de la finalité du séquenceur et de la publication vers Ethereum.

Pour l’utilisateur, la conduite prudente ne change pas entièrement. Limiter le glissement accepté, découper les tailles, éviter les pools trop minces, ne pas mettre de secret dans les données d’appel. Cobalt retire une menace fréquente. Il n’autorise pas à traiter chaque swap comme un ordre de bourse avec contrepartie centrale.

Lecture critique : centralisation des règles, pas du consensus

Cobalt va être lu de deux façons. La première salue des ordres moins exposés et des actifs enfin capables de porter des listes sans bricolage. La seconde voit, dans seizeWithMemo et les politiques de blocage, une infrastructure plus confortable pour le contrôle. Les deux lectures peuvent être vraies en même temps. Un réseau peut faciliter le gel d’un stablecoin émis par une société régulée et, le même jour, protéger un swap contre un robot de mempool.

Le point de vigilance n’est pas que Base aurait, par Cobalt, le pouvoir de saisir n’importe quel jeton. Le point de vigilance est l’optionalité qui devient norme. Si les émetteurs institutionnels activent tous la saisie, et si les interfaces grand public n’affichent pas clairement ce pouvoir, l’utilisateur moyen découvrira la fonction le jour où elle s’exerce. La trace on-chain sera alors une consolation, pas une prévention.

L’autre vigilance concerne le séquenceur. C’est lui qui vérifie les conditions avant l’inclusion, et c’est vers lui que convergent les soumissions privées. Plus la logique d’éligibilité vit à cet endroit, plus la confiance dans l’opérateur du séquenceur compte. Cobalt ne crée pas cette dépendance. Il l’épaissit. Un Layer 2 assume déjà un opérateur de séquencement. Il assume ici, en plus, un vérificateur de conditions et un canal privé jusqu’au bloc.

Scénarios concrets pour un desk et pour un fonds

Un desk peut armer trois swaps avant une annonce, chacun lié à un niveau de stockage différent et à une fenêtre de blocs. Si aucun niveau n’est touché, les trois expirent. Si un seul l’est, lui seul devient éligible. Le desk n’a pas publié ses seuils dans le mempool pendant l’attente. Il a toutefois accepté que l’éligibilité ne vaille pas remplissage, et que les critères ne soient pas un endroit où cacher une information vraiment sensible.

Un fonds peut exiger, pour recevoir ses parts tokenisées, la présence simultanée sur une liste de vérification d’identité et sur un registre d’investisseurs autorisés. Le départ d’une adresse de l’une des listes bloque le transfert suivant, sans que le fonds redéploie une liste fusionnée. Le même fonds peut prévoir un multiplicateur le jour d’un fractionnement, et n’activer seizeWithMemo que si son cadre juridique l’exige, avec un administrateur identifié et un format de mémo fixé à l’avance.

Ces deux scènes ne se parlent pas forcément. Elles montrent pourquoi Cobalt a été vendu comme une double réponse. Le desk n’a pas besoin de la saisie. Le fonds n’a pas besoin du Flashblock. Le réseau, lui, a besoin des deux s’il veut rester le rail commun.

Ce que les interfaces vont devoir dire sans jargon

Le succès public de Cobalt se jouera moins dans la note de mise à jour que dans trois phrases d’interface. « Cet ordre ne sera inclus que si la condition est vraie avant ce bloc. » « Une fois la condition vraie, l’inclusion dépend encore des frais et de la file. » « Ce jeton peut être déplacé par un administrateur de l’émetteur, et l’opération laissera une trace. » Sans ces phrases, les primitives resteront des options de développeur.

Les explorateurs ont un rôle voisin. Montrer qu’une saisie a eu lieu, avec origine, destination, montant et mémo, évite la rumeur. Montrer qu’un transfert a échoué parce qu’une politique composite n’était plus satisfaite évite de croire à un bug de portefeuille. Cobalt fournit les événements. Encore faut-il que quelqu’un les traduise.

Limites assumées, pour ne pas survendre le 30 septembre

Récapitulons les bornes, parce qu’elles font partie de la nouvelle autant que les fonctions. Les conditions supportées sont limitées. L’exécution n’est pas garantie. La confidentialité n’est pas absolue. Les critères ne doivent pas porter de secret. Les politiques composites plafonnent à quatre listes. Le mémo tient en 32 octets. La saisie est optionnelle et dépend de l’émetteur. Les blocs de 200 millisecondes et les smart accounts ne sont pas dans Cobalt. Beryl reste compatible, donc rien n’oblige à tout activer.

Ces bornes n’annulent pas l’intérêt. Elles cadrent l’usage. Un réseau qui dit ce qu’il ne fait pas est plus utile qu’un réseau qui promet un carnet d’ordres complet alors qu’il livre un vérificateur de prédicats. Cobalt appartient à la seconde honnêteté, à condition de le lire jusqu’au bout.

Le 30 septembre 2026, Base a donc fait entrer l’ordre conditionnel dans le chemin du protocole, et a donné aux actifs tokenisés de nouveaux outils d’encadrement. Le trader y gagne une attente moins visible. L’émetteur y gagne une composition de listes, un multiplicateur, et, s’il le veut, une saisie traçable. Personne n’y gagne une promesse d’exécution, ni une conformité automatique. C’est déjà beaucoup pour une mise à jour. C’est encore trop peu pour confondre Base avec une bourse, ou B20 avec un agrément.