钱易qy

Le pire dans les transactions on-chain n’est pas de perdre de l’argent, mais de savoir que le risque approche… et de ne pouvoir que l’attendre pour qu’il se produise.
Avant, beaucoup d’outils de sécurité ressemblaient à des “alarmes” : le hacker avait déjà agi, les actifs avaient déjà été transférés, la liquidation avait déjà eu lieu, et ce n’est qu’alors qu’on te disait “ça a tourné”. Ça sonne très professionnel, mais au fond, c’est encore un débriefing après coup.
Récemment, j’ai relu $NEWT et j’ai remarqué que @NewtonProtocol ne parle pas de “surveillance”, mais de “droit d’autoriser la transaction”.
La logique de Newton ressemble à un contrôle de sécurité à l’aéroport : ce n’est pas vérifier une fois que tu es déjà monté dans l’avion, mais juger avant l’exécution — cette opération respecte-t-elle les règles ? Peut-on l’autoriser ? Si c’est approuvé, la chaîne conserve des preuves vérifiables ; si ce n’est pas approuvé, interception directe.
VaultKit ressemble davantage à l’installation d’un portique de règles pour un vault DeFi. Par exemple : concentration de la position, liquidité du marché, écarts de prix, risque lié aux adresses, contrôles de conformité… Ces conditions ne sont pas écrites dans un PPT ; ce sont des policies qui doivent être validées avant d’exécuter la transaction.
Je pense que c’est crucial. À l’avenir, si les AI Agents, les stratégies automatisées, les RWA, les stablecoins, ou les vaults institutionnels veulent vraiment être massivement déployés on-chain, compter uniquement sur “signaler après coup” ne suffira pas. Plus les montants sont élevés, plus il faut des autorisations préalables, plutôt que chercher des responsables après l’incident.
Bien sûr, $NEWT n’est pas non plus sans problèmes en ce moment. Le mainnet est encore en Beta : il faut continuer d’observer le volume réel, la vitesse d’intégration, le taux de stratégies mal interprétées, et la pression liée aux déblocages ultérieurs. Une capitalisation faible n’est pas une raison d’acheter ; ce sont les données de mise en pratique qui comptent.
Mais je reconnais la direction : faire avancer la sécurité on-chain, de la “notification d’accident” vers “l’accès à la transaction”.
D’un côté : les pompiers. De l’autre : la porte de sécurité.
Qu’en pensez-vous ?
Le contrôle de risque on-chain qui intercepte avant l’exécution, comme $NEWT , deviendra-t-il un besoin indispensable pour l’onboarding institutionnel, ou bien encore un récit d’infrastructure “très prometteur” ?
#Newt #newt

Il y a un vieux problème difficile en matière de conformité on-chain dont personne ne parle franchement : les règles de régulation ont changé, et le contrat doit être redéployé.
Redéployer signifie audit, tests et migration—rapide, c’est quelques semaines ; lent, c’est plus long. Pendant ce temps, les anciennes règles continuent de s’appliquer, tandis que les nouvelles exigences sont déjà en vigueur ; cette fenêtre entre les deux représente réellement un risque de non-conformité.
Sur Newton Mainnet Beta, je pense que le design le plus sous-estimé est la séparation totale entre la policy et le code.
Chez VaultKit, la policy existe de façon indépendante : quand le curator met à jour la liste des sanctions, ajuste les seuils de risque ou modifie les limites sur les contreparties, il n’est pas nécessaire de toucher au contrat, ni de le redéployer. Une fois modifiée, la policy prend effet immédiatement et le réseau Newton exécute directement les nouvelles règles.
Pour les institutions, ce n’est pas seulement plus pratique : c’est un écart fondamental en matière de réactivité de la conformité.
Le mécanisme de capture de valeur de $NEWT repose essentiellement sur le fait que « plus les règles de quelqu’un sont importantes, plus il ne peut pas se passer de cette couche d’exécution ».
@NewtonProtocol $NEWT #Newt #newt

Le réseau principal de Newton (Mainnet Beta) est en ligne, et ma première question n’est pas « est-ce que ça va monter ? ».

C’est plutôt : qui écrit la policy ?

