Binance Square
L I S A
3.1k Publications

L I S A

Ouvert au trading
Détenteur pour LINEA
Détenteur pour LINEA
Trade régulièrement
1.3 an(s)
114 Suivis
5.9K+ Abonnés
29.3K+ J’aime
Publications
Portefeuille
·
--
La partie de TermMax que je trouve la plus intéressante, c’est la façon dont le financement à terme fixe change la manière dont je peux structurer une opération sur options. Je pense généralement à une position d’options à travers l’entrée, le résultat (payoff) et le risque, mais le financement peut modifier le résultat de façon discrète alors que la transaction est encore ouverte. Avec @termmax , un coût d’emprunt fixe me donne un apport de financement connu jusqu’à l’échéance. Cela signifie que je peux estimer le coût de portage avant d’entrer, au lieu de considérer les intérêts futurs comme une inconnue. #TermMax L’arbitrage, c’est que la précision s’accompagne d’un engagement. Un terme fixe signifie que je dois choisir une échéance qui correspond réellement à la stratégie, plutôt que de garder le capital totalement flexible. Mais lorsque le timing est délibéré, cette contrainte peut être utile. Je peux comparer le payoff attendu des options à un coût de financement qui reste défini, ce qui rend l’évaluation des paramètres économiques plus simple avant d’engager mon capital. Je vois cela comme un changement subtil : passer simplement de l’emprunt à la conception du financement en fonction de la transaction elle-même. Si les options exigent déjà des hypothèses soigneuses sur le calendrier et le payoff, pourquoi le coût du capital devrait-il rester imprévisible ?
La partie de TermMax que je trouve la plus intéressante, c’est la façon dont le financement à terme fixe change la manière dont je peux structurer une opération sur options. Je pense généralement à une position d’options à travers l’entrée, le résultat (payoff) et le risque, mais le financement peut modifier le résultat de façon discrète alors que la transaction est encore ouverte. Avec @TermMax , un coût d’emprunt fixe me donne un apport de financement connu jusqu’à l’échéance. Cela signifie que je peux estimer le coût de portage avant d’entrer, au lieu de considérer les intérêts futurs comme une inconnue. #TermMax

L’arbitrage, c’est que la précision s’accompagne d’un engagement. Un terme fixe signifie que je dois choisir une échéance qui correspond réellement à la stratégie, plutôt que de garder le capital totalement flexible. Mais lorsque le timing est délibéré, cette contrainte peut être utile. Je peux comparer le payoff attendu des options à un coût de financement qui reste défini, ce qui rend l’évaluation des paramètres économiques plus simple avant d’engager mon capital. Je vois cela comme un changement subtil : passer simplement de l’emprunt à la conception du financement en fonction de la transaction elle-même. Si les options exigent déjà des hypothèses soigneuses sur le calendrier et le payoff, pourquoi le coût du capital devrait-il rester imprévisible ?
Voir la traduction
My biggest interest in @termmax is not simply that it offers fixed rate borrowing. It is what happens when that fixed cost sits beside options execution. I can think about a trade in terms of actual cost of carry instead of guessing where a floating borrowing rate might drift before maturity. In DeFi, that distinction matters because an options position can look attractive at entry and become much less compelling when financing costs change underneath it. With a fixed term, I know the borrowing cost upfront, which gives me a cleaner base for judging whether an options strategy still makes sense. #TermMax The trade off is liquidity versus predictability. A fixed term can limit flexibility compared with constantly rolling capital through variable rate markets, but I would rather accept that constraint when I need a clearly defined financing window. For me, this makes TermMax interesting as a trading infrastructure layer rather than just another lending venue. The combination of fixed rate credit and options execution could let traders structure positions around maturity, financing cost, and expected payoff with much clearer assumptions. The real question I keep coming back to is this: when financing becomes predictable, does the bigger advantage come from better risk control, or from being able to design more precise strategies? #termmax @TermMax
My biggest interest in @TermMax is not simply that it offers fixed rate borrowing. It is what happens when that fixed cost sits beside options execution. I can think about a trade in terms of actual cost of carry instead of guessing where a floating borrowing rate might drift before maturity. In DeFi, that distinction matters because an options position can look attractive at entry and become much less compelling when financing costs change underneath it. With a fixed term, I know the borrowing cost upfront, which gives me a cleaner base for judging whether an options strategy still makes sense. #TermMax

The trade off is liquidity versus predictability. A fixed term can limit flexibility compared with constantly rolling capital through variable rate markets, but I would rather accept that constraint when I need a clearly defined financing window. For me, this makes TermMax interesting as a trading infrastructure layer rather than just another lending venue. The combination of fixed rate credit and options execution could let traders structure positions around maturity, financing cost, and expected payoff with much clearer assumptions. The real question I keep coming back to is this: when financing becomes predictable, does the bigger advantage come from better risk control, or from being able to design more precise strategies?

#termmax @TermMax
La self-custody est la seule chose sur laquelle je ne fais jamais de compromis. C’est pourquoi la plupart des produits de prêt Bitcoin perdent tout intérêt à partir du moment où ils me demandent d’envelopper ou de faire un pont pour le BTC. Les Trustless Bitcoin Vaults (TBV) de @babylonlabs_io sont différents, et c’est précisément pour cela que j’ai décidé d’en parler. Ce qui a attiré mon attention, c’est que le testnet public pour l’emprunt adossé à du Bitcoin natif via Aave v4 compte déjà plusieurs grandes entités qui testent aux côtés d’utilisateurs réguliers. Ce n’est pas quelque chose qu’on observe sur tous les testnets en phase initiale. Cela indique que le modèle est pris au sérieux, au-delà du simple retail. Je l’ai testé de la même manière que n’importe qui. J’ai récupéré des jetons de test depuis le faucet, déposé du BTC natif, emprunté via Aave v4, puis vérifié que tout fonctionnait sur l’explorateur. Mes clés n’ont jamais quitté mon contrôle à aucun moment. Si vous voulez vous forger votre propre opinion plutôt que de prendre la mienne, les fonds partagent le feedback via le formulaire officiel avant le mainnet. #baby $BABY
La self-custody est la seule chose sur laquelle je ne fais jamais de compromis. C’est pourquoi la plupart des produits de prêt Bitcoin perdent tout intérêt à partir du moment où ils me demandent d’envelopper ou de faire un pont pour le BTC. Les Trustless Bitcoin Vaults (TBV) de @BabylonLabs_io sont différents, et c’est précisément pour cela que j’ai décidé d’en parler.

Ce qui a attiré mon attention, c’est que le testnet public pour l’emprunt adossé à du Bitcoin natif via Aave v4 compte déjà plusieurs grandes entités qui testent aux côtés d’utilisateurs réguliers. Ce n’est pas quelque chose qu’on observe sur tous les testnets en phase initiale. Cela indique que le modèle est pris au sérieux, au-delà du simple retail.

