La mise à niveau Cobalt de Base intègre de nouveaux contrôles directement dans les actifs tokenisés

Base a activé Cobalt le 30 septembre. Pour les émetteurs de ses jetons B20, le fork ajoute un moyen de programmer des multiplicateurs de solde, de saisir des soldes avec un enregistrement et de combiner des politiques de transfert. Rien de tout cela ne fait d'un actif tokenisé une action de l'entreprise qu'il suit. Cela rend les règles appliquées par le jeton plus explicites, et l'identité de l'émetteur plus déterminante.

La spécification de la mise à niveau Cobalt enregistre une activation du mainnet le 30 septembre, une semaine après Sepolia. La page de statut publique de Base a fixé la fenêtre de maintenance du mainnet à 18h00 UTC et l'a marquée comme terminée à 20h00 UTC. Le fork ajoute des fonctions d'actifs B20, des transactions conditionnées à l'état de la chaîne, un registre pour la programmation de futures mises à niveau en mode surveillance et une méthode on-chain pour enregistrer certains signataires de prouveurs d'environnement d'exécution de confiance. Ce sont des changements distincts. L'histoire des actifs commence avec B20, le format de jeton introduit avec la mise à niveau Beryl précédente.

Le fork est en ligne, mais sa liste de souhaits complète ne l'est pas

Deux idées apparues dans les discussions antérieures sur Cobalt sont absentes du périmètre déployé. Le paiement des frais de réseau en jetons B20 a été retiré de la liste du fork le 29 septembre. Des blocs canoniques plus rapides de 200 millisecondes appartiennent à une mise à niveau Denim ultérieure proposée, pas à cette activation. L'abstraction de compte native n'a pas de porte de mainnet programmée ici. Traiter l'un de ces éléments comme des fonctions Cobalt actives confondrait une feuille de route avec du code qu'un émetteur ou un trader peut utiliser aujourd'hui. La distinction est particulièrement importante pour les institutions évaluant un standard de jeton par rapport aux exigences de conformité actuelles.

Le seuil de version de nœud de Base est v1.4.2 pour le mainnet selon la documentation de mise à niveau. La version précédente v1.4.1 incluait l'horodatage mais manquait les modifications de transfert RPC des transactions de validité ; la v1.4.0 ne contient pas l'activation du mainnet. Un nœud qui suit un fork sans transférer correctement le nouveau type de transaction peut présenter une vue partielle de ce que les utilisateurs pensent être un réseau uniforme. La distinction au niveau du code est plus instructive qu'une déclaration générale selon laquelle Cobalt est en ligne.

L'accroche médiatique est réelle, mais ce n'est pas toute la thèse. L'activation antérieure de B20 avait déjà placé des actifs gérés par l'émetteur sur Base. Cobalt augmente les actions que l'émetteur peut entreprendre et les décisions de politique auxquelles un transfert peut faire face. La question clé est de savoir qui peut invoquer ces fonctions, sous quelle promesse juridique, et comment un détenteur peut vérifier le résultat.

Un solde B20 est une écriture de registre avec un émetteur

Un produit d'actions tokenisé peut être représenté comme un solde sur Base tandis que les droits sur le titre sous-jacent restent auprès d'un courtier, d'un dépositaire ou d'un émetteur contractuel. Le standard de jeton ne peut pas à lui seul forcer un agent de transfert à reconnaître le détenteur du portefeuille comme actionnaire. Le lien entre les soldes on-chain et les droits de propriété hors chaîne provient des documents du produit et des entités responsables de la garantie, du rachat et des opérations sur titres. Un jeton de sécurité peut être techniquement transférable et contractuellement restreint en même temps.