La logique du SDK VaultKit est correcte : le curator rédige à l’avance des règles ; quand une transaction arrive, Newton la vérifie, la laisse passer si c’est conforme, la bloque si ce ne l’est pas. À chaque décision, un reçu de signature vérifiable est généré. RedStone fournit les données de prix, Credora fournit les évaluations de risque, et le moteur de policy combine les deux pour produire un verdict d’exécution. Ça sonne complet.

Mais l’efficacité réelle de l’ensemble du système dépend de la qualité de la policy écrite par le curator. Si les règles sont trop souples, la policy ne sert à rien ; si elles sont trop strictes, des transactions normales sont aussi interceptées. Ce n’est pas un problème du protocole Newton lui-même : c’est une question de savoir qui utilise VaultKit et s’il l’utilise bien ou non.

Pendant la phase Mainnet Beta, le plus important à surveiller n’est pas le prix $NEWT , mais le fait de savoir s’il existe de vrais curators qui tournent en production, et combien de transactions de risques réels sont interceptées par la policy. Ce sont les chiffres qui parlent ; le récit, lui, ne parle pas.

@NewtonProtocol $NEWT
#Newt #newt

#newt $NEWT
Quand vous achetez $NEWT , avez-vous vraiment pris le temps de savoir qui sont les utilisateurs réels de @NewtonProtocol ?
Ce n’est pas vous, ce n’est pas moi, pas un simple investisseur particulier.
La suite Newton — le langage Rego pour écrire des policies, le réseau EigenLayer AVS qui effectue des vérifications d’autorisation avant que la transaction soit incluse dans la chaîne, des preuves cryptographiques qui consignent chaque étape de l’exécution — ce sont de vraies institutions qui passent commande : celles qui doivent intégrer des règles de conformité dans les processus on-chain, les protocoles qui gèrent les RWA, et les portefeuilles d’entreprises qui n’osent pas laisser un agent IA agir librement sur des fonds.
Dans la couche d’autorisation de Newton, les particuliers n’ont pas de cas d’usage direct. Ce n’est pas une critique, c’est un problème de positionnement.
C’est pourquoi beaucoup de gens ont l’impression que NEWT « n’a pas de scénarios », simplement parce qu’ils l’observent depuis la perspective d’un produit destiné aux investisseurs particuliers. L’accumulation de plus de 200 000 développeurs de Magic Labs est le plus grand actif invisible, mais ces développeurs ont connecté le client de policy Newton directement à leurs propres contrats, grâce à la pression de conformité et aux besoins institutionnels, pas à la popularité du récit. Le rythme est lent, mais une fois connecté, c’est très difficile à remplacer.
Moi, quand je vois $NEWT , je ne regarde qu’une seule chose : est-ce qu’il existe de vrais protocoles qui écrivent des policies dans des contrats et les font tourner, et pas seulement une démonstration sur testnet.

J’ai passé plus de temps à parcourir la documentation du protocole Newton aujourd’hui, en étant bloqué sur une question.
L’évaluation de la policy pour @NewtonProtocol a besoin de données hors chaîne en temps réel — le flux de prix de RedStone, le score de crédit de Credora, et les mises à jour des listes de sanctions. Tout cela est injecté via un adaptateur TEE. À chaque transaction, avant que celle-ci ne soit incluse dans la chaîne, l’opérateur exécute ces données avec les règles Rego, produit des preuves de signature, et le contrat on-chain vérifie la signature avant d’autoriser la suite.
La logique tient. Mais je me demande un scénario : dans des conditions de marché extrêmes, le flux de prix de RedStone peut avoir quelques secondes de retard. La policy de Newton utilise alors un prix obsolète pour générer les preuves, alors que sur la chaîne le prix réel a déjà sauté. Comment cette différence de temps est-elle traitée dans la conception « autorisation avant exécution » ?
Ce n’est pas qu’on dise que RedStone n’est pas fiable ; c’est plutôt la manière dont ce type de décalage temporel influence le système, qui est très différente de la logique des protocoles qui utilisent directement un oracle pour le règlement — ça mérite d’être clarifié.
Je continue à chercher, pas encore de conclusion.$NEWT #Newt

