Chaîne Anubis : confidentialité sélective L1 avec preuves PLONK ZK

Anubis Chain est une blockchain de couche 1 construite autour Preuves à connaissance nulle PLONK, compatibilité EVM totale, et un modèle programmable que l'équipe appelle confidentialité sélective. Au lieu de masquer chaque transaction par défaut comme Monero ou Zcash, ou d'exposer chaque octet par défaut comme Ethereum, Anubis permet aux utilisateurs et aux institutions de choisir, par transaction ou par contrat, exactement quels champs de données restent privés et lesquels deviennent publiquement auditables. Le réseau principal a été mis en service le 7 avril 2026 et le réseau a depuis ouvert sa couche d'écosystème avec le projet Genesis AWAKE, un déploiement de liquidités de 163 millions de dollars et l'activation d'infrastructures natives telles que RocketSwap DEX et Capybara Launchpad. Ce guide explique l'architecture, le déploiement d'AWAKE, la conception de conformité ZK-KYC et comment Anubis Chain se compare à d'autres réseaux axés sur la confidentialité en compétition pour le flux DeFi institutionnel en 2026.

Le pitch est conceptuellement simple mais techniquement exigeant : les blockchains ont passé une décennie à lutter contre une contradiction entre transparence et confidentialité, et la plupart des projets ont choisi leur camp. Anubis Chain fait valoir que la prochaine vague de financement en chaîne, en particulier les trésors symboliques, les rails de stablecoin réglementés et la tenue de marché institutionnelle, nécessitera les deux confidentialité et vérifiabilité fonctionnant sur la même couche d'exécution. En regroupant des primitives sans connaissance sous forme de précompilations EVM plutôt que de réécrire la machine virtuelle, le réseau peut prendre en charge les contrats Solidity standard tout en offrant des soldes protégés, des adresses furtives et des pistes d'audit sélectives aux applications qui les demandent.

Qu'est-ce que la chaîne Anubis ?

Chaîne Anubis est un réseau de couche 1 compatible EVM qui utilise preuves à connaissance nulle pour donner aux utilisateurs un contrôle granulaire sur les champs de transaction qui sont révélés sur la chaîne. Le réseau est régi par le Fondation ANUBI, une institution d'investissement créée en 2020 et incubée par Laboratoires Anubis, une initiative conjointe entre la fondation et la chaîne elle-même qui fonctionne comme moteur d'incubation de l'écosystème, coordinateur de capital et amplificateur de croissance.

Les principales caractéristiques sont :

• Confidentialité sélective désactivée par défaut, activée par l'utilisateur. Les contrats intelligents optent pour des primitives protégées ; une exécution transparente reste la référence.
• Compatibilité 100% EVM. La chaîne expédie un Geth client qui ne modifie pas le jeu d'instructions de base EVM, la sémantique d'exécution ou le modèle d'état du compte. Les contrats de solidité et les outils standards comme Hardhat, Foundry et MetaMask fonctionnent comme sur Ethereum.
• Modèle d'état hybride. Une couche de compte pour la compatibilité EVM ainsi qu'une couche de style UTXO pour les soldes protégés, toutes deux coordonnées via des transitions d'état synchronisées.
• Mempool crypté par seuil. Les transactions en attente sont cryptées et mélangées avant validation, éliminant ainsi la surface standard d'attaque frontale et sandwich qui sévit dans les DEX transparents.
• Couche de conformité ZK-KYC. Les documents d'identité sont vérifiés hors chaîne ; seule une attestation de validité cryptée est ancrée sur la chaîne, éliminant ainsi le besoin de publier des données personnelles.
• Devise native : gasDAI. Le réseau principal, enregistré sous ID de chaîne 6714, utilise une unité indexée DAI pour le gaz, ancrant les frais à une référence stable plutôt qu'à un jeton natif volatil.

Le réseau principal a été lancé le 7 avril 2026 à 20h00 HAE. L'accès à l'explorateur de blocs est disponible sur browser.anubispace.org et le point de terminaison canonique RPC est exposé via rpc.anubispace.org.

La confidentialité sélective expliquée : résoudre la contradiction de la transparence

