X100 Governance Attack: Flash-Loaned Votes, a Drained Treasury and Five Checks

On October 24, 2026, X100 Global on Ethereum was torn apart by a flash-loan governance attack: the attacker seized two of the project's three "Senate" seats, reached into the treasury, and the X token subsequently crashed 96%. Security firm Blockaid traced roughly $4.85M in USDT losses, and Chainalysis observed the stolen funds being swapped into ETH and split across four wallets holding 400 ETH each.

What really deserves attention here is the attack method: no code vulnerability, no leaked private key — the attacker simply moved the money out through "legitimate voting." If your portfolio holds any token with a governance mechanism, this checklist is worth a read.

How the attack unfolded: three "legitimate" steps to drain the treasury

Based on Blockaid's on-chain monitoring and multiple post-mortems, the process went roughly like this:

1. Borrow governance tokens via flash loan. In a single transaction, the attacker borrowed enough X tokens to obtain voting power — and repaid the loan before that same transaction ended, so almost none of their own capital was at risk.
2. Seize Senate seats. X100 Global's governance uses a "Senate" seat system with three seats in total; the attacker took two of them, gaining majority control.
3. Propose and execute within a single transaction. Governance allowed instant voting, no snapshot, no timelock, and no minimum holding period, so a proposal went from submission to execution inside one transaction: dump 400,000 X from the treasury into the attacker's own pool and drain the liquidity; then another attacker burns the Freezer contract's Uniswap V3 position, and a third party uses the same Senate path to pull out a position of about 550,000 X.

This is what makes a governance attack so frightening: the contract code may be correct, and the vote result may be genuinely valid, yet decision-making power can be rented within seconds. When the cost of controlling governance is lower than the value of the assets in the treasury, the attack is economically worthwhile.

Governance attacks aren't rare — they just rarely make headlines

According to the public incident dataset from DefiLlama, 312 security incidents have been recorded so far in 2026, of which only 10 are classified as "Governance." The count is small, but the damage per incident is enormous — because it takes the treasury outright rather than arbitraging a price gap in some pool. X100 is flagged separately in the dataset as a "Flashloan Governance Attack," the most typical example of its class.

This also explains why governance attacks are easy to overlook: the attacker doesn't need to write exploit code or phish a private key, only to find a "rentable decision-making power" in the governance parameters. ApeCoin in 2022 falls into the same category (also flagged as a flash-loan governance attack). In the October 2026 DeFi incident list, price manipulation dominates; governance attacks amount to just this one, yet it took nearly $5 million in a single blow.

Judging whether a protocol's governance is safe: five checks

X100's governance flaws are highly typical, and inverted, they become your checklist. For any protocol with a treasury, ask these five questions first:

1. Does the proposal support snapshots? If voting power is calculated from the "current real-time balance," a flash loan can borrow tokens and vote; with a historical block snapshot, borrowed tokens carry no voting power. X100 is the former.
2. Is there an execution timelock? After a proposal passes, it must wait (commonly 24–72 hours) before it can execute — the most important buffer, giving the community time to notice and exit. X100 has no timelock, so proposal and execution complete in the same transaction.
3. Is there a minimum holding period? Requiring governance power to be held for a period directly kills the flash-loan model.
4. What authority is needed to move treasury funds? Is the treasury controlled by a single governance contract, or by a multisig plus timelock? Can all assets be moved out in a single transaction?
5. Can governance power be rented? If the governance token has deep liquidity on a DEX with no lock-up, anyone can temporarily buy enough votes.

If "no snapshot + no timelock + no minimum holding period" all hold true at once, the protocol's treasury is essentially open to flash loans.

What ordinary users can do

• Don't look only at TVL and APY. High yields often mean a protocol is trading scale for aggressive parameters — and the more aggressive the parameters, the greater the payoff from manipulating them.
• Check what the audit report actually covered. Many audits review contract logic but not governance parameters (snapshots, timelocks). Passing an audit ≠ safe governance.
• Favor protocols with a timelock. This is the most practical hard rule, and it's publicly verifiable.
• Don't park large amounts in a single protocol. After X100 crashed 96%, there was almost no liquidity left — you couldn't even get out.
• Pull out the moment you see a "governance surprise proposal." When an unusual proposal appears on community forums or X, the timelock is the only escape window you get; with a protocol that has none, you can only regret it afterward.

To systematically review hack types and compensation records, you can follow the same analytical approach used in the hardware wallet supply-chain attack post-mortem and the Gate security special review: look at the historical disclosure record first, then the technical parameters, and only then the promotional narrative.

FAQ

Can money stolen in a governance attack be recovered?

The odds are very low. The attacker has already swapped the stablecoins into ETH and spread them across multiple wallets; on-chain tracing can only flag addresses, not force recovery. Unless the project has other reserves or works with exchanges to freeze deposits, it's essentially a permanent loss.

Can X100's X token still be held?

Based on public data, X has crashed 96% and liquidity is close to exhausted. The problem with such a token isn't "will it rebound" but "is there anyone left to trade against" — an illiquid asset's paper price is meaningless. Any "buy the dip" decision should rest on public facts, not community sentiment.

Why is this not a "contract vulnerability"?

Because the contract executed its logic correctly as designed, and the vote satisfied the governance rules. The problem lies in governance parameters (no snapshot, no timelock) that turned a "legitimate process" into an attack path. That's also why a pure code audit can't catch it.

Don't large protocols avoid this problem?

No. The larger the protocol, the better the governance token's liquidity, and the cost of renting votes may actually be lower relative to the size of the treasury. The difference is that large protocols usually have timelocks and snapshots, which raise the attack cost.

How can I check DefiLlama's data myself?

The public dataset lives at api.llama.fi/hacks. It returns JSON with the date, project name, classification, technique, amount, and chain. You can aggregate it yourself by year and category instead of relying on numbers relayed by the media.

Risk notice: Cryptoasset prices are highly volatile and you may lose your entire principal; this article does not constitute investment advice. Details of the X100 incident are subject to disclosures from security firms such as Blockaid and follow-up statements from the project; loss figures are still being tallied and may change. DefiLlama data is aggregated from a public dataset, and its methodology may differ from media reporting — refer to the original dataset. DeFi protocols carry multiple risks including smart contracts, governance, and oracles; please assess them yourself.