Alpha日报
Aujourd’hui, le largage est arrivé avec un peu de retard. Je l’ai laissé tourner sans bouger : en revenant de mon brossage de dents, je me suis rendu compte que ça avait déjà fait +20u. Par chance, cette fois je n’ai pas “vendu à côté” (ça n’a pas dérapé). Les nouvelles pièces n’ont pas eu d’annonce ; pour les vieilles, on continue de les “brasser”, de manger ce qu’il y a à manger.
Les petits investisseurs particuliers regardaient autrefois les projets AI : les mots du type « nombre de modèles » « profil de financement » les emportaient le plus facilement. A16z y avait investi, des milliers de modèles, rien qu’à l’entendre on se dit que c’est solide. Puis j’ai compris : ce qu’ils montrent, c’est surtout la vitrine du projet. Ce qui détermine vraiment la valeur, au final, est rarement mentionné.
Aujourd’hui, je continue à regarder @OpenGradient . Ce qui m’intéresse n’est pas tant la quantité de concepts d’IA qu’il affiche, mais le truc appelé Model Hub : est-ce que les développeurs sont réellement prêts à y téléverser des modèles et à les utiliser ? Ou est-ce que l’équipe officielle se contente de “brusser des chiffres” pour faire bonne figure. Une bibliothèque de modèles décentralisée : est-ce qu’elle vit vraiment ou non ? À terme, tout dépend de savoir s’il y a des gens qui continuent d’y ajouter du nouveau, pas de si le total du jour de lancement est joli.
$OPG oscille encore à bas niveau. Je ne vais pas penser qu’il n’y a rien juste parce que le prix baisse, et je ne vais pas non plus me sentir rassuré parce que c’est listé sur Binance. Continue à surveiller #OPG pour l’activité de ce Model Hub : voir s’il y a vraiment des développeurs qui s’en servent, et pas seulement de la “chaleur” (de l’engouement).
$OPG #OPG

Alpha日报
Aujourd’hui, OPG a comblé un petit creux. Upbit vient juste d’être lancé, le volume de transactions a grimpé, le prix a fait un bond… puis il est retombé. J’en ai touché un peu vers 0,20, mais je ne sais pas trop si c’est le bon moment. Je veux juste construire d’abord, tant que personne ne fait attention.
Vendre trop tôt et subir une perte, c’est un schéma courant sur la chaîne, j’accepte 😅
Les vieux traders qui regardent les projets IA se faisaient facilement entraîner par des concepts. Plus tard, j’ai compris : la question de savoir si le token a de vrais scénarios de consommation, c’est plus concret que tout le reste.
Aujourd’hui, je continue à regarder @OpenGradient . Je m’intéresse à un détail : à chaque fois qu’un développeur appelle une inférence IA, OPG est consommé une fois réellement. Ensuite, l’exécution se fait via le protocole x402 avec un règlement direct sur Base, pas par des « initiatives de gouvernance d’écosystème » détournées. Ici, lier directement l’usage du réseau et la consommation de tokens. Si cette logique est vraie, ce qu’il faut suivre, ce n’est pas le prix, mais la tendance du nombre d’appels d’inférence.
$OPG Je ne vais pas me contenter de regarder l’attention du moment : je continue aussi à observer #OPG pour voir si les données d’appels réels montent.

