Skip to main content
• 6 min read

Token of Power TOP Governance
Attack: 10B Mint Drains 944.2 WETH from Balancer V1

Token of Power was reportedly hit by a governance-takeover attack after an attacker gained majority voting power, used Aragon DAO to mint 10B TOP, and swapped the unbacked tokens for about 944.2 WETH from a Balancer V1 TOP/WETH pool.

AUTOSEC.DEVAUTOSEC.DEV
Token of Power TOP Governance Attack: 10B Mint Drains 944.2 WETH from Balancer V1
  • Incident Date: June 9, 2026
  • Target: Token of Power (TOP) on Ethereum
  • Target Overview: Token of Power is an Ethereum-based token project whose governance was reportedly wired through Aragon DAO. Public reporting described the affected surface as TOP governance and token mint authority, not the Balancer protocol itself.
  • Reported Loss: Approximately 944.2 WETH, valued at about $1.58 million to $1.59 million in public alerts.
  • Affected Liquidity: TOP/WETH Balancer V1 BPool.
  • Reported Governance Supply: The governance supply was described as only 16,384 TOP.
  • Reported Attacker Voting Power: The attacker reportedly acquired 8,192.000001 TOP, just over 50% of voting power.
  • Minted Supply: The malicious governance action reportedly minted 10 billion TOP to the attacker's contract.
  • Funding and Execution Notes: CryptoTimes cited BlockSec Phalcon saying the attacker wallet, truncated publicly as 0xff8e...b39Fa2, was funded through Tornado Cash. The exploit was reportedly executed through a separate contract truncated as 0x25c6...729A21.
  • Project Response: No official statement from Token of Power or Aragon had been identified in the reviewed sources at the time of writing.
  • Attack Vector: Governance Takeover / Aragon DAO Misconfiguration / No Timelock or Execution Delay / TokenManager Abuse / Unauthorized Mint / Balancer Pool Liquidity Drain

Incident Review & Technical Details​

1. Attack Path​

  1. The Attacker Acquired Majority Voting Power: Public reporting said the TOP governance supply was only 16,384 TOP. By obtaining 8,192.000001 TOP, the attacker crossed the 50% voting threshold and effectively controlled the DAO vote.
  2. Aragon Governance Allowed Same-Transaction Execution: The attacker reportedly used the Aragon voting system to create a proposal, vote on it, and execute it in one transaction. The critical issue was the absence of a meaningful delay, review window, quorum hardening, or emergency pause between proposal creation and execution.
  3. TokenManager Minted 10B TOP: Once the proposal passed, it reportedly called the Aragon TokenManager path and minted 10 billion TOP directly to the attacker's contract.
  4. Unbacked TOP Was Swapped for WETH: The attacker then used the newly minted TOP to trade against the TOP/WETH Balancer V1 pool.
  5. 944.2 WETH Was Extracted: Blockaid's alert, quoted by CryptoTimes, said the attacker drained approximately 944.2 WETH, worth about $1.585 million, from the Balancer V1 TOP/WETH BPool.
  6. Balancer Was Not the Root Cause: Public reports explicitly framed Balancer as the venue where unbacked TOP was sold for real assets. The reported bug or design failure was TOP governance control, not Balancer protocol logic.
  7. Tornado Cash Funding Complicated Attribution: CryptoTimes cited BlockSec Phalcon saying the attacker wallet was funded through Tornado Cash, reducing attribution clarity and making fund tracing harder.

2. Impact Scope​

  • Direct Economic Impact: Public loss estimates clustered around $1.58 million to $1.59 million, denominated as roughly 944.2 WETH.
  • Affected Network: Ethereum.
  • Affected Component: TOP's governance and mint-control path, reportedly connected to Aragon DAO and TokenManager.
  • Affected Liquidity: TOP/WETH liquidity on Balancer V1.
  • Affected Participants: Liquidity providers in the TOP/WETH pool and TOP holders were the practical risk surface after unbacked TOP was minted and sold into the pool.
  • Unaffected Components: Reviewed sources did not identify a Balancer V1 protocol bug, Ethereum consensus failure, WETH vulnerability, or generalized Aragon platform exploit. The available facts point to project-specific governance configuration and token-control design.
  • Disclosure Gap: A final postmortem, full transaction hash, complete attacker address set, patched governance configuration, and recovery or reimbursement plan were not available in the reviewed sources.