La couverture du lancement des actions tokenisées de Coinbase décrit un marché dans lequel les arrangements de garantie et les utilisateurs éligibles comptent autant que les interfaces de trading. Ce contexte fait des ajouts de Cobalt bien plus que de simples commodités pour développeurs. Une politique peut exclure une adresse, exiger une condition ou n'autoriser qu'une classe de transfert. Une saisie administrative peut réattribuer un solde. Un multiplicateur peut modifier la façon dont les soldes s'affichent entre les comptes. Chaque fonction peut répondre à un besoin opérationnel licite et peut aussi créer une dépendance à l'égard du jugement d'un émetteur ou de la sécurité d'une clé administrative.

Le format B20 doit être examiné au niveau du token. Le simple fait que Base prenne en charge seizeWithMemo ne confère pas à chaque émetteur de B20 un droit de saisie sur chaque token, et encore moins sur chaque ERC-20 de Base. La référence des précompilations B20 indique qu'un token dont l'émetteur n'a pas configuré l'emplacement de politique applicable n'a aucune capacité de saisie. Un auditeur doit inspecter la politique de ce token et les comptes autorisés. Deux actifs utilisant la même norme peuvent avoir des droits de détenteur très différents.

C'est la première séparation de contrôle à inscrire sur un tableau blanc : la chaîne décide si une transaction est conforme aux règles déployées ; l'émetteur décide quel appel administratif autorisé envoyer ; et le fournisseur d'actif du monde réel est responsable de la correspondance du token avec une créance exécutoire. Cobalt modifie les deux premières couches. Il ne résout pas la troisième. Une même adresse peut échanger un token on-chain et échouer malgré tout à un test d'éligibilité off-chain lors du remboursement.

La saisie laisse une trace, mais la raison est off-chain

Cobalt introduit seizeWithMemo, une opération autorisée par l'émetteur qui déplace des tokens depuis un détenteur en une seule étape administrative, remplaçant un flux antérieur burnBlocked. Le mémo peut laisser un marqueur de raison dans l'enregistrement on-chain. Il ne prouve pas que la raison était juridiquement suffisante. Un contrat intelligent peut vérifier que le compte appelant dispose de l'autorité et que les exemptions configurées s'appliquent. Il ne peut pas décider si une ordonnance judiciaire était valide, si l'émetteur a identifié le bon défendeur ou si la plainte d'un client devrait aboutir.

Le guide des opérations de l'émetteur décrit les mécanismes. Un token peut recourir à la saisie pour une ordonnance de sanctions, une émission erronée, une récupération en vertu de conditions contractuelles ou une opération corporative. Chacune est une justification différente. Le détenteur devrait pouvoir trouver l'identité de l'administrateur, la politique, l'événement et un processus de litige dans les documents juridiques du produit. Si un émetteur se contente de dire que la tokenisation est transparente, le lecteur devrait demander : transparente sur quoi ? Le transfert peut être visible tandis que la décision sous-jacente reste opaque.

Il existe un détail d'implémentation subtil. La documentation indique que la portée de l'exemption a changé de nom, passant de SEIZE_HOLDER_POLICY à SEIZE_EXEMPT_POLICY, avec un sélecteur différent. Le code qui code en dur l'ancienne portée peut échouer à lire ou à définir la nouvelle, même si les anciens sélecteurs Beryl continuent par ailleurs de fonctionner. C'est une véritable question d'intégration pour les émetteurs et les auditeurs, et non une affirmation générale selon laquelle les soldes seraient devenus saisissables le 30 septembre. Vérifiez la configuration de politique du token en direct et testez l'appel administratif sous le fork déployé.

La chaîne fournit une piste de preuves que les corrections de comptes conventionnelles peuvent ne pas exposer publiquement. Si un émetteur déplace 100 tokens d'un portefeuille à un autre, les observateurs peuvent compter 100 tokens et identifier la transaction. Ils ne peuvent pas en déduire un transfert de 100 actions dans le registre des actionnaires off-chain de l'émetteur sans rapprochement. L'argument le plus solide en faveur de l'émetteur est que les actifs réglementés ont besoin de procédures de correction d'erreurs et d'ordonnances légales ; le volume d'actions tokenisées sur Base fournit le contexte pratique expliquant pourquoi ces procédures sont désormais des choix de conception plutôt que des débats abstraits. Le compromis est qu'un détenteur accepte un administrateur doté d'un pouvoir significatif.