Je l’ai testé de la même manière que n’importe qui. J’ai récupéré des jetons de test depuis le faucet, déposé du BTC natif, emprunté via Aave v4, puis vérifié que tout fonctionnait sur l’explorateur. Mes clés n’ont jamais quitté mon contrôle à aucun moment. Si vous voulez vous forger votre propre opinion plutôt que de prendre la mienne, les fonds partagent le feedback via le formulaire officiel avant le mainnet.

#baby $BABY
Voir la traduction
Babylon built the Bitcoin Staking Protocol, which grew into the largest Bitcoin based project in crypto by total value locked. Now @babylonlabs_io is extending that native BTC into DeFi through Trustless Bitcoin Vaults (TBV), a way to use Bitcoin as collateral without wrapping, bridging, or trusting a middleman. TBV currently powers native Bitcoin backed borrowing on Aave v4, live on public testnet. The flow is simple. Claim test tokens from the faucet, deposit native BTC in the testnet app, borrow assets like USDC on Ethereum, then check the transaction on the explorer. What makes this worth trying is how little trust it asks for. Your Bitcoin stays native the whole time, and you never give up custody to complete the borrow. Test it yourself and send feedback through the official form before mainnet. #baby $BABY {spot}(BABYUSDT)
Babylon built the Bitcoin Staking Protocol, which grew into the largest Bitcoin based project in crypto by total value locked. Now @BabylonLabs_io is extending that native BTC into DeFi through Trustless Bitcoin Vaults (TBV), a way to use Bitcoin as collateral without wrapping, bridging, or trusting a middleman.

TBV currently powers native Bitcoin backed borrowing on Aave v4, live on public testnet. The flow is simple. Claim test tokens from the faucet, deposit native BTC in the testnet app, borrow assets like USDC on Ethereum, then check the transaction on the explorer.

What makes this worth trying is how little trust it asks for. Your Bitcoin stays native the whole time, and you never give up custody to complete the borrow. Test it yourself and send feedback through the official form before mainnet.

#baby $BABY
La plupart des traders ont une hiérarchie mentale des actifs, et tout en haut se trouve le Bitcoin détenu en auto-conservation (self-custody). Tout le reste est généralement traité comme un compromis : soit vous sacrifiez cette sécurité au profit des rendements DeFi, soit vous conservez des positions spot et ignorez le potentiel d’efficacité du capital. Les Trustless Bitcoin Vaults (TBV) forcent enfin ce modèle binaire à évoluer. Au lieu de choisir entre détenir des actifs et les faire travailler, l’architecture TBV vous permet de conserver la garde de la couche de base tout en soutenant simultanément des positions DeFi sur Ethereum. Quand j’observe le flux d’exécution de l’emprunt adossé à un Bitcoin natif, la différence de profil de risque est sans commune mesure avec les variantes utilisant des tokens enveloppés (wrapped). Parce que le collatéral réel reste verrouillé dans des scripts Bitcoin Taproot et ne produit que des preuves d’état, toute la dépendance aux opérateurs de ponts (bridge) tiers s’évapore pratiquement. Ainsi, emprunter cesse d’être une question de confiance pour devenir une question de vérification de l’exécution du script onchain. J’ai passé du temps à examiner la façon dont ces coffres (vaults) gèrent les déclencheurs de liquidation lors des simulations sur testnet, et la rapidité de l’exécution cryptographique est une amélioration massive par rapport aux mises à jour de ponts basées sur des oracles traditionnels. Pour ceux qui se sont tenus à l’écart des protocoles de prêt à cause d’une anxiété liée aux ponts, c’est le premier véritable changement du marché. La transition vers une exécution cryptographique native modifie-t-elle votre vision à long terme du crédit ? @babylonlabs_io $BABY #baby {spot}(BABYUSDT)
La plupart des traders ont une hiérarchie mentale des actifs, et tout en haut se trouve le Bitcoin détenu en auto-conservation (self-custody). Tout le reste est généralement traité comme un compromis : soit vous sacrifiez cette sécurité au profit des rendements DeFi, soit vous conservez des positions spot et ignorez le potentiel d’efficacité du capital.

Les Trustless Bitcoin Vaults (TBV) forcent enfin ce modèle binaire à évoluer. Au lieu de choisir entre détenir des actifs et les faire travailler, l’architecture TBV vous permet de conserver la garde de la couche de base tout en soutenant simultanément des positions DeFi sur Ethereum.

Quand j’observe le flux d’exécution de l’emprunt adossé à un Bitcoin natif, la différence de profil de risque est sans commune mesure avec les variantes utilisant des tokens enveloppés (wrapped). Parce que le collatéral réel reste verrouillé dans des scripts Bitcoin Taproot et ne produit que des preuves d’état, toute la dépendance aux opérateurs de ponts (bridge) tiers s’évapore pratiquement.

Ainsi, emprunter cesse d’être une question de confiance pour devenir une question de vérification de l’exécution du script onchain. J’ai passé du temps à examiner la façon dont ces coffres (vaults) gèrent les déclencheurs de liquidation lors des simulations sur testnet, et la rapidité de l’exécution cryptographique est une amélioration massive par rapport aux mises à jour de ponts basées sur des oracles traditionnels.

Pour ceux qui se sont tenus à l’écart des protocoles de prêt à cause d’une anxiété liée aux ponts, c’est le premier véritable changement du marché. La transition vers une exécution cryptographique native modifie-t-elle votre vision à long terme du crédit ?

@BabylonLabs_io $BABY #baby
Lorsqu’on évalue l’efficacité du capital dans la finance décentralisée, l’emprunt adossé à des actifs au comptant n’est souvent que la première étape d’un changement plus large au sein d’un écosystème. La publication des Trustless Bitcoin Vaults (TBV) ouvre la voie à des garanties Bitcoin natives capables d’alimenter une vaste gamme d’instruments financiers au-delà de simples pools de prêt. En permettant des preuves vérifiables de l’état du Bitcoin via des couches de contrats intelligents externes, les TBV permettent aux développeurs de créer des marchés dérivés, des stablecoins décentralisés et des lignes de crédit directement adossés à du BTC non transféré. Cela signifie que les traders peuvent conserver une exposition spot de long terme tout en déployant leur richesse sous-jacente dans des stratégies de rendement structurées ou des positions de couverture, sans friction liée aux contreparties. Ce qui m’enthousiasme le plus en étendant les TBV à des produits financiers multi-chaînes, c’est la façon dont elles standardisent la sécurité à travers des applications DeFi diverses. Plutôt que de créer des tokens enveloppés isolés pour chaque protocole, un mécanisme de coffre unifié garantit que les règles de garantie et la logique de liquidation restent cryptographiquement cohérentes. Que vous adossiez des actifs synthétiques sur Ethereum ou que vous accédiez à des lignes de crédit automatisées, votre Bitcoin principal reste solidement ancré sur sa chaîne native. À mesure que davantage de protocoles décentralisés adopteront l’infrastructure TBV, le Bitcoin natif se transformera d’une simple réserve passive de valeur en un pilier de garantie de référence pour le web3. Avez-vous envisagé d’utiliser native $BTC to pour soutenir des positions DeFi qui ne sont pas des prêts? @babylonlabs_io $BABY #baby {spot}(BABYUSDT) {spot}(BTCUSDT)
Lorsqu’on évalue l’efficacité du capital dans la finance décentralisée, l’emprunt adossé à des actifs au comptant n’est souvent que la première étape d’un changement plus large au sein d’un écosystème.

