StrongBlock exploit analysis

The capture happened through StrongBlock's own governance machinery, not a stolen key. The StrongBlock DAO had been effectively abandoned, STRONG had become near-worthless, and the project's governance quorum of 200,000 votes had become cheap to manufacture on the open market.

The attacker actor at 0x4462d83150a38cfbe2a6a705861fb92358814d1d began by swapping 22 ETH into roughly 200,984 STRNGR on the Uniswap V2 STRNGR/WETH pair (block 25683569), then crediting those tokens to itself via StrongPoolV5's mineForVotesOnly() (block 25683578). With the votes accredited, the actor submitted a Governor proposal whose single action called Upgrader.setPendingAdmin(drainEOA) and described itself as "1" (block 25683599). The actor then voted its own proposal in (castVote(1, true)), so its roughly 200,984 forVotes cleared the 200,000 quorum. After the standard voting delay and 4320-block voting period, the proposal queued at block 25687923 and executed at block 25691516.

Execution set the drain recipient 0xACBCa357981870f30130B145762d671891CA810c as the Upgrader.admin. With admin authority, the drain recipient called acceptAdmin() (block 25691519), upgraded the StrongPoolV5 service proxy 0x53cA51Ba980B6475C13d158c1825013cf81038Fc to an attacker-supplied implementation (block 25691525), then ran the proxy's new implementation to forward the proxy's STRONG and STRNGR balances to itself (block 25691527). StrongBlock's defence-in-depth assumption was that voting power would remain scarce because the token would retain value. That economic condition no longer held.

Crypto.news reports a loss of roughly $72,000, citing Defimon Alerts. DeFiHackLabs' on-chain reconstruction reports the drained balances as 32,695.761681 STRONG plus 383,447.167299 STRNGR, drained from StrongPoolV5's service reserve. Numbers match across sources.

The DeFiHackLabs reconstruct is read against the live mainnet state at block 25683560, before the actor's 22 ETH swap, and runs the entire buy-votes, mine, propose, vote, queue, execute, acceptAdmin, upgrade, sweep sequence against the Governor and Upgrader as they stand on chain. The malicious service implementation is a minimal stand-in that exposes run() and forwards the proxy's token balances to the attacker; deploying code is not a privileged action.

What would have prevented it: any of the three standard DAO controls, none of which StrongBlock retained. A higher quorum or a non-transferable voting weight, where mineForVotesOnly's accounting read out of a non-STRNGR source. Or simply removing the Governor's authority over the ProxyAdmin of the operational contracts, so passing a proposal could not reach the service reserve.

The capture fits the pattern this corpus now sees several times a year: an on-chain governance system whose quorum was designed for an active token economy is still live on mainnet after the economy has gone, so any actor with capital can buy the keys at auction price. The governance rules themselves worked exactly as written.