Les blockchains publiques exposent chaque entrée, sortie, solde et appel de contrat au monde. Cette propriété est essentielle pour une vérification minimisant la confiance, mais elle est incompatible avec le fonctionnement de la finance réglementée et de la plupart des flux de travail d’entreprise. Un bureau de trésorerie ne peut pas publier d'ordres de rééquilibrage avant leur exécution. Un teneur de marché ne peut pas révéler les positions des stocks en temps réel. Un fournisseur de paie ne peut pas transférer la rémunération des employés dans un grand livre permanent. La réponse standard de l'écosystème de la confidentialité (Monéro, Zcash, Namada, Penumbra) a été de tout cacher par défaut. Cela fonctionne pour les transferts de type espèces, mais ne fonctionne pas pour la composabilité des contrats intelligents et pour toute application qui doit prouver sa conformité à un tiers.

La confidentialité sélective est la voie du milieu. Sur Anubis Chain, un développeur peut déployer un contrat intelligent dont le code est entièrement public et auditable tout en gardant le indiquer à l'intérieur de ce contrat blindé. Un utilisateur peut effectuer une transaction tout en révélant uniquement les champs nécessaires à une contrepartie ou à un auditeur et en masquant le reste. Le mécanisme qui rend cela possible est la couche de précompilation : les vérificateurs sans connaissance, les générateurs d'adresses furtives et les coordinateurs d'État privés sont exposés comme des opcodes à prix d'essence que n'importe quel contrat Solidity peut appeler.

La différence pratique compte. Avec une chaîne entièrement blindée, un DEX ne peut pas publier un carnet de commandes transparent car les soldes individuels sont invérifiables par rapport aux autres contrats. Avec Anubis Chain, le même DEX peut gérer un carnet d'ordres transparent sur la couche de compte tout en cotant des LP à partir d'un pool UTXO protégé. La même dynamique s’applique à Canon à rail-confidentialité de la couche application, sauf que sur Anubis Chain, les primitives de confidentialité résident dans la couche de base et héritent de la sécurité L1 plutôt que de dépendre des ensembles d'anonymat par contrat.

« Anubis Chain permet ce qui était auparavant impossible sur une seule couche d'exécution : une transparence sélective où les institutions obtiennent une conformité vérifiable et les utilisateurs gardent les données de leurs contreparties confidentielles. - Fondation ANUBI, aperçu de l'architecture

Le modèle évite également le mode de défaillance totalement transparent. Les attaques sandwich, le copy trading et l'extraction MEV sur Ethereum et la plupart des L2 existent parce que les transactions en attente restent dans un pool de mémoire public suffisamment longtemps pour que les chercheurs puissent réagir. Anubis pré-crypte le pool de mémoire avec une cryptographie à seuil afin que les validateurs ne puissent pas lire le contenu de la transaction tant que la commande n'est pas corrigée, supprimant ainsi l'asymétrie informationnelle qui rend MEV rentable en premier lieu.

Preuves à connaissance nulle PLONK : le moteur cryptographique

Le système de preuve sous-jacent à Anubis Chain est PLONK, avec ce que l'équipe décrit comme Turbo PLONKOptimisations de style pour la vérification en chaîne. PLONK (Permutations sur les bases de Lagrange pour les arguments œcuméniques non interactifs de la connaissance) est une construction zk-SNARK qui a remplacé l'ancien standard Groth16 par un seul universel et actualisable configuration fiable. Ce changement est important en production pour trois raisons :

1. Une cérémonie d'installation pour l'ensemble du réseau. Groth16 nécessitait une nouvelle cérémonie pour chaque nouveau circuit. PLONK permet à chaque contrat sur Anubis Chain de réutiliser la même chaîne de référence structurée, ce qui rend économique pour la chaîne l'exposition de précompilations ZK génériques au lieu de circuits sur mesure par dApp.
2. Épreuves à taille constante. Une preuve PLONK fait environ 500 octets quelle que soit la complexité du circuit, donc le coût de vérification sur l'EVM reste prévisible et les budgets de gaz n'explosent pas à mesure que les circuits se développent.
3. Vérification rapide, preuve plus lente. La vérification s'exécute en millisecondes, ce qui est l'opération qui doit avoir lieu en chaîne à chaque bloc. La preuve s'exécute hors chaîne sur le portefeuille de l'utilisateur ou sur un service de preuve, où des performances plus lentes sont acceptables.