Le multiplicateur peut changer les unités sans dépôt correspondant

Un multiplicateur programmé permet à un émetteur de définir une modification future de la représentation du solde unitaire d'un actif B20. Pensez à une division d'actions. Si la quantité affichée d'un détenteur passe de 10 unités à 20 selon un ratio de 2 pour 1 tandis que la créance économique par unité est divisée par deux, la valeur n'a pas besoin de changer. Le mécanisme on-chain peut coordonner l'ajustement du solde sans demander à chaque détenteur de signer. L'émetteur doit néanmoins mettre en œuvre l'opération corporative correspondante dans le monde réel et expliquer la conversion aux courtiers, dépositaires et flux de prix.

L'arithmétique est simple et la réconciliation ne l'est pas. Supposons qu'un million d'unités de jetons soient en circulation et qu'un multiplicateur de 2 pour 1 soit programmé. Les nouvelles unités affichées seraient de 2 millions si le même multiplicateur s'applique à tous les soldes concernés. Cela ne crée pas 1 million d'actions sous-jacentes supplémentaires. Un émetteur responsable doit démontrer que le total des créances bénéficiaires est inchangé et que le fractionnement du titre de référence a pris effet selon des modalités correspondantes. Si les unités de jetons doublent alors qu'un système de négociation conserve une ancienne référence de prix par unité, un graphique ou un moteur de garantie pourrait fausser l'exposition d'un facteur deux.

La fonction de programmation améliore la coordination en nommant le moment avant qu'il n'arrive. Elle donne aussi aux observateurs quelque chose à surveiller : une mise à jour en attente, son signataire autorisé et les soldes d'approvisionnement et de détenteurs après le changement. Elle ne garantit pas que chaque système dépendant consomme la mise à jour à temps. Un carnet d'ordres d'une bourse, un oracle, un coffre de prêt et un registre fiscal peuvent chacun utiliser un instantané différent. Un multiplicateur correctement exécuté sur la chaîne peut encore créer des erreurs opérationnelles lorsque les intégrations mettent en cache l'ancienne représentation.

La sémantique des soldes de B20 compte aussi pour les données historiques. Un explorateur affichant le solde du détenteur après le fractionnement peut ne pas expliquer combien d'unités le détenteur détenait un jour plus tôt ou ce que chaque unité représentait. Les analystes devraient normaliser les quantités selon le multiplicateur en vigueur à chaque horodatage avant de prétendre que les dépôts ont bondi ou que l'approvisionnement a gonflé. Un journal d'événements publié donne un chemin vers cette normalisation, mais c'est un travail que quelqu'un doit faire. Le volume de négociation exprimé en jetons bruts sur l'ensemble de l'événement n'est pas comparable sans une unité ajustée.

La combinaison de politiques expose la décision d'éligibilité

Union et Intersect sont les deux nouveaux types de politiques composites. Union permet une opération si une politique sous-jacente l'accepte selon la logique configurée ; Intersect exige que plusieurs conditions sous-jacentes soient remplies. Les politiques constitutives exactes et le sens de l'autorisation doivent être lus dans la configuration du jeton. L'analogie utile est une porte avec des badges alternatifs par opposition à une porte exigeant plusieurs badges. Ce n'est pas une déclaration selon laquelle chaque jeton doit effectuer des vérifications d'identité.

Imaginez un actif dont l'émetteur autorise les transferts vers des portefeuilles de courtiers approuvés ou vers un contrat de rachat désigné. Une politique Union peut exprimer des alternatives. Un autre émetteur peut exiger que l'expéditeur et le destinataire satisfassent à des conditions distinctes, auquel cas un arrangement Intersect est plus approprié. Si une condition est maintenue hors chaîne via un registre autorisé, la règle de transfert apparente sur la chaîne dépend toujours d'une organisation qui met à jour ce registre. Une liste d'autorisation modifiée peut changer la négociabilité sans que le détenteur ne déplace un jeton.