La publication des Trustless Bitcoin Vaults (TBV) ouvre la voie à des garanties Bitcoin natives capables d’alimenter une vaste gamme d’instruments financiers au-delà de simples pools de prêt. En permettant des preuves vérifiables de l’état du Bitcoin via des couches de contrats intelligents externes, les TBV permettent aux développeurs de créer des marchés dérivés, des stablecoins décentralisés et des lignes de crédit directement adossés à du BTC non transféré.

Cela signifie que les traders peuvent conserver une exposition spot de long terme tout en déployant leur richesse sous-jacente dans des stratégies de rendement structurées ou des positions de couverture, sans friction liée aux contreparties.

Ce qui m’enthousiasme le plus en étendant les TBV à des produits financiers multi-chaînes, c’est la façon dont elles standardisent la sécurité à travers des applications DeFi diverses. Plutôt que de créer des tokens enveloppés isolés pour chaque protocole, un mécanisme de coffre unifié garantit que les règles de garantie et la logique de liquidation restent cryptographiquement cohérentes.

Que vous adossiez des actifs synthétiques sur Ethereum ou que vous accédiez à des lignes de crédit automatisées, votre Bitcoin principal reste solidement ancré sur sa chaîne native.

À mesure que davantage de protocoles décentralisés adopteront l’infrastructure TBV, le Bitcoin natif se transformera d’une simple réserve passive de valeur en un pilier de garantie de référence pour le web3.

Avez-vous envisagé d’utiliser native $BTC to pour soutenir des positions DeFi qui ne sont pas des prêts?

@BabylonLabs_io $BABY #baby
Babylon avait besoin d’une liste grandissante d’intermédiaires institutionnels pour diffuser un message visant à supprimer les intermédiaires J’ai consulté la liste des partenariats récents et elle ne cessait de s’étendre. Ginco au Japon, Bflux pour le rendement institutionnel, DSRV pour l’infrastructure de validation, Parataxis pour la stratégie de trésorerie. Tous se situent entre le protocole de Babylon et les institutions qui détiennent réellement le Bitcoin. Cela m’a semblé valoir la peine d’y réfléchir. L’argument central est : pas de dépositaires, pas d’intermédiaires, un staking en auto-garde pur, imposé directement sur le Bitcoin. Pourtant, pour atteindre des institutions, il faut apparemment des fournisseurs de portefeuilles d’entreprise, des spécialistes de la garde et des partenaires régionaux jouant le rôle de couche d’interface entre des réserves à froid $BTC et le protocole en dessous. Je ne pense pas que cela contredise le design sans confiance (trustless). Le BTC lui-même reste verrouillé selon les conditions du script Bitcoin, quelle que soit l’application de portefeuille d’entreprise qui initie la transaction. Mais cela signifie que l’expérience réelle du staking sans confiance, pour une banque ou une trésorerie d’entreprise en tout cas, passe toujours par une chaîne de partenaires vérifiés : conformité, interfaces de garde et intégration. La “sans confiance” au niveau du protocole et l’accès institutionnel s’avèrent être deux couches très différentes du même système. Peut-être que c’est simplement à quoi ressemble l’adoption. Le capital réglementé ne circule pas sans voies (rails) réglementées, aussi propre que soit la cryptographie sous-jacente. Le Bitcoin institutionnel touche-t-il un jour réellement un protocole vraiment sans confiance directement, ou bien passe-t-il toujours d’abord par une couche de partenaires de confiance, indépendamment de ce que promet la couche de base @babylonlabs_io $BABY #baby {spot}(BTCUSDT) {spot}(BABYUSDT)
Babylon avait besoin d’une liste grandissante d’intermédiaires institutionnels pour diffuser un message visant à supprimer les intermédiaires

J’ai consulté la liste des partenariats récents et elle ne cessait de s’étendre. Ginco au Japon, Bflux pour le rendement institutionnel, DSRV pour l’infrastructure de validation, Parataxis pour la stratégie de trésorerie. Tous se situent entre le protocole de Babylon et les institutions qui détiennent réellement le Bitcoin.

Cela m’a semblé valoir la peine d’y réfléchir. L’argument central est : pas de dépositaires, pas d’intermédiaires, un staking en auto-garde pur, imposé directement sur le Bitcoin. Pourtant, pour atteindre des institutions, il faut apparemment des fournisseurs de portefeuilles d’entreprise, des spécialistes de la garde et des partenaires régionaux jouant le rôle de couche d’interface entre des réserves à froid $BTC et le protocole en dessous.

Je ne pense pas que cela contredise le design sans confiance (trustless). Le BTC lui-même reste verrouillé selon les conditions du script Bitcoin, quelle que soit l’application de portefeuille d’entreprise qui initie la transaction. Mais cela signifie que l’expérience réelle du staking sans confiance, pour une banque ou une trésorerie d’entreprise en tout cas, passe toujours par une chaîne de partenaires vérifiés : conformité, interfaces de garde et intégration. La “sans confiance” au niveau du protocole et l’accès institutionnel s’avèrent être deux couches très différentes du même système.

Peut-être que c’est simplement à quoi ressemble l’adoption. Le capital réglementé ne circule pas sans voies (rails) réglementées, aussi propre que soit la cryptographie sous-jacente.

Le Bitcoin institutionnel touche-t-il un jour réellement un protocole vraiment sans confiance directement, ou bien passe-t-il toujours d’abord par une couche de partenaires de confiance, indépendamment de ce que promet la couche de base

@BabylonLabs_io $BABY #baby
Un rapport de bogue en une seule ligne montre davantage sur un protocole que n’importe quelle feuille de route J’ai lu la divulgation et ce qui m’a marqué n’était pas le bogue lui-même, mais le fait qu’il était en réalité très banal. Un validateur malveillant pouvait ignorer un champ d’empreinte de bloc ; protobuf le permettait car le champ était optionnel, et le code de Babylon essayait de lire des données qui n’étaient pas là. Pointeur nul, panique à l’exécution, des validateurs qui s’écrasent juste aux limites d’époque, là où le timing de la concurrence compte le plus. Rien d’exotique. Rien du type $BTC jamais en danger, aucun fonds touché, seulement un bogue de couche de consensus qui aurait pu ralentir la production de blocs si suffisamment de validateurs étaient touchés en même temps. Ce qui m’intéresse en fait, c’est le chemin de la divulgation. Découvert par un contributeur indépendant pseudonyme, déposé publiquement sur GitHub, corrigé dans la version 4.2.0 avec une validation plus stricte autour des extensions de vote. Voilà la réalité ennuyeuse et peu glamour de la façon dont la sécurité fonctionne réellement dans des systèmes de production protégeant des milliards de BTC misés. Pas un code parfait : juste un processus fonctionnel pour repérer et corriger ce qui passe entre les mailles. Je pense que les gens confondent « sans confiance » avec « sans bogues », et ce ne sont pas du tout la même affirmation. « Sans confiance » décrit qui détient la garde. Cela ne dit rien sur le fait que le logiciel en dessous soit parfait, car aucun logiciel ne l’est. Un bogue discret, corrigé rapidement, vous donne-t-il plus confiance dans le processus, ou bien chaque faille au niveau du consensus sur un protocole de sécurité Bitcoin vous rend-elle nerveux, indépendamment de la manière dont elle est résolue @babylonlabs_io $BABY #baby {spot}(BTCUSDT) {spot}(BABYUSDT)
Un rapport de bogue en une seule ligne montre davantage sur un protocole que n’importe quelle feuille de route