Pour les développeurs, cela signifie que le coût de l'intégration de la confidentialité sur Anubis Chain est proche du coût d'un appel contractuel normal, plus le gaz nécessaire pour vérifier une seule preuve PLONK. Pour les utilisateurs finaux, cela signifie que les transactions privées sont confirmées à peu près dans le même temps que les transactions transparentes, sans délai de traitement par lots au niveau du protocole.

La chaîne combine la vérification PLONK avec Adresses furtives EIP-5564, exposé sous forme de précompilations, qui donne à chaque destinataire une adresse unique unique par transaction sans nécessiter un aller-retour supplémentaire avec l'expéditeur. Les destinataires scannent les annonces avec une clé de visualisation pour découvrir les paiements entrants. Le résultat est que même lorsque des soldes transparents sont utilisés, le lien en chaîne entre l’expéditeur et le destinataire est rompu au niveau de l’adresse.

Compatibilité EVM et expérience développeur

L'un des choix de conception les plus conséquents sur Anubis Chain est la décision de ne pas bifurquer l'EVM. Le client basé sur Geth préserve le format d'adresse standard de 160 bits, le modèle d'état du compte et l'ensemble complet d'opcodes. Les contrats de solidité compilés pour Ethereum, Polygon ou toute autre chaîne équivalente à EVM peuvent être déployés sans modification, et les outils de développement tels que Casque de sécurité, Foundry, Remix, Wagmi et Ethers.js fonctionnent sans modification.

La confidentialité est ajoutée aux alentours l'EVM plutôt qu'à l'intérieur de celui-ci. Chaque primitive ZK est exposée sous forme de contrat précompilé à une adresse fixe. Un contrat Solidity qui veut vérifier une preuve PLONK appelle simplement la précompilation de la même manière qu'il appellerait ecrecover. La sortie est un booléen. Ce modèle maintient la surface petite, rend l'audit facile et signifie que les outils d'audit et les analyseurs statiques existants peuvent raisonner sur les contrats Anubis sans extensions spécifiques au protocole.

Pour les équipes fonctionnant déjà sur Ethereum ou un L2, la voie de migration est concrète : redéployez les contrats vers l'ID de chaîne 6714, pointez l'interface vers le RPC Anubis et remplacez toute solution de contournement de confidentialité (mélangeurs hors chaîne, pools protégés tiers) par un appel de précompilation direct. Les portefeuilles compatibles au lancement incluent Portefeuille Bitget et Portefeuille OKX, avec MetaMask pris en charge via le flux réseau personnalisé standard.

Analyse approfondie de l'architecture : comment fonctionne réellement le modèle d'état hybride

La plupart des commentaires publics sur la confidentialité sélective s'arrêtent à la ligne marketing. La question mécanique est plus difficile : comment un seul L1 peut-il prendre simultanément en charge l'état de compte natif EVM et l'état protégé de type UTXO sans qu'aucune couche ne corrompt l'autre ? La réponse d’Anubis Chain est que les deux couches restent structurellement séparées et connectées uniquement via une petite interface de coordination bien définie.

La couche de compte correspond exactement à ce que les développeurs d'Ethereum attendent. Chaque adresse contient un solde, un nom occasionnel, un hachage de code et un essai de stockage. Les transactions ciblant la couche compte se comportent comme les transactions Ethereum et produisent des transitions d'état transparentes. La couche blindée, en revanche, se comporte comme un registre UTXO. Les notes sont créées et consommées ; la propriété est prouvée par des engagements cryptographiques et des annulateurs ; l'ensemble des billets actuellement utilisables est représenté par un arbre Merkle dont la racine est ancrée dans chaque bloc.

