Em $ETH , uma transação com blobs tem dois custos separados: gas da execução EVM e blob gas pelos dados. A EIP-4844 define que a blob fee é debitada antes da execução e não é devolvida quando a transação falha. Assim, uma reversão da EVM não elimina o custo de disponibilização dos dados. Ao revisar uma transação, `maxFeePerGas` não basta: confira também `maxFeePerBlobGas`.
Prova de reservas tem data de corte. No anúncio de 2/11, a Binance informou que concluiu a prova ZK para o snapshot de 31/10 às 00:00 UTC; clientes com um dos dez ativos cobertos podem verificar se o saldo estava respaldado em pelo menos 1:1 naquele retrato. Isso é um ponto verificável no tempo — não um painel em tempo real, nem cobertura de ativos fora da lista. Para $BTC , vale olhar data e escopo antes de ler “1:1” como garantia contínua. A próxima coleta foi anunciada para 4/11; a geração da prova deve levar 40–50 horas.
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.
Em $USDT, o excedente de reservas precisa ser lido junto com a data e o escopo do relatório.
O documento de 30/09/2026 mostra ativos de US$ 191,45 bilhões e passivos de US$ 183,50 bilhões, com excedente de US$ 7,95 bilhões. O BDO emitiu asseguração razoável sobre esse relatório específico; ele não é um conjunto completo de demonstrações financeiras, exclui as notas do escopo e cobre apenas aquela data.
Esse retrato é útil, mas não prova que todos os ativos possam virar caixa imediatamente sob estresse extremo. O próprio relatório diz que as avaliações consideram condições normais de mercado.
Em $SOL , assinar uma mensagem pode provar que você controla uma carteira sem criar uma transação.
O recurso `solana:signOffchainMessage` usa um formato estruturado com domínio próprio. O app verifica a assinatura no servidor sem taxa de rede nem chamada RPC, e a mensagem não pode ser confundida com uma transação on-chain.
Para login, a proteção contra reutilização ainda depende do app: gere um nonce no servidor, associe-o ao desafio e consuma-o uma vez após verificar a assinatura.
Em $XLM , a atualização Bell (Protocol 30) merece uma leitura mais precisa do que “a Stellar ficou resistente à computação quântica”.
A proposta CAP-87 permite que smart contracts verifiquem assinaturas ML-DSA, um padrão pós-quântico do NIST. Mas isso não troca as assinaturas das transações da rede: elas continuam em Ed25519 nesta atualização.
A diferença importa. O avanço cria uma peça para smart accounts que podem exigir uma assinatura pós-quântica; não é uma migração geral das contas nem uma proteção automática para toda carteira que guarda XLM.
As votações estão previstas para 3/11 na testnet e 23/11 na mainnet. Até lá, trata-se de uma mudança proposta, cuja utilidade prática também depende da adoção por carteiras, custodiantes e aplicações.
Fonte: Stellar Development Foundation, Bell / Protocol 30.
Im $BTC -Netzwerk ist die Gebühr kein Prozentsatz des gesendeten Betrags. Sie hängt von zwei Dingen ab: der gewählten Gebühr pro Speichereinheit (sat/vB) und der virtuellen Größe der Transaktion (vsize).
Deshalb können zwei Transaktionen mit derselben Gebühr pro vB unterschiedliche Gesamtbeträge kosten. Das Ausgeben mehrerer UTXOs oder das Erstellen weiterer Outputs erhöht tendenziell den benötigten Speicherplatz; die Wallet berechnet die Kosten anhand dieser Struktur.
Auf dem Bestätigungsbildschirm lohnt es sich, auf beide Zahlen zu achten: sat/vB und den Gesamtbetrag in Sats. Die erste Zahl ist der Preis pro Speichereinheit; die zweite ist der Betrag, den Sie tatsächlich bezahlen. Und die Nachfrage nach Speicherplatz in den Blöcken verändert die erforderliche Gebühr, um mit anderen Transaktionen um die Aufnahme zu konkurrieren.
Ao usar $USDC na Ethereum, uma aprovação de token não é a mesma coisa que uma transferência — mas pode continuar valendo depois que você termina de usar uma dApp.
No padrão ERC-20, `approve` define quanto um endereço pode gastar em seu nome; `transferFrom` permite movimentar tokens dentro dessa autorização. Se a carteira mostrar um limite ilimitado, os fundos não saem automaticamente no momento da aprovação. O risco é manter um contrato autorizado a gastar até aquele limite enquanto a permissão continuar ativa.
Desconectar a dApp não revoga a aprovação: ela fica registrada no contrato do token. Revogá-la exige uma transação on-chain e, portanto, gas. Confira a rede, o endereço do spender e o limite aprovado. Isso reduz exposição, mas não desfaz transferências já realizadas nem prova que o contrato seja seguro.
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.
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
Bei $BTC muss die Wallet kein UTXO haben, das exakt dem Zahlungsbetrag entspricht. Sie kann vorhandene Eingaben kombinieren und zwei Ausgaben erstellen: eine für den Empfänger und eine als Wechselgeld, das den Überschuss an die eigene Wallet zurückgibt.
Die Gebühr ist die Differenz zwischen der Summe der Eingaben und der Summe aller Ausgaben. Deshalb ist in einer Transaktion nicht jede Ausgabe eine Zahlung an eine andere Person – und die Wechselgeldadresse kann neu sein.
Es gibt auch einen Aspekt des Datenschutzes: Eingaben und Ausgaben sind öffentlich. Werden Adressen wiederverwendet oder wird eine Adresse mit deiner Identität verknüpft, lassen sich Transaktionen leichter miteinander in Verbindung bringen. Eine neue Adresse verringert die Wiederverwendung, garantiert aber keine Anonymität. Eine Ausgabe als „Wechselgeld“ einzustufen, kann zudem auf Heuristiken beruhen und nicht auf Gewissheit darüber, wer die Adresse kontrolliert.
Die Struktur der Transaktion lässt sich auf der Blockchain überprüfen, die Identität hinter einer Adresse jedoch nicht unbedingt.
Em $SOL , simular uma transação antes de enviá-la é uma boa checagem — mas não é uma garantia de sucesso.
O RPC `simulateTransaction` permite observar erros e logs sem transmitir a transação para execução. Só que a simulação reflete um estado específico da rede. Se uma conta ou condição relevante mudar antes da inclusão, o resultado real pode ser diferente.
Por isso, trate a simulação como um teste prévio, não como confirmação: confira também as instruções e os endereços que a carteira está pedindo para assinar. A simulação ajuda a detectar problemas; não substitui a revisão do que você autorizou.
Fonte: documentação oficial da Solana — https://solana.com/pt/docs/rpc/http/simulatetransaction
Uma coisa que ajuda a entender a taxa do $ETH : ela não vai toda para o validador.
No modelo EIP-1559, o custo depende do gás usado e da soma de duas parcelas: a base fee, definida pelo protocolo e queimada, e a priority fee, que funciona como gorjeta ao validador. A carteira também pode definir uma max fee; se o custo efetivo ficar abaixo dela, a diferença não é cobrada.
Na prática, uma taxa alta pode refletir tanto uma operação que consome mais gás quanto maior disputa por inclusão no bloco. São fatores diferentes — olhar só o número final esconde essa distinção.
A fórmula e o mecanismo são os descritos pela documentação do Ethereum; os valores reais variam conforme a rede e o momento da transação.
Em $SOL , a novidade desta semana é de distribuição, não de preço: a Samsung Wallet começou a habilitar transferências internacionais de USDC sobre Solana para 82 milhões de dispositivos Galaxy nos EUA, segundo o anúncio da Solana Foundation de 7/10.
Isso pode reduzir o atrito para quem já usa a carteira, mas “disponível em dispositivos” não significa que 82 milhões de pessoas estejam usando o recurso. A adoção real ainda depende de disponibilidade efetiva, experiência de envio, custos e uso recorrente.
É um bom lembrete para separar alcance potencial de atividade on-chain observada.
Um ajuste de cronograma em $ETH : a ativação de Glamsterdam na testnet Hoodi, prevista para 26 de outubro, foi adiada. A Ethereum Foundation ainda não definiu outra data; o motivo informado é investigar a interação do EIP-8037 com contratos inteligentes da mainnet.
O adiamento removeu do cronograma a ativação de Hoodi e o aumento do gas limit para 200 milhões que estava previsto no mesmo marco. Isso não reverte a história da testnet nem anuncia uma mudança no cronograma da mainnet.
Para quem opera nó ou validador em Hoodi, a tarefa prática é confirmar que os clientes de execução e consenso instalados já refletem o adiamento.
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.
Em $SOL , uma pesquisa da Solana Foundation publicada em 14/10 analisa o SIMD-0675: em vez de deixar a agenda de líderes alternar entre validadores muito distantes, a proposta reordena a sequência para aproximar geograficamente quem produz blocos em seguida.
A troca é concreta: handoffs potencialmente mais rápidos, mas mais tempo de produção concentrado numa região — algo relevante em caso de falha regional ou censura. O estudo simulou 6.250 redes com base em 124 localizações observadas; não prova que o ganho já esteja ativo na rede, e as conclusões dependem dessa geografia.
Uma simulação bem-sucedida não garante que uma transação em $SOL será confirmada.
Na Solana, `simulateTransaction` ajuda a verificar instruções e possíveis erros contra o estado observado. Mas entre simular e a transação ser processada, o estado da rede pode mudar. E uma resposta bem-sucedida de `sendTransaction` significa que o RPC aceitou a submissão — não que a transação já foi incluída ou confirmada.
Na prática, trate simulação como uma checagem prévia, não como recibo. Depois de enviar, acompanhe o status da assinatura até obter a confirmação esperada.