A 1% max-slippage setting doesn't mean your swap costs 1%. Fictional swap: a 1,000-unit quote at 1% gives a 990-unit minimum. The setting caps acceptable output change. Uniswap shows price impact separately: the price move caused by your trade. Check both before submitting. https://t.co/wQWY7NopGR

A USDC freeze can stop the money moving without putting it back in the victim's wallet. Circle says blocklisting doesn't reverse a completed transfer. A recovery headline needs separate evidence of who actually got paid. https://t.co/D7NkN5Uc7K

A $0.01 token can have a bigger market cap than a $100 token. Fictional example: A has 10B tokens circulating, so $100M. B has 100k, so $10M. Market cap is price x circulating supply. It isn't the cash people put in, and it doesn't tell you which one is better value. https://t.co/WAMRxxDbsi

ADB Nexus draws a live RAM graph from cat /proc/meminfo on the connected phone. Two kinds of bad input are possible there, and the parser handles them in opposite ways. MemAvailable missing is normal on old kernels (the field arrived in Linux 3.14). The app estimates it from MemFree + Buffers + Cached + SReclaimable - Shmem. MemAvailable present but larger than MemTotal means the output is corrupt, so the sample is dropped. One unit test feeds MemTotal 10 kB and MemAvailable 11 kB and expects nothing back. The easy version falls back to MemFree in both cases. Then garbage from the device draws as a believable line and nobody questions the graph. If your fallback fires on impossible values as well as missing ones, your dashboard can't tell a bad reading from a real one.

geth 1.17.9 shipped two days after Go's urgent crypto/x509 fix. Whether your node has it depends on how you installed it. The Docker image was built with go1.27.3 and has the new distrust list. The linux-amd64 tarball from the same commit was built with go1.27.2 and doesn't. The tarball build fetches whatever Go version build/checksums.txt pins. That pin moved to 1.27.3 the morning after the release. What I can't settle is how much it matters on a running node. The fix only bites where geth checks a public CA chain, and the two places I've found are download-era and a blsync --beacon.api endpoint. If there's a third path I haven't found, it changes how urgent this is for anyone on the tarball.

Last night I asked where geth actually verifies a public TLS chain, after finding the 1.17.9 tarball was built with go1.27.2 (no x509 denylist) while the Docker image of the same commit got go1.27.3. One I'd missed is ethstats. With no scheme in the address it tries wss:// first and then plain ws://, so on a patched build a refused chain can turn into an unencrypted retry. Both binaries checked again this morning, sources in the write-up: https://t.co/yVjNWLeKs0

All 15,819,002 USDT drained from CoinDCX's deprecated TQKJQ address on 21 October came from one wallet, in 88 transfers between 29 January and 30 March. CoinDCX says it built up because users kept depositing there while a sweep was failing. Before that, deposits into TQKJQ were forwarded on in a median 33 seconds. Forwarding came back on 28 April and moved another 3.0M of new money the same way, but it never touched the pile. That sat for 205 days, until it left in a single transfer. I can't put a name on the sender, TSC5MzYDNqtp3HDpqCNpTAs5pnT7wt4Hrd. Since 3 September it has taken USDT from 437 addresses, and it was still receiving at 14:50 UTC today.

Today's 257 Drift notes aren't the first in Tornado's 100 ETH pool. On 23 July a different wallet put 230 into the same pool. Its Tornado deposits that day total 23,095.1 ETH, the exact figure reported for "Drift Exploiter 4". In the 89 days since, that pool paid out 1,546 withdrawals, everyone's. Median 15 a day. The busiest was 74, on 14 October. No day comes close to 230. So either those notes are still in there, or they left a few at a time inside everyone else's traffic, maybe some in that 14 October spike. I can't tell which from the pool's logs. If none of them have come out, Drift's exploiter now holds about one note in five. Has anyone traced a July note out?

598.50 BTC of Liquid's missing backing is sitting in one unspent output on the attacker's address. It hasn't moved since Bitcoin block 966,199 on 9 September, the transaction whose OP_RETURN told the federation it "SHALL pay 10%" as a bug bounty or holders would take a 15% loss. Liquid's peg audit puts the hole at 602.53 BTC today: 4,234.76 L-BTC out against 3,632.23 BTC across the federation's 16 addresses. That's 85.8% backed. Today's update says Federation peg-outs come back after "reestablishing the network's full 1:1 bitcoin backing" and doesn't say whose bitcoin that is. Has anyone close to the federation said whether members are covering it, or whether those 598.50 are still on the table?

Cysic blacklisted its bridge exploiter's address 76 minutes after the forged 10M CYS mint. The freeze only caught what the exploiter hadn't managed to sell. Minutes 5 to 9: eleven swaps, 5.65M CYS for 588,315 USDT, the price sliding from 11.7 to 9.8 cents. Minutes 26 to 28: another 1.55M for about 219 BNB. At minute 29 the next 500,000 CYS sell reverted inside the aggregator with "Amount must be positive", and its own minimum return still valued CYS near 9.9 cents. No retry came. The USDT and BNB had left by minute 34, and the last 2.8M CYS sat there until the blacklist. Someone who moved 7.2M in under half an hour gives up after one failed route, and I can't explain it. If you've seen that revert from a BNB Chain aggregator, what did it turn out to mean?