Vitorhrds

Sur $ETH , une transaction avec blobs comporte deux coûts distincts : le gas d’exécution de l’EVM et le blob gas pour les données. L’EIP-4844 stipule que les frais liés aux blobs sont débités avant l’exécution et ne sont pas remboursés si la transaction échoue. Ainsi, une annulation de l’EVM n’élimine pas le coût de mise à disposition des données. Lors de l’examen d’une transaction, `maxFeePerGas` ne suffit pas : vérifiez également `maxFeePerBlobGas`.

Source : EIP-4844 — Shard Blob Transactions : https://eips.ethereum.org/EIPS/eip-4844

La preuve de réserves a une date de référence. Dans son annonce du 2/11, Binance a indiqué avoir terminé la preuve ZK pour le snapshot du 31/10 à 00:00 UTC ; les clients détenant l’un des dix actifs couverts peuvent vérifier si leur solde était adossé à au moins 1:1 à cette date. Il s’agit d’un point vérifiable dans le temps — pas d’un tableau de bord en temps réel, ni d’une couverture des actifs qui ne figurent pas sur la liste. Pour le $BTC , mieux vaut examiner la date et le périmètre avant d’interpréter « 1:1 » comme une garantie permanente. La prochaine collecte a été annoncée pour le 4/11 ; la génération de la preuve devrait prendre 40 à 50 heures.

Source : Binance, Recovery Update #5 (02/11/2026) : https://www.binance.com/en/support/announcement/detail/185bd9a4717f44088b3be70287b8237f

Dans le minage de $BTC , l’automatisation des flottes se heurte à un problème peu glamour : chaque ASIC, pool et système possède sa propre interface.

Le MDK de Tether tente de résoudre ce problème avec les *Workers* : des adaptateurs qui traduisent des systèmes spécifiques en une couche commune, permettant aux applications d’intégrer le protocole plutôt que de créer une nouvelle connexion pour chaque fournisseur.

Le 24/10, Tether a déclaré que 15 participants s’étaient engagés à développer et à maintenir des intégrations. Cela ne prouve pas encore que tous les Workers sont opérationnels. La documentation précise elle-même que la version 0.x est toujours en développement et n’est pas destinée à la production ; la version 1.0 est la première étape prévue comme prête pour la production, avec une sortie visée en décembre.

Pour mesurer les progrès, il vaut mieux suivre les tests en conditions réelles et la stabilité des interfaces, plutôt que de se fier uniquement à la liste des participants.

Sources : Tether, 24/10/2026 : https://tether.io/news/tethers-mdk-gains-broad-industry-backing-to-accelerate-the-next-generation-of-bitcoin-mining-automation/ ; feuille de route du MDK : https://docs.mdk.tether.io/support/resources/roadmap/

En $USDT, l’excédent de réserves doit être interprété en tenant compte de la date et du périmètre du rapport.

Le document du 30/09/2026 fait état d’actifs de US$ 191,45 milliards et de passifs de US$ 183,50 milliards, soit un excédent de US$ 7,95 milliards. BDO a émis une assurance raisonnable sur ce rapport spécifique ; il ne constitue pas un jeu complet d’états financiers, exclut les notes de son périmètre et ne couvre que cette date.

Cet instantané est utile, mais ne prouve pas que tous les actifs puissent être convertis immédiatement en liquidités en cas de stress extrême. Le rapport lui-même indique que les évaluations tiennent compte de conditions normales de marché.

Sources : Tether/BDO — Rapport sur les chiffres financiers et les réserves (30/09/2026) : https://assets.ctfassets.net/vyse88cgwfbl/7nQYtcoP9GxIUFSyro2dGK/8d0521470b9e99c8c0831019cabea4ee/ISAE_3000R_-_Opinion_Tether_International_Financial_Figure_30-09-2026.pdf ; Tether, 30/10/2026 : https://tether.io/news/tether-generates-1-5-billion-in-q3-net-operating-profit-as-reserve-buffer-doubles-to-almost-8-billion/

Sur $SOL , signer un message peut prouver que vous contrôlez un portefeuille sans créer de transaction.

La fonctionnalité `solana:signOffchainMessage` utilise un format structuré avec son propre domaine. L’application vérifie la signature côté serveur, sans frais de réseau ni appel RPC, et le message ne peut pas être confondu avec une transaction on-chain.