Aujourd’hui, très probablement des anciennes “boxes” aveugles ; une fois terminé, n’oublie pas de soutenir le créateur.
@OpenGradient est monté sur Binance ; « raisonnement IA vérifiable » en parle de façon très séduisante. J’ai vraiment regardé la couche sous-jacente ; aujourd’hui, je vais dire quelques vérités à ceux qui foncent en voyant juste le backing d’a16z.
La direction est réelle : si les résultats de l’IA ne sont pas vérifiables, c’est un vrai problème côté chaîne. Les 2000+ modèles, et 2 millions de données d’inférence vérifiable… ce n’est pas du bluff, je le reconnais.
Mais quel est le prix ? Derrière le « vérifiable », il y a trois hypothèses de confiance totalement différentes.
zkML, ce sont des preuves mathématiques : c’est la voie la plus radicale, mais le coût de calcul est plusieurs centaines de fois supérieur à celui de l’inférence elle-même ; pour l’instant, on ne peut faire tourner que des modèles très petits. TEE, c’est l’exécution dans un matériel de confiance : c’est rapide, mais au fond, c’est une confiance dans Intel et AMD — sans qu’ils aient laissé de portes dérobées — et il y a une friction difficile à concilier avec l’objectif de la décentralisation. Vanilla, lui, n’a aucune vérification.
En pratique, quelle sorte d’inférence est réellement exécutée sur le réseau ? C’est ce ratio qui détermine combien de « AI vérifiable » est réellement concrétisé, et combien relève du simple fantasme. Personne ne pose cette question.
Ma logique opérationnelle : la direction OG est réelle, mais ce qui vaut le plus la peine d’être suivi maintenant n’est pas le nombre de modèles — c’est la proportion d’inférences zkML dans le total. Si ce chiffre ne monte pas, alors la plupart du temps, « vérifiable » signifie une confiance relative sous TEE, et il reste une distance par rapport à une vraie vérifiabilité on-chain.
$OPG est maintenant bien en dessous de son ATH ; les données réelles d’appels des développeurs parlent, ce n’est pas juste la hype.
#OPG $OPG

Aujourd’hui, très probablement, ce sont de vieilles pièces (old coins) : autour de 240 points. Une fois que vous avez terminé, il faut ouvrir.
Ces derniers temps, tout le web encense le BTCFi : il y a tous les jours des gens qui poussent le brBTC de @Bedrock . Je l’ai étudié sérieusement, en regardant les mécanismes “à la base”, et aujourd’hui je vais dire une chose que personne n’a vraiment expliquée de façon directe : que se passe-t-il si les nœuds validateurs de Babylon sont slashés, et que se passe-t-il pour les détenteurs de brBTC ?
D’abord, je l’admets : la logique de routage multi-protocoles de brBTC fonctionne. Mettre le BTC comme mise de sécurité et servir de “caution” budgétise la sécurité, c’est plus durable que de compter uniquement sur des incitations et subventions. Là-dessus, je ne nie rien.
Mais quel est le prix à payer ? Le slash de Babylon est codé en dur dans le protocole : si le validateur agit mal, le BTC qui se trouve derrière est détruit de façon pénalisante.
Le brBTC est un modèle d’appréciation “non-rebase” : la quantité détenue reste inchangée, et le taux de change augmente avec les gains. Donc, à l’inverse, si le nœud est slashé, le taux de change baissera-t-il pour la première fois ? Cette perte est-elle supportée au prorata par les détenteurs de brBTC, ou bien Bedrock a-t-il un fonds d’assurance indépendant pour couvrir ? La taille du fonds d’assurance par rapport au TVL est-elle suffisante : c’est vraiment le chiffre auquel il faut prêter attention, pas les quelques points d’écart d’APY.
La communauté discute tous les jours des rendements. Est-ce que quelqu’un a déjà pris la peine de vérifier les clauses de répartition du risque de slash ? En gros, non.
Mon raisonnement “terrain” est le suivant : comprendre d’abord la taille du fonds d’assurance et le mécanisme de traitement quand des nœuds ont un problème, puis seulement après renforcer fortement. Si vous ne pouvez pas répondre, entrer avec une grosse position, c’est prendre une exposition au risque que vous ne comprenez pas. C’est au moment où le marché verra réellement un premier événement de slash que $BR saura comment gérer — c’est ça que le BTCFi 2.0 devra accepter quand il subira de vrais tests de résistance.
$BR #Bedrock

