I keep saying this; show people what they're signing Tried @phantom new gasless EVM swap on @base today. Fresh burner. normal EOA. 0 eth. 5 used. Zero approvals. Wallet: basescan.org/address/0x5017B… funding: basescan.org/tx/0x823ed96ce8… Enable smart account delegation. Pay gas in USDC. swap 2 usdc for WETH. Worked. No eth needed. basescan.org/tx/0xc0322baff4… Then Remove account delegation Phantom removed it. Wallet is an eoa again. basescan.org/tx/0x276f3ad62f… Opened @RevokeCash 7702 gone. Two USDC approvals from that same swap still there Near-max // Unlimited to @0xProject AllowanceHolder: 0x0000000000001fF3684f28c67538d4D072C22734 Plus paymaster 0x2cc0c7981D846b9F2a16276556f6e8cb52BfB633: leftover 0.006121 usdc. Dust I signed it. That's the point. Neither spender nor amount showed up on enable, swap review, or remove. I had to open an explorer and Revoke.cash to see what the swap had actually approved. Phantom help article covers 7702, alchemy, temporary delegation, and remove. Not the token approvals. Not the amounts Not that they survive remove.. help.phantom.com/articles/un… @0xProject says AllowanceHolder is formally verified. Fine. 0x.org/enterprise/security-b… Phantom still created a near-max approval, didn't show it, and left it after Remove It has no expiry. Future USDC is covered too. Old approvals already get people drained. @RevokeCash tracks more than $495M stolen through approval exploits since 2020 - revoke.cash/exploits ekubo in May 2026; 31 addresses, about $1.43M lost after a router bug met existing approvals. Different contract The bug came later. The approvals were already there. blog.ekubo.org/the-huff-rout… Tried to revoke both through Revoke.cash. It generated approve(0) Phantom: Not enough ETH. No tx Gasless in. Native ETH to clean up after. Nice. Phantom own guide sends EVM users to Revoke.cash to inspect and revoke approvals: help.phantom.com/articles/37… @phantom, the swap worked. The permission UX didn't. Show both approvals before I sign. Say exactly what Remove clears. Let me wipe the leftovers before you flip the wallet back to EOA.....

I've spent the last few years betting that the wallet becomes the whole trading app,, so "Web3 is dead" is where you lose me. @fomo and @Pumpfun nailed the product loop; see it, buy it, never leave the app. that's a product win. It doesn't mean the old distribution playbook is dead. People aren't dpne with Web3. They're done dealing with the plumbing: chains, bridges, gas, dApp hops. Hide that shit. if the wallet connection step disappears from the screen, great. The uX got better. The wallet and protocols didn't die. But a deposit in every app plus Google/X login? We just moved the mess from chains into apps and put a web2 account next to my money. How is that an upgrade? A wallet can be the whole mobile trading app. I keep the keys and can recover if the app vanishes. If something moves on @BNBCHAIN while my money is on @solana , I shouldn't need another app. Same if it's on @ton_blockchain . One place to check it and trade it. spot, perps whatever. Let the app handle routes, bridges and gas. Apple Pay to fund it, Face ID to unlock. Google/X doesn't need to be the door to my wallet. My wallet doesn't need my identity. i don't want the bank back in the middle.

Solana won my network poll, so I took the hint and spent some time looking through the latest network changes. the obvious headline is SIMD-0525: the 350ms slot target is now live. Faster slots and the shorter blockhash window have already been covered. I wanted to see what this changes higher up the stack, so I went through the proposal, docs and public protocol code. What I hadn't seen discussed much is what happens one layer above it:: the chain clock moved, while some app logic still reads time through the old 400ms assumption The SIMD warns about this directly. anything measured in slots now covers less real time, and programs that treat slot distance as wall-clock time may need an update Static SDK constants also stay unchanged for now. @switchboardxyz's Solana tutorial gave me the cleanest example: `.max_age(30)` rejects data older than 30 slots and describes that as roughly 12 seconds.. At the 350ms target, those 30 slots are nominally 10.5 seconds. At 200ms, 6 seconds. Same code. Same parameter. Different risk policy. Switchboard is doing exactly what it says. If you meant 30 slots, the rule still does exactly what you asked. If you meant roughly 12 seconds, you don't have 12 seconds anymore. I checked @kamino's public kLend code and found the same handoff. The path starts with Switchboard's last update slot, uses DEFAULT_MS_PER_SLOT to manufacture a timestamp, then checks that against a max age in seconds. the SDK constant is still 400ms, so against the 350ms target the nominal age comes out 14.3% higher. At the 200ms target, it would read as 2x older than it really is. A 30-second policy would trip after roughly 15 seconds of wall time, without anyone changing the policy. The deeper problem isn't the number 400. It's that a risk check silently translates between two clocks. And this is why "just use `Clock::unix_timestamp`" isn't the whole fix. the current time is in seconds, but this oracle update starts in slots Both sides of the check still need to speak the same clock No exploit claim here. The bias is conservative: valid data can look stale sooner. This is an availability risk, not a direct value-extraction path. The important part is that the handoff exists in real code. This is exactly why I keep banging on about the full execution path. The network can report the right slot. The oracle can report the right update. The check can run exactly as written. the final behavior still changes at the handoff between protocol time and real time. This actually makes me like @Solana's staged rollout more. A faster clock is good infra, and every gate gives builders a real checkpoint to catch these assumptions before 200ms. Before the next gate, grep for every `max_age`, staleness check, cooldown, retry and timeout expressed in slots. Did you mean slots or seconds? @bw_solana, should apps stop converting between the two entirely: slots for protocol ordering, timestamped data for wall-clock policy? And if so, what should an oracle expose so apps never have to manufacture that timestamp themselves? SIMD-0525: github.com/solana-foundation… Switchboard example: docs.switchboard.xyz/docs-by… SDK constant: github.com/anza-xyz/solana-s… Public code example: github.com/Kamino-Finance/kl… github.com/Kamino-Finance/kl…