Vitorhrds

In $ETH , a transaction with blobs has two separate costs: EVM execution gas and blob gas for the data. EIP-4844 specifies that the blob fee is charged before execution and is not refunded if the transaction fails. Therefore, an EVM revert does not eliminate the cost of making the data available. When reviewing a transaction, `maxFeePerGas` is not enough: also check `maxFeePerBlobGas`.

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

Proof of reserves has a cutoff date. In its 2/11 announcement, Binance said it had completed the ZK proof for the 31/10 snapshot at 00:00 UTC; customers with one of the ten covered assets can verify whether their balance was backed at least 1:1 in that snapshot. This is a verifiable point in time—not a real-time dashboard, nor coverage of assets outside the list. For $BTC , it’s worth checking the date and scope before reading “1:1” as a continuous guarantee. The next collection was announced for 4/11; generating the proof is expected to take 40–50 hours.

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

In $BTC mining, automating fleets runs into a not-so-glamorous problem: each ASIC, pool, and system has its own interface.

Tether’s MDK tries to solve this with *Workers*: adapters that translate specific systems into a common layer, allowing applications to integrate with the protocol instead of building a new connection for every vendor.

On 24/10, Tether said 15 participants committed to developing and maintaining integrations. That still does not prove that all Workers are operating. The documentation itself says the 0.x line is still under development and not intended for production; 1.0 is the first milestone planned as production-ready, targeted for December.

To gauge progress, it is worth tracking real tests and interface stability, not just the list of endorsements.

Sources: 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/

In USDT, the reserve surplus needs to be read together with the date and scope of the report.

The 30/09/2026 document shows assets of US$ 191.45 billion and liabilities of US$ 183.50 billion, with a surplus of US$ 7.95 billion. BDO issued reasonable assurance on that specific report; it is not a complete set of financial statements, excludes the notes from the scope, and covers only that date.

This snapshot is useful, but it does not prove that all assets could be turned into cash immediately under extreme stress. The report itself says the valuations consider normal market conditions.

Sources: 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/

In $SOL , signing a message can prove that you control a wallet without creating a transaction.

The `solana:signOffchainMessage` feature uses a structured format with its own domain. The app verifies the signature on the server without a network fee or RPC call, and the message cannot be confused with an on-chain transaction.

For login, replay protection still depends on the app: generate a nonce on the server, associate it with the challenge, and consume it once after verifying the signature.