Aujourd'hui, il y a de fortes chances que ce soit des vieux coins, entre 240 minutes, si ça bouge, il faut y aller.
Dernièrement, le brBTC de @Bedrock est poussé chaque jour, j'ai sérieusement examiné le mécanisme sous-jacent, aujourd'hui je vais aborder quelque chose que personne n'a jamais réellement discuté : que faire pour les détenteurs de brBTC si les nœuds de validation de Babylon se font slasher ?
Il faut d'abord reconnaître que la logique du routage multi-protocole fonctionne, la BTC comme garantie de sécurité est plus durable que le modèle basé uniquement sur les incitations. Je suis d'accord avec ça.
Mais quel est le coût ? Le mécanisme de slash de Babylon existe réellement — la double signature des nœuds, la malveillance, les BTC sous-jacents seront détruits pénalement. Le brBTC est un actif non-rebase à valeur croissante, le nombre de jetons reste constant, le taux de change monte avec les bénéfices. Alors, comment gérer les pertes dues au slash ? Le taux de change va-t-il baisser pour la première fois ? Ou Bedrock a-t-il un fonds d'assurance pour couvrir cela ?
Le taux de couverture du fonds d'assurance est vraiment le chiffre à surveiller, pas une différence de quelques points d'APY.
Dans la communauté, on discute chaque jour pour savoir si les rendements sont élevés, mais y a-t-il quelqu'un qui a lu les termes du protocole concernant la répartition des risques de slash ? Non. Tout le monde regarde juste le taux de change monter, personne ne pense à la logique déclencheuse de sa première baisse.
Ma logique de trading : avant d'entrer dans brBTC, il faut d'abord clarifier deux choses — le ratio de la taille du fonds d'assurance par rapport au TVL, et le mécanisme de traitement spécifique en cas de problème avec les nœuds. Si on ne peut pas répondre à cela et qu'on met une grosse position, on prend des risques qu'on ne comprend pas.
Quand un véritable événement de slash se produira, comment $BR va réagir, ce sera le véritable test de résistance de BTCFi 2.0.
$BR #Bedrock

Aujourd’hui, coffrets de “vieilles pièces” aveugles, autour de 240 points ; quand c’est fini, n’oubliez pas de remercier le créateur.
OPG est monté sur Binance, et “raisonnement IA vérifiable” a été présenté de façon très sexy. J’ai regardé les mécanismes sous-jacents et je vais dire quelques vérités à ceux qui foncent juste parce que a16z a donné son aval.
La direction est réelle : faire appeler un modèle par un protocole on-chain, comment prouver que le modèle exécute bien celui qu’il prétend exécuter, et que la sortie n’a pas été falsifiée ? C’est la vraie question ; @OpenGradient a un besoin de construire la logique d’infrastructure ici.
Mais quel est le coût ? Derrière “vérifiable”, il y a trois hypothèses de confiance entièrement différentes.
zkML est le plus radical : des preuves mathématiques garantissent que le calcul est correct, et il n’y a besoin de faire confiance à personne — mais le coût de calcul est de plusieurs centaines de fois celui du raisonnement lui-même ; pour l’instant, on ne peut exécuter que des modèles avec un volume de paramètres extrêmement faible. Le TEE est rapide, mais en essence il faut faire confiance au matériel d’Intel et d’AMD, sans que l’on sache s’il y a des portes dérobées : il y a donc des frictions difficiles à expliquer entre “confiance au matériel” et “décentralisation”. En “vanilla”, il n’y a tout simplement aucune vérification.
En pratique, quel mode d’inférence le réseau exécute réellement ? Cette proportion détermine à quel point le récit de “l’IA vérifiable” se concrétise réellement.
Dans la communauté, ceux qui ont acheté $OPG : combien peuvent répondre à cette question ? La plupart achètent le concept “IA x blockchain”, pas un jugement réel sur les mécanismes de vérification.
Ma logique opérationnelle : ne pas regarder le nombre de modèles, mais surveiller si la part des inférences zkML dans le volume total d’inférence augmente. Si ce chiffre ne monte pas, “vérifiable” reste seulement une confiance relative au niveau TEE, et il y a encore un écart avec la vraie vérification on-chain.
Le récit est-il assez solide ? Regardez les données d’appel réelles des développeurs, pas la hype.
#OPG $OPG

Cette semaine, on continue de faire tourner les vieilles pièces Alpha : environ 240 points. Une fois terminé, n’oubliez pas de saluer le créateur.

Récemment, on a remis OPG sur le tapis sur tout le web, encore et encore : « 2 millions de fois d’inférence vérifiable », « a16z a investi », « infrastructure AI on-chain ». Même si on prend chaque terme séparément, chacun suffit à écrire un article promotionnel. Ces deux derniers jours, j’ai vraiment lu les documents d’architecture du @OpenGradient , et aujourd’hui je vais dire quelques mots susceptibles de piquer certaines personnes.

