Le produit commence par ses limites

Des frais à suivre, des contrats à distinguer, des paiements de test et deux GPU à choisir : les outils donnent au récit ses questions les plus utiles.

CHOP propose de travailler les oscillations du marché comme du bois. TasQ demande aux détenteurs de choisir deux machines. Les images rendent les produits accessibles ; elles ne remplacent pas le suivi des frais, des commandes et des revenus.

Chez Sectoral, un reçu de loyer donne une échelle humaine à la confidentialité. Le dépôt public précise pourtant un déploiement de test avec un vérificateur provisoire. Chez opcode, les changements de chaîne et de contrat sont déjà une partie de l’expérience des détenteurs.

Ces quatre tokens sont suivis sur Robinhood Chain, vérifiée comme réseau EVM distinct de l’application de courtage. Aucun nom ni lancement ne vaut approbation par Robinhood. Cette semaine, comprendre le produit signifie surtout savoir ce qui fonctionne, ce qui est annoncé et qui conserve les commandes.

Rédigé par Jérôme L.

02 / CHOP / RÉCIT

CHOP : des bûches pour un marché qui hésite

Le projet transforme les allers-retours de prix en récit de rendement. Son image de scierie rend le mécanisme lisible, mais les frais et les pouvoirs de contrôle restent déterminants.

CHOP appelle ses actifs enveloppés des « logs », des bûches. L’image est presque un mode d’emploi : les allers-retours du marché apporteraient du bois à travailler plutôt qu’une simple direction à deviner. Lors du lancement du 7 octobre, le compte du projet publie le contrat Robinhood Chain et présente cette manière de traiter la volatilité. [1] [2]

Ce qui attire ici est le changement de rôle proposé au détenteur. Dans un marché qui monte puis redescend, un trader peut avoir l’impression de revoir toujours la même scène sans encaisser son mouvement. CHOP invite à regarder les échanges comme une activité qui prélève des frais. Le projet tente ainsi de faire du mot « chop », souvent employé pour un marché haché et indécis, une matière première.

Où vont les copeaux ?

Un log est une version enveloppée d’un actif. La documentation prévoit son association à de la liquidité et des positions mises en ferme. Les opérations d’enveloppement, de sortie et les échanges produisent différents frais. Il faut suivre ces étapes pour comprendre le rendement présenté : il ne provient pas d’un intérêt créé sans activité, mais de flux payés autour du mécanisme. [2] [3]

L’exemple donné dans la documentation est parlant. Sans partenaire, sur une valeur de 10 000 dollars équivalents, 15 % vont à la destruction de logs. Le reste est converti en CHOP ; 20 % de cette partie sont détruits et 80 % distribués aux fermiers. Les 1 500, 1 700 et 6 800 qui en résultent sont des équivalents de valeur dans cet exemple, pas trois quantités comparables de tokens. S’il n’existe aucun fermier admissible, la part prévue pour les récompenses est elle aussi détruite. [3]

Le schéma rend la promesse plus concrète. Il laisse également voir une dépendance : sans activité suffisante, les frais qui alimentent le système changent. Un taux passé n’est pas un revenu garanti pour le prochain détenteur. La documentation traite les APY comme des observations historiques, et non comme des engagements fixes. [4]

Une scierie avec ses commandes

Le bilan publié le 10 octobre annonce trois logs pendant les cinq premiers jours, environ 30 000 dollars de valeur bloquée et une part de l’offre enveloppée. Ces chiffres appartiennent au compte de CHOP ; nous n’en faisons pas un audit des positions. Leur fonction dans le récit est claire : montrer qu’un vocabulaire de lancement commence à produire des objets utilisés. [6]

Les objets n’effacent pas les commandes. La page consacrée aux pouvoirs administratifs décrit des fonctions de mise à niveau sur les logs existants et la fabrique de nouveaux logs, ainsi que des réglages de frais avant verrouillage. Elle évoque aussi la pause des récompenses et les positions initiales de l’équipe, qui peuvent recevoir des revenus de la ferme. Ce sont des éléments du mécanisme économique, pas une réserve générale à ranger loin de l’explication. [5]

