Vitorhrds

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`.

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

La prueba de reservas tiene una fecha de corte. En el anuncio del 2/11, Binance informó que completó la prueba ZK para la instantánea del 31/10 a las 00:00 UTC; los clientes con uno de los diez activos cubiertos pueden verificar si su saldo estaba respaldado al menos en una proporción de 1:1 en ese momento. Esto es un dato verificable en un momento concreto: no es un panel en tiempo real ni cubre activos fuera de la lista. Para $BTC , conviene revisar la fecha y el alcance antes de interpretar «1:1» como una garantía continua. La próxima recopilación se anunció para el 4/11; la generación de la prueba debería tardar entre 40 y 50 horas.

Fuente: Binance, Actualización de recuperación #5 (02/11/2026): https://www.binance.com/en/support/announcement/detail/185bd9a4717f44088b3be70287b8237f

En la minería de $BTC , automatizar flotas se topa con un problema poco glamuroso: cada ASIC, pool y sistema tiene su propia interfaz.

El MDK de Tether intenta resolverlo con *Workers*: adaptadores que traducen sistemas específicos a una capa común, lo que permite que las aplicaciones integren el protocolo en lugar de crear una conexión nueva para cada proveedor.

El 24/10, Tether dijo que 15 participantes se comprometieron a desarrollar y mantener integraciones. Esto aún no demuestra que todos los Workers estén operativos. La propia documentación dice que la línea 0.x sigue en desarrollo y no está destinada a producción; 1.0 es el primer hito previsto como listo para producción, con diciembre como objetivo.

Para medir los avances, conviene seguir las pruebas reales y la estabilidad de las interfaces, no solo la lista de adhesiones.

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

En $USDT, el excedente de reservas debe leerse junto con la fecha y el alcance del informe.

El documento del 30/09/2026 muestra activos por US$ 191,45 mil millones y pasivos por US$ 183,50 mil millones, con un excedente de US$ 7,95 mil millones. BDO emitió una opinión de aseguramiento razonable sobre ese informe específico; no es un conjunto completo de estados financieros, excluye las notas del alcance y cubre únicamente esa fecha.

Esta instantánea es útil, pero no demuestra que todos los activos puedan convertirse en efectivo de inmediato en condiciones de estrés extremo. El propio informe indica que las valoraciones consideran condiciones normales de mercado.

Fuentes: Tether/BDO — Financial Figures and Reserves Report (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/

En $SOL , firmar un mensaje puede demostrar que controlas una cartera sin crear una transacción.

La función `solana:signOffchainMessage` utiliza un formato estructurado con su propio dominio. La app verifica la firma en el servidor sin comisiones de red ni llamadas RPC, y el mensaje no puede confundirse con una transacción on-chain.

Para iniciar sesión, la protección contra la reutilización sigue dependiendo de la app: genera un nonce en el servidor, asígnalo al desafío y úsalo una sola vez después de verificar la firma.

Fuentes: Solana Docs — Firmar mensajes y autenticar usuarios (https://solana.com/docs/frontend/messages-and-auth); Solana Changelog, 29/10/2026 (https://solana.com/news/solana-changelog-october-29-2026).

En $XLM , la actualización Bell (Protocol 30) merece una lectura más precisa que «Stellar se volvió resistente a la computación cuántica».

La propuesta CAP-87 permite que los contratos inteligentes verifiquen firmas ML-DSA, un estándar poscuántico del NIST. Pero esto no cambia las firmas de las transacciones de la red: en esta actualización siguen siendo Ed25519.

La diferencia importa. El avance crea una pieza para las cuentas inteligentes que pueden exigir una firma poscuántica; no es una migración general de las cuentas ni una protección automática para todas las carteras que almacenan XLM.

Las votaciones están previstas para el 3/11 en la testnet y el 23/11 en la mainnet. Hasta entonces, se trata de un cambio propuesto, cuya utilidad práctica también depende de que lo adopten las carteras, los custodios y las aplicaciones.

Fuente: Stellar Development Foundation, Bell / Protocol 30.

En la red $BTC , la comisión no es un porcentaje del valor enviado. Depende de dos cosas: la tarifa elegida por unidad de espacio (sat/vB) y el tamaño virtual de la transacción (vsize).

Por eso, dos transacciones con la misma tarifa por vB pueden pagar importes totales diferentes. Gastar varios UTXO o crear más salidas suele aumentar el espacio ocupado; la cartera calcula el coste teniendo en cuenta esa estructura.

En la pantalla de confirmación, conviene fijarse en los dos números: sat/vB y el total en sats. El primero es el precio por unidad de espacio; el segundo es lo que realmente pagas. Además, la demanda de espacio en los bloques cambia la tarifa necesaria para competir por la inclusión.

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

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.

En $UNI , el cambio interesante de Aggregator Hooks no es solo «otro agregador»: Uniswap v4 pasa a representar fuentes externas de liquidez como pools que el enrutador puede comparar.

Según Uniswap Labs, el lanzamiento del 22/10 incorporó siete fuentes, que cubren más del 90 % de la actividad DEX en Ethereum, Base y Robinhood Chain. El enrutador actualiza las cotizaciones en cada bloque y liquida toda la ruta en una transacción. Las tarifas de protocolo de las rutas externas pueden contribuir a la quema de UNI.

Esto amplía la liquidez accesible dentro de la misma ruta, pero no garantiza que cada intercambio obtenga el mejor precio: las cotizaciones, el slippage y los costos de ejecución siguen siendo importantes.

Fuente: Uniswap Labs, 22/10/2026.

En $USDC Ethereum, «aprobar» no significa que los tokens ya se hayan enviado, pero tampoco es un clic inofensivo.

En el estándar ERC-20, `approve` define cuánto puede mover una dirección (spender) posteriormente mediante `transferFrom`. Si la cartera muestra «unlimited», ese permiso puede seguir activo incluso después de cerrar la dApp. La firma autoriza un posible gasto; no confirma únicamente la acción que querías realizar en ese momento.

Antes de confirmar, comprueba la dirección del spender y el límite. Reducir o revocar la allowance limita los gastos futuros, pero no deshace las transferencias que ya se hayan ejecutado.

Fuente: EIP-20 — funciones `approve`, `allowance` y `transferFrom`: https://eips.ethereum.org/EIPS/eip-20

En $BTC , la cartera no necesita tener un UTXO exactamente del importe del pago. Puede combinar entradas existentes y crear dos salidas: una para quien recibe el pago y otra de cambio, que devuelve el excedente a la propia cartera.

La comisión es la diferencia entre la suma de las entradas y la suma de todas las salidas. Por eso, en una transacción, no todas las salidas representan un pago a otra persona, y la dirección de cambio puede ser nueva.

También hay un detalle de privacidad: las entradas y las salidas son públicas. Reutilizar direcciones o asociar una dirección con tu identidad facilita relacionar movimientos. Una dirección nueva reduce la reutilización, pero no garantiza el anonimato; clasificar una salida como «cambio» también puede depender de heurísticas, no de la certeza sobre quién controla la dirección.

La estructura de la transacción se puede verificar en la blockchain; la identidad detrás de una dirección, no necesariamente.

En $SOL , simular una transacción antes de enviarla es una buena comprobación, pero no garantiza que tenga éxito.

El RPC `simulateTransaction` permite observar errores y registros sin transmitir la transacción para su ejecución. Sin embargo, la simulación refleja un estado específico de la red. Si una cuenta o condición relevante cambia antes de que se incluya, el resultado real puede ser diferente.

Por eso, considera la simulación como una prueba previa, no como una confirmación: comprueba también las instrucciones y las direcciones que la cartera te pide firmar. La simulación ayuda a detectar problemas; no sustituye la revisión de lo que has autorizado.

Fuente: documentación oficial de Solana — https://solana.com/pt/docs/rpc/http/simulatetransaction

Algo que ayuda a entender la tarifa de $ETH : no va íntegramente al validador.

En el modelo EIP-1559, el costo depende del gas utilizado y de la suma de dos componentes: la tarifa base, definida por el protocolo y que se quema, y la tarifa de prioridad, que funciona como una propina para el validador. La billetera también puede establecer una tarifa máxima; si el costo efectivo queda por debajo de ese límite, no se cobra la diferencia.

En la práctica, una tarifa alta puede reflejar tanto una operación que consume más gas como una mayor competencia por ser incluida en el bloque. Son factores distintos: fijarse solo en la cifra final oculta esa diferencia.

La fórmula y el mecanismo son los que describe la documentación de Ethereum; los valores reales varían según la red y el momento de la transacción.

En $SOL , la novedad de esta semana tiene que ver con la distribución, no con el precio: Samsung Wallet empezó a habilitar transferencias internacionales de USDC en Solana para 82 millones de dispositivos Galaxy en EE. UU., según el anuncio de la Solana Foundation del 7/10.

Esto podría reducir las fricciones para quienes ya usan la billetera, pero que esté «disponible en dispositivos» no significa que 82 millones de personas estén usando la función. La adopción real aún depende de la disponibilidad efectiva, la experiencia de envío, los costos y el uso recurrente.

Es un buen recordatorio de que hay que distinguir entre el alcance potencial y la actividad observada en la cadena.

Fuente: Solana Foundation, 7/10/2026.

Un ajuste en el calendario de $ETH : la activación de Glamsterdam en la testnet Hoodi, prevista para el 26 de octubre, se ha aplazado. La Ethereum Foundation aún no ha fijado otra fecha; el motivo comunicado es investigar la interacción del EIP-8037 con los contratos inteligentes de la mainnet.

El aplazamiento eliminó del calendario la activación de Hoodi y el aumento del límite de gas a 200 millones, previsto para el mismo hito. Esto no revierte la historia de la testnet ni anuncia un cambio en el calendario de la mainnet.

Para quienes operan un nodo o validador en Hoodi, la tarea práctica es confirmar que los clientes de ejecución y consenso instalados ya reflejan el aplazamiento.

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

Una PSBT no es una transacción ya firmada. Es un formato para llevar los datos de una transacción entre carteras y dispositivos antes de reunir las firmas, incluso con firmantes sin conexión.

La imagen usa una dirección, un importe y una comisión ficticios, solo para ilustrar qué hay que comprobar. Antes de aprobar, verifica el destino, el importe, la comisión y el cambio en el dispositivo de confianza. La PSBT organiza los datos; no sustituye esta comprobación.

Fuente: BIP-174 — Transacciones de Bitcoin parcialmente firmadas.

Un detalle puede encarecer una transacción en $SOL : la tarifa de prioridad de las transacciones legacy y v0 se calcula según el límite de unidades de cómputo solicitado, no según el consumo final. Un límite innecesariamente alto puede hacerte pagar por una capacidad que la transacción no utilizó.

Un flujo más cuidadoso consiste en simular la transacción, medir el consumo y añadir el margen de seguridad del 10 % recomendado por la documentación. En v1, la configuración es diferente; confirma el formato antes de aplicar este ajuste.

Fuente: Solana Docs — Compute Budget y Fee Structure.

En la propuesta de programación geográfica de líderes de Solana, el orden de los validadores cambiaría para acercar a quienes producen bloques consecutivos. La idea es reducir la latencia de los traspasos, pero el posible costo es concentrar más producción en ciertas regiones.

Este mapa ilustra el mecanismo; no muestra un cambio que ya esté activo en la red. La investigación compara redes simuladas con ubicaciones observadas, por lo que el resultado depende de esa distribución geográfica.

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

En $SOL , un estudio de la Solana Foundation publicado el 14/10 analiza el SIMD-0675: en lugar de permitir que el calendario de líderes alterne entre validadores muy distantes, la propuesta reordena la secuencia para acercar geográficamente a quienes producen los bloques siguientes.

El cambio es concreto: traspasos potencialmente más rápidos, pero más tiempo de producción concentrado en una región, algo relevante en caso de fallo regional o censura. El estudio simuló 6.250 redes basándose en 124 ubicaciones observadas; no demuestra que la mejora ya esté activa en la red, y las conclusiones dependen de esa geografía.

Fuente: Solana Foundation, «Calendario de líderes con conciencia geográfica», 14/10/2026.

Una simulación exitosa no garantiza que una transacción en $SOL será confirmada.

En Solana, `simulateTransaction` ayuda a verificar las instrucciones y los posibles errores frente al estado observado. Pero entre la simulación y el procesamiento de la transacción, el estado de la red puede cambiar. Y una respuesta exitosa de `sendTransaction` significa que el RPC aceptó el envío, no que la transacción ya se haya incluido o confirmado.

En la práctica, considera la simulación como una comprobación previa, no como un recibo. Después de enviar la transacción, sigue el estado de la firma hasta obtener la confirmación esperada.

Fuentes oficiales: https://solana.com/docs/rpc/http/simulatetransaction · https://solana.com/docs/rpc/http/sendtransaction