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

Na mineração de $BTC , automatizar frotas esbarra num problema pouco glamouroso: cada ASIC, pool e sistema tem sua própria interface.

O MDK da Tether tenta resolver isso com *Workers*: adaptadores que traduzem sistemas específicos para uma camada comum, permitindo que aplicações integrem o protocolo em vez de criar uma conexão nova para cada fornecedor.

Em 24/10, a Tether disse que 15 participantes se comprometeram a desenvolver e manter integrações. Isso ainda não prova que todos os Workers estejam operando. A própria documentação diz que a linha 0.x continua em desenvolvimento e não é destinada à produção; 1.0 é o primeiro marco planejado como production-ready, com alvo em dezembro.

Para medir o avanço, vale acompanhar testes reais e a estabilidade das interfaces, não só a lista de adesões.

Fontes: Tether, 24/10/2026: https://tether.io/news/tethers-mdk-gains-broad-industry-backing-to-accelerate-the-next-generation-of-bitcoin-mining-automation/; MDK Roadmap: 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.

Em $UNI , a mudança interessante dos Aggregator Hooks não é só “mais um agregador”: a Uniswap v4 passa a representar fontes externas de liquidez como pools que o roteador consegue comparar.

Segundo a Uniswap Labs, o lançamento de 22/10 trouxe sete fontes, cobrindo mais de 90% da atividade DEX em Ethereum, Base e Robinhood Chain. O roteador atualiza cotações a cada bloco e liquida a rota inteira em uma transação. As taxas de protocolo das rotas externas podem contribuir para a queima de UNI.

Isso amplia a liquidez acessível dentro da mesma rota, mas não garante que toda troca terá o melhor preço: cotação, slippage e custos de execução continuam importando.

Fonte: Uniswap Labs, 22/10/2026.

Em $USDC na Ethereum, “aprovar” não significa que os tokens já foram enviados — mas também não é um clique inofensivo.

No padrão ERC-20, `approve` define quanto um endereço (spender) pode movimentar depois via `transferFrom`. Se a carteira mostra “unlimited”, essa permissão pode continuar ativa mesmo depois de fechar o dApp. A assinatura autoriza um gasto possível; não confirma apenas a ação que você queria fazer naquele momento.

Antes de confirmar, confira o endereço do spender e o limite. Reduzir ou revogar a allowance limita o gasto futuro, mas não desfaz transferências já executadas.

Fonte: EIP-20 — funções `approve`, `allowance` e `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

Uma PSBT não é uma transação já assinada. É um formato para levar os dados de uma transação entre carteiras e dispositivos antes de reunir assinaturas — inclusive com assinadores offline.

A imagem usa endereço, valor e taxa fictícios, só para ilustrar o que conferir. Antes de aprovar, verifique destino, valor, taxa e troco no dispositivo confiável. A PSBT organiza os dados; não substitui essa conferência.

Fonte: BIP-174 — Partially Signed Bitcoin Transactions.

Um detalhe pode encarecer uma transação em $SOL : a taxa de prioridade de transações legacy e v0 é calculada pelo limite de unidades de computação solicitado, não pelo consumo final. Um limite alto sem necessidade pode cobrar por capacidade que a transação não usou.

Um fluxo mais cuidadoso é simular a transação, medir o consumo e acrescentar a margem de segurança de 10% recomendada pela documentação. Em v1, a configuração é diferente; confirme o formato antes de aplicar esse ajuste.

Fonte: Solana Docs — Compute Budget e Fee Structure.

Na proposta de agenda geográfica de líderes da Solana, a ordem dos validadores mudaria para aproximar quem produz blocos em sequência. A ideia é reduzir a latência dos handoffs, mas o custo potencial é concentrar mais produção em certas regiões.

Este mapa ilustra o mecanismo; não mostra uma mudança já ativa na rede. A pesquisa compara redes simuladas com localizações observadas, então o resultado depende dessa distribuição geográfica.

Fonte: 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