Les politiques composites facilitent la description d'un actif réglementé en modules réutilisables. Elles peuvent aussi rendre plus difficile pour un détenteur de découvrir pourquoi un transfert a échoué si l'interface ne signale qu'un revert générique. Les invariants et tests B20 donnent aux développeurs un point de départ, mais un produit a encore besoin d'une divulgation lisible par l'homme indiquant quelles adresses peuvent agir, qui met à jour les listes et comment les erreurs sont contestées. Un jeton permissionné avec une porte non documentée n'est pas véritablement transparent simplement parce que la porte est sur une chaîne publique.

L'argument opposé le plus fort est pratique. Un titre tokenisé offert dans plusieurs juridictions ne peut pas promettre un transfert sans restriction et satisfaire en même temps aux restrictions d'éligibilité, aux ordonnances judiciaires et au traitement des opérations sur titres. Des contrôles programmables peuvent être plus prévisibles que des gels manuels dans une base de données de courtier. Cet argument tient lorsque les contrôles sont délégués de manière étroite, auditables et liés à des conditions exécutoires. Le risque opposé est tout aussi précis : une clé administrative, un registre de politiques ou une interprétation de l'émetteur peut déterminer l'accès d'un utilisateur. Le fork Cobalt fournit des primitives. Les émetteurs fournissent la gouvernance.

Les transactions conditionnelles ne remplacent pas les règles de l'émetteur

Cobalt introduit également des transactions de validité : des transactions signées associées à des conditions sur l'état de la chaîne, conservées jusqu'à ce que ces conditions correspondent. Il s'agit d'une fonctionnalité générale de transaction, et non d'une dérogation automatique à la conformité. Un utilisateur peut souhaiter qu'un ordre ne soit exécuté que si un solde, un état lié au prix ou un autre prédicat a une valeur spécifiée. Une transaction qui devient éligible doit encore satisfaire à la politique de transfert du jeton lors de l'exécution. Si un émetteur a modifié une liste d'autorisation entre-temps, la transaction peut échouer ou rester inéligible selon ses conditions.

Cette interaction crée une question précieuse pour la structure du marché. Si un trader signe un ordre aujourd'hui qui devient valide demain, qui peut modifier l'état dont dépend son exécution ? Certains états proviennent de contrats neutres ; d'autres proviennent d'une politique contrôlée par l'émetteur. Une transaction conditionnelle peut réduire une forme d'incertitude d'exécution tout en laissant le détenteur exposé à la capacité d'un administrateur de mettre à jour les permissions. Les documents d'intégration devraient indiquer quel prédicat a été vérifié, quand il a été vérifié et ce qui se passe en cas d'expiration ou d'annulation.

Le logiciel de nœud détermine si les portefeuilles et les fournisseurs de services voient le nouveau chemin de manière fiable. Le minimum du réseau principal v1.4.2 inclut le comportement RPC pour transmettre les soumissions de validité à une entrée de séquenceur compatible. Un nœud v1.4.1 peut suivre le fork de consensus mais échouer à cette route de soumission. Pour un utilisateur, la distinction apparaît comme une transaction rejetée déroutante, et non comme une discussion sur les balises de version. Pour une institution, cela appelle des tests de bout en bout contre la version exacte du nœud et le fournisseur RPC utilisés en production.

Il existe une autre frontière : l’infrastructure de séquençage et de règlement final de Base. Une politique d’émetteur est appliquée lors de l’exécution lorsque la transaction s’exécute ; la soumission conditionnelle ne donne pas à un utilisateur de garantie quant au moment où un séquenceur inclut une transaction éligible. Un reçu on-chain rapide ne règle pas non plus à lui seul un litige juridique sur l’action sous-jacente. Cobalt améliore l’expression et l’admission des transactions. Il ne fusionne pas l’ordonnancement, la propriété légale et le remboursement en une seule preuve.