J’ai lu la divulgation et ce qui m’a marqué n’était pas le bogue lui-même, mais le fait qu’il était en réalité très banal. Un validateur malveillant pouvait ignorer un champ d’empreinte de bloc ; protobuf le permettait car le champ était optionnel, et le code de Babylon essayait de lire des données qui n’étaient pas là. Pointeur nul, panique à l’exécution, des validateurs qui s’écrasent juste aux limites d’époque, là où le timing de la concurrence compte le plus.

Rien d’exotique. Rien du type $BTC jamais en danger, aucun fonds touché, seulement un bogue de couche de consensus qui aurait pu ralentir la production de blocs si suffisamment de validateurs étaient touchés en même temps.

Ce qui m’intéresse en fait, c’est le chemin de la divulgation. Découvert par un contributeur indépendant pseudonyme, déposé publiquement sur GitHub, corrigé dans la version 4.2.0 avec une validation plus stricte autour des extensions de vote. Voilà la réalité ennuyeuse et peu glamour de la façon dont la sécurité fonctionne réellement dans des systèmes de production protégeant des milliards de BTC misés. Pas un code parfait : juste un processus fonctionnel pour repérer et corriger ce qui passe entre les mailles.

Je pense que les gens confondent « sans confiance » avec « sans bogues », et ce ne sont pas du tout la même affirmation. « Sans confiance » décrit qui détient la garde. Cela ne dit rien sur le fait que le logiciel en dessous soit parfait, car aucun logiciel ne l’est.

Un bogue discret, corrigé rapidement, vous donne-t-il plus confiance dans le processus, ou bien chaque faille au niveau du consensus sur un protocole de sécurité Bitcoin vous rend-elle nerveux, indépendamment de la manière dont elle est résolue

@BabylonLabs_io $BABY #baby
L’accord de non-encapsulation a un astérisque exactement quand les choses tournent mal Je me suis plongé dans les mécanismes réels de liquidation de l’intégration d’Aave à Babylon, et j’ai trouvé un détail que personne ne met en une. En fonctionnement normal, $BTC est verrouillé dans un UTXO Taproot, sans encapsulation, sans pont, exactement l’histoire que tout le monde répète. Mais la liquidation est un autre moment. Lorsqu’une position est liquidée, l’échange s’effectue en WBTC avec une petite prime, et ce sont les arbitragistes qui achètent réellement ce vaultBTC puis le rachètent en Bitcoin natif une fois la fenêtre de preuve de fraude refermée. Ainsi, le système reste entièrement sans confiance jusqu’au moment exact où ça casse, et à cet instant précis, brièvement, le Bitcoin encapsulé réapparaît pour que les liquidations soient assez rapides pour avoir de l’importance. Le règlement Bitcoin est lent, les liquidations DeFi n’ont pas de patience, et il faut bien combler cet écart de calendrier. Je ne pense pas que ce soit un défaut, au sens strict. Ce pourrait même être la seule façon réaliste de concilier la vitesse de règlement de Bitcoin avec le fait que les marchés de prêt doivent se comporter comme il faut en période de stress. Mais cela signifie aussi que la « pureté » du discours a une couture exactement là où le risque est le plus élevé, pas là où le marketing pointe d’habitude. Un bref détour par un Bitcoin encapsulé pendant la liquidation mine-t-il la revendication sans confiance, ou c’est simplement à quoi ressemble un génie pragmatique sous pression @babylonlabs_io $BABY #baby {spot}(BTCUSDT) {spot}(BABYUSDT)
L’accord de non-encapsulation a un astérisque exactement quand les choses tournent mal

Je me suis plongé dans les mécanismes réels de liquidation de l’intégration d’Aave à Babylon, et j’ai trouvé un détail que personne ne met en une. En fonctionnement normal, $BTC est verrouillé dans un UTXO Taproot, sans encapsulation, sans pont, exactement l’histoire que tout le monde répète. Mais la liquidation est un autre moment. Lorsqu’une position est liquidée, l’échange s’effectue en WBTC avec une petite prime, et ce sont les arbitragistes qui achètent réellement ce vaultBTC puis le rachètent en Bitcoin natif une fois la fenêtre de preuve de fraude refermée.

Ainsi, le système reste entièrement sans confiance jusqu’au moment exact où ça casse, et à cet instant précis, brièvement, le Bitcoin encapsulé réapparaît pour que les liquidations soient assez rapides pour avoir de l’importance. Le règlement Bitcoin est lent, les liquidations DeFi n’ont pas de patience, et il faut bien combler cet écart de calendrier.

Je ne pense pas que ce soit un défaut, au sens strict. Ce pourrait même être la seule façon réaliste de concilier la vitesse de règlement de Bitcoin avec le fait que les marchés de prêt doivent se comporter comme il faut en période de stress. Mais cela signifie aussi que la « pureté » du discours a une couture exactement là où le risque est le plus élevé, pas là où le marketing pointe d’habitude.

Un bref détour par un Bitcoin encapsulé pendant la liquidation mine-t-il la revendication sans confiance, ou c’est simplement à quoi ressemble un génie pragmatique sous pression

@BabylonLabs_io $BABY #baby
Une mise, plusieurs réseaux, un mauvais jour partout à la fois On n’en parle pas assez. Si votre BTC misé peut sécuriser plus d’un réseau Bitcoin Secured en même temps, cela semble efficace. Le même capital, plusieurs missions de sécurité. Sur le papier, c’est très bien. Mais le risque corrélé fonctionne dans les deux sens. Un validateur qui fonctionne mal sur plusieurs réseaux ne se trompe pas une seule fois. Il échoue partout où il participe. Votre $BTC n’est plus exposé à une seule condition de slashing : il est exposé à autant de réseaux que le validateur touche. L’efficacité et la concentration sont essentiellement la même pièce, retournée. Je ne dis pas que cela détruit le modèle. Je dis que cela change ce que signifie une véritable vérification préalable (due diligence) pour quiconque mise via Babylon. Vous n’évaluez plus simplement la santé d’un seul réseau. Vous évaluez le comportement du validateur sur l’ensemble du portefeuille de réseaux que votre BTC contribue à sécuriser. La plupart des personnes qui misent ne vérifieront pas cela. Elles regarderont le rendement, verront la garde en autocontrôle, et miseront sans cartographier l’exposition du validateur à travers les réseaux. La sécurité partagée devrait-elle s’accompagner d’une transparence obligatoire sur le chevauchement des validateurs, ou est-ce trop demander à un système conçu pour rester simple pour l’utilisateur final @babylonlabs_io $BABY #baby {spot}(BTCUSDT) {spot}(BABYUSDT)
Une mise, plusieurs réseaux, un mauvais jour partout à la fois