Les coûts d’entrée et de sortie comptent de la même manière. La documentation indique des frais d’enveloppement et de retrait pouvant chacun atteindre 1 %, auxquels s’ajoutent les risques liés à la liquidité et aux variations relatives des actifs. Des revenus de trading peuvent coexister avec une perte sur la position. Le terme « farming » ne dispense pas de calculer le parcours complet. [3] [4]

Le projet revendique une infrastructure issue de Peapod. Une filiation logicielle peut expliquer des choix ; elle ne remplace pas un rapport indépendant portant sur les contrats et réglages de ce déploiement. La documentation de CHOP rend au moins les adresses et les pouvoirs consultables, ce qui donne aux participants un objet précis à examiner. [5] [7]

CHOP est intéressant lorsqu’on suit la transformation d’une frustration de trader en produit : le marché qui hésite devient une scierie. L’image rend la proposition mémorable ; les frais, la liquidité et les contrôles déterminent ce qu’elle produit réellement. C’est en gardant ces trois éléments à côté des bûches que le récit reste utile au lecteur.

Rédigé par Jérôme L.

03 / OP / RÉCIT

OP : l’adresse devient le sujet

Lancements, destruction de tokens et remboursements se succèdent autour d’opcode. Avant de discuter son AMM, il faut distinguer ce qui concerne Robinhood de ce qui concerne Solana.

Le 9 octobre, opcode publie un contrat Robinhood Chain et annonce un AMM consacré aux actifs du monde réel, avec une ambition multichaîne. Quelques publications plus loin, le même compte parle de tokens détruits, de remboursements pour des détenteurs Solana et d’un problème de backend. Le lecteur ne manque pas d’annonces ; il manque d’une carte pour les relier. [10] [11] [13] [14]

L’adresse de cette édition finit par d31fb03. Elle est donnée explicitement dans le lancement Robinhood. C’est notre point fixe. Les lettres OP et le nom opcode ne suffisent pas à suivre toutes les opérations ultérieures, parce que le projet emploie aussi des contrats sur Solana. Un récit qui fusionnerait ces étapes produirait une chronologie nette mais fausse.

Brûler ne résout pas le problème d’identité

Dans la foulée du lancement, opcode publie un lien de transaction pour une destruction de tokens. lora décrit cette opération comme une réduction de 71 % de l’offre. Il faut attribuer ce pourcentage à sa lecture : une annonce et un commentaire ne remplacent pas une reconstitution complète de l’offre circulante à chaque instant. [11] [12]

Ce détail compte aussi pour les ATH. Un sommet de prix multiplié par une offre nominale peut afficher une valorisation très différente de celle calculée après destruction. Les chiffres de l’encadré distinguent donc le prix historique de la valorisation théorique sur l’offre référencée. Ils ne prétendent pas reconstituer une capitalisation circulante introuvable à la seconde du sommet.

Le message de remboursement cible, lui, les détenteurs Solana, avec un instantané annoncé à 18 heures UTC et une date limite de réclamation. Cela n’autorise pas à déduire que le contrat Robinhood a été remboursé de la même façon. Le compte reconnaît ensuite un problème de backend et annonce des vérifications autour du déploiement Robinhood. La séparation des chaînes fait partie de l’information, pas d’une note technique accessoire. [13] [14]

Le produit et ses incarnations

Le 10 octobre, une publication annonce un contrôle interne des contrats et un nouveau déploiement. « Interne » reste le mot utile : ce contrôle n’est pas présenté ici comme un audit indépendant. Plus tard, opcode écrit avoir construit un AMM multichaîne et annonce une nouvelle destruction, cette fois en affichant une autre adresse Solana. Ce post ne suffit pas à déclarer détruit l’ensemble du contrat Robinhood étudié. [15] [16]

La FAQ du terminal actuellement consultable indique elle aussi un mint Solana différent. Elle décrit donc une incarnation du produit qui ne doit pas être utilisée pour attribuer automatiquement ses fonctions au token de cette édition. Le nom commun crée une continuité de communication ; les contrats montrent une discontinuité économique. [17]

