Je suis arrivé à VANAR en m'attendant à la « thèse de la chaîne » habituelle, car c'est ainsi que la plupart des gens le présentent encore. Mais plus je passais de temps avec ce qu'ils ont réellement livré et ce qu'ils construisent explicitement, plus ce cadre semblait à l'envers. VANAR ressemble moins à un écosystème suppliant les développeurs d'inventer des cas d'utilisation, et plus à une pile de produits qui se retrouve sur une chaîne qu'ils contrôlent.
Le signal le plus clair est la façon dont ils organisent eux-mêmes la pile : d'abord la chaîne de base, puis Neutron, puis Kayon, et ensuite deux couches qu'ils étiquettent encore comme « à venir » (Axon et Flows). C'est présenté comme une feuille de route de suite logicielle, pas comme une présentation de token.
C'est là que la partie « ressemble à Web2 » commence à avoir du sens. Dans Web2, personne ne vend « une base de données » comme objectif final. Ils vendent des systèmes qui rendent les données utilisables : stockées, recherchables, portables et capables de conduire des flux de travail. VANAR essaie de faire quelque chose structurellement similaire, sauf qu'ils veulent que le stockage et les preuves vivent à l'intérieur de la chaîne plutôt que dans l'infrastructure privée d'une entreprise. Vous pouvez être d'accord ou pas sur le fait que la chaîne doit exister du tout — mais la forme de la stratégie produit est visiblement différente de la plupart des histoires L1.
Sur la couche de base, la documentation plus ancienne de VANAR est assez directe sur ce qu'ils pensent être important pour les applications : des frais bas stables et des temps de bloc qui ne rendent pas les produits interactifs lents. Leur livre blanc cadre un objectif de conception de « frais fixes » (fixés par rapport à la valeur en dollars) et répète l'objectif de frais minimes qui est censé garder les coûts de transaction prévisibles pour une utilisation à haute fréquence. Le but n'est pas la nouveauté. Le but est d'éliminer les frictions afin que les couches supérieures puissent se comporter comme un logiciel normal, où les utilisateurs n'ont pas à penser au coût chaque fois qu'ils cliquent.
Si vous faites de la diligence, vous devez toujours demander si la chaîne est réellement utilisée ou simplement décrite. L'explorateur de VANAR montre un grand total de transactions et d'adresses en cours (des chiffres beaucoup trop importants pour être ignorés, même si vous restez sceptique sur la portion qui est organique). Ces totaux ne prouvent pas l'adéquation produit-marché, mais ils établissent au moins que le réseau est vivant, produisant des blocs et transportant un volume au fil du temps plutôt que de rester inactif.
Là où VANAR devient vraiment intéressant, c'est Neutron, car il n'est pas positionné comme « stockage » dans le sens paresseux. Ils le décrivent comme un système de compression et de restructuration qui transforme des fichiers bruts en « graines » compactes destinées à être stockées directement sur la chaîne et ensuite interrogées comme une mémoire active, pas traitées comme des blobs morts. La revendication principale qu'ils répètent est agressive : comprimer quelque chose comme 25 Mo en environ 50 Ko en utilisant « des couches sémantiques, heuristiques et algorithmiques ».
Si vous êtes sérieux au sujet de la recherche, ce numéro ne doit pas être pris pour vérité juste parce qu'il est imprimé sur une page de destination. Il doit être traité comme un cas de test : quels types de données se compressent aussi bien, à quel point est-ce cohérent, que perd-on, et que signifie « vérifiable » pour un objet transformé ? Mais même avec du scepticisme, je pense que la direction est claire. Ils essaient de transformer « des données » en une primitive réutilisable qui peut être transportée à travers des flux de travail et des applications sans être piégée dans la base de données d'un seul fournisseur.
C'est aussi pourquoi myNeutron est plus important que les gens ne lui en donnent crédit. Ce n'est pas juste « une application » fixée à une chaîne. C'est un coin de distribution. Le produit est présenté comme une base de connaissances personnelles où vous pouvez capturer des pages, des fichiers, des notes et des travaux antérieurs, puis réutiliser ce contexte sans le reconstruire de zéro chaque fois. Si VANAR peut amener de vrais utilisateurs à traiter cette sorte de couche mémoire comme un utilitaire quotidien, la chaîne cesse d'être un pari d'infrastructure abstrait et commence à être les rails sous-jacents à une habitude.
Et je surveille un détail spécifique ici : le mouvement vers la monétisation. La page de mises à jour de VANAR de CoinMarketCap mentionne explicitement un « Modèle d'abonnement d'outils d'IA (2026) » autour du passage de produits comme myNeutron à un modèle payant, avec l'intention déclarée de créer une demande durable sur la chaîne. C'est un ton très différent du manuel typique de crypto de « d'incitations à jamais ». Faire payer de l'argent est inconfortable, mais c'est aussi un signe que quelqu'un essaie au moins de prouver que le produit peut se tenir sur sa propre économie.
Une fois que vous acceptez l'idée que Neutron est censé être la mémoire, Kayon est plus facile à interpréter. VANAR positionne Kayon comme la couche de raisonnement qui se trouve au-dessus de ces graines et des données d'entreprise, transformant le contexte stocké en insights et flux de travail qui peuvent être tracés et vérifiés plutôt que traités comme des sorties en boîte noire. Je ne suis pas ici pour répéter des affirmations génériques « IA + blockchain ». Ce qui importe, c'est la séparation architecturale : mémoire en tant que primitive de base, raisonnement en tant que couche au-dessus. En pratique, c'est ainsi que les systèmes logiciels durables évoluent : une couche se stabilise, puis une autre couche la rend utile à grande échelle.
Cependant, Kayon est aussi l'endroit où je pousserais le plus fort en tant qu'investisseur. « Auditabilité » peut signifier deux choses très différentes : cela peut signifier « nous enregistrons ce qui s'est passé », ou cela peut signifier « des tiers peuvent vérifier indépendamment des étapes et des entrées clés ». Les descriptions publiques de VANAR penchent vers l'interprétation la plus forte. La question de diligence est de savoir si l'implémentation correspond à cela dans des conditions réelles désordonnées, et si les constructeurs en dehors de VANAR peuvent compter sur elle sans un accompagnement personnalisé.
Maintenant, le sommet de la pile est l'endroit où la thèse devient réelle ou reste un joli diagramme. Axon et Flows sont encore explicitement encadrés comme des couches à venir, et les propres pages de VANAR les traitent comme « bientôt disponibles ». Des écrits indépendants à la fin de janvier 2026 décrivent Axon comme un système de contrat « prêt pour les agents » et Flows comme un ensemble d'outils pour les flux de travail automatisés sur la chaîne. Cette description est exactement le genre de chose qui peut sembler impressionnante et échouer encore si l'exécution glisse ou si l'expérience développeur est maladroite.
Mais c'est aussi le morceau manquant si vous essayez de comprendre la comparaison avec la « pile de produits Web2 ». Dans Web2, le saut de « nous stockons des données » à « les équipes gèrent leur entreprise avec cela » est le flux de travail. Orchestration. Automatisation. La colle ennuyeuse qui transforme un outil en une couche opérationnelle. Si VANAR livre Flows d'une manière qui permet vraiment aux équipes de définir des processus en plusieurs étapes de manière fiable, alors Neutron et Kayon deviennent plus que des fonctionnalités ingénieuses — elles deviennent la fondation de mémoire et de raisonnement sur laquelle les flux de travail peuvent s'appuyer.
Une chose que j'apprécie, c'est que VANAR semble documenter l'histoire d'une manière cohérente à travers plusieurs points de contact, pas seulement une page brillante. Leur index de blog montre des publications fréquentes autour de l'API mémoire et de la construction de leur récit de « couche d'intelligence » jusqu'au début de février 2026. Cela ne garantit pas la substance, mais la cohérence est importante. Les projets qui improvisent tendent à se contredire à travers les pages. Ici, la même structure continue d'apparaître : mémoire → raisonnement → orchestration → applications.
En même temps, je fais attention à ce que je traite comme des preuves solides. Beaucoup de contenus « d'analyse » tiers sont essentiellement des commentaires reconditionnés en tant que recherches. Je ne leur accorde pas trop de poids. Je les utilise uniquement pour vérifier si le marché capte les mêmes signaux que VANAR envoie et pour identifier quelles affirmations sont répétées. Par exemple, plusieurs publications récentes font écho aux mêmes affirmations de compression de Neutron et au même cadrage de feuille de route, mais celles-ci sont encore en aval du propre message de VANAR. Ce n'est pas une validation indépendante ; c'est une confirmation que le récit se propage.
Alors, quelle est ma lecture d'investisseur réelle ?
Je pense que VANAR parie que la prochaine vague d'utilisation de la crypto ne sera pas menée par « plus de dApps », mais par de meilleures primitives pour la mémoire, le contexte et le flux de travail — des choses qui rendent le logiciel cohérent à travers le temps, pas seulement à travers les portefeuilles. Neutron est la tentative de rendre les données compactes et réutilisables sur la chaîne. myNeutron est la tentative de transformer cela en une habitude utilisateur. Kayon est la tentative de rendre cette mémoire actionnable sans perdre la traçabilité. Axon et Flows sont la tentative de rendre le tout composable en processus réels plutôt qu'en fonctionnalités isolées.
Ce que je ne pense pas être encore acquis, c'est l'étape finale : la preuve que la pile entraîne une demande durable qui n'est pas cosmétique. Les totaux de l'explorateur montrent l'activité, mais ils ne vous disent pas si les gens utilisent Neutron parce qu'il résout un problème douloureux ou parce qu'une campagne a poussé des transactions à travers le tuyau. Le mouvement d'abonnement, s'il se produit réellement à grande échelle, serait une étape significative précisément parce qu'il force cette question à se poser ouvertement.
C'est pourquoi ma conclusion est plus conditionnelle que célébratoire.
VANAR ne m'intéresse pas parce qu'il prétend être « natif de l'IA » ou parce qu'il utilise de nouvelles étiquettes pour de vieilles idées. C'est intéressant parce qu'il essaie de construire une pile de la manière dont les entreprises de logiciels construisent des piles : commencer avec une couche de base qui se comporte de manière prévisible, ajouter une couche de mémoire qui est réutilisable, ajouter une couche de raisonnement qui est utilisable, puis expédier des outils de flux de travail qui permettent à d'autres équipes de construire sans réinventer la plomberie. S'ils exécutent les couches supérieures et que les constructeurs les adoptent pour des flux de travail ennuyeux et répétés, le « sentiment Web2 sur des rails Web3 » devient un avantage concret plutôt qu'un slogan. Si Axon et Flows ne fonctionnent pas, ou si Neutron se révèle être plus du branding que de la primitive, alors la thèse se résume à « une chaîne avec un joli produit », et c'est un résultat beaucoup plus petit.
