Date: June 9, 2026

‍Chain: EthereumLoss: approximately $472K net (281 WETH). About $1.58M gross (944 ETH) before the attacker's own acquisition seed is subtracted.

‍Class: uncapped self-mint authority, the code-detectable enabler inside a governance takeover

‍Status: in scope for the mint flaw, preventable at the point the loss flowed through

Summary

On June 9, 2026, Token of Power was drained through a governance takeover. A Tornado-funded attacker bought a voting majority directly out of TOP's own Balancer pool, passed and executed a single governance action in one transaction, and used it to mint 10 billion TOP to themselves, which they dumped back into the pool for WETH. The exploit needed three separate conditions to line up, and only one of them is a code defect. The other two are governance configuration and token distribution. The single code flaw, an uncapped mint, was the one the entire loss passed through, and it is exactly the kind of defect pre-deployment analysis is built to catch.

The economic figures are worth stating carefully. The attacker pulled 944 WETH gross out of the pool, but 662.86 of that was their own capital returning from buying the majority, so the real loss to liquidity providers and the attacker's actual profit was near 281 WETH, roughly $472K. Trackers citing $1.58M are reporting the gross swap-out, not the net loss.

Background

Token of Power was an Aragon-based DAO. Governance held the authority to mint the TOP token through a TokenManager contract, and roughly 91 percent of the token's small 16,384 total supply sat inside a Balancer V1 pool as liquidity. Two design facts followed from that setup. Because most of the supply was pooled, a governance majority could be bought on the open market for the cost of acquiring just over half the supply. And because the mint authority had no ceiling, whoever controlled governance could create TOP without limit.

Neither fact is hidden or exotic. Together they meant that control of the DAO was for sale, and that control of the DAO was worth taking, because it unlocked an unbounded mint.

Root Cause

The exploit chained three enablers, and they belong to three different domains.

The first was a buyable majority. With about 91 percent of a 16,384 supply held as pool liquidity, an attacker could acquire a voting majority for roughly the cost of half the supply. This is a token distribution and tokenomics condition. There is no line of code that is wrong, so it is not something code analysis decides.

The second was atomic governance execution with no timelock. The Aragon Voting app executed a proposal the moment yes votes passed half of total supply, and creation, voting, and execution were collapsed into a single transaction. This is a governance configuration choice. The contracts behaved as configured, so this too is outside what code analysis flags as a defect.

The third was the uncapped mint, and this one is a code defect. The mint path in TokenManager.issue() called generateTokens() with no maximum supply check and no remaining-issuance limit, so any holder of the minting privilege, including a governance-captured vote, could inflate supply without bound. This is the enabler that turned a governance majority into 10 billion new tokens, and it is the enabler the entire loss flowed through.

The distinction matters because it is easy to dismiss an incident like this as purely a governance failure that no contract analysis could have helped. That reading is wrong. Two of the three causes are governance and tokenomics, but the third is a plain missing check, and without it the takeover produces nothing to sell.

Attack Flow

1. The Tornado-funded attacker swapped 662.86 WETH into the Balancer V1 TOP/WETH pool and pulled out just over half of the 16,384 supply, a bare governance majority.
2. In a single transaction, the attacker created a governance proposal, voted their majority, and executed it, since the Voting app executed the moment yes passed half of supply and there was no timelock to introduce any delay.
3. The executed action called the TokenManager to mint 10,000,000,000 TOP to the attacker's contract. No cap existed to stop it.
4. The attacker dumped the minted TOP back into the pool for 944 WETH gross, netting roughly 281 WETH after returning their own acquisition seed, and laundered the proceeds through Tornado Cash.

Impact

The pool's WETH was extracted to the attacker, supply went from 16,384 to over 10 billion, a dilution of roughly 600,000 times, and the price collapsed. The real loss to liquidity providers was near 281 WETH, about $472K, with 944 WETH as the gross figure that includes the attacker's returning seed. The Balancer protocol was not at fault. The pool was only the venue where the majority was bought and the minted tokens were sold.

