X100 exploit: a flashloan bought two of three senate seats, what to check now

An attacker took over the governance of the Ethereum project X100 Global on Saturday, October 24, 2026, and emptied its treasury. No stolen key and no bug in the program code were needed: the attacker borrowed money for the length of a single transaction, bought voting weight with it and took two of the three seats on what the protocol calls its senate. According to Bitcoin.com News, the security firm Blockaid tracked roughly $4.85 million in USDT and about 550,000 X tokens leaving the protocol across three transactions. The X token lost more than 96 percent of its value.

If you lock tokens in a protocol, to vote or to earn a yield, this case is less a story about a small project than a list of things to check. Every one of those protocols carries the same component: a vote that decides about money. Whether that vote lets time pass before it takes effect is a setting you can look up before you deposit.

What happened at X100 Global on October 24

X100 Global runs on Ethereum. Its treasury is called the Freezer, and a three-member body the project calls the senate decided over it. Those seats were not filled by an election but by the amount of X tokens locked in the Freezer: the three largest depositors held them.

According to the account of the security firm BlockSec, relayed by the news service MarsBit and published by KuCoin in its news section, the attack ran as follows. The perpetrator took out a flashloan, bought X tokens with it and spread them across two contracts he had set up himself beforehand. Both contracts locked their tokens in the Freezer. That pushed out two of the sitting senators and handed him the majority on the body, all inside the same transaction.

A flashloan is a loan that needs no collateral, because it is taken out and repaid inside a single blockchain transaction. If repayment fails, the whole transaction is discarded and the lender loses nothing. For the attacker that meant buying voting weight with someone else's capital without ever owning it. Bitcoin.com News puts the loan at roughly 1.94 million USDT and names the lending protocol Aave as its source.

Flashloan, Freezer and senate: the attack in four steps

The sequence is short enough to read in full, and that is exactly what makes it so uncomfortable. All of it happened without a waiting period in which anyone could have stepped in.

1. Take out the loan. The attacker borrowed roughly 1.94 million USDT and bought X tokens on the market with it.
2. Build up voting weight. The purchased tokens went to two self-deployed contracts, each of which locked a little more than 19,000 X in the Freezer. That moved both of them into the senate.
3. File a proposal and execute it at once. With two of three votes, the attacker resolved to sell 400,000 X out of the treasury into a liquidity pool he had created himself shortly before. He set the minimum output to zero.
4. Clear the treasury and repay the loan. The pool held almost no USDT. For the 400,000 X, only about 35.68 USDT flowed back into the Freezer, according to BlockSec. The attacker then withdrew his liquidity, sold part of the tokens in another pool and repaid the flashloan.

The third step is the actual theft. The treasury did not lose its tokens, it formally sold them, at a price the buyer had set himself. Technically, every single action was permitted.

400,000 X for 35.68 USDT: how the treasury proposal got through

The minimum output is the safeguard that stops anyone in any normal swap from selling at an absurd rate. Swap 400,000 tokens with zero as the floor, and you declare every possible consideration acceptable, $35.68 included. Nobody would do that with an ordinary exchange order. In a governance proposal voted through by a bought majority, it is precisely the point where the money leaves the protocol.

On the pool, the accounts differ. BlockSec places the pool that was set up on PancakeSwap V3, while Bitcoin.com News names Uniswap V3 for the sale that followed and for further access to liquidity positions. Both can be correct, because setting up and selling off are separate steps.

Why $4.75 million and $4.85 million can both be right

Two figures are circulating for the size of the loss. BlockSec arrives at about $4.75 million, Blockaid at roughly $4.85 million in USDT plus about 550,000 X tokens. The range of $4.75 million to $4.85 million is not a contradiction but a question of where the line is drawn: the higher figure counts follow-up transactions that ran only after the first report. At the time of its statement, Blockaid described an operation that was still under way and said about 12.2 million X were still sitting in the Freezer.

Read figures like these and watch the word behind them. USDT that has left is a fixed amount. Project tokens that have left are not, because their price collapses at the very moment they are sold. In an attack on a small token, a loss figure in dollars is always a snapshot.

No code bug: the three missing safeguards

Both reports reach the same conclusion about the cause, and it is not a programming error. Bitcoin.com News describes the failure as a design flaw in the governance, BlockSec speaks of a weakness in the design of the voting mechanism. Three components were missing.

Voting snapshot: voting weight as of a record date

The snapshot freezes voting weight at a point in time before the proposal. With it, the tokens the attacker acquired only after the proposal had been filed would not have counted. According to Bitcoin.com News, X100 used none.

Minimum holding period: borrowed tokens do not vote

The minimum holding period requires tokens to sit locked for a set time before they confer voting rights. It makes the flashloan useless as a tool, because it provides capital only for fractions of a second. That was missing too.

Execution delay: the deadline that makes an attack visible

The execution delay, or timelock, is the most important of the three. It puts a fixed period, usually 24 or 48 hours, between a resolution and its effect. In that window third parties read the proposal in plain language and can raise the alarm, and in many protocols an emergency body can stop it. Without it, no checkpoint is left between proposal and outflow.

None of these three mechanisms is exotic. Large DeFi protocols have run them for years, and they are set out in the documentation, not in the program code. You can look them up without understanding a line of Solidity. Lock capital in a protocol to earn a yield, and you will find the terms in the provider's governance rules; which platforms disclose their lock-up periods and voting rights at all is shown in our comparison of staking platforms.