La paperasse détermine l’actif sous le token

Un détenteur évaluant une action tokenisée devrait commencer en dehors de la chaîne : qui possède le titre de référence, où est-il détenu, quelle créance le token confère-t-il, et qui doit quelque chose au détenteur lors du remboursement ? Si le produit est un dérivé ou une créance contractuelle sur un émetteur, le détenteur peut ne pas avoir les droits de vote ou les droits en cas d’insolvabilité d’un actionnaire direct. Cobalt ne change pas cette classification. Ses contrôles ajoutés peuvent mettre en œuvre des termes déjà présents dans l’accord ou donner à un émetteur une nouvelle capacité technique qui nécessite une divulgation mise à jour.

La liste croissante d’actions tokenisées de Coinbase illustre la vitesse à laquelle les menus de produits peuvent croître. Un symbole boursier familier sur une application ne remplace pas le nom de l’entité juridique de l’émetteur et les termes spécifiques à l’actif. Certains produits ne sont disponibles que pour certains utilisateurs ou juridictions. Les restrictions peuvent être appliquées à l’intégration, au transfert, au remboursement ou aux trois. Si le transfert on-chain est ouvert mais que le remboursement est soumis à autorisation, l’acheteur secondaire peut se retrouver avec un token qu’il ne peut pas rembourser directement.

Une divulgation transparente des politiques énumérerait chaque rôle d’administrateur, les fonctions qu’il peut appeler, si une multisignature est requise, si les pouvoirs sont verrouillés dans le temps et comment les changements d’urgence sont annoncés. Elle ferait correspondre chaque pouvoir on-chain à une clause contractuelle. Elle montrerait le processus de vérification des réserves ou de la garde et comment un détenteur peut contester une saisie. Le nombre de portefeuilles on-chain détenant un token ne peut pas répondre à ces questions. Un token peut se répartir sur des milliers d’adresses tandis qu’un émetteur conserve une autorité décisive sur chaque remboursement.

Cobalt rend également un vieux mot, « propriété », plus difficile à utiliser avec désinvolture. Une personne peut posséder la clé privée contrôlant un portefeuille. Une autre entité peut contrôler l’émission de tokens et les transferts administratifs. Un dépositaire peut détenir l’action de référence. Un courtier peut contrôler l’accès au marché. Un tribunal peut affirmer son autorité sur la créance. Ces droits peuvent être juridiquement cohérents, mais leur attribution doit être explicite. La chaîne ne peut pas sauver des documents de produit ambigus en rendant une partie du registre publique.

Mesurez le déploiement par les actifs configurés, pas par le statut du fork

L’activation du fork est vérifiable à un bloc et à un moment donnés. L’adoption de ses nouveaux pouvoirs B20 nécessite un décompte différent : combien de contrats d’actifs en direct configurent réellement les nouvelles politiques, combien programment des multiplicateurs et combien invoquent la saisie ? Un décompte nul peu après l’activation ne signifierait pas que le fork a échoué. Cela signifierait que les émetteurs n’avaient pas encore utilisé ces fonctions optionnelles. Un décompte élevé ne prouverait pas que les actifs sont entièrement garantis ou que les contrôles sont bien gouvernés.

Une mesure reproductible inventorierait les actifs B20, vérifierait les sélecteurs de politique à la même hauteur de bloc, identifierait les adresses d’administrateur et classerait les appels observés après le 30 septembre. Elle compterait séparément les tentatives qui échouent et les changements d’état réussis. Elle éviterait de supposer qu’un actif appelé « action » a une action sous-jacente simplement parce que ses métadonnées le disent. C’est une meilleure mesure d’adoption que le volume de transactions, qui peut refléter une spéculation sur des tokens dont la structure juridique diffère largement.