Sources: Solana Docs — Sign Messages & Authenticate Users (https://solana.com/docs/frontend/messages-and-auth); Solana Changelog, 29/10/2026 (https://solana.com/news/solana-changelog-october-29-2026).

For $XLM , the Bell upgrade (Protocol 30) deserves a more precise description than “Stellar is quantum-resistant.”

CAP-87 allows smart contracts to verify ML-DSA signatures, a NIST post-quantum standard. But it does not replace the network’s transaction signatures: they remain Ed25519 in this upgrade.

That distinction matters. The advancement provides a building block for smart accounts that can require a post-quantum signature; it is not a general migration of accounts or automatic protection for every wallet holding XLM.

The votes are scheduled for 3/11 on the testnet and 23/11 on the mainnet. Until then, this remains a proposed change, whose practical usefulness also depends on adoption by wallets, custodians, and applications.

Source: Stellar Development Foundation, Bell / Protocol 30.

On the $BTC network, the fee is not a percentage of the amount sent. It depends on two things: the fee chosen per unit of space (sat/vB) and the virtual size of the transaction (vsize).

Because of this, two transactions with the same fee per vB can pay different total amounts. Spending multiple UTXOs or creating more outputs tends to increase the space used; the wallet calculates the cost taking this structure into account.

On the confirmation screen, it is worth looking at both numbers: sat/vB and total in sats. The first is the price per unit of space; the second is what you actually pay. And the demand for block space changes the fee needed to compete for 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

When using $USDC on Ethereum, a token approval is not the same as a transfer—but it can remain valid after you finish using a dApp.

Under the ERC-20 standard, `approve` sets how much an address can spend on your behalf; `transferFrom` allows tokens to be moved within that authorization. If your wallet shows an unlimited allowance, funds are not automatically transferred at the time of approval. The risk is leaving a contract authorized to spend up to that limit for as long as the permission remains active.

Disconnecting the dApp does not revoke the approval: it remains recorded in the token contract. Revoking it requires an on-chain transaction and therefore gas. Check the network, the spender address, and the approved allowance. This reduces exposure, but does not undo transfers that have already taken place or prove that the contract is safe.

For $UNI , the interesting change with Aggregator Hooks isn’t just “one more aggregator”: Uniswap v4 now represents external liquidity sources as pools that the router can compare.

According to Uniswap Labs, the launch on 10/22 brought seven sources, covering more than 90% of DEX activity on Ethereum, Base, and Robinhood Chain. The router updates quotes every block and settles the entire route in a single transaction. Protocol fees from external routes may contribute to UNI burns.

This expands the liquidity available within the same route, but it doesn’t guarantee that every swap will get the best price: quotes, slippage, and execution costs still matter.

Source: Uniswap Labs, 10/22/2026.

On $USDC Ethereum, “approve” doesn’t mean the tokens have already been sent—but it’s not a harmless click either.

Under the ERC-20 standard, `approve` sets how much an address (spender) can later move using `transferFrom`. If your wallet shows “unlimited,” that permission may remain active even after you close the dApp. The signature authorizes a possible spend; it doesn’t just confirm the action you wanted to take at that moment.

Before confirming, check the spender address and the limit. Reducing or revoking the allowance limits future spending, but doesn’t undo transfers that have already been executed.

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

In $BTC , a wallet doesn’t need to have a UTXO that exactly matches the payment amount. It can combine existing inputs and create two outputs: one for the recipient and another as change, returning the excess to the wallet itself.

The fee is the difference between the sum of the inputs and the sum of all outputs. So, in a transaction, not every output represents a payment to someone else—and the change address may be new.

There’s also a privacy detail: inputs and outputs are public. Reusing addresses or linking an address to your identity makes it easier to correlate transactions. A new address reduces reuse, but doesn’t guarantee anonymity; classifying an output as “change” may also rely on heuristics, rather than certainty about who controls the address.

The transaction structure can be verified on the blockchain; the identity behind an address cannot necessarily be.

On $SOL , simulating a transaction before sending it is a good check—but it doesn’t guarantee success.

The `simulateTransaction` RPC lets you inspect errors and logs without broadcasting the transaction for execution. However, the simulation reflects a specific state of the network. If a relevant account or condition changes before the transaction is included, the actual result may be different.

So treat simulation as a preliminary test, not confirmation: also check the instructions and addresses your wallet is asking you to sign. Simulation helps detect problems; it doesn’t replace reviewing what you authorized.

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

One thing that helps explain the $ETH fee: it doesn't all go to the validator.

Under the EIP-1559 model, the cost depends on the gas used and the sum of two components: the base fee, set by the protocol and burned, and the priority fee, which works as a tip to the validator. The wallet can also set a max fee; if the effective cost is lower than that, the difference isn't charged.

In practice, a high fee can reflect both an operation that uses more gas and greater competition to be included in a block. These are different factors—looking only at the final number obscures that distinction.

The formula and mechanism are as described in the Ethereum documentation; actual values vary depending on the network and the time of the transaction.

For $SOL , this week’s news is about distribution, not price: Samsung Wallet has begun enabling international USDC transfers on Solana for 82 million Galaxy devices in the US, according to the Solana Foundation’s announcement on 7/10.

This could reduce friction for people who already use the wallet, but “available on devices” does not mean that 82 million people are using the feature. Actual adoption still depends on real availability, the sending experience, costs, and recurring use.

It’s a good reminder to distinguish potential reach from observed on-chain activity.

Source: Solana Foundation, 7/10/2026.

A schedule adjustment for $ETH : the Glamsterdam activation on the Hoodi testnet, scheduled for October 26, has been postponed. The Ethereum Foundation has not set a new date; the stated reason is to investigate how EIP-8037 interacts with mainnet smart contracts.

The postponement removed the Hoodi activation from the schedule, along with the increase to the gas limit of 200 million that had been planned for the same milestone. It does not rewrite the testnet’s history or announce a change to the mainnet schedule.

For anyone running a node or validator on Hoodi, the practical task is to confirm that the installed execution and consensus clients reflect the postponement.

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

A PSBT is not an already-signed transaction. It is a format for carrying transaction data between wallets and devices before signatures are combined—including with offline signers.

The image uses a fictitious address, amount, and fee, just to illustrate what to check. Before approving, verify the destination, amount, fee, and change on the trusted device. The PSBT organizes the data; it does not replace this verification.

Source: BIP-174 — Partially Signed Bitcoin Transactions.

One detail can make a $SOL transaction more expensive: for legacy and v0 transactions, the priority fee is calculated based on the requested compute unit limit, not actual consumption. An unnecessarily high limit can charge for capacity the transaction didn’t use.

A more careful approach is to simulate the transaction, measure its consumption, and add the 10% safety margin recommended in the documentation. In v1, the configuration is different; confirm the format before applying this adjustment.

Source: Solana Docs — Compute Budget and Fee Structure.

In Solana leaders’ proposed geo-aware schedule, the order of validators would change to bring consecutive block producers closer together. The idea is to reduce handoff latency, but the potential cost is concentrating more production in certain regions.

This map illustrates the mechanism; it does not show a change already active on the network. The study compares simulated networks with observed locations, so the result depends on that geographic distribution.

Source: Solana Foundation, “Geo-Aware Leader Schedule,” October 14, 2026.

For $SOL , a Solana Foundation study published on 14/10 examines SIMD-0675: instead of letting the leader schedule alternate between validators that are very far apart, the proposal reorders the sequence to bring the next block producers closer together geographically.

The trade-off is concrete: potentially faster handoffs, but more block production concentrated in one region—something that matters in the event of a regional outage or censorship. The study simulated 6,250 networks based on 124 observed locations; it does not prove that the gains are already active on the network, and its conclusions depend on that geography.

Source: Solana Foundation, “Geo-Aware Leader Schedule”, 14/10/2026.

A successful simulation does not guarantee that a transaction in $SOL will be confirmed.

On Solana, `simulateTransaction` helps check instructions and potential errors against the observed state. But the network state can change between simulation and transaction processing. And a successful `sendTransaction` response means the RPC accepted the submission—not that the transaction has already been included or confirmed.

In practice, treat simulation as a preliminary check, not a receipt. After sending, monitor the signature status until you get the expected confirmation.

Official sources: https://solana.com/docs/rpc/http/simulatetransaction · https://solana.com/docs/rpc/http/sendtransaction