The X token after the attack: a 96 percent price loss and empty liquidity pools

The price reacted at once. Bitcoin.com News reports a drop from $50 to $60 before the attack to around $1.75, which is more than 96 percent. Individual readings of liquidity on decentralised exchanges fell to a few dollars. No official statement from the project was available at the time of reporting; X100 Global had not confirmed the incident through its own channels.

That is the part that is repaired least often. A protocol can in principle replace stolen USDT if it holds reserves. A treasury that has handed over its own tokens at a price of zero, and a market in which those tokens are now being sold, cannot be turned back. Holders of X tokens do not have a price problem but a backing problem: the counter-value that gave the token a floor is sitting with the attacker.

For a sense of scale: Ether trades at around $2,329 on October 26, 2026 and has given up about 4.6 percent over seven days, with Bitcoin at around $80,227. The broader market did not react to the incident. That is typical for attacks of this size and at the same time the reason they are easily overlooked: four to five million dollars do not move the Ether price, but they hit every holder of the affected token in full.

Governance attacks are no isolated case: Bonk DAO and Term Finance

X100 is the third case of its kind we have reported on this year, and the pattern repeats itself. In July 2026, Bonk DAO lost around $20 million from its treasury, again without a hack in the narrow sense, but through the vote itself. In August it was Term Finance and a governance exploit, in which audited program code did not protect deposits, because the weakness sat in the rulebook above the code.

That leads to an uncomfortable conclusion for anyone valuing DeFi projects: an audit checks whether the program code does what the specification says. It does not check whether the specification makes sense. A protocol can be fully audited and still allow a majority bought in seconds to empty the treasury. The audit badge on a project page says nothing about that risk.

Put plainly: the question about the audit is the second question. The first is who can resolve a payout from the treasury, and how much time passes between the resolution and the payout.

What MiCA does not regulate about DeFi governance

Under the European crypto regulation MiCA, providers that hold, exchange or broker crypto assets in the EU need authorisation and come under supervision. For a customer of an authorised exchange, that means segregated client funds and reporting duties, among other things. We have set out those duties in detail in our overview of the MiCA obligations for crypto companies.

A protocol such as X100 does not fall under it. MiCA covers service providers, that is companies with customers. A governance in which anonymous contracts vote on a treasury has neither a provider in the sense of the regulation nor a body that could apply for authorisation. That is not a gap someone forgot, but a consequence of the design: where no service provider stands, no service-provider law applies.

Two sober consequences follow for holders. First, a loss in a DeFi protocol leaves no supervisory complaint and no deposit protection; legal action runs against unknown operators and is closed off in practice. Second, responsibility for checking shifts entirely to you. Buying through a regulated exchange in Germany and holding the tokens in self-custody carries a different risk profile than locking tokens in a protocol. How to hold your own keys and which devices manage it is shown in our hardware wallet comparison.

One note on tax, because the question comes up regularly after losses: in Germany, private disposals of crypto assets are subject to a one-year holding period, and a loss realised inside that period can in principle be offset against gains from the same kind of transaction. Whether a total loss through a protocol attack counts as a disposal for tax purposes is a question for your tax adviser in the individual case, not one an article can answer.

Timelock, quorum, snapshot: the terms that decide your risk

Four terms are enough to assess the governance of a protocol. They appear in any decent documentation, and if they do not appear there, that is the answer.

Timelock

The period between an accepted resolution and its execution. Common values run from 24 to 72 hours; zero hours is the warning sign from this case.

Snapshot

The point in time at which voting weight is fixed. If it lies before the proposal is filed, tokens bought afterwards are worthless for the vote.

Quorum

The share of all votes that must at least take part for a resolution to be valid. A three-seat body filled by deposit size effectively has no quorum in the sense of participation.

Emergency stop

A named body that can halt a resolution in progress. It is a concession to reality and a risk in itself, because it concentrates power. Its complete absence alongside a missing timelock is the combination that led to the total loss of the treasury at X100.

All of this can be checked in a few minutes. The governance documentation of a protocol names these values, and the voting portal shows for every proposal when it was filed and when it can be executed. If no interval appears there, that is not sloppy documentation but the setting itself.

Governance risk: without a timelock, one transaction decides

The attack on X100 has shown that the most expensive weakness in a protocol need not sit in the program code, but in a setting anyone can look up. Three steps turn that insight into action.

1. Look up the governance deadlines of your protocols. For every protocol in which you have locked tokens, open the governance documentation and search for the timelock. If you find no deadline and no documentation, treat the capital there as tied up at short notice. Which providers disclose their lock-up periods and voting rules is set out in the comparison of staking platforms.
2. Split your holdings. Tokens you want to hold for the long term do not belong in a governance contract but in your own custody. Which devices cover that and what they cost is shown in the hardware wallet comparison.
3. Watch for authorisation on the way in. For buying and selling in Germany, an exchange authorised under MiCA remains the route with supervision and segregated client funds; the duties that apply there are set out in our overview of the MiCA obligations.

A final point for context: governance attacks hit almost exclusively small protocols with few voters, because a majority is cheap to buy there. The risk falls as a project's market capitalisation rises, and it falls much further with the quality of its deadlines. Neither costs you anything but the time you spend looking it up.

(As of October 26, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)