Cette complication a déjà une réception publique. Le 9 octobre, treyerl demande pourquoi le lancement apparaît ainsi sur son écran et souligne la faible quantité d’informations disponibles. Sa réaction n’établit pas une faute du projet. Elle rend visible le travail supplémentaire demandé aux participants : comprendre ce qu’ils possèdent avant même d’évaluer ce qui est promis. [18]

L’intérêt culturel d’opcode est peut-être là, dans une tension rarement placée au centre du récit de lancement. La communauté doit faire tenir un nom à travers plusieurs actifs, correctifs et annonces. Les mêmes mots peuvent désigner une vision de produit, un ancien token ou une nouvelle version. Chaque changement oblige les lecteurs à reconstruire leurs repères.

L’article ne tranche donc pas cette histoire par un slogan sur l’innovation ou par une accusation. Il suit les objets que les sources permettent d’identifier. Pour le contrat Robinhood, le lancement et les annonces correspondantes sont documentés. Pour les autres étapes, la chaîne et l’adresse restent indiquées. C’est le minimum pour que le récit du produit ne gomme pas celui de ses détenteurs.

Rédigé par Jérôme L.

04 / SECTORAL / RÉCIT

Sectoral : un reçu, pas tout votre relevé

Le projet imagine des paiements dont les montants restent privés. Son exemple de loyer rend l’idée accessible ; son dépôt public situe le prototype bien plus précisément que le mot « banque ».

Un propriétaire a besoin de savoir que le loyer a été payé, pas de lire tout votre historique. Le 9 octobre, Sectoral choisit cette situation pour expliquer son produit. Le détail donne immédiatement une échelle humaine à une expression technique : révéler une preuve utile sans ouvrir le reste de sa vie financière. [21]

Le compte avait publié son contrat Robinhood Chain le 5 octobre. Le site présente depuis une « banque privée » pour les personnes et pour les agents qui dépensent en leur nom. Cette expression relève du positionnement du projet. Les sources étudiées décrivent un logiciel et des contrats ; elles ne permettent pas d’y voir, par le seul vocabulaire choisi, un établissement bancaire agréé. [24] [22]

Ce qui reste visible

La documentation précise la confidentialité plus étroitement que certaines formules de la page d’accueil. Les adresses de l’expéditeur et du destinataire restent visibles ; ce sont les montants qui sont chiffrés. Le projet utilise des soldes chiffrés et des preuves permettant de vérifier qu’un transfert respecte les règles sans publier sa valeur. Cela ne signifie pas que toute trace du paiement disparaît. [22] [23]

Cette distinction donne du sens à l’exemple du loyer. La confidentialité peut être sélective, avec une information présentée au bon interlocuteur. Mais un réseau d’adresses public conserve ses propres indices. Le terme « privé » doit donc désigner ce que le mécanisme protège, pas une invisibilité générale déduite du logo.

Le dépôt public des contrats est particulièrement utile. Il décrit un déploiement de test daté du 4 octobre, avec un substitut de USDG et un vérificateur provisoire qui ne contrôle pas les preuves. Le README indique explicitement que ce composant doit être remplacé avant de faire intervenir une valeur réelle. Le prototype documenté n’est donc pas une preuve de paiements confidentiels de production déjà sécurisés. [23]

Donner un budget à un agent

Le projet distingue aussi le propriétaire et le logiciel qui agit pour lui. Un agent doit recevoir un budget, des limites par opération et par jour, des destinataires autorisés et, dans certains cas, un seuil d’approbation. L’objectif décrit est de rendre les contraintes exécutables dans les contrats, plutôt que de simplement demander à l’agent d’être prudent. [23]

Le README expose des commandes d’arrêt, de changement de clé et de révocation. Une clé d’agent compromise devrait ainsi conduire à retirer son mandat, sans traiter cette clé comme le détenteur libre de tous les fonds du propriétaire. Ces choix racontent une autonomie bornée. Ils ne sont pas une mesure, par nos soins, de la résistance réelle de tout le système. [23]

