MICHAEL MOORE
5.1k Publications
MICHAEL MOORE
Ouvert au trading
Trade régulièrement
4.1 mois
575 Suivis
15.0K+ Abonnés
3.5K+ J’aime
Publications
Portefeuille
Tous
Citations
Direct
PINNED
OpenGradient a fait un argument spécifique cette semaine.
Un ordre gouvernemental a forcé Anthropic à désactiver deux de ses modèles les plus avancés pour tous les utilisateurs en même temps. Pas d'avertissement, pas de période de grâce.
OpenGradient a directement pointé cela et a dit que c'était exactement le problème que leur réseau était conçu pour résoudre. L'IA centralisée dépend d'une entreprise qui peut être ordonnée de ne plus vous servir.
Je suis d'accord avec cette observation. Ce que je ne peux pas concilier, c'est le produit qu'ils ont lancé pour y remédier.
@OpenGradient Chat, lancé le 4 juin 2026, redirige vers des modèles d'IA de pointe à travers une couche d'anonymisation. Selon le communiqué de presse officiel, l'application atteint cinq modèles d'IA majeurs pour commencer. L'architecture fonctionne comme décrit : cryptage local, HTTP Oblivious, enclaves sécurisées qui traitent les requêtes sans les lier à votre identité.
Mais la couche d'anonymisation cache seulement qui vous êtes. Elle ne change pas les modèles avec lesquels vous interagissez.
Si le même ordre gouvernemental qui a désactivé Fable 5 et Mythos 5 s'étendait davantage, chaque requête redirigée via OpenGradient Chat vers un fournisseur affecté cesserait de fonctionner. Non pas parce qu'OpenGradient a échoué. Parce que le fournisseur sous-jacent a reçu l'ordre d'arrêter.
La protection de la vie privée reste intacte. Le modèle disparaît.
Selon le communiqué de presse officiel d'OpenGradient publié le 4 juin 2026 sur PR Newswire, chaque modèle actuellement disponible dans OpenGradient Chat est construit et opéré par une entreprise qui fonctionne sous une juridiction gouvernementale. Tous les cinq.
Le réseau qui ne peut pas être contraint passe par des fournisseurs qui le peuvent.
Je ne pense pas que cela rende OpenGradient Chat un mauvais produit.
Ce que je n'ai pas vu abordé nulle part, c'est ceci : si l'approvisionnement des modèles sous-jacents peut être coupé par un ordre gouvernemental, que signifie exactement la résistance à la censure pour un produit construit dessus ?
#opg $OPG
Un ordre gouvernemental a forcé Anthropic à désactiver deux de ses modèles les plus avancés pour tous les utilisateurs en même temps. Pas d'avertissement, pas de période de grâce.
OpenGradient a directement pointé cela et a dit que c'était exactement le problème que leur réseau était conçu pour résoudre. L'IA centralisée dépend d'une entreprise qui peut être ordonnée de ne plus vous servir.
Je suis d'accord avec cette observation. Ce que je ne peux pas concilier, c'est le produit qu'ils ont lancé pour y remédier.
@OpenGradient Chat, lancé le 4 juin 2026, redirige vers des modèles d'IA de pointe à travers une couche d'anonymisation. Selon le communiqué de presse officiel, l'application atteint cinq modèles d'IA majeurs pour commencer. L'architecture fonctionne comme décrit : cryptage local, HTTP Oblivious, enclaves sécurisées qui traitent les requêtes sans les lier à votre identité.
Mais la couche d'anonymisation cache seulement qui vous êtes. Elle ne change pas les modèles avec lesquels vous interagissez.
Si le même ordre gouvernemental qui a désactivé Fable 5 et Mythos 5 s'étendait davantage, chaque requête redirigée via OpenGradient Chat vers un fournisseur affecté cesserait de fonctionner. Non pas parce qu'OpenGradient a échoué. Parce que le fournisseur sous-jacent a reçu l'ordre d'arrêter.
La protection de la vie privée reste intacte. Le modèle disparaît.
Selon le communiqué de presse officiel d'OpenGradient publié le 4 juin 2026 sur PR Newswire, chaque modèle actuellement disponible dans OpenGradient Chat est construit et opéré par une entreprise qui fonctionne sous une juridiction gouvernementale. Tous les cinq.
Le réseau qui ne peut pas être contraint passe par des fournisseurs qui le peuvent.
Je ne pense pas que cela rende OpenGradient Chat un mauvais produit.
Ce que je n'ai pas vu abordé nulle part, c'est ceci : si l'approvisionnement des modèles sous-jacents peut être coupé par un ordre gouvernemental, que signifie exactement la résistance à la censure pour un produit construit dessus ?
#opg $OPG
PINNED
@OpenGradient utilise le mot "permissionless" à un endroit précis, et il vaut la peine de lire attentivement quel endroit c'est.
La documentation du Model Hub est explicite. Tout le monde peut uploader un modèle. Pas de processus d'approbation, pas de contrôle, pas de demande.
Permissionless apparaît clairement dans les matériaux officiels décrivant l'hébergement de modèles.
Maintenant, lis ce que les docs d'architecture disent sur les nœuds d'inférence, la couche de calcul qui exécute réellement ces modèles.
Selon la documentation officielle actuelle, les nœuds d'inférence s'enregistrent sur le réseau et sont vérifiés avant de servir les demandes. Pour les nœuds TEE spécifiquement, l'enregistrement confirme qu'ils exécutent un logiciel correct et sans altération.
Enregistrement. Vérifié. Confirmé avant de servir.
C'est un mot différent de permissionless.
Les uploads de modèles sont ouverts à tous. L'infrastructure qui exécute réellement ces modèles passe par un processus d'enregistrement et de vérification.
Je n'ai pas trouvé de chemin public expliquant comment un nouvel opérateur de nœud entrerait dans ce processus aujourd'hui.
La description officielle dit que les modèles fonctionnent sur un réseau permissionless de nœuds spécialisés.
Ce que décrivent les docs d'architecture est un réseau où les nœuds sont enregistrés et vérifiés, ce qui est une distinction significative par rapport à permissionless.
Je ne dis pas que le processus d'enregistrement des nœuds est fermé. Je dis que les deux mots ne signifient pas la même chose, et je n'ai pas vu quelqu'un souligner qu'OpenGradient utilise les deux pour décrire le même réseau.
Alors quand tu entends permissionless, quelle couche décris-tu réellement ?
#opg $OPG
La documentation du Model Hub est explicite. Tout le monde peut uploader un modèle. Pas de processus d'approbation, pas de contrôle, pas de demande.
Permissionless apparaît clairement dans les matériaux officiels décrivant l'hébergement de modèles.
Maintenant, lis ce que les docs d'architecture disent sur les nœuds d'inférence, la couche de calcul qui exécute réellement ces modèles.
Selon la documentation officielle actuelle, les nœuds d'inférence s'enregistrent sur le réseau et sont vérifiés avant de servir les demandes. Pour les nœuds TEE spécifiquement, l'enregistrement confirme qu'ils exécutent un logiciel correct et sans altération.
Enregistrement. Vérifié. Confirmé avant de servir.
C'est un mot différent de permissionless.
Les uploads de modèles sont ouverts à tous. L'infrastructure qui exécute réellement ces modèles passe par un processus d'enregistrement et de vérification.
Je n'ai pas trouvé de chemin public expliquant comment un nouvel opérateur de nœud entrerait dans ce processus aujourd'hui.
La description officielle dit que les modèles fonctionnent sur un réseau permissionless de nœuds spécialisés.
Ce que décrivent les docs d'architecture est un réseau où les nœuds sont enregistrés et vérifiés, ce qui est une distinction significative par rapport à permissionless.
Je ne dis pas que le processus d'enregistrement des nœuds est fermé. Je dis que les deux mots ne signifient pas la même chose, et je n'ai pas vu quelqu'un souligner qu'OpenGradient utilise les deux pour décrire le même réseau.
Alors quand tu entends permissionless, quelle couche décris-tu réellement ?
#opg $OPG
Model Uploads
84%
Compute Nodes
6%
Both Layers
5%
Not sure yet
5%
19 Votes • Vote fermé
..............
MICHAEL MOORE
·
--
2M+ inférences vérifiables traitées.
C'est le titre. La répartition ne l'est pas.
C'est sur le site officiel, dans les documents de la Fondation, dans le communiqué de presse pré-TGE du 14 avril 2026. Même chiffre, partout.
Alors je suis allé dans la documentation réseau réelle pour comprendre ce que ce chiffre signifie.
Selon la documentation officielle des développeurs actuelle, le Testnet OpenGradient actif prend en charge x402 LLM inference, qui achemine les demandes vers des fournisseurs comme OpenAI et Anthropic à travers une couche sécurisée.
Cette partie fonctionne. Mais la même page dit clairement autre chose, l'inférence ML sur la chaîne est en développement.
C'est le type d'inférence qui exécute des modèles du Model Hub directement sur du matériel GPU. Le genre qui rend OpenGradient différent d'un simple wrapper de confidentialité autour des fournisseurs d'IA existants.
Le Testnet Alpha, qui supportait l'inférence ML complète via le système PIPE, est listé comme obsolète dans la même documentation.
Donc, quand je regarde 2M+, je ne peux pas dire ce que je regarde réellement. S'agissait-il d'appels proxy LLM acheminés par des fournisseurs existants, ou d'une véritable inférence de modèle ML sur la chaîne du Model Hub ? L'explorateur de blocs OpenGradient montre des transactions d'inférence.
Ce qu'il ne montre pas, c'est une répartition par type d'inférence ou niveau de vérification.
Le projet se qualifie de réseau d'IA vérifiable. Ce chiffre est 2M+. Mais ce que ces inférences étaient, quel niveau de vérification elles utilisaient, et sur quel réseau elles ont fonctionné n'est publié nulle part dans la documentation, l'explorateur, ou les documents de la Fondation.
Si la vérifiabilité est le but principal, le compte des inférences devrait être la chose la plus facile à vérifier.
@OpenGradient #opg $OPG
C'est le titre. La répartition ne l'est pas.
C'est sur le site officiel, dans les documents de la Fondation, dans le communiqué de presse pré-TGE du 14 avril 2026. Même chiffre, partout.
Alors je suis allé dans la documentation réseau réelle pour comprendre ce que ce chiffre signifie.
Selon la documentation officielle des développeurs actuelle, le Testnet OpenGradient actif prend en charge x402 LLM inference, qui achemine les demandes vers des fournisseurs comme OpenAI et Anthropic à travers une couche sécurisée.
Cette partie fonctionne. Mais la même page dit clairement autre chose, l'inférence ML sur la chaîne est en développement.
C'est le type d'inférence qui exécute des modèles du Model Hub directement sur du matériel GPU. Le genre qui rend OpenGradient différent d'un simple wrapper de confidentialité autour des fournisseurs d'IA existants.
Le Testnet Alpha, qui supportait l'inférence ML complète via le système PIPE, est listé comme obsolète dans la même documentation.
Donc, quand je regarde 2M+, je ne peux pas dire ce que je regarde réellement. S'agissait-il d'appels proxy LLM acheminés par des fournisseurs existants, ou d'une véritable inférence de modèle ML sur la chaîne du Model Hub ? L'explorateur de blocs OpenGradient montre des transactions d'inférence.
Ce qu'il ne montre pas, c'est une répartition par type d'inférence ou niveau de vérification.
Le projet se qualifie de réseau d'IA vérifiable. Ce chiffre est 2M+. Mais ce que ces inférences étaient, quel niveau de vérification elles utilisaient, et sur quel réseau elles ont fonctionné n'est publié nulle part dans la documentation, l'explorateur, ou les documents de la Fondation.
Si la vérifiabilité est le but principal, le compte des inférences devrait être la chose la plus facile à vérifier.
@OpenGradient #opg $OPG
...........
MICHAEL MOORE
·
--
@OpenGradient utilise le mot "permissionless" à un endroit précis, et il vaut la peine de lire attentivement quel endroit c'est.
La documentation du Model Hub est explicite. Tout le monde peut uploader un modèle. Pas de processus d'approbation, pas de contrôle, pas de demande.
Permissionless apparaît clairement dans les matériaux officiels décrivant l'hébergement de modèles.
Maintenant, lis ce que les docs d'architecture disent sur les nœuds d'inférence, la couche de calcul qui exécute réellement ces modèles.
Selon la documentation officielle actuelle, les nœuds d'inférence s'enregistrent sur le réseau et sont vérifiés avant de servir les demandes. Pour les nœuds TEE spécifiquement, l'enregistrement confirme qu'ils exécutent un logiciel correct et sans altération.
Enregistrement. Vérifié. Confirmé avant de servir.
C'est un mot différent de permissionless.
Les uploads de modèles sont ouverts à tous. L'infrastructure qui exécute réellement ces modèles passe par un processus d'enregistrement et de vérification.
Je n'ai pas trouvé de chemin public expliquant comment un nouvel opérateur de nœud entrerait dans ce processus aujourd'hui.
La description officielle dit que les modèles fonctionnent sur un réseau permissionless de nœuds spécialisés.
Ce que décrivent les docs d'architecture est un réseau où les nœuds sont enregistrés et vérifiés, ce qui est une distinction significative par rapport à permissionless.
Je ne dis pas que le processus d'enregistrement des nœuds est fermé. Je dis que les deux mots ne signifient pas la même chose, et je n'ai pas vu quelqu'un souligner qu'OpenGradient utilise les deux pour décrire le même réseau.
Alors quand tu entends permissionless, quelle couche décris-tu réellement ?
#opg $OPG
La documentation du Model Hub est explicite. Tout le monde peut uploader un modèle. Pas de processus d'approbation, pas de contrôle, pas de demande.
Permissionless apparaît clairement dans les matériaux officiels décrivant l'hébergement de modèles.
Maintenant, lis ce que les docs d'architecture disent sur les nœuds d'inférence, la couche de calcul qui exécute réellement ces modèles.
Selon la documentation officielle actuelle, les nœuds d'inférence s'enregistrent sur le réseau et sont vérifiés avant de servir les demandes. Pour les nœuds TEE spécifiquement, l'enregistrement confirme qu'ils exécutent un logiciel correct et sans altération.
Enregistrement. Vérifié. Confirmé avant de servir.
C'est un mot différent de permissionless.
Les uploads de modèles sont ouverts à tous. L'infrastructure qui exécute réellement ces modèles passe par un processus d'enregistrement et de vérification.
Je n'ai pas trouvé de chemin public expliquant comment un nouvel opérateur de nœud entrerait dans ce processus aujourd'hui.
La description officielle dit que les modèles fonctionnent sur un réseau permissionless de nœuds spécialisés.
Ce que décrivent les docs d'architecture est un réseau où les nœuds sont enregistrés et vérifiés, ce qui est une distinction significative par rapport à permissionless.
Je ne dis pas que le processus d'enregistrement des nœuds est fermé. Je dis que les deux mots ne signifient pas la même chose, et je n'ai pas vu quelqu'un souligner qu'OpenGradient utilise les deux pour décrire le même réseau.
Alors quand tu entends permissionless, quelle couche décris-tu réellement ?
#opg $OPG
Voir la traduction
If verifiability is the whole point, the inference count should be the easiest thing to verify..?
MICHAEL MOORE
·
--
2M+ inférences vérifiables traitées.
C'est le titre. La répartition ne l'est pas.
C'est sur le site officiel, dans les documents de la Fondation, dans le communiqué de presse pré-TGE du 14 avril 2026. Même chiffre, partout.
Alors je suis allé dans la documentation réseau réelle pour comprendre ce que ce chiffre signifie.
Selon la documentation officielle des développeurs actuelle, le Testnet OpenGradient actif prend en charge x402 LLM inference, qui achemine les demandes vers des fournisseurs comme OpenAI et Anthropic à travers une couche sécurisée.
Cette partie fonctionne. Mais la même page dit clairement autre chose, l'inférence ML sur la chaîne est en développement.
C'est le type d'inférence qui exécute des modèles du Model Hub directement sur du matériel GPU. Le genre qui rend OpenGradient différent d'un simple wrapper de confidentialité autour des fournisseurs d'IA existants.
Le Testnet Alpha, qui supportait l'inférence ML complète via le système PIPE, est listé comme obsolète dans la même documentation.
Donc, quand je regarde 2M+, je ne peux pas dire ce que je regarde réellement. S'agissait-il d'appels proxy LLM acheminés par des fournisseurs existants, ou d'une véritable inférence de modèle ML sur la chaîne du Model Hub ? L'explorateur de blocs OpenGradient montre des transactions d'inférence.
Ce qu'il ne montre pas, c'est une répartition par type d'inférence ou niveau de vérification.
Le projet se qualifie de réseau d'IA vérifiable. Ce chiffre est 2M+. Mais ce que ces inférences étaient, quel niveau de vérification elles utilisaient, et sur quel réseau elles ont fonctionné n'est publié nulle part dans la documentation, l'explorateur, ou les documents de la Fondation.
Si la vérifiabilité est le but principal, le compte des inférences devrait être la chose la plus facile à vérifier.
@OpenGradient #opg $OPG
C'est le titre. La répartition ne l'est pas.
C'est sur le site officiel, dans les documents de la Fondation, dans le communiqué de presse pré-TGE du 14 avril 2026. Même chiffre, partout.
Alors je suis allé dans la documentation réseau réelle pour comprendre ce que ce chiffre signifie.
Selon la documentation officielle des développeurs actuelle, le Testnet OpenGradient actif prend en charge x402 LLM inference, qui achemine les demandes vers des fournisseurs comme OpenAI et Anthropic à travers une couche sécurisée.
Cette partie fonctionne. Mais la même page dit clairement autre chose, l'inférence ML sur la chaîne est en développement.
C'est le type d'inférence qui exécute des modèles du Model Hub directement sur du matériel GPU. Le genre qui rend OpenGradient différent d'un simple wrapper de confidentialité autour des fournisseurs d'IA existants.
Le Testnet Alpha, qui supportait l'inférence ML complète via le système PIPE, est listé comme obsolète dans la même documentation.
Donc, quand je regarde 2M+, je ne peux pas dire ce que je regarde réellement. S'agissait-il d'appels proxy LLM acheminés par des fournisseurs existants, ou d'une véritable inférence de modèle ML sur la chaîne du Model Hub ? L'explorateur de blocs OpenGradient montre des transactions d'inférence.
Ce qu'il ne montre pas, c'est une répartition par type d'inférence ou niveau de vérification.
Le projet se qualifie de réseau d'IA vérifiable. Ce chiffre est 2M+. Mais ce que ces inférences étaient, quel niveau de vérification elles utilisaient, et sur quel réseau elles ont fonctionné n'est publié nulle part dans la documentation, l'explorateur, ou les documents de la Fondation.
Si la vérifiabilité est le but principal, le compte des inférences devrait être la chose la plus facile à vérifier.
@OpenGradient #opg $OPG
............
MICHAEL MOORE
·
--
Un chiffre sur la page de tokenomics du @OpenGradient signifiait quelque chose de différent pour moi hier soir par rapport à la première fois que je l'ai vu.
Selon les tokenomics officielles de la OpenGradient Foundation, les contributeurs principaux détiennent 15 % de l'offre totale, tandis que les investisseurs et conseillers en détiennent 10 % supplémentaires.
Les deux groupes partagent la même structure, avec une période de cliff de 12 mois à partir de l'événement de génération de tokens du 21 avril 2026, suivie de 36 mois de vesting linéaire. Ce cliff se termine en avril 2027.
Au total, cela représente 250 millions de tokens, un quart de l'offre totale, actuellement en dehors de la circulation.
Voici ce que je n'avais pas relié jusqu'à ce soir.
Le même token qui est verrouillé est aussi le token de gouvernance. La page de la Fondation le dit clairement, le réseau est façonné par les personnes qui l'utilisent, et les détenteurs votent sur le matériel TEE supporté, les tarifs de gaz, l'allocation de trésorerie et les mises à jour du protocole.
Alors, je suis allé chercher un enregistrement de la façon dont cela fonctionne réellement en pratique, au moins une proposition passée, un vote, quelque chose de concret.
Je n'ai trouvé aucun enregistrement public. Cela a changé ma perspective sur le cliff d'avril 2027. Avant que 250 millions de tokens de gouvernance supplémentaires n'entrent dans le système, je n'ai pas pu trouver de document public sur la façon dont le processus actuel se maintient sous une participation réelle.
Le cliff n'est plus seulement un événement d'offre pour moi, c'est le moment où un système non prouvé rencontre son plus gros test.
Quelqu'un a-t-il déjà vu ce processus de gouvernance fonctionner, ou le premier vrai test arrive-t-il en même temps que le changement le plus important de ceux qui ont droit de vote ?
#opg $OPG
Selon les tokenomics officielles de la OpenGradient Foundation, les contributeurs principaux détiennent 15 % de l'offre totale, tandis que les investisseurs et conseillers en détiennent 10 % supplémentaires.
Les deux groupes partagent la même structure, avec une période de cliff de 12 mois à partir de l'événement de génération de tokens du 21 avril 2026, suivie de 36 mois de vesting linéaire. Ce cliff se termine en avril 2027.
Au total, cela représente 250 millions de tokens, un quart de l'offre totale, actuellement en dehors de la circulation.
Voici ce que je n'avais pas relié jusqu'à ce soir.
Le même token qui est verrouillé est aussi le token de gouvernance. La page de la Fondation le dit clairement, le réseau est façonné par les personnes qui l'utilisent, et les détenteurs votent sur le matériel TEE supporté, les tarifs de gaz, l'allocation de trésorerie et les mises à jour du protocole.
Alors, je suis allé chercher un enregistrement de la façon dont cela fonctionne réellement en pratique, au moins une proposition passée, un vote, quelque chose de concret.
Je n'ai trouvé aucun enregistrement public. Cela a changé ma perspective sur le cliff d'avril 2027. Avant que 250 millions de tokens de gouvernance supplémentaires n'entrent dans le système, je n'ai pas pu trouver de document public sur la façon dont le processus actuel se maintient sous une participation réelle.
Le cliff n'est plus seulement un événement d'offre pour moi, c'est le moment où un système non prouvé rencontre son plus gros test.
Quelqu'un a-t-il déjà vu ce processus de gouvernance fonctionner, ou le premier vrai test arrive-t-il en même temps que le changement le plus important de ceux qui ont droit de vote ?
#opg $OPG
Vérifié
2M+ inférences vérifiables traitées.
C'est le titre. La répartition ne l'est pas.
C'est sur le site officiel, dans les documents de la Fondation, dans le communiqué de presse pré-TGE du 14 avril 2026. Même chiffre, partout.
Alors je suis allé dans la documentation réseau réelle pour comprendre ce que ce chiffre signifie.
Selon la documentation officielle des développeurs actuelle, le Testnet OpenGradient actif prend en charge x402 LLM inference, qui achemine les demandes vers des fournisseurs comme OpenAI et Anthropic à travers une couche sécurisée.
Cette partie fonctionne. Mais la même page dit clairement autre chose, l'inférence ML sur la chaîne est en développement.
C'est le type d'inférence qui exécute des modèles du Model Hub directement sur du matériel GPU. Le genre qui rend OpenGradient différent d'un simple wrapper de confidentialité autour des fournisseurs d'IA existants.
Le Testnet Alpha, qui supportait l'inférence ML complète via le système PIPE, est listé comme obsolète dans la même documentation.
Donc, quand je regarde 2M+, je ne peux pas dire ce que je regarde réellement. S'agissait-il d'appels proxy LLM acheminés par des fournisseurs existants, ou d'une véritable inférence de modèle ML sur la chaîne du Model Hub ? L'explorateur de blocs OpenGradient montre des transactions d'inférence.
Ce qu'il ne montre pas, c'est une répartition par type d'inférence ou niveau de vérification.
Le projet se qualifie de réseau d'IA vérifiable. Ce chiffre est 2M+. Mais ce que ces inférences étaient, quel niveau de vérification elles utilisaient, et sur quel réseau elles ont fonctionné n'est publié nulle part dans la documentation, l'explorateur, ou les documents de la Fondation.
Si la vérifiabilité est le but principal, le compte des inférences devrait être la chose la plus facile à vérifier.
@OpenGradient #opg $OPG
C'est le titre. La répartition ne l'est pas.
C'est sur le site officiel, dans les documents de la Fondation, dans le communiqué de presse pré-TGE du 14 avril 2026. Même chiffre, partout.
Alors je suis allé dans la documentation réseau réelle pour comprendre ce que ce chiffre signifie.
Selon la documentation officielle des développeurs actuelle, le Testnet OpenGradient actif prend en charge x402 LLM inference, qui achemine les demandes vers des fournisseurs comme OpenAI et Anthropic à travers une couche sécurisée.
Cette partie fonctionne. Mais la même page dit clairement autre chose, l'inférence ML sur la chaîne est en développement.
C'est le type d'inférence qui exécute des modèles du Model Hub directement sur du matériel GPU. Le genre qui rend OpenGradient différent d'un simple wrapper de confidentialité autour des fournisseurs d'IA existants.
Le Testnet Alpha, qui supportait l'inférence ML complète via le système PIPE, est listé comme obsolète dans la même documentation.
Donc, quand je regarde 2M+, je ne peux pas dire ce que je regarde réellement. S'agissait-il d'appels proxy LLM acheminés par des fournisseurs existants, ou d'une véritable inférence de modèle ML sur la chaîne du Model Hub ? L'explorateur de blocs OpenGradient montre des transactions d'inférence.
Ce qu'il ne montre pas, c'est une répartition par type d'inférence ou niveau de vérification.
Le projet se qualifie de réseau d'IA vérifiable. Ce chiffre est 2M+. Mais ce que ces inférences étaient, quel niveau de vérification elles utilisaient, et sur quel réseau elles ont fonctionné n'est publié nulle part dans la documentation, l'explorateur, ou les documents de la Fondation.
Si la vérifiabilité est le but principal, le compte des inférences devrait être la chose la plus facile à vérifier.
@OpenGradient #opg $OPG
........
MICHAEL MOORE
·
--
Je feuilletais la mise à jour de la documentation du 12 juin @OpenGradient quand j'ai remarqué quelque chose que je ne m'attendais pas à voir. Le système de paiement avait atteint le mainnet. Le Model Hub ne l'avait pas.
La documentation pour les développeurs confirme que le flux de paiement pour l'inférence LLM se règle désormais directement sur Base, le mainnet. C'est un vrai changement par rapport à la documentation précédente, où le même flux de paiement passait par un réseau de test.
L'inférence de modèles personnalisés raconte une histoire différente. Le genre qui exécute des modèles depuis le Model Hub sans autorisation nécessite toujours de se connecter à ce que la doc appelle l'Alpha Testnet.
Selon la documentation actuelle pour les développeurs, ce réseau offre des capacités expérimentales incluant l'inférence de modèles ML personnalisés et l'orchestration de flux de travail, et ces fonctionnalités nécessitent de se connecter spécifiquement à l'Alpha Testnet.
Voici ce qui m'a marqué à propos de ce fossé.
Le pitch entier d'OpenGradient, du moins tel que je le comprends, est le Model Hub. N'importe qui peut télécharger un modèle, pas de gardiens, pas de file d'attente d'approbation, instantanément disponible pour l'inférence.
Cet hébergement de modèle sans autorisation est ce qui rend cela différent de simplement envelopper OpenAI ou Anthropic derrière une API.
Donc, ce qui règle le vrai paiement aujourd'hui, c'est la partie qui enveloppe les fournisseurs existants.
Ce qui est censé faire d'OpenGradient son propre écosystème est toujours étiqueté comme expérimental dans la même documentation.
Je ne pense pas que cela signifie que quelque chose est cassé. L'équipe a probablement construit cela de cette manière pour tester en toute sécurité les chemins d'inférence personnalisés avant le règlement sur le mainnet. C'est une séquence d'ingénierie raisonnable.
Mais voici ce que je n'ai pas encore vu quelqu'un demander.
La documentation explique comment les développeurs accèdent au Model Hub aujourd'hui. Ce que je ne trouve nulle part, c'est un calendrier pour quand l'inférence du Model Hub personnalisé passera de l'Alpha Testnet au règlement sur le mainnet.
#opg $OPG
La documentation pour les développeurs confirme que le flux de paiement pour l'inférence LLM se règle désormais directement sur Base, le mainnet. C'est un vrai changement par rapport à la documentation précédente, où le même flux de paiement passait par un réseau de test.
L'inférence de modèles personnalisés raconte une histoire différente. Le genre qui exécute des modèles depuis le Model Hub sans autorisation nécessite toujours de se connecter à ce que la doc appelle l'Alpha Testnet.
Selon la documentation actuelle pour les développeurs, ce réseau offre des capacités expérimentales incluant l'inférence de modèles ML personnalisés et l'orchestration de flux de travail, et ces fonctionnalités nécessitent de se connecter spécifiquement à l'Alpha Testnet.
Voici ce qui m'a marqué à propos de ce fossé.
Le pitch entier d'OpenGradient, du moins tel que je le comprends, est le Model Hub. N'importe qui peut télécharger un modèle, pas de gardiens, pas de file d'attente d'approbation, instantanément disponible pour l'inférence.
Cet hébergement de modèle sans autorisation est ce qui rend cela différent de simplement envelopper OpenAI ou Anthropic derrière une API.
Donc, ce qui règle le vrai paiement aujourd'hui, c'est la partie qui enveloppe les fournisseurs existants.
Ce qui est censé faire d'OpenGradient son propre écosystème est toujours étiqueté comme expérimental dans la même documentation.
Je ne pense pas que cela signifie que quelque chose est cassé. L'équipe a probablement construit cela de cette manière pour tester en toute sécurité les chemins d'inférence personnalisés avant le règlement sur le mainnet. C'est une séquence d'ingénierie raisonnable.
Mais voici ce que je n'ai pas encore vu quelqu'un demander.
La documentation explique comment les développeurs accèdent au Model Hub aujourd'hui. Ce que je ne trouve nulle part, c'est un calendrier pour quand l'inférence du Model Hub personnalisé passera de l'Alpha Testnet au règlement sur le mainnet.
#opg $OPG
Vérifié
Un chiffre sur la page de tokenomics du @OpenGradient signifiait quelque chose de différent pour moi hier soir par rapport à la première fois que je l'ai vu.
Selon les tokenomics officielles de la OpenGradient Foundation, les contributeurs principaux détiennent 15 % de l'offre totale, tandis que les investisseurs et conseillers en détiennent 10 % supplémentaires.
Les deux groupes partagent la même structure, avec une période de cliff de 12 mois à partir de l'événement de génération de tokens du 21 avril 2026, suivie de 36 mois de vesting linéaire. Ce cliff se termine en avril 2027.
Au total, cela représente 250 millions de tokens, un quart de l'offre totale, actuellement en dehors de la circulation.
Voici ce que je n'avais pas relié jusqu'à ce soir.
Le même token qui est verrouillé est aussi le token de gouvernance. La page de la Fondation le dit clairement, le réseau est façonné par les personnes qui l'utilisent, et les détenteurs votent sur le matériel TEE supporté, les tarifs de gaz, l'allocation de trésorerie et les mises à jour du protocole.
Alors, je suis allé chercher un enregistrement de la façon dont cela fonctionne réellement en pratique, au moins une proposition passée, un vote, quelque chose de concret.
Je n'ai trouvé aucun enregistrement public. Cela a changé ma perspective sur le cliff d'avril 2027. Avant que 250 millions de tokens de gouvernance supplémentaires n'entrent dans le système, je n'ai pas pu trouver de document public sur la façon dont le processus actuel se maintient sous une participation réelle.
Le cliff n'est plus seulement un événement d'offre pour moi, c'est le moment où un système non prouvé rencontre son plus gros test.
Quelqu'un a-t-il déjà vu ce processus de gouvernance fonctionner, ou le premier vrai test arrive-t-il en même temps que le changement le plus important de ceux qui ont droit de vote ?
#opg $OPG
Selon les tokenomics officielles de la OpenGradient Foundation, les contributeurs principaux détiennent 15 % de l'offre totale, tandis que les investisseurs et conseillers en détiennent 10 % supplémentaires.
Les deux groupes partagent la même structure, avec une période de cliff de 12 mois à partir de l'événement de génération de tokens du 21 avril 2026, suivie de 36 mois de vesting linéaire. Ce cliff se termine en avril 2027.
Au total, cela représente 250 millions de tokens, un quart de l'offre totale, actuellement en dehors de la circulation.
Voici ce que je n'avais pas relié jusqu'à ce soir.
Le même token qui est verrouillé est aussi le token de gouvernance. La page de la Fondation le dit clairement, le réseau est façonné par les personnes qui l'utilisent, et les détenteurs votent sur le matériel TEE supporté, les tarifs de gaz, l'allocation de trésorerie et les mises à jour du protocole.
Alors, je suis allé chercher un enregistrement de la façon dont cela fonctionne réellement en pratique, au moins une proposition passée, un vote, quelque chose de concret.
Je n'ai trouvé aucun enregistrement public. Cela a changé ma perspective sur le cliff d'avril 2027. Avant que 250 millions de tokens de gouvernance supplémentaires n'entrent dans le système, je n'ai pas pu trouver de document public sur la façon dont le processus actuel se maintient sous une participation réelle.
Le cliff n'est plus seulement un événement d'offre pour moi, c'est le moment où un système non prouvé rencontre son plus gros test.
Quelqu'un a-t-il déjà vu ce processus de gouvernance fonctionner, ou le premier vrai test arrive-t-il en même temps que le changement le plus important de ceux qui ont droit de vote ?
#opg $OPG
MAINNET
ou Toujours
ALPHA .........
ou Toujours
ALPHA .........
MICHAEL MOORE
·
--
Je feuilletais la mise à jour de la documentation du 12 juin @OpenGradient quand j'ai remarqué quelque chose que je ne m'attendais pas à voir. Le système de paiement avait atteint le mainnet. Le Model Hub ne l'avait pas.
La documentation pour les développeurs confirme que le flux de paiement pour l'inférence LLM se règle désormais directement sur Base, le mainnet. C'est un vrai changement par rapport à la documentation précédente, où le même flux de paiement passait par un réseau de test.
L'inférence de modèles personnalisés raconte une histoire différente. Le genre qui exécute des modèles depuis le Model Hub sans autorisation nécessite toujours de se connecter à ce que la doc appelle l'Alpha Testnet.
Selon la documentation actuelle pour les développeurs, ce réseau offre des capacités expérimentales incluant l'inférence de modèles ML personnalisés et l'orchestration de flux de travail, et ces fonctionnalités nécessitent de se connecter spécifiquement à l'Alpha Testnet.
Voici ce qui m'a marqué à propos de ce fossé.
Le pitch entier d'OpenGradient, du moins tel que je le comprends, est le Model Hub. N'importe qui peut télécharger un modèle, pas de gardiens, pas de file d'attente d'approbation, instantanément disponible pour l'inférence.
Cet hébergement de modèle sans autorisation est ce qui rend cela différent de simplement envelopper OpenAI ou Anthropic derrière une API.
Donc, ce qui règle le vrai paiement aujourd'hui, c'est la partie qui enveloppe les fournisseurs existants.
Ce qui est censé faire d'OpenGradient son propre écosystème est toujours étiqueté comme expérimental dans la même documentation.
Je ne pense pas que cela signifie que quelque chose est cassé. L'équipe a probablement construit cela de cette manière pour tester en toute sécurité les chemins d'inférence personnalisés avant le règlement sur le mainnet. C'est une séquence d'ingénierie raisonnable.
Mais voici ce que je n'ai pas encore vu quelqu'un demander.
La documentation explique comment les développeurs accèdent au Model Hub aujourd'hui. Ce que je ne trouve nulle part, c'est un calendrier pour quand l'inférence du Model Hub personnalisé passera de l'Alpha Testnet au règlement sur le mainnet.
#opg $OPG
La documentation pour les développeurs confirme que le flux de paiement pour l'inférence LLM se règle désormais directement sur Base, le mainnet. C'est un vrai changement par rapport à la documentation précédente, où le même flux de paiement passait par un réseau de test.
L'inférence de modèles personnalisés raconte une histoire différente. Le genre qui exécute des modèles depuis le Model Hub sans autorisation nécessite toujours de se connecter à ce que la doc appelle l'Alpha Testnet.
Selon la documentation actuelle pour les développeurs, ce réseau offre des capacités expérimentales incluant l'inférence de modèles ML personnalisés et l'orchestration de flux de travail, et ces fonctionnalités nécessitent de se connecter spécifiquement à l'Alpha Testnet.
Voici ce qui m'a marqué à propos de ce fossé.
Le pitch entier d'OpenGradient, du moins tel que je le comprends, est le Model Hub. N'importe qui peut télécharger un modèle, pas de gardiens, pas de file d'attente d'approbation, instantanément disponible pour l'inférence.
Cet hébergement de modèle sans autorisation est ce qui rend cela différent de simplement envelopper OpenAI ou Anthropic derrière une API.
Donc, ce qui règle le vrai paiement aujourd'hui, c'est la partie qui enveloppe les fournisseurs existants.
Ce qui est censé faire d'OpenGradient son propre écosystème est toujours étiqueté comme expérimental dans la même documentation.
Je ne pense pas que cela signifie que quelque chose est cassé. L'équipe a probablement construit cela de cette manière pour tester en toute sécurité les chemins d'inférence personnalisés avant le règlement sur le mainnet. C'est une séquence d'ingénierie raisonnable.
Mais voici ce que je n'ai pas encore vu quelqu'un demander.
La documentation explique comment les développeurs accèdent au Model Hub aujourd'hui. Ce que je ne trouve nulle part, c'est un calendrier pour quand l'inférence du Model Hub personnalisé passera de l'Alpha Testnet au règlement sur le mainnet.
#opg $OPG
Vérifié ou juste étiqueté ..?
MICHAEL MOORE
·
--
Je parcourais la documentation des développeurs d'OpenGradient et une ligne m'a vraiment arrêté.
Selon la documentation officielle des développeurs de juin 2026, le mode de vérification est défini sur Vanilla, à moins qu'un développeur ne le change activement.
Les docs d'architecture définissent cela comme une vérification de signature uniquement, sans preuve d'exécution correcte. TEE et ZKML existent comme options. Vanilla est simplement ce qui s'exécute si rien n'est sélectionné.
Les docs expliquent pourquoi et ils sont honnêtes à ce sujet. ZKML ajoute 1000x à 10000x de surcharge computationnelle, complètement impraticable pour des modèles volumineux. TEE couvre la plupart des scénarios de production. Le spectre existe pour une raison technique légitime et je comprends cela.
Ce que je ne trouve nulle part, c'est ce que les développeurs choisissent réellement.
La Fondation OpenGradient a rapporté plus de 2M d'inférences traitées en avril 2026.
Il n'existe aucune répartition publique sur combien ont exécuté TEE, combien ont exécuté ZKML, et combien ont fonctionné sur Vanilla sans preuve vérifiable d'exécution correcte.
Cette répartition est le seul chiffre qui me dirait ce que ce réseau est réellement en pratique, pas ce que les docs officiels disent qu'il peut être.
Le choix de conception a du sens technique pour moi, le compromis est réel.
Que l'utilisation derrière cela corresponde à la marque est une question à laquelle je n'ai pas vu OpenGradient répondre publiquement, et c'est celle à laquelle je reviens sans cesse.
@OpenGradient #opg $OPG
Selon la documentation officielle des développeurs de juin 2026, le mode de vérification est défini sur Vanilla, à moins qu'un développeur ne le change activement.
Les docs d'architecture définissent cela comme une vérification de signature uniquement, sans preuve d'exécution correcte. TEE et ZKML existent comme options. Vanilla est simplement ce qui s'exécute si rien n'est sélectionné.
Les docs expliquent pourquoi et ils sont honnêtes à ce sujet. ZKML ajoute 1000x à 10000x de surcharge computationnelle, complètement impraticable pour des modèles volumineux. TEE couvre la plupart des scénarios de production. Le spectre existe pour une raison technique légitime et je comprends cela.
Ce que je ne trouve nulle part, c'est ce que les développeurs choisissent réellement.
La Fondation OpenGradient a rapporté plus de 2M d'inférences traitées en avril 2026.
Il n'existe aucune répartition publique sur combien ont exécuté TEE, combien ont exécuté ZKML, et combien ont fonctionné sur Vanilla sans preuve vérifiable d'exécution correcte.
Cette répartition est le seul chiffre qui me dirait ce que ce réseau est réellement en pratique, pas ce que les docs officiels disent qu'il peut être.
Le choix de conception a du sens technique pour moi, le compromis est réel.
Que l'utilisation derrière cela corresponde à la marque est une question à laquelle je n'ai pas vu OpenGradient répondre publiquement, et c'est celle à laquelle je reviens sans cesse.
@OpenGradient #opg $OPG
Vérifié
Je feuilletais la mise à jour de la documentation du 12 juin @OpenGradient quand j'ai remarqué quelque chose que je ne m'attendais pas à voir. Le système de paiement avait atteint le mainnet. Le Model Hub ne l'avait pas.
La documentation pour les développeurs confirme que le flux de paiement pour l'inférence LLM se règle désormais directement sur Base, le mainnet. C'est un vrai changement par rapport à la documentation précédente, où le même flux de paiement passait par un réseau de test.
L'inférence de modèles personnalisés raconte une histoire différente. Le genre qui exécute des modèles depuis le Model Hub sans autorisation nécessite toujours de se connecter à ce que la doc appelle l'Alpha Testnet.
Selon la documentation actuelle pour les développeurs, ce réseau offre des capacités expérimentales incluant l'inférence de modèles ML personnalisés et l'orchestration de flux de travail, et ces fonctionnalités nécessitent de se connecter spécifiquement à l'Alpha Testnet.
Voici ce qui m'a marqué à propos de ce fossé.
Le pitch entier d'OpenGradient, du moins tel que je le comprends, est le Model Hub. N'importe qui peut télécharger un modèle, pas de gardiens, pas de file d'attente d'approbation, instantanément disponible pour l'inférence.
Cet hébergement de modèle sans autorisation est ce qui rend cela différent de simplement envelopper OpenAI ou Anthropic derrière une API.
Donc, ce qui règle le vrai paiement aujourd'hui, c'est la partie qui enveloppe les fournisseurs existants.
Ce qui est censé faire d'OpenGradient son propre écosystème est toujours étiqueté comme expérimental dans la même documentation.
Je ne pense pas que cela signifie que quelque chose est cassé. L'équipe a probablement construit cela de cette manière pour tester en toute sécurité les chemins d'inférence personnalisés avant le règlement sur le mainnet. C'est une séquence d'ingénierie raisonnable.
Mais voici ce que je n'ai pas encore vu quelqu'un demander.
La documentation explique comment les développeurs accèdent au Model Hub aujourd'hui. Ce que je ne trouve nulle part, c'est un calendrier pour quand l'inférence du Model Hub personnalisé passera de l'Alpha Testnet au règlement sur le mainnet.
#opg $OPG
La documentation pour les développeurs confirme que le flux de paiement pour l'inférence LLM se règle désormais directement sur Base, le mainnet. C'est un vrai changement par rapport à la documentation précédente, où le même flux de paiement passait par un réseau de test.
L'inférence de modèles personnalisés raconte une histoire différente. Le genre qui exécute des modèles depuis le Model Hub sans autorisation nécessite toujours de se connecter à ce que la doc appelle l'Alpha Testnet.
Selon la documentation actuelle pour les développeurs, ce réseau offre des capacités expérimentales incluant l'inférence de modèles ML personnalisés et l'orchestration de flux de travail, et ces fonctionnalités nécessitent de se connecter spécifiquement à l'Alpha Testnet.
Voici ce qui m'a marqué à propos de ce fossé.
Le pitch entier d'OpenGradient, du moins tel que je le comprends, est le Model Hub. N'importe qui peut télécharger un modèle, pas de gardiens, pas de file d'attente d'approbation, instantanément disponible pour l'inférence.
Cet hébergement de modèle sans autorisation est ce qui rend cela différent de simplement envelopper OpenAI ou Anthropic derrière une API.
Donc, ce qui règle le vrai paiement aujourd'hui, c'est la partie qui enveloppe les fournisseurs existants.
Ce qui est censé faire d'OpenGradient son propre écosystème est toujours étiqueté comme expérimental dans la même documentation.
Je ne pense pas que cela signifie que quelque chose est cassé. L'équipe a probablement construit cela de cette manière pour tester en toute sécurité les chemins d'inférence personnalisés avant le règlement sur le mainnet. C'est une séquence d'ingénierie raisonnable.
Mais voici ce que je n'ai pas encore vu quelqu'un demander.
La documentation explique comment les développeurs accèdent au Model Hub aujourd'hui. Ce que je ne trouve nulle part, c'est un calendrier pour quand l'inférence du Model Hub personnalisé passera de l'Alpha Testnet au règlement sur le mainnet.
#opg $OPG
...............
MICHAEL MOORE
·
--
Je parcourais la documentation des développeurs d'OpenGradient et une ligne m'a vraiment arrêté.
Selon la documentation officielle des développeurs de juin 2026, le mode de vérification est défini sur Vanilla, à moins qu'un développeur ne le change activement.
Les docs d'architecture définissent cela comme une vérification de signature uniquement, sans preuve d'exécution correcte. TEE et ZKML existent comme options. Vanilla est simplement ce qui s'exécute si rien n'est sélectionné.
Les docs expliquent pourquoi et ils sont honnêtes à ce sujet. ZKML ajoute 1000x à 10000x de surcharge computationnelle, complètement impraticable pour des modèles volumineux. TEE couvre la plupart des scénarios de production. Le spectre existe pour une raison technique légitime et je comprends cela.
Ce que je ne trouve nulle part, c'est ce que les développeurs choisissent réellement.
La Fondation OpenGradient a rapporté plus de 2M d'inférences traitées en avril 2026.
Il n'existe aucune répartition publique sur combien ont exécuté TEE, combien ont exécuté ZKML, et combien ont fonctionné sur Vanilla sans preuve vérifiable d'exécution correcte.
Cette répartition est le seul chiffre qui me dirait ce que ce réseau est réellement en pratique, pas ce que les docs officiels disent qu'il peut être.
Le choix de conception a du sens technique pour moi, le compromis est réel.
Que l'utilisation derrière cela corresponde à la marque est une question à laquelle je n'ai pas vu OpenGradient répondre publiquement, et c'est celle à laquelle je reviens sans cesse.
@OpenGradient #opg $OPG
Selon la documentation officielle des développeurs de juin 2026, le mode de vérification est défini sur Vanilla, à moins qu'un développeur ne le change activement.
Les docs d'architecture définissent cela comme une vérification de signature uniquement, sans preuve d'exécution correcte. TEE et ZKML existent comme options. Vanilla est simplement ce qui s'exécute si rien n'est sélectionné.
Les docs expliquent pourquoi et ils sont honnêtes à ce sujet. ZKML ajoute 1000x à 10000x de surcharge computationnelle, complètement impraticable pour des modèles volumineux. TEE couvre la plupart des scénarios de production. Le spectre existe pour une raison technique légitime et je comprends cela.
Ce que je ne trouve nulle part, c'est ce que les développeurs choisissent réellement.
La Fondation OpenGradient a rapporté plus de 2M d'inférences traitées en avril 2026.
Il n'existe aucune répartition publique sur combien ont exécuté TEE, combien ont exécuté ZKML, et combien ont fonctionné sur Vanilla sans preuve vérifiable d'exécution correcte.
Cette répartition est le seul chiffre qui me dirait ce que ce réseau est réellement en pratique, pas ce que les docs officiels disent qu'il peut être.
Le choix de conception a du sens technique pour moi, le compromis est réel.
Que l'utilisation derrière cela corresponde à la marque est une question à laquelle je n'ai pas vu OpenGradient répondre publiquement, et c'est celle à laquelle je reviens sans cesse.
@OpenGradient #opg $OPG
..........
MICHAEL MOORE
·
--
Je cherchais une info dans la doc brBTC de Bedrock hier soir. J'ai trouvé tout autre chose.
La page qui présente brBTC, le produit phare BTCFi 2.0 de Bedrock, a un avis en haut. Ça dit que la page est encore en développement.
Un peu plus bas, dans la section qui décrit comment le collatéral des utilisateurs est réparti sur sept protocoles de restaking, Babylon, Kernel, Pell, Satlayer, Symbiotic, Mellow, et Bedrock lui-même, la doc dit que les ratios d'allocation sont à confirmer.
Cette combinaison ne m’a pas paru bonne.
brBTC est commercialisé comme une allocation dynamique intelligente.
La propre page produit de Bedrock l'appelle "stratégies d'allocation d'actifs intelligentes et dynamiques" qui offrent des rendements supérieurs. C'est ce que le produit est censé faire.
Mais la documentation qui décrit comment ce routage fonctionne réellement dit que les ratios sont encore à confirmer.
J'ai aussi vérifié l'appli.
La répartition des allocations n'est pas visible là non plus.
En fait, ce n’est même pas la question la plus profonde.
Les ratios sont une chose. Ce à quoi je revenais sans cesse est autre.
Qui décide quand l'allocation change ? Y a-t-il un cadre publié pour ces décisions, ou les critères sont-ils actuellement non documentés dans les matériaux publics ?
Je n'ai trouvé cette réponse nulle part dans la doc officielle ou l'appli.
Les détenteurs de brBTC ne font pas que faire confiance à la sécurité de Bedrock. Ils font confiance à son jugement sur les décisions d'allocation qui se produisent après le dépôt, sans avis de l'utilisateur, sous des règles qui ne sont pas définies publiquement.
Le produit est documenté. Les destinations sont documentées. Le processus décisionnel qui relie les deux ne l'est pas.
@Bedrock #bedrock $BR
La page qui présente brBTC, le produit phare BTCFi 2.0 de Bedrock, a un avis en haut. Ça dit que la page est encore en développement.
Un peu plus bas, dans la section qui décrit comment le collatéral des utilisateurs est réparti sur sept protocoles de restaking, Babylon, Kernel, Pell, Satlayer, Symbiotic, Mellow, et Bedrock lui-même, la doc dit que les ratios d'allocation sont à confirmer.
Cette combinaison ne m’a pas paru bonne.
brBTC est commercialisé comme une allocation dynamique intelligente.
La propre page produit de Bedrock l'appelle "stratégies d'allocation d'actifs intelligentes et dynamiques" qui offrent des rendements supérieurs. C'est ce que le produit est censé faire.
Mais la documentation qui décrit comment ce routage fonctionne réellement dit que les ratios sont encore à confirmer.
J'ai aussi vérifié l'appli.
La répartition des allocations n'est pas visible là non plus.
En fait, ce n’est même pas la question la plus profonde.
Les ratios sont une chose. Ce à quoi je revenais sans cesse est autre.
Qui décide quand l'allocation change ? Y a-t-il un cadre publié pour ces décisions, ou les critères sont-ils actuellement non documentés dans les matériaux publics ?
Je n'ai trouvé cette réponse nulle part dans la doc officielle ou l'appli.
Les détenteurs de brBTC ne font pas que faire confiance à la sécurité de Bedrock. Ils font confiance à son jugement sur les décisions d'allocation qui se produisent après le dépôt, sans avis de l'utilisateur, sous des règles qui ne sont pas définies publiquement.
Le produit est documenté. Les destinations sont documentées. Le processus décisionnel qui relie les deux ne l'est pas.
@Bedrock #bedrock $BR
Je parcourais la documentation des développeurs d'OpenGradient et une ligne m'a vraiment arrêté.
Selon la documentation officielle des développeurs de juin 2026, le mode de vérification est défini sur Vanilla, à moins qu'un développeur ne le change activement.
Les docs d'architecture définissent cela comme une vérification de signature uniquement, sans preuve d'exécution correcte. TEE et ZKML existent comme options. Vanilla est simplement ce qui s'exécute si rien n'est sélectionné.
Les docs expliquent pourquoi et ils sont honnêtes à ce sujet. ZKML ajoute 1000x à 10000x de surcharge computationnelle, complètement impraticable pour des modèles volumineux. TEE couvre la plupart des scénarios de production. Le spectre existe pour une raison technique légitime et je comprends cela.
Ce que je ne trouve nulle part, c'est ce que les développeurs choisissent réellement.
La Fondation OpenGradient a rapporté plus de 2M d'inférences traitées en avril 2026.
Il n'existe aucune répartition publique sur combien ont exécuté TEE, combien ont exécuté ZKML, et combien ont fonctionné sur Vanilla sans preuve vérifiable d'exécution correcte.
Cette répartition est le seul chiffre qui me dirait ce que ce réseau est réellement en pratique, pas ce que les docs officiels disent qu'il peut être.
Le choix de conception a du sens technique pour moi, le compromis est réel.
Que l'utilisation derrière cela corresponde à la marque est une question à laquelle je n'ai pas vu OpenGradient répondre publiquement, et c'est celle à laquelle je reviens sans cesse.
@OpenGradient #opg $OPG
Selon la documentation officielle des développeurs de juin 2026, le mode de vérification est défini sur Vanilla, à moins qu'un développeur ne le change activement.
Les docs d'architecture définissent cela comme une vérification de signature uniquement, sans preuve d'exécution correcte. TEE et ZKML existent comme options. Vanilla est simplement ce qui s'exécute si rien n'est sélectionné.
Les docs expliquent pourquoi et ils sont honnêtes à ce sujet. ZKML ajoute 1000x à 10000x de surcharge computationnelle, complètement impraticable pour des modèles volumineux. TEE couvre la plupart des scénarios de production. Le spectre existe pour une raison technique légitime et je comprends cela.
Ce que je ne trouve nulle part, c'est ce que les développeurs choisissent réellement.
La Fondation OpenGradient a rapporté plus de 2M d'inférences traitées en avril 2026.
Il n'existe aucune répartition publique sur combien ont exécuté TEE, combien ont exécuté ZKML, et combien ont fonctionné sur Vanilla sans preuve vérifiable d'exécution correcte.
Cette répartition est le seul chiffre qui me dirait ce que ce réseau est réellement en pratique, pas ce que les docs officiels disent qu'il peut être.
Le choix de conception a du sens technique pour moi, le compromis est réel.
Que l'utilisation derrière cela corresponde à la marque est une question à laquelle je n'ai pas vu OpenGradient répondre publiquement, et c'est celle à laquelle je reviens sans cesse.
@OpenGradient #opg $OPG
............ ..
MICHAEL MOORE
·
--
Je cherchais une info dans la doc brBTC de Bedrock hier soir. J'ai trouvé tout autre chose.
La page qui présente brBTC, le produit phare BTCFi 2.0 de Bedrock, a un avis en haut. Ça dit que la page est encore en développement.
Un peu plus bas, dans la section qui décrit comment le collatéral des utilisateurs est réparti sur sept protocoles de restaking, Babylon, Kernel, Pell, Satlayer, Symbiotic, Mellow, et Bedrock lui-même, la doc dit que les ratios d'allocation sont à confirmer.
Cette combinaison ne m’a pas paru bonne.
brBTC est commercialisé comme une allocation dynamique intelligente.
La propre page produit de Bedrock l'appelle "stratégies d'allocation d'actifs intelligentes et dynamiques" qui offrent des rendements supérieurs. C'est ce que le produit est censé faire.
Mais la documentation qui décrit comment ce routage fonctionne réellement dit que les ratios sont encore à confirmer.
J'ai aussi vérifié l'appli.
La répartition des allocations n'est pas visible là non plus.
En fait, ce n’est même pas la question la plus profonde.
Les ratios sont une chose. Ce à quoi je revenais sans cesse est autre.
Qui décide quand l'allocation change ? Y a-t-il un cadre publié pour ces décisions, ou les critères sont-ils actuellement non documentés dans les matériaux publics ?
Je n'ai trouvé cette réponse nulle part dans la doc officielle ou l'appli.
Les détenteurs de brBTC ne font pas que faire confiance à la sécurité de Bedrock. Ils font confiance à son jugement sur les décisions d'allocation qui se produisent après le dépôt, sans avis de l'utilisateur, sous des règles qui ne sont pas définies publiquement.
Le produit est documenté. Les destinations sont documentées. Le processus décisionnel qui relie les deux ne l'est pas.
@Bedrock #bedrock $BR
La page qui présente brBTC, le produit phare BTCFi 2.0 de Bedrock, a un avis en haut. Ça dit que la page est encore en développement.
Un peu plus bas, dans la section qui décrit comment le collatéral des utilisateurs est réparti sur sept protocoles de restaking, Babylon, Kernel, Pell, Satlayer, Symbiotic, Mellow, et Bedrock lui-même, la doc dit que les ratios d'allocation sont à confirmer.
Cette combinaison ne m’a pas paru bonne.
brBTC est commercialisé comme une allocation dynamique intelligente.
La propre page produit de Bedrock l'appelle "stratégies d'allocation d'actifs intelligentes et dynamiques" qui offrent des rendements supérieurs. C'est ce que le produit est censé faire.
Mais la documentation qui décrit comment ce routage fonctionne réellement dit que les ratios sont encore à confirmer.
J'ai aussi vérifié l'appli.
La répartition des allocations n'est pas visible là non plus.
En fait, ce n’est même pas la question la plus profonde.
Les ratios sont une chose. Ce à quoi je revenais sans cesse est autre.
Qui décide quand l'allocation change ? Y a-t-il un cadre publié pour ces décisions, ou les critères sont-ils actuellement non documentés dans les matériaux publics ?
Je n'ai trouvé cette réponse nulle part dans la doc officielle ou l'appli.
Les détenteurs de brBTC ne font pas que faire confiance à la sécurité de Bedrock. Ils font confiance à son jugement sur les décisions d'allocation qui se produisent après le dépôt, sans avis de l'utilisateur, sous des règles qui ne sont pas définies publiquement.
Le produit est documenté. Les destinations sont documentées. Le processus décisionnel qui relie les deux ne l'est pas.
@Bedrock #bedrock $BR
$BR ..........
MICHAEL MOORE
·
--
Le 25 mai, Bedrock a annoncé un changement majeur de direction. Nouveau nom. Nouvelles vaults. Un outil d'IA appelé BRclaw.
J'ai parcouru ça hier soir et la plupart des éléments semblaient établis, comme des décisions déjà prises quelque part et simplement mises par écrit.
Quatre types de vaults avec des descriptions spécifiques. Un système de routage.
BRclaw expliqué comme un analyste IA pour le capital Bitcoin. Tout cela avait du poids.
Puis je suis arrivé à la section BR.
Accès prioritaire aux vaults. Rendement différencié. Fonctionnalités BRclaw plus approfondies pour les détenteurs. Puis je suis tombé sur cette phrase, directement tirée du post.
"Les mécaniques sont encore en cours de perfectionnement. Plus de détails à venir bientôt."
J'ai pris un moment pour réfléchir à cela.
Tout le reste avait une forme. Les vaults avaient des noms. BRclaw avait une description. Le rôle de BR dans tout cela ne l'avait pas.
Peut-être que c'est comme ça que ça fonctionne. Direction d'abord, mécaniques ensuite.
Mais en ce moment, quiconque détient du BR possède un token dont le nouveau rôle a été décrit en concept le 25 mai, sans rien de finalisé dans ce même post.
Les vaults arrivent dans quelques semaines. Le rôle de BR ne l'est pas. Cet écart vaut la peine d'être observé.
@Bedrock #bedrock $BR
J'ai parcouru ça hier soir et la plupart des éléments semblaient établis, comme des décisions déjà prises quelque part et simplement mises par écrit.
Quatre types de vaults avec des descriptions spécifiques. Un système de routage.
BRclaw expliqué comme un analyste IA pour le capital Bitcoin. Tout cela avait du poids.
Puis je suis arrivé à la section BR.
Accès prioritaire aux vaults. Rendement différencié. Fonctionnalités BRclaw plus approfondies pour les détenteurs. Puis je suis tombé sur cette phrase, directement tirée du post.
"Les mécaniques sont encore en cours de perfectionnement. Plus de détails à venir bientôt."
J'ai pris un moment pour réfléchir à cela.
Tout le reste avait une forme. Les vaults avaient des noms. BRclaw avait une description. Le rôle de BR dans tout cela ne l'avait pas.
Peut-être que c'est comme ça que ça fonctionne. Direction d'abord, mécaniques ensuite.
Mais en ce moment, quiconque détient du BR possède un token dont le nouveau rôle a été décrit en concept le 25 mai, sans rien de finalisé dans ce même post.
Les vaults arrivent dans quelques semaines. Le rôle de BR ne l'est pas. Cet écart vaut la peine d'être observé.
@Bedrock #bedrock $BR
Vérifié
Je cherchais une info dans la doc brBTC de Bedrock hier soir. J'ai trouvé tout autre chose.
La page qui présente brBTC, le produit phare BTCFi 2.0 de Bedrock, a un avis en haut. Ça dit que la page est encore en développement.
Un peu plus bas, dans la section qui décrit comment le collatéral des utilisateurs est réparti sur sept protocoles de restaking, Babylon, Kernel, Pell, Satlayer, Symbiotic, Mellow, et Bedrock lui-même, la doc dit que les ratios d'allocation sont à confirmer.
Cette combinaison ne m’a pas paru bonne.
brBTC est commercialisé comme une allocation dynamique intelligente.
La propre page produit de Bedrock l'appelle "stratégies d'allocation d'actifs intelligentes et dynamiques" qui offrent des rendements supérieurs. C'est ce que le produit est censé faire.
Mais la documentation qui décrit comment ce routage fonctionne réellement dit que les ratios sont encore à confirmer.
J'ai aussi vérifié l'appli.
La répartition des allocations n'est pas visible là non plus.
En fait, ce n’est même pas la question la plus profonde.
Les ratios sont une chose. Ce à quoi je revenais sans cesse est autre.
Qui décide quand l'allocation change ? Y a-t-il un cadre publié pour ces décisions, ou les critères sont-ils actuellement non documentés dans les matériaux publics ?
Je n'ai trouvé cette réponse nulle part dans la doc officielle ou l'appli.
Les détenteurs de brBTC ne font pas que faire confiance à la sécurité de Bedrock. Ils font confiance à son jugement sur les décisions d'allocation qui se produisent après le dépôt, sans avis de l'utilisateur, sous des règles qui ne sont pas définies publiquement.
Le produit est documenté. Les destinations sont documentées. Le processus décisionnel qui relie les deux ne l'est pas.
@Bedrock #bedrock $BR
La page qui présente brBTC, le produit phare BTCFi 2.0 de Bedrock, a un avis en haut. Ça dit que la page est encore en développement.
Un peu plus bas, dans la section qui décrit comment le collatéral des utilisateurs est réparti sur sept protocoles de restaking, Babylon, Kernel, Pell, Satlayer, Symbiotic, Mellow, et Bedrock lui-même, la doc dit que les ratios d'allocation sont à confirmer.
Cette combinaison ne m’a pas paru bonne.
brBTC est commercialisé comme une allocation dynamique intelligente.
La propre page produit de Bedrock l'appelle "stratégies d'allocation d'actifs intelligentes et dynamiques" qui offrent des rendements supérieurs. C'est ce que le produit est censé faire.
Mais la documentation qui décrit comment ce routage fonctionne réellement dit que les ratios sont encore à confirmer.
J'ai aussi vérifié l'appli.
La répartition des allocations n'est pas visible là non plus.
En fait, ce n’est même pas la question la plus profonde.
Les ratios sont une chose. Ce à quoi je revenais sans cesse est autre.
Qui décide quand l'allocation change ? Y a-t-il un cadre publié pour ces décisions, ou les critères sont-ils actuellement non documentés dans les matériaux publics ?
Je n'ai trouvé cette réponse nulle part dans la doc officielle ou l'appli.
Les détenteurs de brBTC ne font pas que faire confiance à la sécurité de Bedrock. Ils font confiance à son jugement sur les décisions d'allocation qui se produisent après le dépôt, sans avis de l'utilisateur, sous des règles qui ne sont pas définies publiquement.
Le produit est documenté. Les destinations sont documentées. Le processus décisionnel qui relie les deux ne l'est pas.
@Bedrock #bedrock $BR
...............
MICHAEL MOORE
·
--
Le 25 mai, Bedrock a annoncé un changement majeur de direction. Nouveau nom. Nouvelles vaults. Un outil d'IA appelé BRclaw.
J'ai parcouru ça hier soir et la plupart des éléments semblaient établis, comme des décisions déjà prises quelque part et simplement mises par écrit.
Quatre types de vaults avec des descriptions spécifiques. Un système de routage.
BRclaw expliqué comme un analyste IA pour le capital Bitcoin. Tout cela avait du poids.
Puis je suis arrivé à la section BR.
Accès prioritaire aux vaults. Rendement différencié. Fonctionnalités BRclaw plus approfondies pour les détenteurs. Puis je suis tombé sur cette phrase, directement tirée du post.
"Les mécaniques sont encore en cours de perfectionnement. Plus de détails à venir bientôt."
J'ai pris un moment pour réfléchir à cela.
Tout le reste avait une forme. Les vaults avaient des noms. BRclaw avait une description. Le rôle de BR dans tout cela ne l'avait pas.
Peut-être que c'est comme ça que ça fonctionne. Direction d'abord, mécaniques ensuite.
Mais en ce moment, quiconque détient du BR possède un token dont le nouveau rôle a été décrit en concept le 25 mai, sans rien de finalisé dans ce même post.
Les vaults arrivent dans quelques semaines. Le rôle de BR ne l'est pas. Cet écart vaut la peine d'être observé.
@Bedrock #bedrock $BR
J'ai parcouru ça hier soir et la plupart des éléments semblaient établis, comme des décisions déjà prises quelque part et simplement mises par écrit.
Quatre types de vaults avec des descriptions spécifiques. Un système de routage.
BRclaw expliqué comme un analyste IA pour le capital Bitcoin. Tout cela avait du poids.
Puis je suis arrivé à la section BR.
Accès prioritaire aux vaults. Rendement différencié. Fonctionnalités BRclaw plus approfondies pour les détenteurs. Puis je suis tombé sur cette phrase, directement tirée du post.
"Les mécaniques sont encore en cours de perfectionnement. Plus de détails à venir bientôt."
J'ai pris un moment pour réfléchir à cela.
Tout le reste avait une forme. Les vaults avaient des noms. BRclaw avait une description. Le rôle de BR dans tout cela ne l'avait pas.
Peut-être que c'est comme ça que ça fonctionne. Direction d'abord, mécaniques ensuite.
Mais en ce moment, quiconque détient du BR possède un token dont le nouveau rôle a été décrit en concept le 25 mai, sans rien de finalisé dans ce même post.
Les vaults arrivent dans quelques semaines. Le rôle de BR ne l'est pas. Cet écart vaut la peine d'être observé.
@Bedrock #bedrock $BR
La capitalisation du marché de uniBTC a augmenté.
La mise à jour du nombre de détenteurs n'a pas suivi. Ce fossé est toujours ouvert.
La mise à jour du nombre de détenteurs n'a pas suivi. Ce fossé est toujours ouvert.
MICHAEL MOORE
·
--
J'ai ouvert la page Etherscan de uniBTC à la recherche de quelque chose de précis, et j'ai trouvé deux chiffres de dates différentes qui ne s'alignent pas vraiment.
Selon Etherscan, au 6 mars 2026, uniBTC avait une capitalisation boursière on-chain de 129 133 516,67 $ répartie sur 938 détenteurs.
J'ai pris un moment pour réfléchir à ce ratio.
En fait, en divisant l'un par l'autre, cela donne environ 137 000 $ dans le portefeuille moyen d'un détenteur, d'après mes propres calculs approximatifs. Pour un token phare de liquidité de restaking commercialisé comme accessible à tout détenteur de BTC, cette moyenne est élevée.
Voici ce qui rend cela plus pertinent aujourd'hui.
Selon les données de CoinGecko de juin 2026, la capitalisation boursière de uniBTC a augmenté pour atteindre environ 200 à 260 millions de dollars, en forte hausse par rapport à ce chiffre de mars, avec un prix en hausse d'environ 10 à 19 % au cours de la semaine dernière.
La capitalisation boursière a presque doublé en trois mois.
Ce que je n'ai pas pu trouver nulle part, c'est un compte de détenteurs mis à jour pour accompagner cette croissance.
Peut-être que le nombre de détenteurs a augmenté au même rythme, et l'image reste équilibrée. Ou bien le même petit groupe est juste devenu plus riche pendant que le chiffre principal avait l'air brillant.
Je ne sais vraiment pas lequel c'est.
Bedrock n'a rien dit à ce sujet.
Si quelqu'un a un compte actuel de détenteurs de uniBTC provenant de n'importe quel tracker, cette comparaison réglerait la question dans un sens ou dans l'autre.
@Bedrock #bedrock $BR
Selon Etherscan, au 6 mars 2026, uniBTC avait une capitalisation boursière on-chain de 129 133 516,67 $ répartie sur 938 détenteurs.
J'ai pris un moment pour réfléchir à ce ratio.
En fait, en divisant l'un par l'autre, cela donne environ 137 000 $ dans le portefeuille moyen d'un détenteur, d'après mes propres calculs approximatifs. Pour un token phare de liquidité de restaking commercialisé comme accessible à tout détenteur de BTC, cette moyenne est élevée.
Voici ce qui rend cela plus pertinent aujourd'hui.
Selon les données de CoinGecko de juin 2026, la capitalisation boursière de uniBTC a augmenté pour atteindre environ 200 à 260 millions de dollars, en forte hausse par rapport à ce chiffre de mars, avec un prix en hausse d'environ 10 à 19 % au cours de la semaine dernière.
La capitalisation boursière a presque doublé en trois mois.
Ce que je n'ai pas pu trouver nulle part, c'est un compte de détenteurs mis à jour pour accompagner cette croissance.
Peut-être que le nombre de détenteurs a augmenté au même rythme, et l'image reste équilibrée. Ou bien le même petit groupe est juste devenu plus riche pendant que le chiffre principal avait l'air brillant.
Je ne sais vraiment pas lequel c'est.
Bedrock n'a rien dit à ce sujet.
Si quelqu'un a un compte actuel de détenteurs de uniBTC provenant de n'importe quel tracker, cette comparaison réglerait la question dans un sens ou dans l'autre.
@Bedrock #bedrock $BR
Connectez-vous pour découvrir plus de contenu