X100 governance flaws trigger $6M loss due to a flash loan

Two separate blockchain governance attacks exploited different vulnerabilities to steal approximately $6 million, with X100 losing $4.75 million through a flash loan exploit and Arkadiko losing $1.09 million via a late-voting attack.

In the X100 attack, two helper contracts each froze 19,000.000001 X tokens under a one-year term, registered for Senate seats, and immediately voted to approve proposal 7. This single transaction executed a swap sending 400,000 treasury X tokens to an attacker-created pool, while repaying a flash loan of approximately 1.94 million USDT plus premium. The attacker extracted tokens from the pool and sold X to obtain repayment funds, with the frozen stake remaining untouched.

Arkadiko's ballot admitted late money

Meanwhile, Arkadiko's proposal 12 was submitted on October 17 and executed on October 22 after a five-day voting period. The attacker purchased approximately 4.573 million DIKOs worth about $51,000 just before the decisive vote, with Bitquery tracing showing 77% of the STX used came from an earlier StackSwap haul. The proposal closed with yes votes and zero no votes, immediately activating a malicious contract that removed $780,000 of stSTX, $135,000 of sBTC, and $173,000 of STX obtained by selling unbacked USDA.

Governance timing gaps exposed

Both attacks revealed fundamental flaws in governance systems. X100's year-long token lock didn't prevent immediate authority upon freezing, while Arkadiko's five-day ballot window allowed late purchases to influence the vote without creating a mandatory waiting period between approval and execution.

OpenZeppelin's governance documentation highlights historical voting power and execution timelocks as distinct mechanisms. The incidents demonstrate that newly acquired capital can gain authority too quickly, and approved actions can move assets immediately without sufficient time for community response or intervention.

Arkadiko restored normal operations on October 27 with proposal 14, "AIP 32.2 – Restore Vault Operations," which set the vault-operations entry to their legitimate v1-3 contract. However, both protocols now face questions about implementing execution delays or requiring longer stake durations to prevent similar attacks.