Aadi33

Aveu du marché #38

J’ai une étrange habitude.

Dès que tout le monde commence à dire : « Cette fois, c’est différent », je cesse de regarder le graphique et je commence à observer la foule.

Les marchés changent. La psychologie humaine, rarement.

J’ai appris que la conviction la plus bruyante apparaît souvent près des tournants, non pas parce que tout le monde se trompe, mais parce que la certitude atteint son sommet lorsque le risque est déjà intégré.

La foule a de meilleurs antécédents pour se tromper que le marché.

C’est pourquoi je prête davantage attention à la confiance qu’au consensus.

$BNB #MarketSentimentToday
#MarketPsychology #SmartMoney #Cryptomindset

Confession de marché #37

Je ne sais pas vraiment pourquoi je vends comme je le fais. Je le fais, tout simplement, puis j’invente une raison après.

J’ai commencé à regarder mes propres transactions comme celles d’un étranger. La même configuration, la même peur, le même point de sortie, à chaque fois. Pas d’analyse. La mémoire musculaire déguisée en décision.

Alors j’ai commencé à me poser une question avant chaque transaction : est-ce que je fais ça à cause du graphique, ou parce que la précédente m’a fait mal.

Le plus souvent, c’est la deuxième.

Il s’avère que le marché ne teste pas vos prévisions. Il teste si vous vous êtes déjà rencontré.

$BTC $BNB $ZEC #crypto #BinanceSquare

Les ETF Bitcoin viennent de mettre fin à une série de sorties sur 8 semaines avec 197 millions de dollars d’entrées nettes fraîches.

Les institutions font discrètement marche arrière.

Une semaine verte ne confirme pas une nouvelle tendance, mais c’est le premier signe significatif que la pression de vente pourrait commencer à s’atténuer. Si les entrées en ETF se poursuivent au cours des prochaines semaines, le sentiment du marché pourrait évoluer bien plus vite que la plupart ne l’anticipent.

L’argent intelligent ne retentit pas au bas du cycle.

Il s’accumule pendant que la foule débat encore.

#bitcoin #BTC #etf #crypto #BinanceSquare
$BTC

On suppose souvent que des actifs réels tokenisés portent le même modèle de risque que les actifs qu’ils représentent : une obligation du Trésor tokenisée se comporte comme une obligation du Trésor, simplement avec une exécution plus rapide.

J’ai examiné comment @NewtonProtocol évalue le risque réel dans les RWA, et en fait ce n’est pas tellement lié à l’actif sous-jacent. La documentation de Newton pointe vers la compromission de la clé d’administration, la manipulation de la valeur liquidative (NAV) ou des oracles, et la création non autorisée de jetons comme modèle de menace réel. Ce sont des risques qui existent à cause de la façon dont le jeton est émis et géré onchain, et non à cause de quoi que ce soit concernant l’obligation du Trésor elle-même.

Ce que Newton impose, ce sont des invariants d’exécution spécifiquement à ce sujet : des contraintes qui tiennent quels que soient les détenteurs de la clé d’administration. Les garde-fous pour la frappe et le rachat garantissent que seuls des investisseurs éligibles participent. Les contrôles d’intégrité de la NAV recoupent les prix des oracles avec des seuils de tolérance. Ce ne sont pas des autorisations que quiconque aurait un accès élevé pourrait contourner : elles sont vérifiées au niveau de la transaction à chaque fois.

Voici ce qui m’intéresse vraiment. Pour la plupart des actifs tokenisés, si quelqu’un obtient la clé d’administration, c’est essentiellement tout le jeu : il peut frapper des jetons sans autorisation, vider un trésor, contourner les « contrôles » censés être en place. La clé était le contrôle. Les invariants d’exécution brisent volontairement ce lien : obtenir la clé ne signifie donc pas automatiquement obtenir aussi la contrainte.

Je serais curieux de savoir si ces invariants ont réellement été testés dans un scénario de compromission de clé d’administration réelle, ou si cette garantie est encore majoritairement théorique à ce stade.

$NEWT #Newt
#BinanceTurns9



Les invariants d’exécution empêcheraient-ils réellement une clé d’administration compromise ?

Les gens supposent que si une passerelle refuse de traiter votre requête, vous êtes bloqué.

