On-chain losses have moved from smart-contract bugs toward credential compromise and social engineering.

Please walk us through the permit-signature chain. Once a victim approves that off-chain signature, what can the attacker do, and why does a hardware wallet not stop it?

Amador: A permit signature is a standing authorisation. You sign a message off-chain that says: “This address may spend these tokens from my wallet.” No funds move at signing. Nothing shows up on-chain. That’s the trap.

The chain of attack works in three moves. First, malware gets on the device, usually through a fake video call link or a “software update” prompt. Second, the attacker waits and watches wallet activity. Third, they slip a permit request into a moment that looks routine. The victim signs. The attacker now holds a valid, transferable claim on those assets. They can execute it in an hour or in a month, from anywhere, without touching the victim’s device again.

And they choose the moment. Often the drain executes at 3 am in the victim’s timezone, when nobody is watching the wallet and nobody can intervene. By the time the victim wakes up, the funds have already moved through mixers and bridges.

The hardware wallet doesn’t stop it because the hardware wallet did its job perfectly. It signed exactly what it was given. The compromise happened upstream, in what the victim believed they were signing. Many hardware devices display limited details on signing requests, so the screen shows a hash or a truncated payload, not “you are granting unlimited spend to an attacker.”

This delivery method mirrors the social engineering that hit capable teams like Drift and Humanity. When a well-resourced target is compromised through people rather than code, how is it detected and blocked?

Amador: You don’t detect it at the perimeter. The Drift case proves that. The attackers spent six months posing as a quantitative trading firm and built relationships with contributors in person at crypto events. One contributor was likely compromised by cloning a shared code repository. Another was persuaded to beta test a fake wallet app on TestFlight. Against a nation-state adversary with a six-month budget and a payroll, no one wins on vigilance alone.

So you detect at the point of execution, and you block with process.

First, no blind signing, ever. Every privileged transaction gets simulated and verified in human-readable form on an independent device before it’s signed. At Drift, council members signed transactions they did not fully understand.

Second, timelocks. Drift migrated to a 2/5 multisig with zero timelock days before the attack, which eliminated the delay that would have allowed detection and intervention. A 48-hour delay on admin actions turns a 12-minute drain into a blocked attempt.

Where does coordinated disclosure fit in an attack class that begins with malware and social engineering rather than a contract vulnerability?

Amador: It fits everywhere except where people assume it fits. The contract wasn’t the entry point in these incidents. But the attack still ran through software, and software has bugs someone found first.

With Drift, the initial infection likely exploited a known vulnerability in the VSCode and Cursor editors that allowed silent arbitrary code execution. That’s a disclosable bug. If a researcher finds it and gets paid before an adversary weaponizes it, the six-month attack operation loses its foothold. Same for wallet signing interfaces that truncate transaction detail, TestFlight distribution abuse, and CI/CD pipelines.

The scope of disclosure has to expand to match the scope of attack. Smart contract-only bug bounties defend the one surface attackers have stopped preferring. The programs that work now cover infrastructure, key management flows, signing UX, and the supply chain around the protocol.

The second fit is response. Whitehats and groups like SEAL 911 were in the Drift fight within hours. Coordinated disclosure is a standing relationship with the researcher community so that when staging behavior appears on-chain, the people who recognize it have a channel and an incentive to say so.

When defending a protocol treasury against standing-authorization abuse today, what controls would you prioritize first?

Amador: In this order:

1. Kill blind signing. Human-readable verification of every payload, simulated on a device separate from the one that received the request. If a signer can’t explain what a transaction does, it doesn’t get signed. This is the cheapest control, and it defeats the core mechanic of both the permit-signature scam and Drift’s durable nonces.
2. Timelocks on all privileged actions. Zero exceptions, especially during migrations. Migrations are when attackers strike because that’s when defenses are down.
3. Minimize standing authorizations as a category. Audit and revoke token allowances quarterly. Ban pre-signed transactions for treasury operations. Cap approval amounts. Every open authorization is a loaded claim on your assets waiting for an execution date.
4. Separate powers. Humanity Protocol’s structural failure was one key trusted with both the funds and the power to rewrite the rules. Attackers took proxy admin control, drained roughly 141 million H, and minted 200 million more through malicious contract upgrades. Mint authority, upgrade authority, and treasury access should never share a compromise path.
5. Pay good actors. At Immunefi, we have 85,000 security researchers probing protocols for exactly these failure modes.