On n’en parle pas assez.

Si votre BTC misé peut sécuriser plus d’un réseau Bitcoin Secured en même temps, cela semble efficace. Le même capital, plusieurs missions de sécurité. Sur le papier, c’est très bien.

Mais le risque corrélé fonctionne dans les deux sens.

Un validateur qui fonctionne mal sur plusieurs réseaux ne se trompe pas une seule fois. Il échoue partout où il participe. Votre $BTC n’est plus exposé à une seule condition de slashing : il est exposé à autant de réseaux que le validateur touche.

L’efficacité et la concentration sont essentiellement la même pièce, retournée.

Je ne dis pas que cela détruit le modèle. Je dis que cela change ce que signifie une véritable vérification préalable (due diligence) pour quiconque mise via Babylon. Vous n’évaluez plus simplement la santé d’un seul réseau. Vous évaluez le comportement du validateur sur l’ensemble du portefeuille de réseaux que votre BTC contribue à sécuriser.

La plupart des personnes qui misent ne vérifieront pas cela. Elles regarderont le rendement, verront la garde en autocontrôle, et miseront sans cartographier l’exposition du validateur à travers les réseaux.

La sécurité partagée devrait-elle s’accompagner d’une transparence obligatoire sur le chevauchement des validateurs, ou est-ce trop demander à un système conçu pour rester simple pour l’utilisateur final

@BabylonLabs_io $BABY #baby
Voir la traduction
Why does a Bitcoin security protocol even need its own chain This one bugged me for a bit. If the whole pitch is trustless Bitcoin staking with everything enforced through Bitcoin script and timelocks, why introduce Babylon Genesis chain into the picture at all. Doesn't adding another chain reintroduce the exact kind of extra trust surface this protocol is supposed to be avoiding. The answer I landed on is that Bitcoin itself cannot coordinate anything beyond simple locking conditions. It has no concept of validator sets, no way to track which Proof of Stake networks are being secured or how slashing gets enforced across dozens of different Bitcoin Secured Networks. Genesis chain exists to do the coordination and governance work that Bitcoin was never designed to handle, while the actual custody and staking commitment stays enforced at the Bitcoin layer itself. So it is less about adding trust and more about separating enforcement from orchestration. Bitcoin holds the guarantees, Genesis chain handles the bookkeeping and governance through BABY. Still, any additional chain is additional infrastructure that needs its own security assumptions, even if it never touches your actual staked $BTC . Does that separation actually hold up as more networks plug in, or does complexity creep back in through the coordination layer instead of the custody layer @babylonlabs_io $BABY #baby {spot}(BTCUSDT) {spot}(BABYUSDT)
Why does a Bitcoin security protocol even need its own chain

This one bugged me for a bit. If the whole pitch is trustless Bitcoin staking with everything enforced through Bitcoin script and timelocks, why introduce Babylon Genesis chain into the picture at all. Doesn't adding another chain reintroduce the exact kind of extra trust surface this protocol is supposed to be avoiding.

The answer I landed on is that Bitcoin itself cannot coordinate anything beyond simple locking conditions. It has no concept of validator sets, no way to track which Proof of Stake networks are being secured or how slashing gets enforced across dozens of different Bitcoin Secured Networks. Genesis chain exists to do the coordination and governance work that Bitcoin was never designed to handle, while the actual custody and staking commitment stays enforced at the Bitcoin layer itself.

So it is less about adding trust and more about separating enforcement from orchestration. Bitcoin holds the guarantees, Genesis chain handles the bookkeeping and governance through BABY. Still, any additional chain is additional infrastructure that needs its own security assumptions, even if it never touches your actual staked $BTC .

Does that separation actually hold up as more networks plug in, or does complexity creep back in through the coordination layer instead of the custody layer

@BabylonLabs_io $BABY #baby
Voir la traduction
Rego Policy Rules Are Only As Good As Whoever Writes Them $NEWT Newton runs evaluations through Rego, a declarative policy language, and that's the part nobody's poking at yet. Someone still has to actually author these rules correctly, and Rego is notoriously easy to write technically valid logic that doesn't do what you think it does. If a vault curator or protocol writes a flawed policy, the zk proof will happily confirm that flawed policy was followed perfectly. Verification proves the rule executed as written, it says nothing about whether the rule itself was smart. That's a human error surface sitting right underneath all this cryptographic guarantee. I want to see policy auditing tools before I trust curator written rules with real size. My exposure grows once there's a standard for reviewing Rego logic before it goes live on a vault. Proofs don't save you from bad policy design. @NewtonProtocol $NEWT #Newt {spot}(NEWTUSDT)
Rego Policy Rules Are Only As Good As Whoever Writes Them

$NEWT Newton runs evaluations through Rego, a declarative policy language, and that's the part nobody's poking at yet. Someone still has to actually author these rules correctly, and Rego is notoriously easy to write technically valid logic that doesn't do what you think it does. If a vault curator or protocol writes a flawed policy, the zk proof will happily confirm that flawed policy was followed perfectly. Verification proves the rule executed as written, it says nothing about whether the rule itself was smart. That's a human error surface sitting right underneath all this cryptographic guarantee.

I want to see policy auditing tools before I trust curator written rules with real size. My exposure grows once there's a standard for reviewing Rego logic before it goes live on a vault. Proofs don't save you from bad policy design.

@NewtonProtocol $NEWT #Newt
Article
Voir la traduction
Newton’s Airdrop Claim Window Quietly Taught A Lesson Most Projects Never Bother TeachingI went back and looked at how Newton actually ran its airdrop instead of just checking if I got tokens. It ran on a fixed thirty day claim window, and unclaimed tokens didn’t vanish or get redistributed to insiders. They went straight back into the Onchain Ecosystem Growth Fund, reserved for future campaigns, staking rewards, and grants instead of quietly disappearing. That’s a small design choice most projects skip, and it tells you something about how the Foundation thinks about unclaimed value belonging to the ecosystem rather than nobody. Eligibility timing mattered more than people realized going in. Most users needed to complete required actions by a set cutoff well before the claim window even opened, and users who came in through the Kaito rewards campaign got a slightly extended deadline. Anyone onboarding through a Magic Labs partner wallet still had to separately sign up on Newton’s own site using the same email before the window closed, which is a small friction point but a reasonable one for preventing duplicate claims across wallet integrations. The team running this isn’t anonymous either, and that actually matters for user trust in a protocol handling automated financial permissions. David Jeong, a director at the Foundation, spent years at Morgan Stanley doing quantitative research in algorithmic execution before founding Tread.fi, so the person shaping governance here has actual institutional execution background, not just crypto native experience. Mohammad Akhavannik running day to day operations brings a legal and policy background from Meta and top law firms, which lines up with how carefully the governance separation between configurable parameters and core protocol logic was structured. Here’s what I take from all this. An airdrop that returns unclaimed value to the ecosystem instead of burning it, combined with a team that has actual quant and legal execution background, doesn’t guarantee the protocol succeeds. But it does mean the people setting the rules for AI agents touching your wallet aren’t purely crypto opportunists learning governance for the first time. I still want to see how that judgment holds up once real adversarial pressure hits the system, credentials don’t survive contact with a live exploit on their own. @NewtonProtocol $NEWT #Newt