3. Root Cause Assessment​

This incident is best understood as a governance configuration failure. The attacker did not need to exploit a complex arithmetic bug or break Balancer. Instead, they acquired enough voting power in a small governance supply, passed a self-serving proposal, minted an enormous amount of TOP, and converted that artificial supply into WETH through available liquidity.

Key risk patterns to examine:

  • Governance Supply Was Too Small: If a majority can be acquired with just over 8,192 TOP, governance capture becomes economically cheap relative to pool liquidity.
  • No Effective Timelock: Proposal creation, voting, and execution in one transaction leaves no time for monitoring, veto, multisig intervention, or LP withdrawal.
  • Mint Authority Was Governance-Reachable: A governance proposal that can mint 10B TOP is effectively a treasury-drain function if market liquidity exists.
  • Quorum and Vote-Weight Controls Were Insufficient: Governance should account for circulating supply, quorum, voting delay, proposal threshold, vote snapshots, and anti-flash or anti-last-minute accumulation assumptions.
  • Liquidity Made the Attack Profitable: The TOP/WETH pool converted governance capture into WETH extraction. The pool did not need to be vulnerable; it only needed to accept TOP at a price before the market fully reflected the new supply.
  • Monitoring Did Not Stop the Single Transaction: When the full governance lifecycle executes atomically, standard governance-watch dashboards and human review are too slow.

The core invariant should have been strict: no immediately executable governance action should be able to mint market-moving TOP supply or redirect liquidity-sensitive value without delay, quorum hardening, proposal review, emergency veto, and supply-cap limits.

4. Mitigation and Response​

Recommended actions for TOP-style DAO and token-governance systems:

  • Add voting delay, voting period, execution timelock, and an emergency cancellation path for all governance actions.
  • Put mint, burn, upgrade, treasury, bridge, and liquidity-sensitive actions behind stricter quorum, proposal thresholds, multisig review, and supply-cap constraints.
  • Limit per-proposal and per-epoch mint amounts directly in token or TokenManager logic.
  • Require snapshot-based voting power and defend against last-minute accumulation, low-float capture, and same-block governance execution.
  • Treat liquidity pools as downstream victims: monitor newly minted supply, governance execution, large TOP transfers, and immediate swaps against TOP/WETH liquidity.
  • Build automated alerts for proposal creation, vote threshold crossing, immediate execution attempts, large mint calls, TokenManager calls, and abnormal pool reserve changes.
  • Reconstruct the exploit transaction on a fork and turn the create-vote-execute-mint-swap path into regression tests.
  • Publish a final postmortem with the exact governance configuration, proposal calldata, transaction hash, attacker contract, recovered funds if any, and changes made to prevent repeat capture.

AUTOSEC.DEV Solution: Building a 360-Degree Defense​

The Token of Power incident shows why DAO security reviews must cover governance economics and execution timing, not only Solidity syntax. If governance can be cheaply captured, every mint, treasury, bridge, and liquidity control reachable through governance becomes an attack path.

  1. DAO Governance Review: AUTOSEC.DEV reviews voting thresholds, quorum, proposal delays, timelocks, execution permissions, veto paths, snapshot assumptions, and privileged governance actions.
  2. Token Mint and Supply-Control Audit: We assess TokenManager, mint caps, role separation, market-moving supply changes, emergency pause logic, and governance-reachable token controls.
  3. Economic Attack Simulation: We model low-float vote capture, same-transaction governance execution, flash-loan or market-purchase vote accumulation, and post-mint liquidity extraction.
  4. Incident Response (IR): AUTOSEC.DEV supports exploit reconstruction, fund-flow tracing, governance lockdown, exchange and pool coordination, emergency disclosure, and post-incident hardening.

Service Content​

Reference​