D’après ce que j’ai lu, Newton dispose d’un mécanisme d’inclusion par force qui permet aux applications d’envoyer des tâches directement au réseau de l’opérateur, au lieu de passer par la passerelle. Si c’est exact, cela signifie que la passerelle n’est pas un goulot d’étranglement permanent, ce qui constitue une propriété importante pour la résistance à la censure.

Ce dont je suis moins sûr, c’est le côté pratique.

En empruntant ce chemin, il faut probablement gérer le travail que la passerelle abstrait normalement, comme le routage et la coordination avec le réseau de l’opérateur. Cela soulève la question de savoir si l’inclusion par force est quelque chose qu’une application « moyenne » pourrait réellement utiliser pendant une panne ou un événement de censure, ou si c’est surtout pratique pour des équipes disposant d’une infrastructure conséquente.

Quelqu’un ici a-t-il réellement testé l’inclusion par force de bout en bout ? Je serais intéressé par de savoir comment ça marche en pratique par rapport à la façon dont c’est décrit sur papier.

@NewtonProtocol $NEWT #Newt
$ZEC $BTC

La plupart des gens supposent souvent que l’infrastructure de mise en conformité (compliance) pour les institutions est l’œuvre d’une boutique RegTech spécialisée, très impliquée dans le travail réglementaire mais encore nouvelle dans l’infrastructure crypto à l’échelle grand public. En général, c’est une hypothèse plutôt prudente pour ce type de produit.

Ce n’est pas le cas avec @NewtonProtocol . Le développeur principal, c’est Magic Labs, et je n’avais pas fait le lien jusqu’à ce que je regarde qui se cache réellement derrière. Ils ont construit des wallets embarqués — une infrastructure qui permet à une application de faire entrer des utilisateurs sans jamais leur montrer une phrase secrète (seed phrase). Soutenu par PayPal Ventures, déjà déployé à grande échelle réelle : plus de 57 millions de wallets, plus de 200 000 développeurs, et c’est la couche portefeuille qui alimente Polymarket.

Cela change la façon dont je lis le risque d’exécution de Newton. Une grande partie de l’infrastructure crypto orientée conformité est construite par des équipes fortes sur le plan réglementaire, mais relativement nouvelles en matière de déploiement à une échelle significative. Magic Labs, eux, font l’inverse : ils ont déjà résolu la distribution et la fiabilité, spécifiquement pour l’infrastructure de wallets. Newton n’est pas une équipe qui tente, pour la première fois, de gérer un volume de transactions réel ; c’est une équipe déjà établie qui s’étend à un problème adjacent.

Cela dit, ce que je mettrais en avant, c’est que les wallets embarqués et l’autorisation pilotée par des politiques sont de vrais problèmes d’ingénierie différents. L’infrastructure portefeuille, c’est surtout la gestion des clés et la disponibilité. La couche d’autorisation de Newton implique un consensus décentralisé d’opérateurs, des attestations cryptographiques, et la résolution des litiges via des preuves à divulgation nulle (zero-knowledge proofs). Le fait d’avoir une expertise dans l’un ne se transfère pas automatiquement à l’autre.

Ce n’est pas une faiblesse,.. juste une raison d’être précis. Je serais curieux de savoir quelle part de la conception des opérateurs et du consensus de Newton est menée par des personnes ayant fait leurs preuves dans ce domaine précis, plutôt que par l’équipe côté wallets qui s’y étend.

@NewtonProtocol $NEWT #Newt
#Polymarket #MagicLabs #zkProofs
$SXT $LAB

Beaucoup de gens supposent qu’un transfert de stablecoin soit il est bloqué soit il ne l’est pas, succès ou échec, avec un simple test.

Cependant, les éléments de conformité des stablecoins de Newton incluent une partie d’attribution liée à la Travel Rule, qui n’est pas vraiment du type « passe ou échoue » comme le dépistage des sanctions. La Travel Rule vise à faire en sorte que les informations relatives à l’initiateur et au bénéficiaire suivent le transfert au-delà de certains seuils : qui l’a envoyé, qui le reçoit, avec ces informations associées de manière sécurisée au transfert.

C’est donc un type de contrôle différent de celui qui consiste à bloquer un mauvais acteur. Le dépistage des sanctions est binaire : l’expéditeur figure sur une liste ou non. La Travel Rule concerne davantage le fait de s’assurer que les informations requises suivent le transfert entre entités réglementées, et pas seulement d’être vérifiées une fois puis oubliées.