Le croisement entre les couches est la partie intéressante. Un utilisateur peut bouclier un solde transparent en gravant des jetons sur la couche de compte et en créant une note équivalente sur la couche protégée via un appel de précompilation. L'opération inverse, déblindage, brûle une note (en publiant uniquement son annulateur) et crédite un solde de compte. Les deux opérations sont atomiques et validées par des preuves PLONK. La racine Merkle ancrant l'ensemble de notes protégé est mise à jour chaque bloc en même temps que la racine d'état de la couche de compte, ce qui permet à la chaîne de rester une seule machine à états cohérente malgré l'exécution en parallèle de deux registres structurellement différents.

Cette conception a des conséquences directes pour les développeurs d'applications. Un protocole qui souhaite exposer des soldes protégés à ses utilisateurs n’a pas besoin de mettre en œuvre lui-même une cryptographie. Il appelle les précompilations Shield, Unshield et Transfer comme il appellerait ecrecover. Le protocole lui-même peut rester dans la solidité standard, ce qui permet de maintenir la surface d'audit souple.

Chiffrement à seuil et fin du standard MEV

MEV est l'une des plus grandes surfaces fiscales de DeFi. Sur les chaînes transparentes, les chercheurs surveillent le pool de mémoire en attente, identifient les commandes rentables et paient les validateurs pour qu'ils incluent leurs transactions dans la position optimale. Les attaques classiques sont le sandwich (attaquer la victime en avant, puis inverser l'impact sur les prix qui en résulte), le front-running généralisé (rejouer toute stratégie rentable qu'un utilisateur est sur le point d'exécuter) et la liquidité JIT (ajouter et supprimer des positions LP autour d'un seul grand swap).

Le pool de mémoire Anubis Chain corrige cela en cryptant les transactions en attente avec un schéma de seuil avant que les validateurs puissent voir leur contenu. La clé de déchiffrement est détenue collectivement par un comité, et la clé n'est reconstruite qu'après qu'un bloc a été proposé et que la commande a été finalisée. L’effet pratique est que le validateur proposant un bloc le fait sur un ensemble opaque de transactions. Au moment où les transactions sont déchiffrées et exécutées, l’ordre n’est plus négociable et il ne reste plus de surface économique pour des attaques sandwich ou des attaques frontales généralisées.

La conception n'élimine pas toutes les formes de MEV. Le MEV statistique, où les chercheurs déduisent l'intention de transaction à partir de sources extérieures au mempool (échec des vérifications avant vol, télémétrie frontale, surveillance du mempool sur les chaînes pontées), peut toujours exister en périphérie. Mais il supprime la surface d’attaque dominante, et ce au niveau du protocole plutôt que d’exiger que chaque DEX mette en œuvre sa propre atténuation. Pour une chaîne qui souhaite héberger des flux institutionnels à grande échelle, cette propriété est structurellement importante : les institutions ne peuvent pas négocier sur un lieu où leurs flux d’ordres sont régulièrement arbitrés en fonction du profit.

À quoi cela ressemble de construire sur Anubis Chain

Du point de vue d'un constructeur, le déploiement sur Anubis Chain en 2026 est intentionnellement peu dramatique. L'environnement de développement est le même espace de travail Hardhat ou Foundry déjà utilisé, avec deux modifications : l'URL RPC de la cible de déploiement pointe vers Anubis et l'URL du projet. foundry.toml ou la configuration Hardhat enregistre l'ID de chaîne 6714. Les contrats sont compilés et déployés comme sur n'importe quelle chaîne EVM. Dans la plupart des cas, les rapports d'audit existants sont conservés sans recertification car la sémantique EVM reste inchangée.

L'ajout de confidentialité consiste à appeler la bonne précompilation. Un contrat de jeton qui souhaite exposer les transferts protégés importe une interface Solidity mince autour des précompilations de bouclier/déshield/transfert, bloque les points d'entrée pertinents derrière cette interface et permet à la comptabilité existante du protocole de gérer le côté couche de compte. Les adresses furtives pour les flux de réception fonctionnent de la même manière : une annonce compatible EIP-5564 est publiée sous forme de journal, le destinataire analyse les journaux avec une clé de visualisation et l'interface utilisateur du portefeuille du destinataire fait apparaître les notes entrantes sans autre interaction en chaîne.