Pour la connexion, la protection contre la réutilisation dépend toujours de l’application : générez un nonce côté serveur, associez-le au défi et utilisez-le une seule fois après avoir vérifié la signature.

Sources : Solana Docs — Signer des messages et authentifier les utilisateurs (https://solana.com/docs/frontend/messages-and-auth) ; Solana Changelog, 29/10/2026 (https://solana.com/news/solana-changelog-october-29-2026).

Pour $XLM , la mise à jour Bell (Protocol 30) mérite une lecture plus précise que « Stellar est devenue résistante à l’informatique quantique ».

La proposition CAP-87 permet aux contrats intelligents de vérifier des signatures ML-DSA, une norme post-quantique du NIST. Mais elle ne remplace pas les signatures des transactions du réseau : elles restent en Ed25519 dans cette mise à jour.

La différence est importante. Cette avancée crée un élément de base pour les comptes intelligents qui peuvent exiger une signature post-quantique ; il ne s’agit pas d’une migration générale des comptes ni d’une protection automatique pour tous les portefeuilles qui détiennent des XLM.

Les votes sont prévus le 3/11 sur le testnet et le 23/11 sur le mainnet. D’ici là, il s’agit d’un changement proposé, dont l’utilité pratique dépend également de son adoption par les portefeuilles, les dépositaires et les applications.

Source : Stellar Development Foundation, Bell / Protocol 30.

Sur le réseau $BTC , les frais ne sont pas un pourcentage du montant envoyé. Ils dépendent de deux choses : le frais choisi par unité d’espace (sat/vB) et la taille virtuelle de la transaction (vsize).

C’est pourquoi deux transactions avec le même frais par vB peuvent payer des montants totaux différents. Dépenser plusieurs UTXO ou créer plus de sorties tend à augmenter l’espace occupé ; le portefeuille calcule le coût en tenant compte de cette structure.

Sur l’écran de confirmation, il vaut la peine de regarder les deux chiffres : sat/vB et total en sats. Le premier est le prix par unité d’espace ; le second est ce que vous payez effectivement. Et la demande d’espace dans les blocs fait varier le frais nécessaire pour être compétitif en vue de l’inclusion.

Sources : Bitcoin Developer Guide — Transactions : https://developer.bitcoin.org/devguide/transactions.html | Bitcoin Core — Mempool terminology : https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-terminology.md

Lors de l’utilisation de $USDC sur Ethereum, une approbation de jeton n’est pas la même chose qu’un transfert — mais elle peut rester valable après que vous avez fini d’utiliser une dApp.

Dans la norme ERC-20, `approve` définit le montant qu’une adresse peut dépenser en votre nom ; `transferFrom` permet de déplacer des jetons dans les limites de cette autorisation. Si le portefeuille affiche une limite illimitée, les fonds ne sont pas transférés automatiquement au moment de l’approbation. Le risque est de laisser un contrat autorisé à dépenser jusqu’à cette limite tant que l’autorisation reste active.

Déconnecter la dApp ne révoque pas l’approbation : celle-ci reste enregistrée dans le contrat du jeton. La révoquer nécessite une transaction on-chain et donc des frais de gas. Vérifiez le réseau, l’adresse du dépensier et la limite approuvée. Cela réduit votre exposition, mais n’annule pas les transferts déjà effectués et ne prouve pas que le contrat est sûr.

En $UNI , le changement intéressant apporté par les Aggregator Hooks ne consiste pas simplement à ajouter un agrégateur : Uniswap v4 représente désormais les sources externes de liquidité sous forme de pools que le routeur peut comparer.

Selon Uniswap Labs, le lancement du 22/10 a introduit sept sources, couvrant plus de 90 % de l’activité DEX sur Ethereum, Base et Robinhood Chain. Le routeur actualise les cotations à chaque bloc et règle l’intégralité de la route en une seule transaction. Les frais de protocole des routes externes peuvent contribuer à la destruction des UNI.

Cela élargit la liquidité accessible au sein d’une même route, mais ne garantit pas que chaque échange bénéficiera du meilleur prix : les cotations, le slippage et les coûts d’exécution restent importants.

Source : Uniswap Labs, 22/10/2026.

Sur $USDC , sur Ethereum, « approuver » ne signifie pas que les tokens ont déjà été envoyés — mais ce n’est pas non plus un clic anodin.

Dans la norme ERC-20, `approve` définit le montant qu’une adresse (spender) peut ensuite déplacer via `transferFrom`. Si le portefeuille affiche « illimité », cette autorisation peut rester active même après la fermeture de la dApp. La signature autorise une dépense possible ; elle ne confirme pas uniquement l’action que vous vouliez effectuer à ce moment-là.

Avant de confirmer, vérifiez l’adresse du spender et la limite. Réduire ou révoquer l’autorisation limite les dépenses futures, mais n’annule pas les transferts déjà effectués.

Source : EIP-20 — fonctions `approve`, `allowance` et `transferFrom` : https://eips.ethereum.org/EIPS/eip-20

En $BTC , le portefeuille n’a pas besoin de disposer d’un UTXO correspondant exactement au montant du paiement. Il peut combiner des entrées existantes et créer deux sorties : l’une pour le destinataire et l’autre comme monnaie, en renvoyant l’excédent au portefeuille lui-même.

Les frais correspondent à la différence entre la somme des entrées et celle de toutes les sorties. Ainsi, dans une transaction, toutes les sorties ne représentent pas un paiement à une autre personne — et l’adresse de monnaie peut être nouvelle.

Il y a aussi un aspect lié à la confidentialité : les entrées et les sorties sont publiques. Réutiliser des adresses ou associer une adresse à votre identité facilite la corrélation des mouvements. Une nouvelle adresse réduit la réutilisation, mais ne garantit pas l’anonymat ; déterminer qu’une sortie correspond à de la « monnaie » peut également reposer sur des heuristiques, et non sur une certitude quant à l’identité du détenteur de l’adresse.

La structure de la transaction est vérifiable sur la blockchain ; l’identité derrière une adresse ne l’est pas nécessairement.

Sur $SOL , simuler une transaction avant de l’envoyer est une bonne vérification — mais ne garantit pas sa réussite.

Le RPC `simulateTransaction` permet d’observer les erreurs et les journaux sans transmettre la transaction pour exécution. Cependant, la simulation reflète un état spécifique du réseau. Si un compte ou une condition pertinente change avant l’inclusion, le résultat réel peut être différent.

C’est pourquoi il faut considérer la simulation comme un test préalable, et non comme une confirmation : vérifiez également les instructions et les adresses que le portefeuille vous demande de signer. La simulation aide à détecter les problèmes ; elle ne remplace pas la vérification de ce que vous avez autorisé.

Source : documentation officielle de Solana — https://solana.com/pt/docs/rpc/http/simulatetransaction

Un point important pour comprendre les frais en $ETH : ils ne vont pas tous au validateur.

Dans le modèle EIP-1559, le coût dépend du gaz utilisé et de la somme de deux composantes : les frais de base, définis par le protocole et brûlés, et les frais de priorité, qui servent de pourboire au validateur. Le portefeuille peut aussi définir des frais maximaux ; si le coût effectif est inférieur à ce montant, la différence n’est pas facturée.

En pratique, des frais élevés peuvent refléter aussi bien une opération qui consomme davantage de gaz qu’une concurrence accrue pour être incluse dans un bloc. Ce sont des facteurs différents : ne regarder que le montant final masque cette distinction.

La formule et le mécanisme sont ceux décrits dans la documentation d’Ethereum ; les montants réels varient selon le réseau et le moment de la transaction.

Pour $SOL , la nouveauté de la semaine concerne la distribution, pas le prix : Samsung Wallet a commencé à activer les transferts internationaux d’USDC sur Solana pour 82 millions d’appareils Galaxy aux États-Unis, selon l’annonce de la Solana Foundation du 7/10.

Cela pourrait réduire les obstacles pour les personnes qui utilisent déjà le portefeuille, mais « disponible sur les appareils » ne signifie pas que 82 millions de personnes utilisent cette fonctionnalité. L’adoption réelle dépend encore de sa disponibilité effective, de l’expérience d’envoi, des coûts et de la fréquence d’utilisation.

C’est un bon rappel : il faut distinguer la portée potentielle de l’activité observée sur la chaîne.

Source : Solana Foundation, 7/10/2026.

Un ajustement du calendrier pour $ETH : l’activation de Glamsterdam sur le testnet Hoodi, prévue le 26 octobre, a été reportée. La Ethereum Foundation n’a pas encore fixé de nouvelle date ; le motif indiqué est l’étude de l’interaction entre l’EIP-8037 et les contrats intelligents du réseau principal.

Le report a retiré du calendrier l’activation de Hoodi ainsi que l’augmentation de la limite de gas à 200 millions, qui étaient prévues lors de la même étape. Il ne revient pas sur l’historique du testnet et n’annonce aucun changement du calendrier du réseau principal.

Pour les personnes qui exploitent un nœud ou un validateur sur Hoodi, la tâche pratique consiste à vérifier que les clients d’exécution et de consensus installés prennent bien en compte le report.

Source : Ethereum Foundation, 22/10/2026 — https://blog.ethereum.org/2026/10/22/glamsterdam-hoodi-delay

Une PSBT n'est pas une transaction déjà signée. C'est un format permettant de transporter les données d'une transaction entre portefeuilles et appareils avant de réunir les signatures — y compris avec des signataires hors ligne.

L'image utilise une adresse, un montant et des frais fictifs, uniquement pour illustrer les éléments à vérifier. Avant d'approuver, vérifiez la destination, le montant, les frais et la monnaie rendue sur l'appareil de confiance. La PSBT organise les données ; elle ne remplace pas cette vérification.

Source : BIP-174 — Transactions Bitcoin partiellement signées.

Un détail peut rendre une transaction sur $SOL plus coûteuse : pour les transactions legacy et v0, les frais de priorité sont calculés en fonction de la limite d’unités de calcul demandée, et non de la consommation réelle. Une limite inutilement élevée peut entraîner des frais pour une capacité que la transaction n’a pas utilisée.

Une approche plus prudente consiste à simuler la transaction, à mesurer la consommation et à ajouter la marge de sécurité de 10 % recommandée dans la documentation. En v1, la configuration est différente ; vérifiez le format avant d’appliquer cet ajustement.

Source : documentation Solana — budget de calcul et structure des frais.

Dans la proposition de calendrier géographique des leaders de Solana, l’ordre des validateurs serait modifié afin de rapprocher ceux qui produisent des blocs consécutifs. L’idée est de réduire la latence des transferts, mais le coût potentiel serait de concentrer davantage la production dans certaines régions.

Cette carte illustre le mécanisme ; elle ne montre pas un changement déjà activé sur le réseau. L’étude compare des réseaux simulés à partir de localisations observées : le résultat dépend donc de cette répartition géographique.

Source : Solana Foundation, « Geo-Aware Leader Schedule », 14/10/2026.

Sur $SOL , une étude de la Solana Foundation publiée le 14/10 analyse le SIMD-0675 : au lieu de laisser le calendrier des leaders alterner entre des validateurs très éloignés, la proposition réorganise la séquence afin de rapprocher géographiquement les producteurs des blocs suivants.

Le compromis est concret : des transferts potentiellement plus rapides, mais une production concentrée plus longtemps dans une même région — un facteur important en cas de panne régionale ou de censure. L’étude a simulé 6 250 réseaux à partir de 124 localisations observées ; elle ne prouve pas que le gain est déjà actif sur le réseau, et ses conclusions dépendent de cette répartition géographique.

Source : Solana Foundation, « Geo-Aware Leader Schedule », 14/10/2026.

Une simulation réussie ne garantit pas qu'une transaction sur $SOL sera confirmée.

Sur Solana, `simulateTransaction` aide à vérifier les instructions et les erreurs éventuelles par rapport à l'état observé. Mais entre la simulation et le traitement de la transaction, l'état du réseau peut changer. Et une réponse réussie de `sendTransaction` signifie que le RPC a accepté la soumission — pas que la transaction a déjà été incluse ou confirmée.

En pratique, considérez la simulation comme une vérification préalable, et non comme un reçu. Après l'envoi, suivez le statut de la signature jusqu'à obtenir la confirmation attendue.

Sources officielles : https://solana.com/docs/rpc/http/simulatetransaction · https://solana.com/docs/rpc/http/sendtransaction