Ce qui est vraiment intéressant, c’est que cela ne se déclenche que pour les transferts admissibles, au-delà du seuil qui le déclenche. Ainsi, la plupart des transferts de stablecoins de taille retail ne touchent jamais cela : c’est conçu pour les transferts suffisamment importants pour que les régulateurs se soucient réellement de la piste documentaire.

Je ne suis toutefois pas sûr de la manière dont cela tient compte en inter-chaînes. Si l’origine d’un transfert se trouve sur une blockchain et qu’il va vers une blockchain de destination via l’ensemble d’opérateurs synchronisés de Newton, les informations sur l’initiateur passent-elles proprement, ou bien quelque chose se perd en coordonnant les informations d’identité au-delà de cette frontière ? L’attribution n’a de sens que si elle survit à tout le trajet, pas seulement au premier saut.

J’aimerais savoir si quelqu’un a réellement testé un transfert soumis à la Travel Rule qui traverse plusieurs chaînes en une seule fois, ou si c’est surtout testé au sein d’une seule chaîne jusque-là.

@NewtonProtocol $NEWT #Newt
$PYR $HMSTR

#RetailStockBuyingLowestSince2020 #JapanUrgesGPIFToBoostDomesticAssets #SKHynixCompletesRecordUSListing

Les gens supposent souvent qu’un coffre « curated » signifie que quelqu’un surveille réellement le risque en temps réel, avec une équipe qui contrôle des tableaux de bord, prête à réagir dès que quelque chose semble anormal.

Dans la plupart des cas, ce n’est pas du tout comme ça. « Curated » signifie généralement simplement que quelqu’un a rédigé les règles une fois. L’application concrète se fait transaction par transaction, au moment où quelque chose tente de bouger, et non via une surveillance continue en arrière-plan.

J’ai étudié la manière dont @NewtonProtocol gère cela pour des cas d’usage RWA et de coffres en particulier. Newton propose des packs de politiques, des ensembles de modules Rego précomposés, qui incluent des contrôles d’intégrité de la NAV en recoupant les prix des oracles avec des bornes de tolérance configurées, ainsi que des garde-fous d’éligibilité pour l’émission et le rachat. Ces vérifications s’exécutent au moment même de la transaction. Personne n’est tenu de regarder un écran. Le contrôle est simplement là et se déclenche lorsqu’il est « triggered ».

C’est une amélioration réelle par rapport au fait de compter sur un humain pour détecter un problème après coup, ce qui est généralement trop tard. Mais cela signifie aussi que la protection du coffre n’est aussi bonne que ce que garantissent les bornes de tolérance et les règles configurées lors de la rédaction initiale de la politique. Si le marché évolue d’une manière que personne n’avait anticipée lorsque ces bornes ont été définies, le contrôle continue de s’exécuter. Il se peut simplement qu’il ne vérifie plus par rapport au bon seuil.

Je ne dis pas que c’est un défaut de conception. C’est simplement le genre d’hypothèse dont il vaut la peine d’être conscient. La protection n’est pas une vigilance continue : c’est une règle écrite à l’avance, appliquée de manière cohérente, mais qui n’est mise à jour que jusqu’au dernier moment où quelqu’un l’a modifiée.

Je serais intéressé de savoir à quelle fréquence ces bandes de tolérance sont réellement revues une fois qu’un coffre est en service, ou si elles sont typiquement définies une fois puis laissées telles quelles.
@NewtonProtocol $NEWT #Newt
$LAB $TAG #LABTokenDrops94% #USNaturalGasFallsOver6%

On suppose que, lorsqu’un système choisit sa cryptographie, c’est essentiellement verrouillé. L’enlever plus tard et tout reconstruire revient à refaire la moitié du système.

Cependant, la couche de confidentialité de Newton n’est pas conçue comme ça. Elle utilise l’HPKE, qui combine vraiment trois éléments interchangeables : l’échange de clés, la dérivation de clés et le chiffrement lui-même. Comme ces composants sont modulaires plutôt que fusionnés, remplacer l’échange de clés par un équivalent post-quantique serait apparemment juste une modification de configuration, pas une reconstruction.