D’abord, reconnaissons ce qui est solide : l’architecture HACA d’OpenGradient sépare l’exécution de l’inférence AI et la vérification on-chain. L’idée est correcte. Forcer toutes les inférences à tourner sous des preuves zkML, pour des tâches de type LLM, ça ne passerait tout simplement pas : trop coûteux. Du coup, ils ont mis en place un « spectre de vérification » : pour les tâches simples, preuves mathématiques zkML ; pour les inférences LLM complexes, exécution dans un environnement TEE de confiance pour garantir la vérification. C’est pragmatique, pas du n’importe quoi.

Mais quel est le prix à payer ? « Vérifiable » ne veut pas dire la même chose selon les tâches.
Les preuves zkML sont vérifiables au niveau mathématique : n’importe qui peut contrôler indépendamment les résultats de calcul.
Le « vérifiable » côté TEE repose sur l’hypothèse de confiance d’un matériel type Intel SGX (ou équivalent) : au fond, c’est « faire confiance à cette puce pour ne pas tricher », ce n’est pas une preuve cryptographique.

Sur les « 2 millions d’inférences vérifiables », quelle part correspond réellement à des preuves zkML, et quelle part est traitée via TEE ? Les chiffres, l’OPG ne les dissocie pas publiquement. Pour quelqu’un qui veut évaluer sérieusement la sécurité de cette infrastructure, mélanger ces informations réduit fortement la valeur informative.

Regardons aussi la « boucle d’économie circulaire » du $OPG : l’inférence AI est payée via OPG, et les frais sont répartis entre les opérateurs de nœuds. La logique est correcte, mais le préalable pour que cette roue tourne est le suivant : il faut de vrais développeurs externes qui utilisent OPG pour payer et exécuter des inférences, pas seulement des tests internes et des périodes d’incitation servant à gonfler les volumes avec des récompenses.

Le TGE vient juste de passer il y a deux mois ; l’incitation n’a pas encore complètement décroché. À ce moment-là, sur la quantité d’inférences, quelle part vient de besoins réels payants, et quelle part vient de « chasseurs de points » qui exécutent des tâches ? On peut les vérifier on-chain, mais très peu de gens le font.

Ma logique pratique : la feuille de route technique d’OPG est sérieuse ; a16z n’investit pas « au hasard », et Balaji ne fait pas de simple sponsoring de façade. Mais la valeur d’OPG dépend en fin de compte du fait que des développeurs externes soient prêts à débourser de l’argent réel pour exécuter des inférences, pas de la simple étiquette narrative « IA + blockchain » pour gonfler le prix.

Le volume d’inférences payantes après la fin de la période d’incitation est la véritable réponse à : combien vaut l’OPG.

#OPG

Aujourd’hui, les boîtes aveugles de vieilles pièces sont probablement autour de 240, avec possibilité de séparation, pas grand-chose à attendre.
Récemment, tout le monde sur le web encense la conception non-rebase de @Bedrock : la quantité de brBTC détenue ne change jamais, et la valeur augmente lentement avec les rendements. Dit comme ça, ça paraît beaucoup plus “propre” que ces tokens rebase où la quantité gonfle en permanence. J’adhère à cette logique de design, mais aujourd’hui je vais parler d’un point que personne ne mentionne.

Combien de BTC on peut obtenir contre du brBTC, ce n’est pas quelque chose qu’on peut calculer directement en regardant le grand livre : cela dépend d’un taux de change mis à jour en temps réel.
D’où vient ce taux ? Il est calculé à partir de la synthèse des revenus réellement produits par les protocoles de base — Babylon, Pell, Satlayer — puis réécrit dans le contrat. Autrement dit, la vraie valeur de votre brBTC dépend du bon fonctionnement stable d’un mécanisme de mise à jour du taux on-chain, et du fait que les données de revenus des protocoles sous-jacents soient correctement lues et agrégées.