Newton’s Airdrop Claim Window Quietly Taught A Lesson Most Projects Never Bother Teaching

I went back and looked at how Newton actually ran its airdrop instead of just checking if I got tokens. It ran on a fixed thirty day claim window, and unclaimed tokens didn’t vanish or get redistributed to insiders. They went straight back into the Onchain Ecosystem Growth Fund, reserved for future campaigns, staking rewards, and grants instead of quietly disappearing. That’s a small design choice most projects skip, and it tells you something about how the Foundation thinks about unclaimed value belonging to the ecosystem rather than nobody.
Eligibility timing mattered more than people realized going in. Most users needed to complete required actions by a set cutoff well before the claim window even opened, and users who came in through the Kaito rewards campaign got a slightly extended deadline. Anyone onboarding through a Magic Labs partner wallet still had to separately sign up on Newton’s own site using the same email before the window closed, which is a small friction point but a reasonable one for preventing duplicate claims across wallet integrations.
The team running this isn’t anonymous either, and that actually matters for user trust in a protocol handling automated financial permissions. David Jeong, a director at the Foundation, spent years at Morgan Stanley doing quantitative research in algorithmic execution before founding Tread.fi, so the person shaping governance here has actual institutional execution background, not just crypto native experience. Mohammad Akhavannik running day to day operations brings a legal and policy background from Meta and top law firms, which lines up with how carefully the governance separation between configurable parameters and core protocol logic was structured.
Here’s what I take from all this. An airdrop that returns unclaimed value to the ecosystem instead of burning it, combined with a team that has actual quant and legal execution background, doesn’t guarantee the protocol succeeds. But it does mean the people setting the rules for AI agents touching your wallet aren’t purely crypto opportunists learning governance for the first time. I still want to see how that judgment holds up once real adversarial pressure hits the system, credentials don’t survive contact with a live exploit on their own.
@NewtonProtocol $NEWT #Newt
Voir la traduction
Seven Days Out And The Numbers Finally Match The Hype I stopped taking airdrop farming seriously a while ago because most seasons end with a token that nobody actually wants once trading opens. GRVT is the first one in months where I actually pulled up the metrics before the token generation event instead of after, and the open interest data alone made me sit up. Open interest went from roughly 11 million to 484 million during Season 2, that is not organic hype, that is real derivatives volume backing the points. TVL climbed from about 11 million to over 107 million in the same stretch. Cumulative trading volume crossed 393 billion double sided, and January alone printed 51.6 billion in monthly volume. Numbers like that usually show up after a token launches, not before it. With the TGE landing July 21 and community allocation now sitting at 28 percent of the fixed 1 billion supply, this is one of the rare cases where the fundamentals were already stacking up while everyone else was just farming points blindly. I have seen too many projects launch a token into thin volume and watch it get dumped within days. This one is launching into an exchange that already proved it can handle real size. That changes how I am thinking about post TGE positioning completely. Watching order books closely once trading opens. @grvt_io #grvt
Seven Days Out And The Numbers Finally Match The Hype

I stopped taking airdrop farming seriously a while ago because most seasons end with a token that nobody actually wants once trading opens. GRVT is the first one in months where I actually pulled up the metrics before the token generation event instead of after, and the open interest data alone made me sit up.

Open interest went from roughly 11 million to 484 million during Season 2, that is not organic hype, that is real derivatives volume backing the points. TVL climbed from about 11 million to over 107 million in the same stretch. Cumulative trading volume crossed 393 billion double sided, and January alone printed 51.6 billion in monthly volume. Numbers like that usually show up after a token launches, not before it.

With the TGE landing July 21 and community allocation now sitting at 28 percent of the fixed 1 billion supply, this is one of the rare cases where the fundamentals were already stacking up while everyone else was just farming points blindly. I have seen too many projects launch a token into thin volume and watch it get dumped within days.

This one is launching into an exchange that already proved it can handle real size. That changes how I am thinking about post TGE positioning completely.

Watching order books closely once trading opens.

@grvt_io #grvt
Les règles de politique bloquant des transactions légitimes sont le risque dont personne ne parle Tout le monde évoque Newton $NEWT stopping malicious settlement, mais inversons le raisonnement une seconde. Un moteur de politique suffisamment strict pour repérer les mauvais acteurs est aussi assez strict pour se tromper et sanctionner à tort des stratégies d’agents légitimes qui paraissent simplement inhabituelles sur le papier. Si ma stratégie automatisée est signalée et bloquée parce qu’elle ne correspond pas à un ensemble de règles prédéfinies, je subis du slippage et des entrées manquées pendant que le système me protège contre une menace qui n’a jamais existé. Les faux positifs dans une couche d’application des règles avant transaction ont un coût réel, pas seulement théorique. Personne n’a encore publié de données sur la fréquence à laquelle des transactions légitimes sont refusées par rapport aux cas réellement malveillants. Je veux connaître les taux de faux positifs avant de lui confier des montants réels. Mes stratégies ne peuvent pas se permettre d’être bloquées en cours d’exécution à cause d’un ensemble de règles trop prudent. La précision compte autant que la protection ici. @NewtonProtocol $NEWT #Newt {spot}(NEWTUSDT)
Les règles de politique bloquant des transactions légitimes sont le risque dont personne ne parle

Tout le monde évoque Newton $NEWT stopping malicious settlement, mais inversons le raisonnement une seconde. Un moteur de politique suffisamment strict pour repérer les mauvais acteurs est aussi assez strict pour se tromper et sanctionner à tort des stratégies d’agents légitimes qui paraissent simplement inhabituelles sur le papier. Si ma stratégie automatisée est signalée et bloquée parce qu’elle ne correspond pas à un ensemble de règles prédéfinies, je subis du slippage et des entrées manquées pendant que le système me protège contre une menace qui n’a jamais existé. Les faux positifs dans une couche d’application des règles avant transaction ont un coût réel, pas seulement théorique. Personne n’a encore publié de données sur la fréquence à laquelle des transactions légitimes sont refusées par rapport aux cas réellement malveillants.

Je veux connaître les taux de faux positifs avant de lui confier des montants réels. Mes stratégies ne peuvent pas se permettre d’être bloquées en cours d’exécution à cause d’un ensemble de règles trop prudent. La précision compte autant que la protection ici.

@NewtonProtocol

$NEWT