Les pièces qui nécessitent une nouvelle réflexion sont là qui données à garder privées. La valeur par défaut pour la plupart des projets sur Anubis est toujours l'état transparent, car la plupart des logiques d'application ne bénéficient pas de la confidentialité et le gaz est moins cher pour les opérations transparentes. La surface de confidentialité est activée de manière sélective pour les champs de données pour lesquels la valeur de la confidentialité dépasse le coût de génération de preuves. C'est pourquoi l'équipe utilise le terme de confidentialité sélective plutôt que de confidentialité par défaut : l'architecture pousse le choix jusqu'à la couche application au lieu de le prendre au niveau de la couche protocole.

L'écosystème AWAKE : 163 M$ de liquidité de genèse

Le premier projet phare à finaliser la migration full-stack sur Anubis Chain est RÉVEIL. Les échanges ont débuté le 13 mai 2026 à 20h00 SGT via le DEX natif du réseau, RocketSwap, avec la paire DAI/LGNS ancrant le lancement.

Les chiffres et la structure :

• Pool de liquidité initial : 163 millions de dollars en DAI et LGNS, décrits par le comité d'organisation AWAKE DAO comme l'un des plus grands déploiements uniques de l'écosystème Anubis Chain.
• Prix de lancement du LGNS : 5 $ par jeton.
• Origine de la liquidité : Une offre initiale de liquidité pilotée par la communauté et coordonnée via la plateforme de lancement Capybara plutôt qu'une allocation privée aux teneurs de marché.
• Véhicule de gouvernance : AWAKE DAO, dont le comité d'organisation a structuré l'OIT et la politique de liquidité post-lancement.
• Accès au portefeuille : Bitget Wallet et OKX Wallet dès le premier jour via la plateforme officielle RocketSwap.

L'importance stratégique du lancement d'AWAKE concerne moins le LGNS en tant qu'actif individuel que ce que le déploiement prouve. Un pool de 163 millions de dollars provenant de la communauté, négocié via un DEX natif sur un réseau principal vieux de moins de trois mois, règle la question de savoir si une infrastructure de confidentialité sélective peut prendre en charge une liquidité réelle à grande échelle. Il définit également le modèle pour les projets de genèse ultérieurs, qui, selon la fondation, suivront un modèle similaire d'OIT sur Capybara et de cotation sur RocketSwap.

RocketSwap : le DEX natif

RocketSwap est l'échange décentralisé qui fait partie de la pile principale d'Anubis Chain. Sur le plan architectural, il se situe plus près de la chaîne que les DEX tiers sur d'autres L1, avec un accès direct au pool de mémoire chiffré par seuil et aux précompilations à balance protégée. La combinaison a trois effets en aval :

• Résistance native MEV. Étant donné que les swaps en attente sont cryptés avant la commande, l'infrastructure de recherche qui profite des attaques sandwich et en arrière-plan sur les DEX Ethereum n'a pas de flux d'ordres lisible sur lequel agir.
• Positions LP blindées. Les fournisseurs de liquidité peuvent choisir de déposer dans des pools protégés, masquant la taille des positions individuelles tout en gardant les réserves globales du pool vérifiables.
• Ajustement dynamique des frais. RocketSwap utilise une matrice de frais qui répond à la volatilité et à la profondeur du pool, conçue pour isoler les jetons fraîchement cotés des cascades spéculatives tout en préservant l'efficacité du capital pour les paires stables.

Le DEX propose également des incitations de mise spécialisées pour les fournisseurs de liquidités dans les premiers pools d'écosystèmes, dans le but d'encourager les engagements à long terme plutôt que les capitaux mercenaires. Les traders peuvent surveiller les marchés et les analyses via DEXOutils une fois la couverture de la chaîne entièrement intégrée.

Capybara Launchpad : infrastructure de l'OIT pour les projets écosystémiques

Capybara Launchpad est la plateforme officielle d'offre initiale de liquidité pour Anubis Chain. Il fonctionne comme un cadre de collecte de fonds communautaire qui permet aux projets écosystémiques de mettre en commun les actifs publics et d'établir d'importantes réserves de liquidités avant d'être cotés sur RocketSwap ou tout autre DEX.