Le 11 octobre, Sectoral annonce des identifiants de paiement où humains et agents sont indiqués distinctement. Ce détail d’interface prolonge le même enjeu : savoir à qui l’on s’adresse et sous quel mandat le paiement part. L’agent n’est pas seulement un nouveau nom dans un carnet ; il représente une délégation qui doit pouvoir être comprise et interrompue. [25]

La communauté entre la démo et la promesse

Une publication du 9 octobre évoque des cartes virtuelles. Nous la conservons comme annonce du projet : les sources consultées n’établissent pas indépendamment l’émetteur, les conditions ni l’accès effectif au service. Le 11 octobre, une rencontre communautaire est annoncée pour la semaine suivante, sans horaire confirmé dans le message. Les questions sur le passage du prototype au produit ont donc encore un lieu annoncé où être posées. [26] [27]

Sectoral gagne en intérêt lorsque l’on quitte le mot « neobank » pour regarder les permissions, le reçu et le déploiement réel. Le reçu de loyer est une idée claire ; la documentation expose les pièces nécessaires pour la réaliser. La distance entre cette idée et un système de production ne doit pas être effacée par le token. Elle est précisément l’histoire que ses prochains développements devront permettre de suivre.

Rédigé par Jérôme L.

05 / TASQ / RÉCIT

TasQ : les détenteurs choisissent les machines

Un vote propose l’achat ou la location de deux GPU. Derrière ce geste tangible, le papier technique distingue encore les modèles, les simulations et le réseau à construire.

Deux GPU, achetés ou loués, avec leurs revenus destinés à racheter puis détruire des tokens. Le 11 octobre, TasQ publie sa proposition n°1 et invite les détenteurs, même d’une petite quantité, à voter. La gouvernance prend un objet que l’on peut se représenter : des machines physiques. Le lien de vote utilise Privy, sans que cette invitation soit une preuve du résultat du scrutin. [30]

Le contraste est utile. Lancé le 7 octobre sur Robinhood Chain, TasQ veut organiser un marché de calcul où le client n’aurait pas à faire confiance au fournisseur de GPU sur parole. Sa proposition matérielle offre une étape proche et lisible ; son papier de 23 pages raconte un chantier beaucoup plus large. [31] [32]

Trois manières de demander une preuve

Le Yellow Paper distingue trois voies. La première utilise l’attestation d’un environnement matériel pour protéger l’exécution. La deuxième fait reproduire des travaux et introduit des contrôles cachés afin de décourager les résultats fabriqués. La troisième emploie des preuves cryptographiques lorsque leur coût est compatible avec le travail demandé. Les trois ne procurent pas exactement les mêmes garanties de confidentialité et d’intégrité. [32]

Ce choix est plus intéressant qu’une formule universelle de « calcul vérifiable ». Il admet que tous les travaux ne peuvent pas être prouvés de la même manière à un coût acceptable. Le papier discute notamment le problème des fournisseurs qui coopèrent pour fournir une mauvaise réponse : une sélection publique facilite certaines attaques, tandis que des audits cachés cherchent à en changer l’économie. [32]

Il situe également ses résultats. Les coûts d’un environnement GPU sécurisé sont modélisés plutôt que mesurés sur le déploiement final. Les expériences présentées comprennent simulations et microbenchmarks ; le document n’expose pas une évaluation de réseau de test achevée. La coordination reste opérée par TasQ. Ces indications viennent du papier du projet lui-même et empêchent de raconter un marché décentralisé déjà éprouvé à grande échelle. [32]

Les machines disponibles et celles du vote

Le site montre des offres de matériel et de prix. Ces éléments d’interface ne suffisent pas à vérifier la disponibilité indépendante de chaque machine. Le 11 octobre, le compte annonce aussi un accès à plus de cinquante GPU à la demande via des crédits Google Cloud. C’est une déclaration d’accès à une infrastructure ; elle ne prouve pas un partenariat commercial officiel avec Google. [33] [34]

Le vote sur deux GPU propres au projet concerne encore autre chose. Il proposerait de contrôler directement quelques machines et d’affecter la totalité de leurs revenus à des rachats et destructions. Ce pourcentage vise le périmètre de cette proposition, pas nécessairement chaque revenu de toute l’infrastructure. Les coûts, la mise en œuvre et les flux devront rester lisibles après le vote pour que les détenteurs puissent suivre leur décision. [30]

