Switched from Ledger to OneKey a few years ago because their screens kept dying on me, and I never looked back. Still using OneKey daily with zero drama. Just got the OneKey Pro 2 — if you’re still on Ledger, maybe time to switch. #OneKey# #HardwareWallet# #Ledger#

I was pretty late to deposit into @fablesfi, but I still managed to break into the top 10. Here’s my lightweight audit of the project. The Fables founder @0xlayans also replied in the thread, outlining the improvements they plan to make. Deposit now, and you’ll be eligible for rewards at TGE in less than two weeks. Feel free to use my referral code: @RobinhoodCrypto robinhood:0xb9972ca7188e511174947e3936a5315ac7073277 #RobinhoodChain# #DeFi# #RWA#

I spent a short auditing @fablesfi — the hook-native ve(3,3) DEX on Robinhood Chain — from scratch. Not a checklist review. Every deployed hook read line by line, recompiled locally to prove the bytecode matches, then attacked on a live mainnet fork with 37 adversarial tests. The short version: the contract engineering is genuinely better than most of what I review. What should worry you is almost entirely somewhere else. Full breakdown 🧵 @RobinhoodCrypto $PROLOGUE #RobinhoodChain# #DeFi# #RWA# #UniswapV4# #ve33# #SmartContractSecurity# #DeFiSecurity# #TokenizedStocks#

🧵 Longbow (Robinhood Chain) — spot-oracle exploit, technical post-mortem + still-open advisory 1/ 🚨 Security advisory for @longbowlend The NOTHING market on Longbow was drained via spot-oracle price manipulation. The root cause is a design choice in the market's oracle — and as of Robinhood Chain block 55,530,002 it is still not fixed. Full on-chain breakdown 👇 #DeFiSecurity# 2/ The oracle. Market NOTHING (id 0x071fb8a9…f4b0be) is priced by 0x0F932e0fE68B0219820ffcB4C2B1906E29BedacC. Disassembling it: it reads a Uniswap v4 pool slot0 directly via extsload. No observe(), no TWAP. Longbow's own API labels its oracleType: "spot". 3/ Why that's fatal. Morpho Blue calls oracle.price() inside both borrow and liquidate. An instantaneous AMM spot price is movable within a single transaction, so the collateral valuation can be inflated and deflated atomically by the same caller. This is the textbook spot-oracle failure. 4/ The attack — tx 0x414b5b7c832b67dcd0c3f16907c8702ff794ce9dd0b749d0100e7549ba202d49 (a contract-creation whose constructor ran the whole thing atomically): ① pump the v4 pool ② supplyCollateral 20,599 NOTHING ③ borrow 24,691.89 USDG ④ dump NOTHING back into the pool 5/ ⑤ liquidate its own position, repaying only 914.45 USDG → Morpho returns all 20,599 NOTHING to the liquidator (= attacker) ⑥ sell the returned collateral ⑦ net 17,800.74 USDG to an EOA badDebtAssets written off: 23,777.45 USDG. 6/ Where the loss landed. The bad debt was socialized 100% onto the MonkeyHood / Partner VaultV2 0x19d55f7FE2d3962796F5825CbDae2dd493Be0986, which held 100% of that market's supply shares. The vault realized a ~95% write-down that has not recovered since. 7/ ⚠️ STILL OPEN — verified today at block 55,530,002: • oracle address unchanged (still the extsload/slot0 contract) • vault collateralToken cap still 50,000 USDG (not zeroed) • price() still live & manipulable • no remediation tx — only a 414 USDG adapter withdrawal since 8/ Fairness / scope: this is NOT a Morpho bug. @MorphoLabs markets are permissionless and behaving exactly as specified, and Morpho's own oracle guidance warns against raw AMM spot feeds. The vulnerable decision is Longbow's: a spot oracle wired to a live market with a non-zero cap. 9/ The rest of Longbow is not exposed to this vector — the other 54 markets use Uniswap V3 TWAP (e.g. PONS, backed by a deep pool w/ observationCardinality 20,000) or Chainlink feeds. NOTHING is the only market reading a raw spot price. But one open market is enough. 10/ Actionable asks for @longbowlend: 1️⃣ set the NOTHING collateralToken cap to 0 (stops new allocation immediately, no timelock) 2️⃣ retire/replace the oracle with a TWAP or Chainlink feed 3️⃣ audit every market's oracle bytecode for slot0/extsload vs observe()/latestRoundData 11/ cc curators & ecosystem for visibility: @SteakhouseFi @robinhoodcrypto @ponsdotfamily Read-only analysis, no funds touched, all reasoning reproduced on a mainnet fork. Reproducible IOCs above. #DeFi# #RobinhoodChain# #bow#