La conception Capybara reflète deux leçons tirées des cycles précédents de la rampe de lancement. Premièrement, les augmentations directement versées à un teneur de marché centralisé ont tendance à concentrer le contrôle des jetons et à amplifier la volatilité le jour du lancement. Capybara achemine le capital apporté vers des pools de liquidités transparents en chaîne où les participants particuliers et institutionnels sont des actionnaires plutôt que des contreparties. Deuxièmement, les politiques de liquidité limitées dans le temps garantissent une confiance durable en appliquant les calendriers d’acquisition et de verrouillage du pool directement au niveau du contrat, en remplaçant les promesses par des garanties cryptographiques que les participants peuvent vérifier en chaîne.

Le premier déploiement majeur via Capybara a été le lancement AWAKE/LGNS, qui a validé le modèle dans des conditions réelles de liquidité. Les futurs projets d'écosystème, notamment les primitives DeFi, les plates-formes de tokenisation RWA et les rails de paiement institutionnels, devraient emprunter le même chemin.

ZK-KYC : conformité sans doxxing

La caractéristique la plus importante pour l'adoption institutionnelle est la Cadre ZK-KYC. Le mécanisme fonctionne comme ceci :

1. Un utilisateur effectue une vérification KYC standard auprès d'un fournisseur hors chaîne autorisé. Les documents et données personnelles ne quittent jamais l'environnement de ce fournisseur.
2. Le prestataire délivre une attestation de connaissance zéro : une preuve cryptographique que l'utilisateur satisfait à un schéma de conformité défini (âge, juridiction, levée de sanctions, statut d'investisseur qualifié, etc.) sans révéler les données sous-jacentes.
3. L'attestation est ancrée sur Anubis Chain en tant qu'identifiant que l'utilisateur contrôle.
4. Les contrats intelligents qui nécessitent une conformité peuvent vérifier l'attestation via un appel de précompilation PLONK. Le contrat n'apprend que la réponse booléenne à un prédicat spécifique (par exemple, « cet utilisateur n'est-il pas sur la liste OFAC SDN ? »), jamais l'identité de l'utilisateur.

Le framework prend également en charge capacités d'audit sélectif: les auditeurs et régulateurs autorisés peuvent se voir accorder des clés de visualisation qui décryptent des transactions ou des soldes spécifiques sans exposer le reste de l'historique de l'utilisateur. Il s’agit du mécanisme qui permet à un protocole DeFi réglementé de satisfaire aux exigences de reporting AML et CFT tout en préservant la confidentialité au niveau de l’utilisateur dans le cas par défaut.

La conception est structurellement similaire aux systèmes d'identification en cours de prototypage ailleurs dans la pile de confidentialité, y compris le SDK Kohaku de la Fondation Ethereum, mais à la différence que sur Anubis Chain, les primitives de vérification sont au niveau du protocole plutôt que de vivre dans une bibliothèque d'applications. Cette distinction est importante pour les institutions : les garanties au niveau du protocole survivent aux mises à niveau des contrats intelligents et sont plus faciles à défendre auprès des équipes de conformité.

Paramètres et économie du réseau

Le réseau principal Anubis Chain fonctionne avec les paramètres réseau confirmés suivants, provenant de la documentation officielle et du registre de chaîne sur ChainList :

La décision d'utiliser une unité indexée sur le DAI (gasDAI) pour la tarification du gaz est structurellement importante. Les jetons natifs volatils rendent les coûts du gaz imprévisibles en termes fiduciaires, ce qui constitue un problème pour toute institution effectuant une comptabilité en chaîne. L'ancrage des frais à une référence stable correspond au modèle lancé par Gnosis Chain avec xDAI et facilite l'intégration d'Anubis dans les flux de paiement, de paie et de trésorerie où un coût prévisible est une exigence stricte.

L'ensemble de validateurs est autorisé au lancement avec un plan de transition publié vers une participation plus large. La sécurité économique du réseau est liée à la trésorerie de la Fondation ANUBI, avec des paramètres de réduction et de récompense du validateur définis dans la documentation de gouvernance de la chaîne. L'économie des jetons de l'écosystème, y compris tout actif natif prévu pour la gouvernance ou le jalonnement au-delà de gasDAI, devrait être divulguée dans les publications ultérieures de la fondation.

Anubis Chain vs autres réseaux de confidentialité

Comment Anubis Chain se compare-t-elle au reste du paysage de la blockchain de confidentialité ? Le tableau ci-dessous met en évidence les principales différences architecturales entre les principaux projets comparables en 2026 :

L'axe différenciateur d'Anubis Chain est la combinaison de activer la confidentialité avec compatibilité EVM complète et primitives de conformité natives. La plupart des concurrents choisissent un ou deux de ces trois. Le compromis est que la confidentialité opt-in dépend de la couche d’application qui l’utilise correctement, où les chaînes privées par défaut protègent les utilisateurs même lorsque les applications sont négligentes.

Cas d'utilisation : lorsque la confidentialité sélective est importante

L'architecture est spécialement conçue pour un cluster spécifique d'applications :

• DeFi institutionnel. Les bureaux de trésorerie, les teneurs de marché et les gestionnaires d'actifs peuvent exécuter des stratégies en chaîne sans diffuser les positions en temps réel, tout en prouvant leur solvabilité ou leur conformité via les attestations ZK.
• Trading DEX privé. Les commerçants de détail et professionnels peuvent acheminer les commandes via RocketSwap sans divulguer leur intention aux chercheurs MEV, supprimant ainsi une taxe structurelle qui coûte aux utilisateurs d'Ethereum des centaines de millions par an.
• Transferts privés conformes. La paie, le règlement des fournisseurs et les paiements B2B peuvent s'exécuter en chaîne avec des montants et des contreparties confidentiels tout en satisfaisant aux exigences juridictionnelles en matière de reporting grâce à un audit sélectif.
• Tokenisation RWA. Les bons du Trésor, les actions et le crédit privé tokenisés peuvent s'installer sur une chaîne qui prend en charge à la fois la transférabilité transparente et les données confidentielles du tableau des plafonds, résolvant ainsi l'une des frictions majeures dans la pile RWA institutionnelle.
• DeFi sécurisé par identité. Les protocoles qui nécessitent un accès spécifique à un investisseur accrédité ou à une juridiction peuvent appliquer le contrôle via les informations d'identification ZK-KYC sans exécuter de processus KYB par utilisateur.

Pourquoi Anubis Chain se démarque

Feuille de route 2026 et au-delà

Sur la base des communications publiées par la fondation, la trajectoire post-mainnet pour 2026 se concentre sur quatre domaines :

Le positionnement stratégique est cohérent : la fondation traite Anubis Chain comme une infrastructure de confidentialité prête à être conforme pour les flux institutionnels plutôt que comme un produit de confidentialité des consommateurs.

Comment accéder à la chaîne Anubis

Se lancer sur Anubis Chain en 2026 ressemble à se lancer sur n'importe quel réseau EVM moderne :

1. Ajoutez le réseau à votre portefeuille. Utilisez Bitget Wallet, OKX Wallet ou ajoutez Chain ID 6714 comme réseau personnalisé dans MetaMask. RPC : rpc.anubispace.org; explorateur : browser.anubispace.org; monnaie native : gasDAI.
2. Pont en stablecoins. Déplacez DAI vers Anubis via le pont officiel documenté sur anubischain.ai. La liquidité Stablecoin est la principale rampe d'accès car le gaz est libellé en gasDAI.
3. Échangez via RocketSwap. Le DEX natif héberge les pools les plus profonds, y compris la paire DAI/LGNS.
4. Suivez les marchés sur DEXTools. Une fois la couverture de la chaîne entièrement intégrée, DEXOutils peut être utilisé pour surveiller les paires, la liquidité et le flux des traders sur Anubis Chain.
5. Vérifiez en chaîne. Utilisez l'explorateur de blocs pour confirmer l'inclusion de la transaction. Les transactions transparentes sont résolues en une seconde environ ; les transactions protégées ajoutent le temps de génération de la preuve PLONK du côté de l'utilisateur.

Questions fréquemment posées