En temps normal, ce mécanisme fonctionne bien. Mais si on y réfléchit attentivement, où sont les risques ?
D’abord : si les données de revenus d’un des protocoles de base deviennent anormales (par exemple Pell rencontre un problème), cette anomalie peut-elle affecter la mise à jour du taux global de brBTC ? Y a-t-il des mécanismes d’arrêt “fail-safe” en cas d’erreur dans la logique de mise à jour, ou bien est-ce que les données incorrectes seront simplement écrites dans le taux ?
Ensuite : quand le brBTC est utilisé comme collatéral sur un protocole de prêt externe, ce dernier utilise-t-il la source officielle de taux de Bedrock, ou estime-t-il lui-même le prix ? Si ce n’est pas un suivi en temps réel du taux officiel, alors l’évaluation de votre collatéral s’écartera de la valeur réelle ; si l’écart devient important, c’est un risque de liquidation qu’on ne peut pas calculer correctement.

Je ne dis pas que ces problèmes vont forcément arriver, mais avant que beaucoup de gens n’utilisent le brBTC pour des opérations complexes, ils n’ont tout simplement jamais pensé : “Comment ce taux se met à jour ? Et si ça se casse, qui compense ?”
Dans la communauté, on compare tous les jours l’APY des différents protocoles BTCFi, mais très peu de gens vont vérifier le contrat de mise à jour du taux de brBTC : y a-t-il une tolérance aux pannes en cas de défaillance des protocoles sous-jacents ? C’est ça, en réalité, qui détermine si le brBTC est vraiment stable dans des conditions extrêmes, et pas juste “qui a 0,5 % d’APY de plus”.

Mon raisonnement pratique : placer le brBTC sur la plateforme de Bedrock elle-même, pour gagner des intérêts simplement—dans ce cas, le risque de taux est assumé par la plateforme, ce qui est la manière la plus propre. Mais dès qu’on déplace le brBTC vers un protocole externe pour servir de collatéral, il faut d’abord vérifier la logique de traitement du protocole concernant le taux de brBTC : ne le présumez pas “équivalent à BTC”.

Que l’écosystème BR continue de grandir, c’est une bonne chose. Mais la robustesse du mécanisme de taux du brBTC est, elle, la vraie fondation de tout l’édifice.
$BR #Bedrock

Aujourd’hui, probablement une vente à l’aveugle pour les vieilles pièces : autour de 240 points. Une fois que c’est terminé, ouvre—ne reste pas à mourir d’attente.
Récemment, l’écosystème lié à @Bedrock compte de plus en plus de personnes. En observant, je vois que les nouveaux arrivants sont d’environ deux types : l’un accumule du brBTC, l’autre en stocke $BR . Beaucoup prennent les deux, pensant à une « double bénéfic e ». Aujourd’hui, parlons de ce sujet : la plupart des gens n’ont tout simplement pas clarifié la relation entre ces deux actifs.
D’abord, brBTC. La logique est très claire : tu déposes du BTC, tu reçois un titre qui s’apprécie. La quantité que tu détiens ne change jamais, mais le nombre de BTC que brBTC peut échanger augmente continuellement avec les rendements réels générés par les protocoles sous-jacents tels que Babylon, Pell, Satlayer, etc. Ce mécanisme d’appréciation est directement piloté au niveau du protocole ; il n’est pas lié de façon directe aux variations de prix du token BR. Tant que le TVL augmente, les détenteurs de brBTC en bénéficient passivement : la chaîne logique est courte et très claire.
BR, c’est autre chose. C’est le token de gouvernance de la plateforme Bedrock. En le verrouillant en veBR, tu participes à la gouvernance. En détenant veBR, tu peux obtenir des réductions de frais, et il existe aussi une attente de redistribution des frais du protocole. Mais il y a un point à examiner sérieusement : sur les frais générés grâce à la croissance du TVL de la plateforme, quelle proportion revient réellement aux détenteurs de BR / veBR ? Le chemin de transmission de la valeur est-il suffisamment transparent et stable ?
Voici le coût : le rendement de brBTC est déterministe au niveau du mécanisme—les protocoles sous-jacents génèrent des rendements, donc le taux d’échange augmente, sans lien avec le sentiment du marché. Le soutien de valeur de BR repose sur une autre logique : dépendre de l’expansion continue de la plateforme, d’une exécution claire du mécanisme de redistribution des frais de protocole, et du fait qu’à ce stade le pouvoir de gouvernance ait une utilité réelle. Si l’un de ces trois facteurs manque, le soutien de valeur de BR repose encore sur une autre logique—dépendre de l’expansion continue de la plateforme, d’une exécution claire du mécanisme de redistribution des frais de protocole, et du fait que le pouvoir de gouvernance ait une signification réelle à ce stade. Il manque un de ces trois facteurs : BR ne tient plus que sur des attentes.
Quand l’écosystème de Bedrock 2.0 s’ouvrira vraiment, les données réelles de distribution des frais de protocole parleront d’elles-mêmes. C’est seulement à ce moment-là que l’on pourra valider la capacité de capture de valeur du $BR . Pour l’instant, ceux qui ont couru en se basant sur le récit le sauront le jour où les données tomberont : ce qu’ils ont réellement acheté.
#Bedrock