La limite de l'enregistrement actuel est que la spécification de fork décrit une capacité, et non un registre complet des émetteurs actifs et de leurs conditions. Il n'existe pas de paramètre Cobalt universel qui détermine tous les droits sur les actifs tokenisés. Chaque émetteur peut configurer les fonctions différemment, et une mise à jour ultérieure peut modifier les autorisations. Un nœud peut vérifier correctement un transfert alors que la déclaration du dépositaire hors chaîne reste tardive ou contestée. Un token peut montrer un mouvement administratif en public sans indiquer au détenteur s'il était licite.

La conclusion est concrète. Base dispose désormais d'outils plus précis permettant aux émetteurs de contrôler les soldes d'actifs et l'éligibilité. Les détenteurs ont une meilleure chance d'inspecter ces contrôles si les émetteurs les divulguent clairement. Le test significatif commence à chaque token : qui peut modifier le multiplicateur, qui peut saisir, qui peut modifier la politique de transfert et quelle créance juridique subsiste si l'émetteur fait défaut ?

Un détenteur peut tester trois promesses contre un seul contrat

La première promesse est l'approvisionnement. Un rapport de couverture peut indiquer que chaque token correspond à une unité d'un actif sous-jacent détenu par un dépositaire. Le détenteur peut comparer l'approvisionnement en tokens déclaré au moment de l'instantané du rapport avec la position déclarée du dépositaire, en ajustant pour tout multiplicateur alors en vigueur. Les deux nombres doivent avoir le même horodatage et la même unité. Un rapport de 1 million d'actions à la clôture d'hier ne peut pas être mis en regard d'un approvisionnement post-fractionnement de 2 millions de tokens aujourd'hui et qualifié de déficit. Un total correspondant ne prouve pas non plus que chaque détenteur individuel dispose du droit de rachat que la page marketing laisse entendre.

La deuxième promesse est le transfert. Un produit peut annoncer un règlement de pair à pair, puis appliquer une politique qui n'autorise les transferts qu'entre intermédiaires enregistrés. Les deux affirmations peuvent être vraies si l'ensemble des pairs autorisés est restreint. Un détenteur peut inspecter les politiques configurées du token, soumettre une simulation en lecture seule d'un transfert entre des types d'adresses représentatifs et comparer le résultat avec les règles d'éligibilité publiées. Cet exercice devrait inclure un portefeuille éligible pour détenir, un portefeuille non éligible et la destination de rachat. Si les résultats diffèrent des conditions, l'émetteur devrait expliquer la divergence avant que les utilisateurs ne négocient.

La troisième promesse est le recours. Un utilisateur dont le solde est déplacé par seizeWithMemo a besoin de plus qu'un hachage d'événement. L'émetteur devrait publier une référence de dossier qui protège les informations privées tout en identifiant l'autorité invoquée, la condition applicable, la date de notification et le canal de contestation. Le détenteur peut alors comparer le mouvement enregistré avec ce compte. Un mémo qui indique « conformité » sans procédure n'apporte guère d'aide à quelqu'un qui conteste une identité erronée ou une instruction dupliquée. Une norme de token ne peut pas imposer un appel équitable, mais sa trace d'événements peut rendre l'absence visible.

Il existe un quatrième test pratique pour quiconque utilise ces tokens comme garantie. Un protocole de prêt peut évaluer l'actif à un prix de marché et l'accepter comme sûreté pour un prêt. Si l'émetteur peut geler ou saisir l'adresse de la garantie, ou modifier le nombre d'unités via un multiplicateur, le logiciel de liquidation doit comprendre ces deux événements. Un prêteur qui évalue un actif uniquement par son ticker peut manquer une restriction au niveau du contrat sur son transfert pendant la liquidation. L'emprunteur, quant à lui, peut voir une cotation saine mais être incapable de déplacer le solde mis en gage pour rembourser. La divulgation pertinente est de savoir si le contrat de prêt lui-même est exempté, qui peut modifier cette exemption et ce qui se passe lorsque l'émetteur révoque l'éligibilité d'un utilisateur.