#Newt
Article
Voir la traduction
Newton’s Validators Are Still Foundation Run And That’s The Detail Everyone’s Ignoring$NEWT Everybody treats Newton like it’s already decentralized because the mainnet beta is live. It’s not, not yet. Validators securing the Keystore rollup right now are Foundation operated, and the roadmap explicitly lays out a staged handoff, moving first to a permissioned set of third party operators before eventually opening things up to a fully permissionless validator set. That’s a meaningful distinction most holders skip past when they see “restaked EigenLayer operators” and assume the network is already trustless end to end. There’s another migration sitting quietly in the background too. NEWT currently exists as a standard ERC-20 token, but it’s designed to migrate to a rollup native token standard once the Keystore infrastructure is fully deployed across chains. That’s not a cosmetic upgrade. A rollup native standard changes how the token interacts with state proofs and settlement, meaning wallets, exchanges, and integrated protocols will eventually need to support a different token implementation than the one currently listed everywhere. Governance decentralization follows a similar staged path. Right now the Foundation still controls core operational decisions, but the plan moves toward subject matter expert councils overseeing specific pieces of ecosystem development before full community governance takes over. Staked NEWT holders get voting rights as that transition progresses, covering things like reward rates and fee distribution, while core rollup logic changes still require validator coordinated hard forks regardless of how decentralized governance gets. Here’s what actually concerns me. Every one of these transitions, validator onboarding, token migration, governance handoff, represents a moment where something can break or get exploited during the switch itself. Migrations are where bugs live, not in stable running systems. I don’t think holders are pricing in that Newton has at least three separate infrastructure transitions still ahead of it, each one a fresh attack surface before this thing can honestly call itself decentralized. @NewtonProtocol $NEWT #Newt

Newton’s Validators Are Still Foundation Run And That’s The Detail Everyone’s Ignoring

$NEWT
Everybody treats Newton like it’s already decentralized because the mainnet beta is live. It’s not, not yet. Validators securing the Keystore rollup right now are Foundation operated, and the roadmap explicitly lays out a staged handoff, moving first to a permissioned set of third party operators before eventually opening things up to a fully permissionless validator set. That’s a meaningful distinction most holders skip past when they see “restaked EigenLayer operators” and assume the network is already trustless end to end.
There’s another migration sitting quietly in the background too. NEWT currently exists as a standard ERC-20 token, but it’s designed to migrate to a rollup native token standard once the Keystore infrastructure is fully deployed across chains. That’s not a cosmetic upgrade. A rollup native standard changes how the token interacts with state proofs and settlement, meaning wallets, exchanges, and integrated protocols will eventually need to support a different token implementation than the one currently listed everywhere.
Governance decentralization follows a similar staged path. Right now the Foundation still controls core operational decisions, but the plan moves toward subject matter expert councils overseeing specific pieces of ecosystem development before full community governance takes over. Staked NEWT holders get voting rights as that transition progresses, covering things like reward rates and fee distribution, while core rollup logic changes still require validator coordinated hard forks regardless of how decentralized governance gets.
Here’s what actually concerns me. Every one of these transitions, validator onboarding, token migration, governance handoff, represents a moment where something can break or get exploited during the switch itself. Migrations are where bugs live, not in stable running systems. I don’t think holders are pricing in that Newton has at least three separate infrastructure transitions still ahead of it, each one a fresh attack surface before this thing can honestly call itself decentralized.
@NewtonProtocol $NEWT #Newt
Voir la traduction
Trusting A CEX With Proof Instead Of Promises I have lost count of how many times an exchange told us our funds were safe right before everything collapsed. That is the entire reason on chain ZK settlement matters to me now, GRVT is not asking me to trust a balance sheet I cannot see, the proofs are verifiable instead of just promised in a blog post after something already broke. Centralized exchanges historically operate on faith, you assume the reserves are there until a withdrawal freeze proves otherwise. GRVT flips that by settling trades through zero knowledge proofs on chain while still running execution off chain for speed, so the safety net is mathematical rather than reputational. That distinction hits different after watching multiple platforms implode where users found out too late that their exposure was never actually backed the way it claimed. Here the settlement layer does not care about vibes or trust me bro announcements, it just verifies. Licensed operation on top of that removes another layer of blind faith, this is not some anonymous team hoping regulators never notice them. $GRVT holding a fixed 1 billion supply cap gives the token side of this equation the same kind of predictability the settlement architecture already provides. Watching how this holds up as bigger players start allocating size. @grvt_io #grvt
Trusting A CEX With Proof Instead Of Promises

I have lost count of how many times an exchange told us our funds were safe right before everything collapsed. That is the entire reason on chain ZK settlement matters to me now, GRVT is not asking me to trust a balance sheet I cannot see, the proofs are verifiable instead of just promised in a blog post after something already broke.

Centralized exchanges historically operate on faith, you assume the reserves are there until a withdrawal freeze proves otherwise. GRVT flips that by settling trades through zero knowledge proofs on chain while still running execution off chain for speed, so the safety net is mathematical rather than reputational.

That distinction hits different after watching multiple platforms implode where users found out too late that their exposure was never actually backed the way it claimed. Here the settlement layer does not care about vibes or trust me bro announcements, it just verifies.

Licensed operation on top of that removes another layer of blind faith, this is not some anonymous team hoping regulators never notice them. $GRVT holding a fixed 1 billion supply cap gives the token side of this equation the same kind of predictability the settlement architecture already provides.

Watching how this holds up as bigger players start allocating size.

@grvt_io #grvt
Voir la traduction
Gas Deltas Are Going To Decide Where Volume Actually Goes Newton runs on both Base and Ethereum mainnet but the execution cost between those two chains isn't even close, and that difference changes how agents actually behave in practice. If policy enforcement adds any extra computation on top of a normal transaction, that overhead gets multiplied by whatever gas environment you're in. On Base it's probably negligible, but on Ethereum mainnet during any real congestion that added verification step could make automated strategies unprofitable before they even settle. Nobody's published numbers comparing the actual cost delta between the two chains under this new enforcement layer. I'd bet most serious agent activity migrates toward Base purely on cost, not because Ethereum $ETH is less secure. But if that happens fast, Ethereum side liquidity for this system could end up thin while everyone chases cheaper execution. Watching gas data before I size up. @NewtonProtocol $NEWT #Newt {spot}(ETHUSDT) {spot}(NEWTUSDT)
Gas Deltas Are Going To Decide Where Volume Actually Goes

Newton runs on both Base and Ethereum mainnet but the execution cost between those two chains isn't even close, and that difference changes how agents actually behave in practice. If policy enforcement adds any extra computation on top of a normal transaction, that overhead gets multiplied by whatever gas environment you're in. On Base it's probably negligible, but on Ethereum mainnet during any real congestion that added verification step could make automated strategies unprofitable before they even settle. Nobody's published numbers comparing the actual cost delta between the two chains under this new enforcement layer.

I'd bet most serious agent activity migrates toward Base purely on cost, not because Ethereum $ETH is less secure. But if that happens fast, Ethereum side liquidity for this system could end up thin while everyone chases cheaper execution. Watching gas data before I size up.

