Wasabi Perp's admin authority across Ethereum, Base, and Blast was held by a single private key with no timelock, no co-signer, and no execution delay. When that key was compromised, the protocol drained itself through its own privileged functions in two hours.
The access checks passed. The role grants were real. Every transaction is traceable onchain back to Wasabi's own deployer wallet. No vulnerability in the smart contract code was found or exploited. The protocol was drained through its own privileged function surface because a single private key held unconditional authority over all of it.
Hypernative's detection engine flagged the attacker's orchestrator contract as a suspected drainer at 07:46:23 UTC, three minutes before the first vault drain. Wasabi is not a Hypernative customer, so no automated response was configured. However, for a protocol or asset manager with monitoring and response active on Wasabi's admin infrastructure, that window was enough to pause vaults or unwind positions before a single transaction settled.
Wasabi Perp is a perpetual futures protocol deployed across Ethereum, Base, and Blast. Its architecture uses per-collateral ERC4626-style vault contracts, long and short pool contracts, and a central PerpManager contract that acts as the owner and authority of every vault and pool.
Admin authority on each PerpManager is the protocol's highest privilege: it controls strategy redirection on every vault, gates implementation upgrades on every upgradeable contract, and can assign further admin rights. From the day of protocol deployment, that authority had been held by a single wallet across all three chains, with no timelock, no co-signer requirement, and no execution delay on any privileged operation.
Pre-staging
Admin grant before deployment
Vault drain across three chains
Pool drain via contract upgrade
Consolidation
At the time of writing, Wasabi's deployer wallet still holds admin rights on every contract across all three chains. The attacker-controlled contracts also retain admin rights. The incident is classified as active.
Nothing in the contract code was wrong. The access checks admitted the attacker's calls because the attacker genuinely held admin authority at the time, granted moments earlier by Wasabi's own deployer wallet. Those grants are real transactions, signed by the legitimate key, and visible onchain.
The failure was in how authority was structured. A single private wallet held total control over every vault, pool, and upgrade path across three chains with nothing to limit what that wallet could authorize and no delay between a grant being signed and taking effect. Once that key was in the wrong hands, there was no friction anywhere in the chain.
Hypernative's platform flagged the orchestrator contract as a suspected drainer at 07:46:23 UTC, two minutes before the first role grant and three minutes before the first vault drain
The gap. No monitoring was in place for drainer-class bytecode being deployed from wallets connected to protocol admin infrastructure, before any privileged call was made.
Policy. Drainer Deployment Policy: any contract deployment from a wallet that has previously interacted with protocol admin contracts, where bytecode analysis scores above a defined drainer threshold, triggers an immediate alert. The policy fires before any admin grant is signed.
Monitoring and response. Hypernative's drainer bytecode ML model flagged the orchestrator contract as a suspected drainer at 07:46:23 UTC, two minutes before the first role grant and three minutes before the first vault drain. For teams with Onchain Monitoring & Response active, that window was enough to alert the security team and trigger an emergency vault pause before a single vault moved collateral, while those with positions in Wasabi vaults, the signal was available as a portfolio trigger. A watchlist configured on Wasabi's admin infrastructure, paired with an automated position unwind on drainer detection, would have initiated an exit three minutes before the drain executed. The signal was there; what was missing was a response configured to act on it.
The gap. Wasabi's deployer wallet signed an admin grant to an unknown address with no execution delay. Nothing flagged this as the attack in progress that it was. With the grant taking effect immediately, the window between the first admin grant and the first vault drain was one minute.
Policy. Admin Key Activity Policy: any role-granted event on a PerpManager is checked against a pre-approved list of expected grant destinations and scheduled maintenance windows. A grant to any address outside that list, or issued outside a defined window, triggers an immediate alert and automated vault pause. The policy evaluates the destination address, not the signer's identity.
Monitoring and response. A role-granted event from your own admin wallet to an address you did not authorize is the clearest possible onchain signal that a key compromise is in progress. It fires before any funds move. Monitoring for unscheduled admin grants across all three PerpManagers, paired with an automated emergency pause or withdrawal trigger, turns a one-minute window into enough time to act. If holding positions with collateral exposure, this is precisely the kind of event a watchlist is built for. An alert on any unscheduled admin grant, configured to trigger an automated position exit, would have initiated an unwind before the first drain transaction settled. The loss was realized over the following minutes; a pre-configured response acts in seconds.
The gap. strategyDeposit accepted any address as a fund destination with no whitelist and no post-call verification that vault assets remain in place. Once admin access was established, draining every vault required only one call per vault.
Policy. Strategy Whitelist Policy: any call to strategyDeposit routing collateral to an address not on the governance-approved strategy list is blocked before execution. The policy evaluates the proposed destination regardless of the caller's identity or whether their admin rights were legitimately obtained.
Monitoring and response. Monitoring for strategyDeposit calls to unrecognized addresses flags the drain on the first vault before the loop completes across the remaining seven. With automated position management, a vault balance drop alert on any Wasabi vault token would have triggered an exit across correlated positions, in lending markets, yield strategies, or anywhere those vault tokens were held as collateral. The balance drop is immediate and measurable; a pre-configured unwind acts on it without requiring manual review. Being first out of a draining vault is not luck. It is a watchlist and a response rule.
The gap. Replacing the WasabiLongPool contract implementation required only a single admin-approved call. No governance process, no second signer, no verification of what the new implementation contains. One call swapped legitimate code for attacker-authored code that swept pool balances in the same transaction.
Policy. Upgrade Governance Policy: any contract upgrade is evaluated against a pre-authorized implementation list. An upgrade to any address not previously reviewed and approved is blocked. The policy does not assess the purpose of the upgrade; it checks only whether the destination implementation was authorized before the call executes.
Monitoring and response. Monitoring for upgrade events to unverified contract addresses on WasabiLongPool and WasabiShortPool flags the implementation swap at the point it is attempted. With Transaction Guard pre-transaction enforcement, a policy blocking upgrades to non-whitelisted implementations intercepts the call before the implementation pointer changes and before the attacker's code is ever active.
The gap. Each individual step passed its access check. The attack pattern as a sequence (unexpected admin grant from a known deployer wallet, followed immediately by privileged calls from the newly-granted address, followed by fund movement) is only identifiable as a compound sequence. Monitoring any single event in isolation does not catch it.
Policy. Admin privilege escalation sequence policy: flag any sequence where a new address receives admin rights from a known admin wallet and then calls privileged functions within a configurable block window. A stateful policy monitoring the full grant-to-call sequence identifies this attack class regardless of which specific functions are subsequently invoked.
Monitoring and response. Hypernative's first detection fired at 07:46:23 UTC. The admin grant followed at 07:48. The first drain at 07:49. Three minutes separated earliest detection from first loss. That window is a circuit breaker: an automated vault pause or emergency guardian response turns detection into prevention. For any investor with automated portfolio management configured, the same alert window triggers a position unwind before the loss is realized. Detection without a response configured to act on it is a record of what happened. Detection with automated response is the constraint that key custody alone was not.
The same controls prevent operator error, not just key compromise. A strategy whitelist on strategyDeposit blocks an attacker routing collateral to a stub but also blocks an engineer accidentally pointing a vault at the wrong address during a migration.
An upgrade governance policy blocks attacker code from replacing a pool implementation. It also blocks a rushed deployment of an unaudited fix during an incident. An admin grant watchlist flags a privilege escalation by a compromised key. It also flags a fat-finger transaction sending admin rights to the wrong address.
Transaction validation asks: is this specific action malicious? Policy enforcement asks: is the resulting protocol state safe? The Wasabi attack used legitimate signatures to produce an unsafe state. The same gap is open every time an operator with admin rights makes a mistake.
At the time of writing, Wasabi's deployer wallet still holds admin rights on every contract it controls across Ethereum, Base, and Blast. The attacker-controlled contracts also retain admin rights. The WasabiLongPool implementations on Ethereum and Base remain the attacker's code. None of these state changes have been publicly reversed onchain.
The initial drain is not the only risk. The same access that executed this attack can re-upgrade any vault or pool, assign admin rights to new addresses if existing attacker contracts are blocked, and redirect vault strategies again. The total exposure is the entire current value of every Wasabi-controlled contract across all three chains, not just what was drained this morning.
→ Watch the contract events. Set up alerts on admin grant, contract upgrade, and strategyDeposit events across all three PerpManager contracts. Any of these firing without a corresponding public announcement from the Wasabi team is a signal to act before waiting for further confirmation. Hypernative's Onchain Monitoring & Response supports per-event watchlist configuration across all three chains with custom alert conditions and automated response actions.
→ Watch the deployer wallet. Any transaction from Wasabi's deployer wallet to any of the three PerpManager contracts is an admin action. Monitor this address across Ethereum, Base, and Blast. An admin grant from this wallet that was not publicly announced is the earliest onchain warning the attack is continuing.
→ Assess downstream collateral exposure. Lending markets, yield protocols, or any position that holds Wasabi vault tokens as collateral carries residual risk until the admin migration is verified onchain and the affected pool implementations on Ethereum and Base are redeployed with legitimate code. Transaction Guard policy enforcement can add pre-transaction checks blocking any further interaction with Wasabi contracts whose admin state has not been publicly confirmed clean.
Reach out for a demo of Hypernative’s solutions, tune into Hypernative’s blog and our social channels to keep up with the latest on cybersecurity in Web3.
Secure everything you build, run and own in Web3 with Hypernative.
.png)
.png)