Un dépositaire peut répondre à certaines questions par une attestation indépendante, mais une attestation a une portée. Elle peut vérifier les actions détenues dans un compte omnibus à un moment donné sans vérifier que les détenteurs de tokens ont un intérêt de propriété direct. Elle peut vérifier la couverture globale sans vérifier si une saisie a modifié la répartition entre les clients. Un audit sérieux indique l'entité juridique, l'identifiant de l'actif, l'heure de l'instantané, la méthode de rapprochement et les exclusions. Le document devrait être actualisé après toute émission, rachat ou opération sur titres significatifs. Les lecteurs devraient pouvoir comparer des instantanés successifs, et non simplement admirer un badge ponctuel sur une application.

Il existe un cas de défaillance que la blockchain ne peut pas régler : l'émetteur devient insolvable alors que le token continue d'être négocié. L'approvisionnement on-chain, les politiques et les journaux d'événements peuvent tous être intacts. La question décisive est alors de savoir si les actifs sous-jacents sont ségrégués pour les détenteurs, font partie de la masse d'un dépositaire, ou constituent une créance générale contre l'émetteur. Un contrat intelligent avec une application parfaite des restrictions de transfert ne choisit pas une priorité de faillite. C'est pourquoi la précision administrative de Cobalt accroît l'urgence de lire les conditions du produit. Elle indique aux utilisateurs exactement ce que l'émetteur peut faire avec le token, tandis que les documents doivent leur indiquer ce qu'ils peuvent exiger de l'émetteur.

Un audit qui teste ces trois promesses irait au-delà de la simple démonstration que le code s'exécute. Il concilierait les créances en cours avec les actifs détenus, les barrières de transfert réelles avec le règlement publié et les actions administratives avec un processus extérieur à l'interface propre de l'émetteur. La chaîne publique fournit des preuves pour chaque test, mais jamais la réponse complète. Les registres de conservation et les conditions contractuelles doivent être ramenés à la même date et à la même unité. C'est le travail qu'un actif tokenisé exige après l'annonce festive du fork.

Une autre frontière opérationnelle mérite un test public. L'administrateur d'un token pourrait être un portefeuille multisignature avec plusieurs signataires, mais une seule entreprise pourrait nommer chaque signataire. Publier le seuil sans nommer les organes de gouvernance ne démontre pas une surveillance indépendante. Un émetteur peut divulguer le seuil, la procédure de rotation des clés et l'autorité d'urgence sans révéler de secrets. S'il affirme que les détenteurs peuvent faire appel d'une décision, il devrait identifier l'entité juridique qui examine un appel et la période durant laquelle elle répond. Ces faits transforment une permission on-chain en un processus responsable.

Un lecteur sceptique devrait également vérifier si les changements de politique émettent des événements que les fournisseurs de données suivent. Si un portefeuille était autorisé à transférer à midi et bloqué à 12h01, le moment importe pour un ordre en attente, le calcul de marge d'un prêteur et un détenteur tentant de racheter. Un tableau de bord mis à jour une fois par jour peut faire apparaître un changement en temps réel comme une saisie surprise. Surveiller directement le contrat peut combler cet écart, mais le fournisseur du produit devrait tout de même envoyer une notification aux utilisateurs dont les droits changent. Cobalt rend les changements exécutables. La divulgation détermine si ces changements sont intelligibles.

Ce qu'il faut surveiller

• Nombre de politiques configurées : contrats B20 publics utilisant les permissions Union, Intersect et seizure après le fork du 30 septembre.
• Premier multiplicateur programmé : son heure d'effet annoncée, le ratio appliqué et la réconciliation avec l'action corporative hors chaîne.
• Actions administratives : événements seizeWithMemo réussis, le rôle autorisant et une explication de l'émetteur pour chaque cas important.
• Parité RPC : principaux fournisseurs de nœuds et de RPC Base exécutant au moins la v1.4.2 et acceptant les soumissions de validité de manière cohérente.
• Divulgations de l'émetteur : conditions du produit qui associent chaque pouvoir d'administrateur on-chain à un droit exécutoire et à un processus d'appel.

FAQ