The Problem With Audit-Only Security

When an exploit has several causes spread across code, governance, and tokenomics, the common reflex is to file the whole thing under "governance attack" and conclude that nothing on the security side could have prevented it. That conclusion quietly does two harmful things. It treats a multi-cause incident as if it had a single nature, and it lets the one cause that was a genuine code defect disappear into the others.

A one-time audit makes this worse in a specific way. A missing maximum-supply check is a classic invariant, the kind that is simple to state, that a contract should never let a mint exceed a defined cap, and simple to test. It is also the kind of invariant that a point-in-time manual review can pass over, especially in framework and inherited code where the mint path runs through a token manager and a base token implementation rather than a single obvious function. The review ends at launch, and a clean report then gets read as a guarantee of safety across governance and distribution decisions that the audit never examined at all. The contract was governed by code that allowed unbounded minting, and that fact sat in plain Solidity the entire time.

Separating the code-detectable cause from the governance and tokenomics causes is not an academic exercise. It is the difference between concluding nothing could be done and identifying the one load-bearing flaw that a continuous invariant check would have surfaced before deployment.

How Olympix Would Have Prevented It

Olympix targets exactly the kind of defect that carried this loss. The uncapped mint is the missing_mint_cap class: a mint path that reaches generateTokens() with no maximum-supply check and no remaining-issuance limit, leaving any holder of the minting privilege able to inflate supply without bound. BugPocer flags this by testing the invariant that every mint path must enforce a supply cap, and on a contract like this TokenManager that invariant fails, because the mint never compares against a maximum before issuing.

That detection is decisive here precisely because of how the loss was structured. All three enablers were required, but only the mint produced value for the attacker. A bought majority with no way to inflate supply is an expensive stake in a tiny token, not a drain. Closing the uncapped mint before deployment removes the path the entire loss flowed through, even though the governance capture would still be possible. The takeover becomes unprofitable when the mint it depends on is bounded.

This is also where the limits of code analysis should be stated plainly, because honesty about scope is the point. Olympix addresses the mint flaw. It does not decide that a token should not place most of its supply in a public pool, and it does not configure a timelock into a governance app. Those are tokenomics and governance design, and a complete defense pairs the code-level fix with a sane distribution and an execution delay. What code analysis owns is the missing cap, and the missing cap is what made the takeover pay.

This is not an argument against audits. A skilled human review remains valuable. It is an argument that an audit alone is not a security model, because a missing-cap invariant can survive a single review, and an incident with governance and tokenomics causes can hide a real code defect inside the narrative that nothing could have been done. Continuous, code-level analysis that tests the contract's invariants is what keeps that defect visible.

Takeaway

The Token of Power takeover needed three things to line up, but only one of them carried the money, and that one was a missing check. A mint with no cap let a governance majority become 10 billion tokens, and everything after that was a sale. The governance configuration and the token distribution were real weaknesses, and they sit outside what code analysis decides, but the load-bearing flaw was code, it was a plain missing invariant, and it was the kind a pre-deployment check surfaces and proves before the contract ships. Knowing which part of an exploit is code, and closing it, is the difference between a takeover that drains a pool and one that captures an empty seat. You can see Olympix test your contracts against the invariants that carry this kind of loss, with a working proof-of-concept for every finding, in a free demo.

On-Chain References

TOP Token: 0x0EBD5eC91680d3B0CEDbb1d5BB61851154D3eDb6
Exploit Contract: 0x25c68C44A96518294f5B47D758f98309c6729A21
Attacker Wallet: 0xff8eF7bC455a57e5893232203052Ce0232b39Fa2
Exploit Tx: 0x967aa34c69b7775c718545c7f94d92e965eb5fc553c0f27f6f1a9c65c93ac156

Flaw location: TokenManager.issue() -> generateTokens(), missing max-supply check
Finding class: missing_mint_cap (High)