Zergity

[Zergity @0xZergity]

@hinkal_protocol lets you deposit & claim tokens with no link between sender and recipient. To stop a deposit being spent twice, each note's nullifier must be bound to its stealthAddress — and Hinkal verifies that binding in the DEPOSIT circuit, not the spending one.

Requiring a zk proof on every deposit hurt UX, so prooflessDeposit offloads all proving to the spend tx. But the nullifying-key ↔ stealthAddress binding was never added to the spending circuit. So proofless notes skip the check entirely → one deposit, unlimited valid nullifiers → ~$772K drained.

https://t.co/dpzyQ5ib1P

[Zergity @0xZergity]

@LouisCKfanpage they do, by the ref's watch

[Zergity @0xZergity]

@hinkal_protocol you forgot the stealthAddress to nullifying-key binding (H1 = nk·H0) in the spending circuit for prooflessDeposit notes — so one deposit mints unlimited valid nullifiers. That's the ~$772K drain.

https://t.co/YfFR7aTrPI

[CertiK Alert @CertiKAlert]

#CertiKInsight 🚨

We have detected suspicious transactions involving @hinkal_protocol.

The EOA 0xbB3f01a1b1C68F3DEB36C55342b5F5706c32fc20 conducted multiple "Transact" transactions following a "Proofless Deposit" to drain a Hinkal contract of ~$800K USDC.

Stay Vigilant!

[Zergity @0xZergity]

8/ The real takeaway is bigger than one hack: EVM and blockchain have to get rid of the blind-signing UX. As long as wallets ask people to approve opaque EIP-712 payloads they can't read, every compromised frontend is a blank check. Human-readable, simulated, scope-limited signing shouldn't be a premium add-on — it should be the default the chain refuses to work without.

Full writeup + every tx hash: https://t.co/JBgIUQCjKQ

[Zergity @0xZergity]

1/ The $3.1M @Polymarket hack (June 25, 2026) keeps getting called a "malicious signature" drainer. We decoded it on-chain, and the exact mechanism hasn't appeared in any public writeup. It abuses @Polymarket's own account-abstraction.

[Zergity @0xZergity]

7/ The one piece nobody can recover: the malicious script itself. It was wallet-gated — served only to real wallet sessions. urlscan captures of https://t.co/txdMbQiB8D during the attack window show a clean page (no wallet → no drainer fires), and the one obfuscated third-party script on it decodes to a pre-existing ad-tech/fingerprinting stack (ruled out). Crawler tooling structurally can't catch a payload that only arms for a connected wallet, so the compromised vendor and the script's URL/hash stay unidentified.

[Zergity @0xZergity]

10/ The irony: the bot's profit-check simulation — the very thing that keeps it safe — is exactly what got weaponized. The honeypot never "broke" the bot. It made the bot's own simulator lie to it.

[Zergity @0xZergity]

1/ JaredFromSubway — the most active sandwich bot on Ethereum — was drained ~$15M on Jun 20 2026. Not a leaked key. Not a contract bug. A counter-MEV honeypot that turned the bot's own safety machinery against it. Here's the play, step by step. 👇

[zubic @zubic_eth]

This is actually insane 🤯

JaredFromSubway's MEV bot (the one that's been printing money for ages) just got cooked for $7.5 million in one of the sneakiest exploits I've seen.

This wasn't a contract hack. It wasn't phishing.

The bot basically approved its own robbery because it thought it was about to feast on a juicy MEV opportunity.

What happened:

> Attacker deploys fake wrapper tokens (fWETH, fUSDC, fUSDT) along with fake liquidity pools designed to look profitable

> The bot spots the "opportunity" and does what it's programmed to do, approving attacker-controlled helper contracts as spenders

> During early tests, those approvals get used immediately, so nothing appears suspicious

> In later transactions, the bot grants approvals that are never consumed or revoked, leaving the attacker with unlimited spending power

> Once enough approvals are collected, the attacker executes the final drain

> WETH, USDC, and USDT are pulled directly from the bot contract via transferFrom and sent to the attacker's wallet (0x3e37f4A10d771Ba9dE44b6d301410b1BEdeA65d0)

One example:

The bot approved more than 92 WETH to one of the attacker's helper contracts, and that approval simply remained active until the funds were drained.

This wasn't some random wallet drainer.

The bot's own automation was turned against it. It was doing exactly what it was designed to do, and that logic ended up being its downfall.

Wild times in MEV land.

Always revoke approvals, kids.

Even if you're a bot making millions.

[Zergity @0xZergity]

9/ Endgame: once enough standing allowances were armed, one sweep tx drained them via transferFrom → 1,474.58 WETH (16×92.16) + 2.87M USDC + 2.04M USDT, straight to the attacker. Reconciles to the wei. Builder tips spent: a few hundred dollars. Haul: ~$15M.