Polosukhin Présente Animaux IA Trading Et Paiements Near

<![CDATA[

Et si votre prochain animal de compagnie n’avait ni gamelle ni litière, mais un solde en tokens destiné à payer ses propres pensées ? La question a quelque chose d’absurde, presque enfantin, jusqu’à ce qu’on la pose à côté d’une caisse marchande capable d’encaisser n’importe quel actif, sur n’importe quelle chaîne, sans demander au client de changer de portefeuille. Le 3 octobre 2026, Illia Polosukhin, co-fondateur de NEAR, a publié sur X une liste de treize idées d’applications, plus cinq pistes de distribution. Le ton n’est pas celui d’une feuille de route officielle. C’est plutôt celui d’un bâtisseur qui constate que le chantier technique s’est allégé, et que le vrai goulot d’étranglement a changé de place.

Depuis quelques semaines, de nouveaux développeurs et d’anciens revenants construisent de nouveau sur le réseau. Polosukhin le dit sans détour : construire est devenu plus simple. Du coup, la question n’est plus de savoir comment déployer un contrat. Elle est de savoir quoi construire, et comment se faire voir. Cette bascule mérite qu’on s’y arrête, parce qu’elle décrit un moment précis de l’industrie. Les outils d’agents, les intents de paiement et les couches de confidentialité existent déjà. Ce qui manque, ce sont des produits que des gens utilisent sans avoir lu un livre blanc.

Quand construire devient facile, le vrai sujet change de camp

Polosukhin résume le virage en une phrase qui vaut mieux qu’un communiqué. Construire s’est simplifié, donc tout se joue sur le choix du produit et sur la distribution. Ce n’est pas une formule marketing. C’est un diagnostic. Pendant des années, une équipe qui voulait lancer une application sur une chaîne devait d’abord résoudre le pont, le gaz, le portefeuille, la signature, parfois la langue du smart contract. Chaque friction éliminait des utilisateurs avant même le premier écran.

Construire est devenu plus simple, alors tout se joue vraiment sur ce qu’on construit et sur la manière de se démarquer pour obtenir de la distribution.

Illia Polosukhin, co-fondateur de NEAR, le 3 octobre 2026

La liste qu’il propose n’est pas un catalogue de protocoles. Elle mélange des objets grand public, des outils pour traders, des services de santé, de la transcription, de la levée de fonds et de la caisse. Le fil rouge, c’est NEAR comme couche de règlement, de vérification et parfois de paiement du calcul. Le réseau n’est plus présenté comme une destination où il faudrait migrer ses fonds. Il est présenté comme une pièce qu’on peut cacher derrière une interface que l’utilisateur connaît déjà.

Cette posture explique pourquoi les idées de paiement arrivent en tête de lecture, même si les animaux numériques attirent davantage l’œil. Un widget de caisse ou un dépôt d’événement ne fait pas rêver. En revanche, il touche un usage que les gens comprennent sans tutoriel : payer, s’inscrire, récupérer son argent si l’autre ne vient pas. C’est là que la promesse d’intents prend un sens concret.

Une liste, pas un lancement

Il faut d’abord poser le statut du message. Polosukhin ne présente pas treize produits déjà en production. Il propose des pistes à des développeurs qui construisent ou reviennent. Certaines s’appuient sur des briques déjà annoncées, d’autres restent des esquisses. Confondre les deux serait une erreur de lecture. Un pitch public sert à orienter l’attention, pas à certifier qu’un animal virtuel combattra dans une arène le mois prochain.

Cette nuance change la manière de juger la publication. On ne demande pas à une liste d’idées d’avoir un audit, un tokenomics ou un calendrier. On lui demande d’être cohérente avec l’infrastructure déjà en place, et de désigner des problèmes que des équipes peuvent attaquer sans réinventer la pile. Sur ce critère, le message est plus serré qu’il n’en a l’air. Presque chaque piste renvoie à un mécanisme déjà nommé : intents, inférence vérifiable, staking converti en crédits de calcul, connexion de portefeuilles étrangers.

Pourquoi la distribution passe devant le code

Dans la plupart des écosystèmes, les équipes qui survivent ne sont pas celles qui ont le contrat le plus élégant. Ce sont celles qui trouvent un canal. Polosukhin le sait. Il ne se contente pas de lister des idées. Il ajoute des portes d’entrée : connexions de portefeuille via Aurora, communautés existantes, NEARLegion, Product Hunt, plateformes de découverte du même genre, et X. Le conseil est banal en apparence. Il devient intéressant parce qu’il reconnaît que le réseau seul ne suffit plus à faire venir les utilisateurs.

Un produit crypto qui exige un pont, un nouveau seed et une pièce de gaz dédiée perd la majorité de son public avant la première action. L’inverse aussi est vrai. Une application qui accepte le portefeuille que la personne a déjà, et qui règle en coulisse, a une chance d’être jugée sur son usage, pas sur sa chaîne. C’est le pari implicite de toute la liste.

La caisse universelle, premier outil concret

Pour les marchands et les développeurs d’applications, Polosukhin propose un widget de paiement universel. Le client paierait via NEAR Intents avec le portefeuille et la blockchain où ses actifs se trouvent déjà. Le développeur n’aurait pas à convaincre l’acheteur de migrer. Il offrirait un bouton. Le marchand l’intégrerait. Shopify est cité comme cible de distribution possible, pas comme partenariat signé.

L’idée paraît simple parce que le problème l’est aussi. Aujourd’hui, accepter un paiement crypto revient souvent à choisir une chaîne, afficher une adresse, espérer que le client a le bon actif et le bon gaz, puis réconcilier le reçu. Chaque étape est une occasion d’abandon. Un bouton qui absorbe cette complexité déplace le travail vers l’infrastructure de règlement. C’est précisément le rôle que les intents revendiquent : exprimer une intention de paiement, laisser un réseau de liquidité et de settlement la remplir.

Le geste commercial suggéré est aussi révélateur. Polosukhin ne dit pas seulement « construisez le widget ». Il dit de le proposer directement aux marchands, puis de viser une place dans un outil de commerce déjà installé. Autrement dit, la distribution ne passe pas par un airdrop. Elle passe par un canal que les commerçants ouvrent déjà chaque matin. C’est une logique de produit, pas une logique de jeton.

Reste une question que la publication ne tranche pas : qui porte le risque de change, le délai de règlement et le litige ? Un widget universel qui accepte des dizaines d’actifs doit décider à quel moment le marchand est payé, dans quelle unité, et que se passe-t-il si la route de liquidité échoue à mi-chemin. Ces détails font la différence entre une démo et une caisse. Les équipes qui reprendront l’idée devront les écrire avant de parler à un commerçant.

Les dépôts d’événements, héritiers de Kickback

La deuxième piste de paiement vise les organisateurs d’événements. Le principe : un système d’inscription qui garde le dépôt des participants sous séquestre jusqu’au check-in de l’hôte. Ceux qui viennent se partagent ensuite les fonds versés. Polosukhin s’appuie sur un projet antérieur, Kickback, et propose d’étendre le modèle à plusieurs blockchains et plusieurs actifs, pour rendre les inscriptions crypto plus fiables.

Le problème visé est connu de quiconque a organisé un meetup. Les gens s’inscrivent, ne viennent pas, et la salle est à moitié vide. Un dépôt remboursable ou redistribué change l’incitation. Si l’absence coûte, la présence devient un acte économique, pas seulement une intention. Le séquestre jusqu’au check-in ajoute une condition : l’argent ne bouge pas sur une simple case cochée en ligne. Il bouge quand l’organisateur confirme la présence.

Étendre cela au-delà d’une seule chaîne est le vrai ajout. Un participant qui tient ses fonds sur un réseau, et un autre qui les tient ailleurs, devraient pouvoir s’inscrire au même événement sans se coordiner à l’avance. C’est exactement le genre de friction que les intents sont censés absorber. L’organisateur voit une liste et une cagnotte. Les participants gardent leur portefeuille habituel.

Le modèle a aussi ses angles morts. Qui définit le check-in ? Un QR code, une signature, un organisateur de confiance ? Que se passe-t-il si l’hôte ne valide personne, ou valide ses amis ? Une redistribution des dépôts peut devenir un petit jeu d’extraction si les règles ne sont pas publiques et vérifiables. Kickback avait déjà exploré l’incitation à venir. La version interchaînes devra être aussi claire sur l’arbitrage que sur le dépôt.

Aurora et l’usage sans pont

La compatibilité des portefeuilles revient dans les conseils de distribution. Via Intent Connect d’Aurora, Polosukhin recommande de laisser les gens utiliser des applications depuis d’autres chaînes, sans organiser de pont et sans apprendre à opérer sur NEAR. L’idée n’est pas isolée. Le 17 septembre, Aurora Labs a annoncé une exécution Sui en une signature, permettant à des actifs d’autres réseaux d’entrer dans des applications Sui par Intents Connect. Selon la société, les utilisateurs pouvaient accomplir des actions prises en charge sans changer de portefeuille, sans bridger, et sans obtenir de SUI pour les frais.

Aurora Labs présentait NEAR Intents comme le fournisseur de liquidité, d’infrastructure de règlement et de connexions entre chaînes. Les applications pouvaient s’en servir pour le prêt, le trading, le staking et le rendement. Le message du 3 octobre s’inscrit dans cette continuité. Il ne découvre pas le mécanisme. Il invite les développeurs à le placer devant l’utilisateur, plutôt que de le laisser dans une documentation.

Pour un nouvel arrivant, la différence est immense. « Apprends NEAR » est un coût. « Garde ton portefeuille, signe une fois » est une promesse d’interface. La promesse tient seulement si la route derrière fonctionne, si les actifs pris en charge sont ceux que les gens détiennent vraiment, et si l’échec de route est expliqué sans jargon. Une signature unique qui échoue en silence redevient une friction, simplement déplacée.

L’animal IA, entre Tamagotchi et solde de calcul

Côté grand public, la piste la plus visuelle est un AI Tamagotchi. Des personnages numériques représentés par des jetons non fongibles. Chaque personnage porterait un solde en NEAR pour financer l’inférence. NEAR AI exécuterait une inférence vérifiable à partir d’une invite encodée sur la chaîne. Polosukhin suggère d’abord de nourrir et d’habiller, puis d’ouvrir des arènes et des compétitions.

Le souvenir du Tamagotchi n’est pas anodin. L’objet des années 1990 devait être nourri, soigné, sorti, sous peine de dépérir. Ici, la faim serait computationnelle. Un animal qui n’a plus de solde ne pense plus, ou pense moins. Le propriétaire ne paie pas un abonnement abstrait. Il alimente une créature dont l’état dépend d’un solde visible. C’est une manière de rendre le coût de l’IA tangible, presque affective.

Le choix du NFT comme support n’est pas seulement nostalgique de 2021. Il donne un objet transférable, exposable, peut-être échangeable, auquel on peut attacher un prompt et un solde. La vérification de l’inférence est le point technique. Si le personnage répond à partir d’une invite écrite sur la chaîne, et si l’exécution peut être attestée, le propriétaire a un début de preuve que la créature n’a pas été remplacée en coulisse par un autre modèle. Dans un jeu, cette preuve compte peu. Dans une compétition avec enjeu, elle compte davantage.

Les risques sont évidents, et il vaut mieux les nommer. Un animal qui consomme du calcul peut devenir une machine à drainer un solde si les règles de dépense ne sont pas plafonnées. Une arène peut attirer des mises déguisées. Un prompt encodé publiquement peut aussi exposer la personnalité du personnage, donc une partie de ce que le propriétaire a écrit. Le charme du produit dépendra de ce qu’on choisit de montrer et de ce qu’on garde local.

Le staking déjà converti en crédits de calcul

Le mécanisme de paiement proposé n’arrive pas dans le vide. Le 31 juillet, crypto.news rapportait que NEAR avait introduit des paiements d’IA fondés sur le staking, convertissant des tokens verrouillés en crédits de calcul mensuels. Le système couvrait 43 modèles au lancement, dont des modèles d’OpenAI, d’Anthropic et de Google. Selon le protocole, les utilisateurs gardaient la propriété de leurs tokens stakés et pouvaient les récupérer après unstaking, tandis que le solde verrouillé déterminait les crédits disponibles.

Cette brique éclaire l’animal IA, mais aussi la transcription privée évoquée plus loin. Au lieu d’un abonnement en carte bancaire, l’usage peut être financé par un verrouillage temporaire. L’utilisateur ne « dépense » pas au sens d’une vente. Il immobilise, obtient du calcul, puis peut récupérer le principal. Le coût économique réel est le rendement auquel il renonce, plus les frais éventuels du service. C’est une autre psychologie de paiement, plus proche d’une caution que d’une facture.

Pour un produit grand public, cette psychologie peut aider ou gêner. Aider, parce qu’on ne sent pas l’argent partir. Gêner, parce qu’il faut déjà détenir le token, comprendre le verrouillage, et accepter que le crédit dépende d’un solde. Un animal numérique qui exige d’abord d’acheter et de staker NEAR parlera à un public déjà dans l’écosystème. Il parlera moins à quelqu’un qui voulait juste un compagnon. Le widget de caisse et l’animal IA ne visent donc pas le même utilisateur, même s’ils partagent une infrastructure.

Une encyclopédie dont les faits sont des marchés

Autre produit d’information : une encyclopédie d’IA dont les faits deviendraient des marchés de prédiction continus, dans l’esprit d’Augur. Plutôt que de s’en remettre à l’édition communautaire, l’IA générerait les pages à partir de l’évaluation courante de chaque fait par les marchés. L’idée inverse le Wikipédia mental. La page n’est pas le consensus d’éditeurs. Elle est le reflet d’un prix, puis d’un texte produit par un modèle à partir de ce prix.

Le attrait intellectuel est réel. Un marché oblige à mettre quelque chose en jeu pour affirmer qu’un fait tient. Une page qui bouge quand le prix bouge rend visible l’incertitude, au lieu de la cacher derrière un ton neutre. Pour des sujets où la vérité se stabilise, le dispositif pourrait converger. Pour des sujets controversés, il pourrait aussi amplifier celui qui a le plus de capital, pas celui qui a la meilleure source.

Augur a montré à la fois la puissance et la lourdeur des marchés de prédiction on-chain : résolution des enjeux, oracles, faible liquidité sur les questions de niche, et difficulté à formuler une question qui ne soit pas ambiguë. Une encyclopédie entière multiplierait ces problèmes par le nombre de faits. L’IA peut rédiger. Elle ne résout pas, à elle seule, la question de savoir qui décide qu’un marché est clos, ni comment on empêche une page de devenir un pari déguisé sur l’actualité.

Tester des modèles sans montrer les données

Dans une piste de benchmark séparée, Polosukhin propose de tester des modèles d’IA contre des jeux de données privés, sans exposer le matériau sous-jacent. Les résultats seraient certifiés, liés à un modèle précis et au hash identifiant du jeu de test. Les développeurs soumettraient un cadre de test ou un modèle hébergé en privé.

Le besoin est concret pour toute équipe qui ne veut pas publier ses exemples. Un hôpital, un cabinet, une entreprise industrielle, un laboratoire : chacun a des données qu’il ne peut pas coller dans un classement public. Aujourd’hui, beaucoup de comparaisons de modèles se font sur des jeux ouverts, donc potentiellement déjà vus à l’entraînement. Un test dont on publie le hash et le score, sans publier les lignes, offre un compromis : on peut vérifier qu’on parle du même ensemble, sans le livrer.

La confiance se déplace alors vers celui qui détient les données et vers le mécanisme de certification. Si le hash est public mais que le passage du modèle sur les données ne l’est pas, il faut une attestation. C’est là que l’inférence vérifiable et l’exécution privée deviennent le sujet, pas le classement lui-même. Sans cette attestation, un score certifié n’est qu’une affirmation signée.

Le trading privé bute encore sur le contrepartie

Côté marché, Polosukhin identifie un obstacle dans la fonction existante de « deals privés » de NEAR Intents. Trouver une contrepartie. Selon son message, les utilisateurs doivent aujourd’hui savoir avec qui ils échangent. Il propose une place de marché où les participants annonceraient les deals disponibles, et où d’autres pourraient les remplir via les intents.

Le constat est lucide. La confidentialité d’un échange de gré à gré ne sert à rien si le seul moyen de trouver l’autre est un canal public ou un carnet d’adresses. Le OTC crypto a toujours vécu de cette tension : on veut de la discrétion sur le prix et la taille, mais on a besoin d’une découverte. Une marketplace d’intentions résout une partie du problème si elle montre assez pour attirer un remplisseur, et pas assez pour exposer la stratégie.

Le dessin exact de cette frontière n’est pas dans le post. Quelles informations sont visibles ? La paire, la taille approximative, le sens, le délai ? Un carnet trop opaque ne se remplit pas. Un carnet trop lisible redevient un order book. Les équipes qui construiront cela devront choisir un niveau de fuite acceptable, et l’assumer devant les utilisateurs qui viennent précisément pour ne pas être lus.

Vendre des clés de lecture, pas tout le livre

Pour le social trading, la piste est plus fine. Vendre des clés de visualisation qui donneraient à des clients choisis l’accès à des transactions autrement privées. Le trader pourrait afficher son profit et sa perte en public, tout en limitant l’accès à l’activité que les suiveurs copieraient. On sépare donc la vitrine et le détail.

C’est une réponse à un défaut connu des copies de trades. Si tout le monde voit l’ordre en même temps, la copie devient une course, et le signal se dégrade. Si personne ne voit rien, il n’y a pas de produit. Une clé vendue à un cercle réduit crée un bien intermédiaire : la performance est publique, la recette est payante. Le modèle ressemble à une lettre d’investissement dont le track record est ouvert et les positions réservées.

Les questions de conformité ne disparaissent pas parce que la clé est cryptographique. Vendre l’accès à des positions peut, selon les juridictions et la manière de présenter le service, ressembler à un conseil, à un signal, ou à une gestion. Le post ne traite pas ce point. Une équipe qui lancerait le produit devrait le traiter avant le premier abonné, surtout si elle accepte des paiements en fiat en plus du crypto.

« Ne jamais être liquidé », un slogan à lire avec prudence

Sous l’étiquette « Never get liquidated », Polosukhin propose d’utiliser NEAR Intents pour gérer des positions de prêt et de contrats perpétuels, en cherchant un revenu d’intérêt tout en pilotant l’exposition à la liquidation. Il présente la formule comme une idée d’application, pas comme une garantie démontrée. La distinction est importante, et elle mérite d’être répétée.

Aucun mécanisme d’intents n’abolit le risque de marché. Une position perpétuelle peut être liquidée si le collatéral ne suit pas, si l’oracle saute, si la route de rééquilibrage arrive trop tard, ou si la liquidité manque au moment où il faut bouger. Un produit qui promet l’absence de liquidation dans son nom vend une émotion. Le texte de Polosukhin, lui, vend une piste de gestion. Les deux ne doivent pas être collés l’un à l’autre dans la communication d’une future application.

L’idée sous-jacente reste intéressante : déléguer à un contrat le soin de déplacer du collatéral, de réduire une exposition, ou d’encaisser un rendement, via des intents, plutôt que de laisser l’utilisateur surveiller un écran. C’est de l’automatisation de risque, pas de la suppression du risque. Bien nommé, le produit peut aider des gens qui ne veulent pas gérer un levier à la main. Mal nommé, il peut attirer exactement ceux qui ne devraient pas utiliser de levier.

Delta neutre, ou l’art de tenir les deux bouts

Une autre stratégie proposerait d’apparier des avoirs au comptant avec des positions de perpétuels, sous un contrat NEAR qui gère les transactions via les intents. Polosukhin décrit le concept comme « delta neutre sur n’importe quoi ». Le principe est classique en finance : tenir l’actif, vendre l’exposition directionnelle via un dérivé, et chercher à capturer un écart, un funding, ou un rendement, plutôt qu’une hausse.

Rendre cela générique, « sur n’importe quoi », est le saut. Un contrat qui peut ouvrir les deux jambes à travers des intents évite à l’utilisateur de coordonner deux plateformes, deux gaz, deux délais. Le delta neutre manuel échoue souvent sur ce détail : une jambe est exécutée, l’autre non, et la position n’est plus neutre. L’automatisation a donc un sens opérationnel, pas seulement un sens marketing.

Elle a aussi un coût de compréhension. Un utilisateur qui croit détenir « juste » l’actif, alors qu’un perpétuel court en face, doit savoir ce qui se passe si le funding s’inverse, si une jambe est liquidée, ou si l’intent ne trouve pas de route. Le produit utile serait celui qui montre les deux jambes, le funding estimé et la condition de sortie, dans une langue ordinaire. Le produit dangereux serait celui qui cache le dérivé derrière un bouton de rendement.

L’ETF américain comme toile de fond, pas comme preuve

Le même automne a donné aux investisseurs américains un véhicule coté sur le token du réseau. Le 29 septembre, Bitwise a annoncé le lancement de son ETF NEAR aux États-Unis sur NYSE Arca, sous le ticker NRR, avec des frais de gestion de 0,75 %. Selon le gestionnaire, le fonds détient NEAR en direct et prévoit de staker ses avoirs, les récompenses passant par la valeur liquidative.

En expliquant la thèse, Matt Hougan, directeur des investissements, a cité NEAR Intents comme exemple d’infrastructure de règlement pour des agents d’IA qui gèrent paiements et échanges. Le post de Polosukhin, quelques jours plus tard, peut se lire comme une illustration concrète de cette phrase. Agents qui paient leur calcul, caisses qui règlent, positions qui se rééquilibrent : ce sont des activités d’agents, pas seulement des applications humaines.

Il ne faut pas en tirer un lien de causalité commerciale. Un ETF ne valide pas une liste d’idées. Une liste d’idées ne fait pas monter un fonds. Les deux parlent toutefois le même langage : NEAR comme couche où des logiciels règlent des intentions, plutôt que comme simple chaîne de transfert. Pour un lecteur qui découvre le nom via le ticker, le post du 3 octobre est une traduction en usages.

Relire le code sans le montrer à tout le monde

Pour les équipes logicielles, Polosukhin propose un agent qui relirait en privé des pull requests privées, via NEAR AI, avec une exécution vérifiable. Le cas d’usage est immédiat pour toute société qui ne veut pas coller son dépôt dans un outil dont elle ne contrôle pas la rétention. Une revue de code touche des secrets, des clés, des logiques métier. La promesse ici est double : le modèle travaille, et l’exécution peut être attestée sans ouvrir le diff au public.

La vérification ne remplace pas la qualité de la revue. Un agent peut certifier qu’il a tourné sur tel modèle, à partir de tel hash de diff, et quand même rater un bug. Le produit utile serait celui qui montre ce qu’il a regardé, ce qu’il n’a pas regardé, et qui laisse le développeur garder le dernier mot. Le produit cosmétique serait celui qui appose un sceau « vérifié » sur un commentaire générique.

Il y a aussi un enjeu de latence et de coût. Une revue utile arrive avant le merge. Si l’inférence vérifiable ajoute un délai ou un prix imprévisible, les équipes reviendront à l’outil qu’elles ont déjà. Le staking converti en crédits peut lisser ce prix pour celles qui détiennent déjà le token. Pour les autres, il faudra un paiement simple, crypto ou fiat, comme Polosukhin le suggère ailleurs pour la santé.

Un second avis médical qui chiffre avant d’envoyer

En santé, la piste est un frontal qui chiffrerait les données médicales de bout en bout avant de les envoyer à NEAR AI pour un second avis. Le paiement pourrait être crypto ou fiat. Des prompts personnalisés seraient stockés dans des NFT, que l’utilisateur choisirait selon l’expertise d’agent voulue. On ne parle pas de remplacer un médecin. On parle d’une couche de relecture, avec une tentative de limiter ce qui quitte l’appareil en clair.

Le chiffrement de bout en bout est la partie la plus sensible à bien nommer. Si le modèle doit lire le dossier pour donner un avis, quelqu’un, ou quelque chose, doit pouvoir déchiffrer au moment du calcul. La question devient : qui détient la clé à cet instant, où le calcul a lieu, et ce qui est journalisé. Un bouton « privé » ne suffit pas. L’architecture doit dire si le fournisseur du modèle voit le prompt, s’il voit le dossier, et pendant combien de temps.

Les NFT de prompts ajoutent une couche curieuse. Une expertise d’agent devient un objet que l’on sélectionne, peut-être que l’on achète ou que l’on prête. Cela peut aider à versionner des consignes médicales validées par un professionnel. Cela peut aussi créer un marché de prompts non vérifiés, présentés comme des spécialistes. Dans la santé, la distinction entre un outil d’information et un dispositif de soin n’est pas un détail de wording. Elle détermine qui a le droit de proposer le service, et sous quelle responsabilité.

Le post ne décrit pas d’agrément, de parcours de consentement, ni de conservation. Ce n’est pas un reproche : c’est une idée. Toute équipe qui la reprendrait devrait commencer par le cadre, pas par le jeton. Un second avis qui fuit un dossier est pire qu’une absence de second avis.

La transcription qui reste sur la machine

Pour le bureau, Polosukhin esquisse une application de transcription privée, sur le modèle de Granola. NEAR AI traiterait la transcription, les utilisateurs garderaient leurs enregistrements en local, et les sauvegardes seraient chiffrées avec leurs propres clés. Comme alternative à l’abonnement, il suggère de financer le service par le staking NEAR.

Granola s’est fait connaître en prenant des notes de réunion sans se comporter comme un enregistreur intrusif classique. Reprendre ce geste avec une contrainte de localité répond à une fatigue réelle : les comptes rendus automatiques qui partent dans un cloud dont on ne connaît pas la politique. Ici, la promesse est que l’audio ou le texte maître reste chez l’utilisateur, et que le calcul est une étape, pas une copie permanente.

Encore une fois, la promesse tient si le flux est décrit. Un fichier qui « reste en local » mais dont un extrait part en clair vers un modèle tiers n’est pas privé au sens où l’utilisateur l’entend. Le chiffrement des backups avec les clés de l’utilisateur est, en revanche, un choix sain : la sauvegarde ne devient pas un second cloud lisible par le service. Le financement par staking, déjà évoqué pour l’animal et pour les crédits de juillet, unifie le paiement. Il réserve aussi le produit à ceux qui acceptent de détenir le token.

Une table de capitalisation qui encaisse

Pour les sociétés qui lèvent, la liste inclut un outil de table de capitalisation, avec des instruments de levée associés, l’acceptation de paiements crypto, et un support bancaire. C’est la piste la plus « back-office » du lot, et peut-être l’une des plus sobres. Une cap table mal tenue empoisonne une levée, un départ de fondateur, un tour suivant. Y ajouter le crypto comme rail d’encaissement, sans couper le bancaire, reconnaît que les startups vivent encore dans les deux mondes.

Le lien avec le reste de la liste n’est pas cosmétique. Une société qui utilise déjà des intents pour encaisser des clients, ou qui paie du calcul en tokens verrouillés, a besoin d’un endroit où ces flux apparaissent à côté des actions et des BSA. Sinon, la crypto reste un compte à part, mal réconcilié. L’outil proposé serait utile s’il traite le paiement comme une écriture, pas comme un gadget à coller dans un tableau.

Le support bancaire est le morceau le plus difficile, et le post ne le détaille pas. Connecter un compte, émettre une facture, rapprocher un virement et un encaissement on-chain : chaque pays a ses règles. Une équipe qui viserait ce produit devrait choisir un périmètre géographique étroit au début. Vouloir servir toutes les levées, dans toutes les devises, est le meilleur moyen de ne servir personne.

Cinq portes pour se faire voir

Sur la distribution, Polosukhin conseille d’aller vers NEARLegion, d’atteindre d’autres communautés par de la promotion croisée, et de pousser les produits sur Product Hunt, des plateformes de découverte similaires, et X. Cinq gestes, aucun miracle. Ils ont en commun de ne pas supposer que le déploiement suffit.

• NEARLegion : s’adresser à une communauté déjà organisée autour du réseau, plutôt que d’espérer un trafic organique.
• Promotion croisée : aller dans des communautés qui ne sont pas NEAR, avec un usage qui ne demande pas de migrer.
• Product Hunt et cousins : se soumettre au rituel de lancement public, utile pour un outil, moins pour un protocole.
• X : le canal où le post lui-même a été publié, donc le terrain naturel de la conversation.
• Intent Connect : la porte technique, qui laisse entrer un utilisateur d’une autre chaîne sans pont manuel.

Le dernier point n’est pas dans la phrase de distribution, mais il en est la condition. Promouvoir une application que personne ne peut ouvrir avec son portefeuille actuel, c’est promouvoir un tutoriel. Promouvoir une application qui s’ouvre en une signature, c’est promouvoir un usage. Aurora fournit ici le précédent du 17 septembre, côté Sui. Le conseil du 3 octobre généralise ce précédent : ne forcez pas l’utilisateur à devenir un utilisateur NEAR pour profiter d’une application qui règle via NEAR.

Ce que les intents changent dans la vie d’un bouton

Pour comprendre pourquoi tant de pistes tiennent en une page, il faut regarder ce qu’un intent remplace. Dans un flux classique, l’application dit : envoie tel actif, sur telle chaîne, à telle adresse, avec tel gaz. L’utilisateur doit déjà être au bon endroit. Dans un flux d’intent, l’application dit : je veux être payé de tel montant, ou je veux cette position ajustée. Un réseau de remplisseurs cherche une route. L’utilisateur signe une intention, pas un transfert bricolé.

Ce déplacement explique la caisse, le dépôt d’événement, le deal privé, le delta neutre et même une partie de l’animal IA. Dans chaque cas, quelqu’un exprime un résultat. Le règlement se fait derrière. Quand le résultat est simple, payer un marchand, le gain d’expérience est immédiat. Quand le résultat est complexe, rééquilibrer un perpétuel sans être liquidé, le gain existe seulement si la route est rapide et si l’échec est explicite.

Il existe aussi un coût caché : la lisibilité. Un transfert vers une adresse, on peut l’expliquer à un proche. Une intention remplie par un solveur, avec une route multi-chaînes, demande une confiance dans des acteurs que l’utilisateur ne voit pas. Les produits qui gagneront seront ceux qui montrent la route après coup, le montant reçu, et l’écart éventuel. La magie sans reçu ne dure pas.

Vie privée : trois sens qu’il ne faut pas mélanger

Le mot « privé » revient souvent dans la liste. Il ne veut pas dire la même chose à chaque ligne. Pour le trading, il veut dire que la contrepartie et la taille ne sont pas dans un carnet public. Pour la revue de code, il veut dire que le diff ne sort pas du périmètre de l’équipe. Pour la santé et la transcription, il veut dire que les données restent chiffrées hors du moment de calcul, et que les backups sont sous les clés de l’utilisateur.

Mélanger ces sens dans une même campagne produit créerait de la confusion. Un trader qui achète une clé de visualisation accepte précisément que certains voient ses opérations. Un patient qui envoie un dossier n’accepte pas la même chose. Un animal IA dont le prompt est encodé sur la chaîne est, par construction, plus public qu’une note de réunion chiffrée en local. La liste est cohérente sur l’infrastructure. Elle ne l’est pas sur un seul niveau de confidentialité. C’est normal : ce sont des produits différents.

Un point de comparaison utile est apparu ailleurs dans l’actualité récente du secteur. Des travaux autour d’API à connaissance nulle, côté Ethereum, ont montré qu’on peut cacher qui paie pour une inférence sans cacher le prompt au modèle. Autrement dit, payer en privé n’est pas penser en privé. La liste de Polosukhin devra, produit par produit, dire laquelle des deux promesses elle tient. L’inférence vérifiable atteste une exécution. Elle ne rend pas automatiquement le contenu illisible pour le modèle qui l’exécute.

Agents, pas seulement applications

Plusieurs pistes se lisent mieux si l’on remplace « application » par « agent ». L’animal qui paie son inférence est un agent avec un budget. La revue de pull request est un agent avec un périmètre. Le gestionnaire de positions est un agent avec un mandat de risque. L’encyclopédie est un agent qui rédige à partir d’un prix. Hougan, en parlant de l’ETF, plaçait déjà les intents comme settlement pour des agents qui paient et échangent. Le post du 3 octobre donne des visages à cette phrase.

Le budget est le morceau le plus nouveau pour le grand public. Un agent sans plafond dépense jusqu’à ce que le solde ou la carte lâche. Un animal dont le solde est visible, ou un service financé par un verrouillage, rend le plafond tangible. Ce n’est pas un détail d’interface. C’est la condition pour laisser un logiciel agir sans surveiller chaque appel. Les idées de Polosukhin qui survivront seront peut-être celles qui montrent ce plafond avant de montrer le personnage ou le rendement.

L’autre condition est l’arrêt. Un agent qui peut payer doit pouvoir être coupé. Un agent qui peut ajuster une position doit pouvoir être gelé. Un agent médical doit pouvoir refuser une question hors cadre. Rien de tout cela n’est dans un pitch de treize lignes. Tout cela décidera si une idée devient un produit que l’on laisse tourner la nuit.

Ce qu’un développeur peut prendre dès maintenant

Si l’on enlève le spectacle, la liste se range en quatre chantiers praticables. Le premier est le bouton de paiement : widget, marchands, cible de type boutique en ligne, règlement par intents. Le deuxième est le séquestre d’événement, héritier de Kickback, étendu à plusieurs actifs. Le troisième est la découverte de contrepartie pour des deals déjà privés. Le quatrième est n’importe quel frontal qui paie l’inférence avec un solde ou un staking, et qui garde les données sensibles hors du clair inutile.

Les autres pistes, arènes d’animaux, encyclopédie-marché, delta neutre générique, second avis, sont des paris plus longs. Elles dépendent de règles de jeu, de résolution, de conformité, ou d’une pédagogie du risque. Les lancer en même temps que la caisse serait disperser une petite équipe. Le message de Polosukhin n’impose pas un ordre. La logique de distribution, elle, en impose un : commencer par l’usage qu’un étranger comprend en dix secondes.

Shopify comme symbole, pas comme contrat

Citer Shopify dans un post n’est pas annoncer une intégration. C’est nommer le type d’endroit où un bouton de paiement doit vivre s’il veut sortir du cercle crypto. Les commerçants n’installent pas un portefeuille pour faire plaisir à une chaîne. Ils installent un module s’il réduit un abandon de panier ou ouvre un client qu’ils n’avaient pas. Le widget n’a de sens que dans cette équation.

Pour y arriver, l’équipe devra parler remboursement, reçu, devise de comptabilisation, et échec de paiement. Un intent qui reste « pending » pendant qu’une route cherche de la liquidité ne peut pas bloquer une commande sans message clair. Le commerce a une horloge. Le settlement crypto en a une autre. Le produit qui les accorde aura fait plus pour NEAR Intents qu’une dizaine d’animaux virtuels.

Il y a aussi un enjeu de charge. Qui paie les frais de route ? Le marchand, le client, un solveur qui se rémunère sur l’écart ? Si le bouton affiche un prix et en encaisse un autre, la confiance casse au premier écart visible. Les intents peuvent absorber la complexité. Ils ne peuvent pas absorber un prix surprise.

Kickback, ou pourquoi l’ancien projet compte

Revenir à Kickback n’est pas un détail nostalgique. Cela signale que la piste événementielle a déjà été touchée, avec ses leçons. Les systèmes de dépôt pour meetups crypto ont montré que l’incitation fonctionne quand le montant est assez haut pour faire réfléchir, et assez bas pour ne pas exclure. Ils ont aussi montré que l’organisateur devient un point de confiance au moment du check-in. Étendre le modèle à plusieurs chaînes ne supprime pas ce point. Cela le rend plus utile, parce que le public potentiel s’élargit.

Une version interchaînes réussie se jugerait à une chose simple : un participant qui n’a jamais ouvert NEAR s’inscrit, vient, et repart avec sa part ou son remboursement, sans avoir appris un nouveau portefeuille. Si le tutoriel reste obligatoire, l’extension n’a pas eu lieu. Elle a seulement déplacé le formulaire.

Le précédent Sui, une semaine et demie plus tôt

L’annonce d’Aurora Labs du 17 septembre donne un ancrage. Exécution Sui en une signature. Actifs d’autres réseaux admis dans des applications Sui via Intents Connect. Pas de changement de portefeuille séparé, pas de bridge manuel, pas de SUI à obtenir pour les frais, pour les actions prises en charge. NEAR Intents fournissait liquidité, settlement et liens entre chaînes. Les usages cités : prêt, trading, staking, rendement.

Le post d’octobre ne répète pas cette annonce. Il en tire une consigne pour les bâtisseurs : branchez vos applications sur ce type de connexion, afin que l’utilisateur d’une autre chaîne n’ait pas à « venir sur NEAR » pour s’en servir. C’est une stratégie d’invisibilité. Le réseau gagne s’il est utile sans être nommé dans l’interface. Beaucoup d’écosystèmes refusent cette invisibilité, parce qu’ils veulent la marque. Polosukhin, ici, semble accepter le trade-off.

43 modèles, et ce que cela autorise

Le système de crédits de juillet, avec 43 modèles au lancement, dont des modèles d’OpenAI, d’Anthropic et de Google, change la lecture des pistes IA. On ne parle pas d’un seul modèle maison que toute l’application devrait adopter. On parle d’un moyen de payer du calcul sur une gamme. L’animal, la revue de code, le second avis et la transcription peuvent donc viser des qualités différentes. Un compagnon n’a pas besoin du même modèle qu’une relecture de diff.

Le maintien de la propriété des tokens stakés, avec récupération après unstaking, est le point qui rend le mécanisme acceptable pour un trésor d’entreprise ou un utilisateur prudent. On ne vend pas son principal pour obtenir des crédits. On l’immobilise. Le crédit suit le solde verrouillé. Pour une application, cela suggère un affichage simple : solde verrouillé, crédits du mois, date de récupération. Sans cet affichage, le staking redevient un mot qui fait fuir.

Compétitions d’animaux : le jeu et la mise

Nourrir et habiller sont des gestes de soin. Les arènes et les compétitions sont des gestes de spectacle. Le glissement n’est pas neutre. Dès qu’une compétition a un classement et un prix, des gens optimisent, et certains misent. Un animal dont le comportement dépend d’un prompt on-chain et d’un budget de calcul peut devenir un athlète dont on achète l’entraînement. C’est amusant. C’est aussi un terrain où les règles doivent précéder les récompenses.

Que mesure-t-on ? La qualité des réponses, un combat tour par tour, un vote du public ? Si le budget de calcul influence la performance, les plus riches ont de meilleurs animaux, et le jeu le dit ouvertement. Ce n’est pas forcément un défaut, à condition de ne pas le déguiser en mérite. L’inférence vérifiable sert ici à empêcher qu’un concurrent substitue un modèle plus fort hors cadre. Elle ne sert pas à rendre la partie équitable si les soldes sont libres.

Marchés de faits : une encyclopédie qui a un prix

Reprendre Augur comme modèle, c’est accepter que certaines pages restent ouvertes. Un fait tranché par un marché n’est pas un fait tranché par une source. Il est une prévision agrégée, parfois excellente, parfois capturée. L’IA qui rédige la page à partir de cette évaluation peut rendre le tout lisible. Elle peut aussi donner à un prix l’autorité d’un paragraphe bien écrit. Le risque éditorial est là : la forme encyclopédique inspire confiance, même quand le fond est un pari.

Une version honnête afficherait le prix, le volume, la question exacte, et la date de résolution à côté du texte. Une version flatteuse cacherait le marché derrière une prose sûre d’elle. Si des développeurs reprennent l’idée, le premier choix de design est celui-là. Pas le modèle. Pas le jeton. L’affichage de l’incertitude.

Benchmarks privés : le hash comme contrat

Publier le hash d’un jeu de test, et lier un score à un modèle et à ce hash, crée un contrat social minimal. On peut redemander le même test. On ne peut pas, sans le jeu, vérifier le score soi-même. D’où l’importance du cadre soumis par les développeurs, ou du modèle hébergé en privé. Le dispositif sert les équipes qui se font mutuellement confiance sur la détention des données, et qui veulent une trace. Il sert moins le public, qui ne peut pas rejouer l’épreuve.

C’est déjà utile. Beaucoup de choix de modèles en entreprise se font sur des démos. Un score attaché à un hash et à une attestation vaut mieux qu’une démo, même s’il ne vaut pas un article scientifique reproductible. NEAR, dans cette piste, serait le registre du résultat, pas le lieu où les données vivent. Encore un usage d’invisibilité : la chaîne atteste, elle n’héberge pas le secret.

Deals privés : de l’annuaire au remplissage

Dire que les deals privés exigent aujourd’hui de connaître l’autre, c’est décrire un produit qui a résolu le règlement avant la découverte. C’est l’ordre inverse du trading public, où la découverte est le carnet et le règlement vient après. Polosukhin propose de remettre la découverte au milieu, sous forme d’annonces que d’autres remplissent. Le succès se mesurera au taux de remplissage sans fuite excessive.

Un marché d’annonces a ses parasites : fausses tailles, annulations, repérage de stratégies. Les intents peuvent exécuter. Ils ne filtrent pas seuls la qualité des annonces. Il faudra une réputation, un collatéral d’annonce, ou un cercle d’accès. La clé de visualisation du social trading pourrait d’ailleurs voisiner avec ce marché : certains montrent leur P and L, d’autres ne montrent qu’une intention de deal. Deux niveaux de révélation, un même rail.

Social trading : la vitrine et la copie

Afficher le résultat et vendre la trace est un modèle que la finance traditionnelle connaît sous d’autres noms. La nouveauté serait la clé cryptographique comme droit d’accès, révocable, peut-être transférable. Si la clé est un NFT, on retombe sur un objet que l’on peut prêter ou revendre. Si elle est un simple secret, elle fuira dès le premier groupe de discussion. Le design du droit compte autant que le design du trade.

Le suiveur, lui, doit savoir ce qu’il copie. Un P and L public peut être une courbe choisie, une période favorable, un levier non dit. La clé qui ouvre les transactions permet de vérifier. Elle ne force pas à vérifier. Un produit sérieux imposerait un aperçu du drawdown et de la fréquence avant l’achat de la clé. Sinon, on vend une story, pas un accès.

Liquidation : ce qu’un intent peut faire, et pas plus

Gérer un prêt et un perpétuel pour chercher un intérêt tout en surveillant la liquidation, c’est de la mécanique de marge. Les intents peuvent déclencher un apport de collatéral, une réduction de position, un swap de garantie, si une route existe au moment voulu. Ils ne créent pas de liquidité absente. Ils ne corrigent pas un oracle faux. Ils ne raccourcissent pas un bloc saturé.

D’où la nécessité de lire le slogan comme une accroche de hackathon, pas comme une promesse. Une application honnête dirait : nous tentons de réduire les liquidations en réagissant à tels seuils, avec tel délai, et voici les cas où nous ne pouvons rien. Cette phrase est moins partageable. Elle est la seule qui devrait figurer au-dessus du bouton.

Delta neutre : le funding n’est pas un loyer

Apparier spot et perpétuel pour neutraliser la direction est une stratégie de desk, devenue un produit d’interface dans plusieurs protocoles. Le piège pédagogique est de présenter le funding encaissé comme un rendement stable. Il ne l’est pas. Il change de signe. Une jambe peut coûter plus que l’autre ne rapporte. Un contrat qui « gère » doit montrer ce signe, pas seulement le nominal apparié.

Le rôle des intents, ici, est la coordination. Ouvrir, ajuster, fermer les deux jambes sans laisser l’utilisateur exposé entre deux clics. C’est un vrai service. Il suppose des places qui acceptent ces routes, et un contrat dont les permissions sont étroites. Un contrat autorisé à « gérer des transactions » sans limite de taille n’est pas un produit delta neutre. C’est une délégation totale.

NRR, frais et staking du fonds

Le véhicule Bitwise, ticker NRR, frais de 0,75 %, détention directe et intention de staker, avec récompenses dans la valeur liquidative, place le token dans un circuit réglementé américain. Cela ne dit rien de la qualité des treize idées. Cela dit que le nom circule déjà hors des canaux développeurs. Un post technique qui parle d’animaux et de caisses peut, par ricochet, être lu par des gens venus du ticker. D’où l’intérêt d’une langue claire, et de ne pas laisser un slogan de liquidation circuler seul.

Hougan a utilisé les intents comme exemple de settlement pour agents. C’est une thèse d’infrastructure. Les idées du 3 octobre sont une thèse de produit. Les deux se renforcent si des boutons réels apparaissent. Elles se contredisent si l’infrastructure reste un exemple de présentation, et les applications une liste sans suite.

Revue de code : le sceau et le jugement

Un agent de revue privée avec exécution vérifiable répond à une peur précise : coller son code dans un chat public. Le sceau rassure l’audit interne. Il ne remplace pas le relecteur humain sur les changements dangereux. Une équipe pourrait l’utiliser comme filet, pas comme porte. Le hash du diff, le modèle, l’heure : voilà ce que la vérification peut fixer. Le « ce bug aurait cassé la prod » reste un jugement.

Le paiement par crédits de staking aligne ce produit avec les autres fronts IA de la liste. Une société qui stake déjà pour d’autres usages pourrait ajouter la revue sans nouvelle facture. Une société qui ne détient rien devrait avoir le rail fiat évoqué pour la santé. Sans ce rail, l’outil reste un avantage pour les initiés, pas un produit pour les équipes logicielles en général.

Santé : prompts en NFT, expertise en objet

Stocker des prompts personnalisés dans des NFT pour choisir une expertise d’agent est une idée de modularité. On sépare le frontal, le paiement et la consigne. Un hôpital pourrait publier un prompt validé. Un patient pourrait le sélectionner. Le risque est l’apparence d’autorité. Un objet collectionnable n’est pas un diplôme. Si l’interface montre un NFT « cardiologie » sans dire qui l’a écrit et selon quel protocole, elle induit en erreur.

Le chiffrement avant envoi est la bonne intuition. Il doit être accompagné d’une phrase simple : ce qui est déchiffré, où, et si le fournisseur du modèle conserve le texte. Tant que cette phrase n’existe pas, le produit ne devrait pas toucher un dossier réel. Le post ouvre la porte. Il ne la franchit pas, et c’est préférable.

Transcription : local d’abord, calcul ensuite

Garder les enregistrements en local et chiffrer les backups avec les clés de l’utilisateur inverse le modèle dominant des outils de notes. Le service n’est plus le lieu de vérité. Il est un processeur. Ce renversement plaît aux professions qui parlent de clients, de patients, de stratégies. Il demande une application bureau soignée, pas seulement un contrat. Polosukhin vise juste en parlant de desktop. Une transcription qui exige un portefeuille mobile à chaque réunion ne sera pas adoptée.

Le financement par staking, en alternative à l’abonnement, peut séduire ceux qui ont déjà une position. Il peut aussi compliquer une note de frais. Une équipe qui construirait l’outil aurait intérêt à afficher les deux prix : crédits issus du verrouillage, et équivalent en abonnement. Le choix devient alors comptable, pas idéologique.

Cap table : le crypto comme écriture, pas comme folklore

Une table de capitalisation qui accepte le crypto et garde le bancaire sert les sociétés qui lèvent auprès des deux publics. L’erreur serait d’en faire un tableau de tokens à côté d’un tableau d’actions, sans rapprochement. L’utilité commence quand un encaissement, quel que soit le rail, met à jour la même histoire de détention et de promesse. Les instruments de levée associés, mentionnés sans détail, devraient rester secondaires. Le premier écran est la réconciliation.

Ce produit parle moins à la crypto Twitter qu’un animal de combat. Il parle davantage à un fondateur qui a déjà perdu une soirée à recoller un tableur. Dans la logique de distribution de Polosukhin, c’est précisément le genre d’outil qui a sa place sur une plateforme de lancement, parce qu’on peut le montrer en une démo, sans expliquer un consensus.

Communautés : NEARLegion n’est pas un plan média

Conseiller NEARLegion, c’est rappeler qu’un réseau a déjà des gens organisés. Ce n’est pas un plan média complet. La promotion croisée vers d’autres communautés est le complément nécessaire, sinon l’application ne parle qu’aux convaincus. Product Hunt et X servent la découverte hors cercle. Aucun de ces canaux ne répare un onboarding cassé. Ils amplifient ce que le premier écran permet.

D’où le lien avec Intent Connect. La distribution technique et la distribution sociale doivent partir ensemble. Un lancement public d’une application qui demande un bridge est un lancement de friction. Un lancement d’une application qui signe une fois est un lancement de produit. Le post traite les deux, dans des paragraphes séparés. Les équipes auraient intérêt à les traiter comme une seule décision.

Ce que cette liste dit de la concurrence

D’autres réseaux vendent aussi des agents, des paiements et de la confidentialité. La différence revendiquée ici n’est pas un modèle d’IA exclusif. C’est l’assemblage : intents pour le règlement interchaînes, crédits de staking pour le calcul, inférence attestable, connexion de portefeuilles étrangers. Une équipe peut retrouver des morceaux ailleurs. Le pitch de Polosukhin consiste à dire que les morceaux sont déjà assez alignés pour construire des produits, pas seulement des démos de protocole.

Cette affirmation se vérifiera dans les semaines qui suivent le post. Si des développeurs reprennent la caisse, le dépôt ou la revue, la liste aura fait son travail. Si elle reste un fil admiré puis oublié, le diagnostic sur la distribution se sera appliqué à elle-même. Il est plus facile de publier treize idées que d’en faire adopter une.

Risques que le post laisse ouverts

Aucun de ces chantiers n’est sans contrepartie. Le widget peut mal afficher un prix. Le dépôt d’événement peut être capturé par l’organisateur. L’animal peut drainer un solde. Le marché de faits peut habiller un pari en encyclopédie. Le deal privé peut fuir. La clé de copie peut être revendue. Le slogan de liquidation peut être pris au pied de la lettre. Le second avis peut sortir du cadre de l’information. La transcription peut envoyer plus qu’elle ne dit. La cap table peut mal réconcilier et donner une fausse certitude juridique.

Les nommer n’est pas rejeter la liste. C’est la prendre au sérieux. Polosukhin s’adresse à des bâtisseurs, pas à des acheteurs de jeton. Un bâtisseur qui ne voit pas le risque de son idée la construira mal. Le ton du post est ouvert, presque invitant. La suite utile est une spécification, pas un autre thread.

Une lecture pour l’utilisateur non technique

Si l’on retire les noms de produits, le message dit ceci. Vous pourriez payer un commerçant sans changer de portefeuille. Vous pourriez déposer pour un événement et partager la cagnotte de ceux qui ne viennent pas. Vous pourriez avoir un compagnon numérique dont le budget de pensée est visible. Vous pourriez faire relire un document sensible sans le publier. Rien de cela n’est livré le 3 octobre. Tout cela est proposé comme direction à ceux qui construisent.

Cette lecture suffit à juger l’intérêt. Les gens n’adoptent pas des intents. Ils adoptent un bouton, un dépôt, un animal, une note de réunion. Le réseau gagne s’il disparaît derrière ces objets. Il perd s’il exige d’être compris avant d’être utile.

Calendrier rapproché, pour situer le post

Trois dates aident à ne pas lire le fil comme une île. Le 31 juillet, des paiements d’IA par staking, 43 modèles, principal récupérable. Le 17 septembre, exécution Sui en une signature via Intents Connect, sans bridge manuel pour les actions prises en charge. Le 29 septembre, ETF Bitwise NRR sur NYSE Arca, frais 0,75 %, staking prévu des avoirs du fonds. Le 3 octobre, la liste d’applications. Le fil conducteur est le même : règlement, calcul, accès depuis ailleurs.

Un lecteur pressé peut s’arrêter à l’animal. Un lecteur qui aligne les dates voit une infrastructure qui cherche des interfaces. C’est moins viral. C’est plus proche de ce que le co-fondateur a écrit.

Ce qu’il ne faut pas conclure trop vite

La publication ne dit pas que NEAR a dépassé ses concurrents sur l’IA. Elle ne dit pas que Shopify intégrera le widget. Elle ne dit pas que les liquidations sont résolues. Elle ne dit pas que les données médicales sont déjà protégées de bout en bout dans un produit live. Elle dit que construire est plus simple, que des gens construisent, et que voici des directions plus la distribution.

Tenir cette limite est une forme de respect pour le texte. Le secteur a l’habitude de transformer une piste en annonce, puis l’annonce en cours. Ici, la matière est assez riche sans ce glissement. Treize idées, cinq portes, une infrastructure déjà nommée dans des annonces antérieures : cela suffit pour un automne de prototypes, pas pour une conclusion de marché.

Le geste qui compte après le fil

Le geste utile, pour une équipe qui se reconnaît dans une ligne, est de choisir un utilisateur et un échec. Pour la caisse : un marchand, et l’échec d’une route trop lente. Pour l’événement : un organisateur, et l’échec d’un check-in contesté. Pour l’animal : un propriétaire, et l’échec d’un solde qui fond. Pour la revue : une équipe, et l’échec d’un sceau trop confiant. Écrire cet échec avant l’interface évite de construire le slogan.

Polosukhin a fait la partie publique : pointer le goulot, qui n’est plus le déploiement. La partie privée, celle des dépôts de code et des conversations avec des marchands, ne se voit pas dans un fil. C’est pourtant là que la liste deviendra soit une anecdote d’octobre, soit le début d’applications que l’on peut ouvrir sans mode d’emploi.

En attendant, le texte a un mérite rare dans ce genre de publication. Il mélange le spectacle et le comptoir, l’animal et la caisse, le second avis et la table de capitalisation, sans prétendre que tout est prêt. Il demande aux développeurs de se démarquer. La meilleure manière de se démarquer, à la lecture de sa propre liste, n’est pas d’ajouter une quatorzième idée. C’est d’en finir une, avec un reçu, un check-in, ou un solde que l’on comprend sans traduction.

]]>