Le projet donne des noms aux rôles : Jun Ting pour la direction, Paing Chan pour la technique, Baris pour le marketing et Newman Wang comme conseiller. La page d’équipe constitue une présentation par TasQ, non une vérification indépendante de tous les parcours. Elle rend au moins les responsabilités plus identifiables qu’un collectif entièrement anonyme. [35]

Voter ensemble demande un lieu

Dans les réponses à la proposition, Berlin demande un Telegram ou un espace communautaire. Le message donne une limite pratique à l’idée de gouvernance : pouvoir cocher une option ne remplace pas un endroit où discuter ses coûts et ses alternatives. Un actif peut disposer d’un scrutin avant d’avoir organisé la conversation qui l’entoure. [37]

L’allocation présentée sur le site dit que les tokens de l’équipe ont été achetés sur le marché et placés sous vesting, plutôt que pris dans une réserve initiale. Cette présentation et les liens de lancement offrent des points de contrôle ; ils ne rendent pas toutes les incitations identiques entre ceux qui exploitent les machines et ceux qui détiennent le token. [36] [31]

TasQ propose ainsi une histoire à deux vitesses. Une décision collective peut porter très vite sur deux GPU. Les garanties du marché de calcul demandent, elles, un travail technique et des mesures que le papier situe encore à un stade de construction. Le vote donne une première prise aux détenteurs. Sa valeur narrative dépendra de ce qu’ils pourront observer ensuite : les machines, leur activité et l’exécution de l’usage promis pour les revenus.

Rédigé par Jérôme L.

Les références numérotées dans les articles renvoient à cette liste. Les liens externes s’ouvrent dans un nouvel onglet.

1. CHOP — lancement et contrat, 7 octobre
2. CHOP — introduction aux logs
3. CHOP — répartition des frais
4. CHOP — risques
5. CHOP — pouvoirs administratifs
6. CHOP — bilan des cinq premiers jours, 10 octobre
7. CHOP — contrats
8. GMGN — CHOP, ATH de prix ; relevé du 11 octobre 2026
9. DEX Screener — CHOP, contrat et réseau ; consultation du 11 octobre
10. opcode — lancement Robinhood, 9 octobre
11. opcode — annonce de destruction, 9 octobre
12. lora — lecture de l’offre détruite, 9 octobre
13. opcode — remboursements des détenteurs Solana, 9 octobre
14. opcode — problème de backend, 9 octobre
15. opcode — audit interne et déploiement annoncé, 10 octobre
16. opcode — message de destruction avec un autre contrat Solana, 10 octobre
17. opcode — FAQ et mint du terminal actuel
18. treyerl — questions sur le lancement, 9 octobre
19. GMGN — OP, ATH de prix ; relevé du 11 octobre 2026
20. DEX Screener — OP, contrat et réseau ; consultation du 11 octobre
21. Sectoral — reçu de loyer, 9 octobre
22. Sectoral — documentation
23. Sectoral — contrats et déploiement de test
24. Sectoral — lancement et contrat, 5 octobre
25. Sectoral — identifiants humains et agents, 11 octobre
26. Sectoral — annonce de cartes, 9 octobre
27. Sectoral — réunion communautaire annoncée, 11 octobre
28. GMGN — SECTORAL, ATH de prix ; relevé du 11 octobre 2026
29. DEX Screener — SECTORAL, contrat et réseau ; consultation du 11 octobre
30. TasQ — proposition n°1, 11 octobre
31. TasQ — lancement et contrat, 7 octobre
32. TasQ — Yellow Paper, version révisée en octobre
33. TasQ — présentation du réseau
34. TasQ — accès à des GPU via des crédits cloud, 11 octobre
35. TasQ — équipe
36. TasQ — token et allocation
37. Berlin — demande d’espace communautaire, 11 octobre
38. GMGN — TasQ, ATH de prix ; relevé du 11 octobre 2026
39. DEX Screener — TasQ, contrat et réseau ; consultation du 11 octobre
40. Robinhood Chain — documentation officielle, consultation du 11 octobre