Ça semble pratique… jusqu’à ce que vous réalisiez que l’HPKE a été littéralement conçue pour ça. Newton n’a pas inventé cette flexibilité ; ils se sont simplement appuyés sur quelque chose qui l’avait déjà. Et le NIST a déjà standardisé les remplacements post-quantiques en 2024, donc les pièces existent déjà, prêtes à être remplacées dès que nécessaire.

Ma première réaction a été : casser le chiffrement avec des ordinateurs quantiques ressemble à un problème « de someday », pas à quelque chose d’urgent. Mais c’est un peu le piège : les données chiffrées récupérées aujourd’hui peuvent simplement rester en attente et être déchiffrées plus tard, une fois que la capacité existera. Une migration peu coûteuse plus tard compte donc maintenant, même si, pour l’instant, cela ne semble pas urgent.

Ce sur quoi je continue de réfléchir, toutefois, c’est que cela ne couvre que le côté chiffrement. Les opérateurs signent des attestations avec des signatures agrégées BLS, et c’est un système cryptographique totalement distinct des clés de chiffrement. Rien de ce que j’ai vu n’aborde ce qu’une migration de BLS exigerait même. Contrairement à l’échange de clés modulaire de l’HPKE, les signatures ne sont pas conçues comme un remplacement simple « plug and play », donc je m’attendrais à ce que la migration soit substantiellement plus impliquée.

Ainsi, « notre chiffrement est prêt pour le quantique » et « tout notre stack est prêt pour le quantique » ne font pas la même affirmation. Ça ne sonne pareil qu’en apparence.

Je suis curieux : est-ce que quelqu’un a réellement examiné à quoi ressemblerait un chemin post-quantique pour la partie signatures ici, ou si c’est encore une question de conception ouverte.

@NewtonProtocol $NEWT #Newt
$LAB $SKYAI
#quantum

On suppose souvent qu’une fois votre identité vérifiée, le service qui gère la vérification a réellement consulté vos documents, les a évalués et se contente ensuite de mémoriser le résultat.

La vérification d’identité de Newton est conçue différemment. La vérification s’exécute à l’intérieur d’un TEE, un Trusted Execution Environment (environnement d’exécution de confiance), de sorte que l’infrastructure habituelle du vérificateur n’accède jamais directement aux données d’identité sous-jacentes. Le vérificateur reçoit le résultat de la vérification plutôt que les entrées brutes elles-mêmes.

C’est un modèle de sécurité différent de celui du seul chiffrement. Le chiffrement protège les données lorsqu’elles sont stockées ou transmises, mais, pour effectuer la vérification, il faut généralement les déchiffrer. Un TEE vise à isoler même ce calcul, de sorte que l’hôte qui exécute le système ne puisse pas inspecter ce qui se passe à l’intérieur de l’enclave.

Cela correspond aussi au modèle d’identité plus large de Newton. Les vérificateurs valident des preuves de justificatifs sans apprendre l’information personnelle sous-jacente. L’objectif n’est pas seulement de « garder les données off chain », mais aussi de les empêcher d’être visibles par le vérificateur.

La question restante concerne la confiance. Les TEE réduisent la quantité de confiance à accorder au vérificateur, mais ils ne suppriment pas totalement cette confiance. Au contraire, une partie de celle-ci se déplace vers l’implémentation du TEE, le fabricant du matériel, le micrologiciel et le processus d’attestation. Les TEE ont déjà présenté dans le passé de vraies vulnérabilités matérielles et des failles liées aux canaux auxiliaires (side channel). Ce sont donc davantage des mécanismes de réduction du risque que des garanties.

Ce qui m’intéresse le plus, c’est le modèle d’échec. Si une vulnérabilité sérieuse de TEE était découverte dans le matériel sur lequel Newton s’appuie, que se passe-t-il pour les identifiants (credentials) qui ont été validés précédemment via ces enclaves ? L’impact serait-il limité aux attestations futures uniquement une fois la vulnérabilité connue, ou bien des sessions de vérification antérieures pourraient-elles aussi être considérées comme compromises ? Et si cela se produisait, existe-t-il un processus de reprise documenté, par exemple la révocation des enclaves de confiance, la rotation des clés d’attestation, ou l’exigence de re-vérifier les credentials ?
$NEWT @NewtonProtocol #Newt
$LAB $TLM #labcrashed

