According to Cryptopolitan, reported on June 10, an anonymous attacker used Token of Power (TOP) tokens accumulated to exceed 50% of the circulating supply to complete the creation, voting, and execution of a governance proposal within a single transaction. After minting a large amount of new tokens, they cleared the Balancer V1 liquidity pool on Ethereum, extracting 944.2 WETH (about $1.58 million).
Attack Mechanism: How 8,192 TOP Completed Governance Takeover in a Single Transaction
The total supply of TOP tokens is 16,384. According to on-chain analysis by Blockaid, the attacker accumulated 8,192.000001 TOP tokens, exactly surpassing the 50% threshold and enabling them to have unilateral voting power to pass governance proposals. Since the Aragon Voting application has no time lock, the attacker used a dedicated contract to complete three steps in a single transaction:
Create governance proposal: Mint a large amount of new TOP tokens to the attacker’s address
Vote to pass: Unilaterally approve the proposal using voting power exceeding 50%
Execute immediately and empty the liquidity pool: The newly minted TOP tokens were exchanged in Balancer V1 BPool for 944.2 WETH
BlockSec Phalcon confirmed the proposal execution and token minting process. Balancer itself has no vulnerabilities; the attacker only used the liquidity pool to exchange TOP tokens whose supply had been artificially expanded into WETH.
Funds Path: Tornado Cash Top-Up and Current On-Chain Tracing Status
According to Blockaid’s on-chain analysis, the initial source of funds for the attacker’s wallet was Tornado Cash. The attack was carried out via a dedicated contract within a single transaction. As of the report on June 10, 2026, the 944.2 WETH could still be traced on-chain, but the addition of the initial Tornado Cash funding source increased the difficulty of recovering funds and confirming the attacker’s identity.
Root Cause: Missing Governance Settings, Not a Smart-Contract Code Vulnerability
The root cause of this incident was a missing layer of governance settings, not a traditional smart-contract code error—every contract function executed according to design. The missing specific settings include:
No time lock: No waiting period after a proposal passes, leaving other token holders unable to respond
No quorum delay: No requirement for a minimum proportion of token holders to participate in voting
No proposal creation delay: A proposal can be created and executed within the same block
With a total TOP token supply of only 16,384, the cost to gain majority control was extremely low. Aragon’s official documentation explicitly states that the permissions to call sensitive operations such as token minting must be restricted to authorized addresses, but TOP’s configuration failed to implement this requirement.
Status as of Publication: No Statement, Funds Still On-Chain
Cryptopolitan’s report confirmed that as of June 10, 2026: the Token of Power team has made no statements regarding this vulnerability; Aragon has also made no statements; and the 944.2 WETH can still be traced on-chain.
FAQ
Why was this attack categorized as a “governance vulnerability” rather than a “smart-contract vulnerability”?
Traditional smart-contract vulnerabilities involve attackers bypassing expected logic through code flaws. In this incident, all contract functions executed according to design—the governance voting operated normally, and token minting complied with the DAO’s configured permissions. The vulnerability lies in TOP’s DAO configuration, which allows a single holder to fully control the governance process with no time delay, which is a missing governance configuration rather than a code error.
Does the Balancer protocol need to take responsibility?
Based on the analyses by Blockaid and BlockSec Phalcon, it was confirmed that the Balancer protocol itself has no vulnerabilities. The attacker used normal token exchange functionality to exchange TOP tokens with artificially increased supply into WETH. Balancer, as a liquidity pool tool, was used, not as the attack target or the source of the vulnerability.
Which governance settings can prevent this kind of attack?
According to Aragon’s official documentation and the on-chain analysis of this incident, the following three configurations can prevent similar attacks: a time lock (setting a waiting period between proposal passing and execution); a quorum threshold (requiring a minimum proportion of holders to participate in voting); and proposal delay (allowing voting only after some time elapses following creation). As of the report on June 10, 2026, TOP had implemented none of the above settings.
