Seems like your usual NPM supply-chain pop -- a maintainer account gets hijacked, a popular package ships a poisoned minor version, front-ends pull it and the JS swaps addresses / injects malicious approvals. We've seen variants before (event-stream, Ledger ConnectKit, etc.). Whether Ledger's tweet has marketing spin or not, the class of risk is real.

Hardware wallets help if you actually read the screen. For Bitcoin, confirm every output/address and amount on the device; For EVM, confirm to, value, chainId and especially approvals (unlimited approve() is how most drains start).

If you use a browser/extension wallet, assume the page can lie. Avoid copy/paste; use an address book or a QR / known contact. Do small test sends. Never type a seed anywhere except your hardware device during setup. If a web page asks for it then close the tab.
Check and revoke suspicious token approvals (e.g., revoke.cash) after using unfamiliar dapps.

For devs, freeze builds now: lockfile + exact versions, no auto-updates. Roll back any package released in the suspicious window until there's a clean advisory.
Verify checksums / provenance (npm --integrity, npm ci, Sigstore if you have it). Don't ship from latest.

A HW wallet won't save you from approving a malicious contract if you click through. "Clear signing" only helps if you read it. It can't stop drains from an already-granted allowance; that's on you to revoke.

Treat this like any other NPM blast radius -- freeze, verify, and verify on the device before you sign, somewhat decent opsec.

Seems like your usual NPM supply-chain pop -- a maintainer account gets hijacked, a popular package ships a poisoned minor version, front-ends pull it and the JS swaps addresses / injects malicious approvals. We've seen variants before (event-stream, Ledger ConnectKit, etc.). Whether Ledger's tweet has marketing spin or not, the class of risk is real.

Hardware wallets help if you actually read the screen. For Bitcoin, confirm every output/address and amount on the device; For EVM, confirm to, value, chainId and especially approvals (unlimited approve() is how most drains start).

If you use a browser/extension wallet, assume the page can lie. Avoid copy/paste; use an address book or a QR / known contact. Do small test sends. Never type a seed anywhere except your hardware device during setup. If a web page asks for it then close the tab.
Check and revoke suspicious token approvals (e.g., revoke.cash) after using unfamiliar dapps.

For devs, freeze builds now: lockfile + exact versions, no auto-updates. Roll back any package released in the suspicious window until there's a clean advisory.
Verify checksums / provenance (npm --integrity, npm ci, Sigstore if you have it). Don't ship from latest.

A HW wallet won't save you from approving a malicious contract if you click through. "Clear signing" only helps if you read it.It can't stop drains from an already-granted allowance; that's on you to revoke.

Treat this like any other NPM blast radius -- freeze, verify, and verify on the device before you sign, somewhat decent opsec.