⚠️ Twofold ($TWO, Robinhood Chain) — a warning for LPs. I ran an independent, attacker-perspective audit and reproduced the attack on a local fork against real on-chain state: anyone holding Twofold's owner key can drain 100% of every pool's LP principal in four steps. In my PoC I took 100% of the SPY/USDG pool's SPY and all 5,755 USDG from the SPY+NVDA pools — no swap, no reentrancy, one transaction sequence. The mechanism, in plain terms: when the hook binds a "vault" contract it grants that vault an unlimited allowance (type(uint256).max) over the hook's entire balance of that token — while its internal bookkeeping is partitioned per pool. Allowance is global, accounting is per-pool. A vault bound to one new pool therefore gains control over the hook's balance of that currency across all pools. Four steps: ① the owner allowlists a fake vault it controls; ② opens a new pool binding it → the hook auto-grants the unlimited allowance; ③ the stock/WETH legs sit as RAW ERC-20 in the hook — just transferFrom them out; ④ the USDG legs live in Steakhouse — call emergencyRevokeVault to redeem them into the hook's raw balance, then drain. The nastiest part: after the drain the pool still reports the reserves as present, but the hook holds 0. LPs calling removeLiquidity simply revert — the ledger says you're owed, the tokens are gone, the protocol is insolvent toward LPs. Why every built-in defense fails: · the allowlist — the party that picks the vault and the operator are the same address, so the allowlist defends nothing against its own owner; · the "feeless-vault" probe — trivially passed with identity functions; the upstream code itself notes the probe can't stop an adversarial vault; · emergencyRevokeVault — only revokes the allowance of that pool's own vault, never the attacker's vault bound to a different pool. And the key to all of it is a single anonymous EOA: 0xC8720447712e6C4c851B3884b4Ec93F9cE8aD5fD — owner of every contract, de-facto controller of the hook, holder of most LP shares. No multisig, no timelock, empty cast code. Nothing can slow or veto those four steps. Exit signals to watch: a new vault added to VaultAllowlist, a new pool created, emergencyRevokeVault / PoolLivenessUpdated(false) events, that EOA or its linked wallets sending to the PoolManager/Settler, setRewarder / transferHookOwnership pointing at a new address. Disclosure: all attacks were simulated on a local fork only — no mainnet transaction was sent. I'm not claiming the team has rugged. I'm stating that the ability to drain LPs in full is real and sits in the hands of one anonymous, unchecked key that can act at any block. The underlying hook is Uniswap's upstream code deployed byte-for-byte; the "global allowance" design is upstream's, and upstream explicitly requires the operator to be trustworthy. Twofold made that operator a single anonymous EOA with no separation and no delay — while telling users "no contract path can reach LP principal." That's what turns a documented trust assumption into a live rug path. DYOR. Don't bet your principal on the goodwill of one anonymous private key. @RobinhoodCrypto @twofoldfi

$GOOG Alphabet's earnings are out. On the $200B capex guide, 82% cloud growth, the first negative free-cash-flow quarter since going public, and how depreciation is handled — plus which AI hardware companies this capex curve is actually paying. Alphabet Q2 2026, examined:

Bought some SK hynix. $SKHY My reasoning: all three major memory makers are pouring capex into HBM back-end capacity — but none of them is expanding DRAM front-end wafer capacity anywhere near as fast. HBM eats a huge amount of DRAM wafers. So in theory, even two or three years out, the DRAM supply-demand imbalance gets worse, not better. The more wafers get diverted to HBM, the fewer are left to produce conventional DRAM for everything else. And a single AI server needs a massive amount of HBM. HBM is the key bottleneck for token output speed on inference chips. It's not just NVIDIA — AMD, Google, and every big player building inference silicon is scrambling to secure supply. Full deep-dive here:

Aave unfroze WETH on Ethereum Core V3 on April 21. Opening exits before a loss-allocation plan is finalized creates a dynamic that is structurally disadvantageous to retail. Each withdrawal reduces the liquidity pool and enlarges each remaining supplier's pro-rata exposure to bad debt. By the time losses are socialized, the fewer WETH LPs remain, the larger the haircut each must bear. This does not disperse risk — it concentrates it on whoever exits last. The dynamic is amplified by asymmetric information access. Participants with technical tooling monitor repayment queues in real time and exit within seconds. Retail depositors cannot match that response speed. In scenarios of this kind, time advantage translates directly into loss avoidance. Kelp still holds substantial restaking ETH reserves, LayerZero remains solvent, and Arbitrum has frozen 30,766 ETH. Initiating a partial unfreeze before upstream responsibility is settled shifts the cost of that negotiation onto the slowest depositors to react — who are, overwhelmingly, retail.

Strongly agree, but LayerZero’s statement is clearly deflecting responsibility, and Aave doesn’t want to take the main blame either. They’ve probably already been arguing about it in the TG group.