Les gens supposent qu’une fois qu’un protocole dit « préservant la confidentialité », c’est essentiellement l’état final : la partie difficile serait faite et il ne resterait que des détails d’implémentation.

Ce n’est pas vraiment le cas avec le plan à long terme de Newton. Il y a une section entière dans le livre blanc sur le chiffrement homomorphe totalement (FHE), qui correspond à la version idéale de ce concept : exécuter directement le calcul de la politique sur des données chiffrées, sans jamais les déchiffrer à aucun moment. Pas d’étape de déchiffrement par seuil. Aucune donnée en clair n’est exposée pendant l’évaluation.

Sauf que pour l’instant, c’est simplement listé comme une direction de recherche. Pas encore implémenté. La percée originale de Craig Gentry sur le FHE date de 2009, et même aujourd’hui, c’est encore plusieurs ordres de grandeur plus lent que le calcul sur des données en clair. Pour le cas d’usage de Newton, qui repose surtout sur des vérifications booléennes et des comparaisons par seuil, le livre blanc indique que cela se situe plutôt vers l’extrémité basse de cette gamme, mais cela reste très loin d’un scénario réellement exploitable en production.

Il y a donc toute une feuille de route entre l’endroit où se situe aujourd’hui le modèle de confidentialité et l’endroit où le livre blanc indique qu’il arrivera. La version actuelle repose sur le déchiffrement par seuil : les données sont déchiffrées pendant l’évaluation de la politique, plutôt que de rester chiffrées de bout en bout. La couche MPC qui suit vise à éviter de reconstruire le texte en clair pendant l’évaluation. Puis, avec la FHE, la politique pourrait être évaluée directement sur des données chiffrées, supprimant le besoin de MPC interactif.

Je respecte le fait qu’ils soient transparents sur le fait que c’est une recherche sur plusieurs années plutôt que de prétendre que c’est proche. Mais cela signifie aussi que quand les gens lisent « préservant la confidentialité », il vaut la peine de se demander quel modèle de confidentialité ils obtiennent dès maintenant, par rapport à celui que la feuille de route vise.

Je me demande combien de personnes qui utilisent réellement cette solution savent qu’il existe une différence entre ces deux aspects, ou si tout est simplement perçu comme une garantie globale de confidentialité.

@NewtonProtocol $NEWT #Newt
$LAB $TLM

On suppose souvent que, une fois qu’un smart contract est déployé, ses règles suffisent à garantir la sécurité des utilisateurs et des actifs. Pour les protocoles qui gèrent un capital significatif, de nombreuses garanties importantes existent encore en dehors de la blockchain.

Je me suis intéressé à la manière dont @NewtonProtocol s’y prend. Au lieu de s’appuyer sur des listes de contrôle hors chaîne ou sur une surveillance manuelle, il permet d’appliquer des politiques onchain avant qu’une transaction n’arrive au règlement. Ces politiques peuvent couvrir la conformité, l’identité, la sécurité et le risque, et ainsi s’intégrer au flux d’exécution plutôt qu’à un simple ajout après coup.

Cela change l’arbitrage. Plutôt que de faire confiance à chaque application pour implémenter et maintenir ses propres contrôles, les protocoles peuvent référencer une couche d’autorisation commune qui évalue les transactions par rapport à des politiques aCtive avant qu’elles ne poursuivent leur traitement. En théorie, cela rend l’application plus cohérente entre différentes applications.

Le point intéressant, c’est la gestion des politiques dans le temps. Les conditions de risque évoluent, les exigences de conformité changent et des menaces de sécurité apparaissent sans prévenir. Le défi n’est pas seulement d’appliquer des politiques onchain, mais de les mettre à jour sans créer d’incertitude sur les règles qui étaient actives au moment où A transaction a été autorisée.

Je ne dis pas que c’est une faille. C’est simplement le type d’hypothèse de conception qui mérite d’être surveillée. Une couche d’autorisation n’est utile que dans la mesure où les politiques qu’elle applique sont fiables et transparentes.

J’aimerais savoir comment Newton prévoit d’équilibrer des mises à jour rapides des politiques avec le besoin de décisions d’autorisation prévisibles et auditables.

@NewtonProtocol $NEWT #Newt
$TLM $VANRY
#SKHynixToIssue177.9MillionADSs