@NewtonProtocol $NEWT #Newt
Le slippage sur un DEX m’a appris à détester l’attente Quiconque a déjà essayé de trader une taille réelle sur une application décentralisée connaît la routine : vous signez une transaction, vous attendez la confirmation, vous voyez votre prix évoluer contre vous, puis vous recommencez pour la prochaine étape du trade. GRVT supprime entièrement cette boucle grâce à un moteur de matching de 600k TPS qui donne vraiment l’impression d’une bourse centralisée, tout en conservant un règlement en chaîne via des preuves ZK. Ce qui m’a convaincu n’était pas seulement la vitesse : c’était la possibilité de passer entre des crypto perp et une exposition RWA, comme l’or et le pétrole, au sein de la même interface, sans changer de plateforme ni faire manuellement de pont entre des actifs. Sur les configurations DEX traditionnelles, la profondeur de marché pour tout ce qui ne concerne pas les majors est généralement faible, et le slippage grignote votre entrée avant même que vous ne soyez à l’aise dans la position. Ici, l’exécution ressemble davantage à un carnet d’ordres de CEX : les exécutions sont suffisamment rapides pour que je ne reste pas à surveiller une transaction en attente pendant que ma thèse devient obsolète. Cet écart entre l’autonomie d’un DEX et la rapidité d’un CEX est précisément là où la plupart des plateformes échouent : elles choisissent l’un et sacrifient l’autre. GRVT a un plafond d’offre fixe de 1 milliard, ce qui me donne au moins un chiffre clair à suivre par rapport à l’open interest pendant que cela attire davantage l’attention. Je continue de surveiller comment ça évolue quand le volume augmente. @grvt_io #grvt
Le slippage sur un DEX m’a appris à détester l’attente

Quiconque a déjà essayé de trader une taille réelle sur une application décentralisée connaît la routine : vous signez une transaction, vous attendez la confirmation, vous voyez votre prix évoluer contre vous, puis vous recommencez pour la prochaine étape du trade. GRVT supprime entièrement cette boucle grâce à un moteur de matching de 600k TPS qui donne vraiment l’impression d’une bourse centralisée, tout en conservant un règlement en chaîne via des preuves ZK.

Ce qui m’a convaincu n’était pas seulement la vitesse : c’était la possibilité de passer entre des crypto perp et une exposition RWA, comme l’or et le pétrole, au sein de la même interface, sans changer de plateforme ni faire manuellement de pont entre des actifs. Sur les configurations DEX traditionnelles, la profondeur de marché pour tout ce qui ne concerne pas les majors est généralement faible, et le slippage grignote votre entrée avant même que vous ne soyez à l’aise dans la position.

Ici, l’exécution ressemble davantage à un carnet d’ordres de CEX : les exécutions sont suffisamment rapides pour que je ne reste pas à surveiller une transaction en attente pendant que ma thèse devient obsolète. Cet écart entre l’autonomie d’un DEX et la rapidité d’un CEX est précisément là où la plupart des plateformes échouent : elles choisissent l’un et sacrifient l’autre.

GRVT a un plafond d’offre fixe de 1 milliard, ce qui me donne au moins un chiffre clair à suivre par rapport à l’open interest pendant que cela attire davantage l’attention.

Je continue de surveiller comment ça évolue quand le volume augmente.

@grvt_io #grvt
Article
Voir la traduction
Newton’s Reputation Layer Is The Part Everyone Skipped And It’s Actually The Interesting BitForget the proofs for a second. Every agent operating on Newton accumulates reputation based on how it behaves against its own permission scope, and violations trigger real economic penalties, not just a warning label. That’s a different mechanism from slashing validators. This is scoring the agent itself, tracking a wallet level execution history that gets checked every time a new automation intent comes in referencing that same model. Wallet tracking here isn’t just a block explorer showing balances. It’s tied directly to the Model Registry, where every agent model is published with a reference id, and each wallet interacting with that agent builds a traceable chain of intents, approvals, and executed actions. Developers listing a model post collateral in NEWT, and that collateral is what actually gets touched if the agent’s reputation tanks from repeated rule violations. Users can theoretically audit an agent’s full track record before granting it a single permission. The catch is enforcement timing. Reputation penalties apply after a violation is detected, which means the punishment is retroactive by definition. A ZKP can stop a transaction that violates a hard permission boundary before it executes, but a reputation score can’t stop an agent from technically staying inside its permission scope while still making objectively bad calls for the user. Scoped autonomy protects against theft, it doesn’t protect against a mediocre strategy executed perfectly within its rules. That gap is where I’d put my attention if I were stress testing this thing. A reputation system sounds like accountability, but it’s really just a lagging indicator dressed up as a control. It works fine when volume is low and violations are rare enough to actually get flagged and priced in before damage compounds. Under real stress, with hundreds of agents firing simultaneously, I don’t think reputation scoring reacts fast enough to matter before the damage is already done. @NewtonProtocol $NEWT #Newt

Newton’s Reputation Layer Is The Part Everyone Skipped And It’s Actually The Interesting Bit

Forget the proofs for a second. Every agent operating on Newton accumulates reputation based on how it behaves against its own permission scope, and violations trigger real economic penalties, not just a warning label. That’s a different mechanism from slashing validators. This is scoring the agent itself, tracking a wallet level execution history that gets checked every time a new automation intent comes in referencing that same model.
Wallet tracking here isn’t just a block explorer showing balances. It’s tied directly to the Model Registry, where every agent model is published with a reference id, and each wallet interacting with that agent builds a traceable chain of intents, approvals, and executed actions. Developers listing a model post collateral in NEWT, and that collateral is what actually gets touched if the agent’s reputation tanks from repeated rule violations. Users can theoretically audit an agent’s full track record before granting it a single permission.
The catch is enforcement timing. Reputation penalties apply after a violation is detected, which means the punishment is retroactive by definition. A ZKP can stop a transaction that violates a hard permission boundary before it executes, but a reputation score can’t stop an agent from technically staying inside its permission scope while still making objectively bad calls for the user. Scoped autonomy protects against theft, it doesn’t protect against a mediocre strategy executed perfectly within its rules.
That gap is where I’d put my attention if I were stress testing this thing. A reputation system sounds like accountability, but it’s really just a lagging indicator dressed up as a control. It works fine when volume is low and violations are rare enough to actually get flagged and priced in before damage compounds. Under real stress, with hundreds of agents firing simultaneously, I don’t think reputation scoring reacts fast enough to matter before the damage is already done.
@NewtonProtocol $NEWT #Newt
Connectez-vous pour découvrir plus de contenu
Rejoignez la communauté mondiale des adeptes de cryptomonnaies sur Binance Square
⚡️ Suviez les dernières informations importantes sur les cryptomonnaies.
💬 Jugé digne de confiance par la plus grande plateforme d’échange de cryptomonnaies au monde.
👍 Découvrez les connaissances que partagent les créateurs vérifiés.
Adresse e-mail/Nº de téléphone
Plan du site
Préférences de cookies
CGU de la plateforme