Aujourd’hui, très probablement encore des “vieilles monnaies” en mode boîte aveugle, autour de 240 points ; pas d’annonce de nouvelle monnaie. Si tu dois farmer, fais-le—ne reste pas là à attendre désespérément.

Récemment, j’ai vu pas mal de gens faire l’éloge du design “non-rebase” de brBTC : le nombre de brBTC que tu as ne change jamais, mais la quantité de BTC qu’il peut échanger augmente progressivement avec les gains. Ainsi, 1 brBTC finit par valoir lentement 1,02 ou 1,05 BTC. Par rapport aux tokens rebase où la quantité change en permanence, la tenue des comptes et la perception psychologique sont beaucoup plus claires—ce design, en soi, je l’approuve.

Mais quel est le prix à payer ? Tant que c’est à l’intérieur de la plateforme de @Bedrock , tout est clair. Mais dès que tu utilises brBTC comme garantie (collatéral) pour emprunter sur un autre protocole, tout devient flou.
brBTC n’est pas strictement 1:1 avec BTC : son taux de conversion réel est flottant et continue de monter. Si tu utilises brBTC pour emprunter sur un protocole, ce protocole doit avoir une source de prix dédiée qui suit le “taux de change brBTC/BTC en temps réel”, et ne peut pas simplement reprendre le feed de prix de BTC pour l’utiliser comme prix de brBTC.
Dès que ces deux éléments ne sont pas alignés, il y a deux scénarios : soit le protocole sous-évalue la valeur réelle de brBTC, et ta ligne de liquidation est calculée plus serrée que ce qu’elle devrait être—des positions qui n’auraient pas dû être liquidées explosent trop tôt ; soit le protocole surévalue, et dans ce cas c’est lui qui assume un risque de créances douteuses dont l’origine n’est pas claire.
Dans la communauté, beaucoup de gens voient le taux de brBTC qui monte et se disent : “c’est un rendement gratuit, peu importe où on le met, c’est sûr”. Mais personne ne vérifie en réalité : celui des protocoles de prêt que j’utilise, a-t-il vraiment un mécanisme de tarification du taux spécifique pour brBTC, ou est-ce qu’il se contente de prendre le prix de BTC par défaut ? Les données on-chain permettent de le vérifier, mais presque personne ne le fait.
Mon raisonnement pratique : si brBTC est utilisé dans l’écosystème Bedrock, cette mécanique ne pose pas problème—logiquement, le design est cohérent. Mais avant de l’utiliser comme collatéral sur d’autres protocoles, commence par consulter la documentation de la source de prix de ce protocole : est-ce qu’il a vraiment branché le taux spécifique brBTC, ou est-ce qu’il suppose par défaut que brBTC = BTC.
$BR la véritable douve (moat), ce n’est pas seulement le fait que le produit brBTC soit conçu de façon ingénieuse : c’est aussi le nombre de protocoles externes qui acceptent de prendre le temps d’intégrer correctement sa logique de taux. Ce nombre-là—c’est l’expression réelle de la profondeur de l’écosystème, pas juste le chiffre total de TVL.
$BR #Bedrock