Two governance attacks in October exploited different gaps between acquiring voting power and executing approved actions, leading to millions in losses. On Oct. 24, an attacker gained two Senate seats on X100 and approved a treasury transaction while repaying a flash loan in a single blockchain transaction. Days earlier, a malicious proposal on Arkadiko passed after a late purchase of voting tokens, giving a contract control over vault assets.
X100: locked stake, immediate authority
X100’s Freezer contract holds frozen X tokens and provides the stake used to rank candidates for its Senate. Lock terms run for one, three, or five years, but Senate eligibility depends only on the amount currently frozen, with no minimum stake age.
In the first Oct. 24 attack, two helper contracts each froze 19,000.000001 X under the one-year term. They registered, entered the ranking, and supplied the two supporting votes that executed proposal 7—all in a single transaction. Holding two of the three Senate seats gave them enough power to act immediately while the proposal was open.
The approved swap sent 400,000 treasury X into an attacker-created pool. The Freezer received only 35.675313 USDT, and the attacker then extracted tokens from the pool and sold X to obtain cash for repayment. The attack borrowed about 1.94 million USDT and repaid the principal plus its premium. After repayment, about 4.75 million USDT reached the first final recipient. ChainBounty contributor Philippark reconciled 4.848 million USDT paid to three selected recipients, a subtotal that excludes unsold X and its changing value.
The Freezer retained a constraint: after execution, its X balance had to cover the total amount users had frozen. However, protecting that locked principal did not protect external pool liquidity or the token’s market value.
Arkadiko: late money, no delay
Arkadiko’s proposal 12 was submitted at 20:35 UTC on Oct. 17 and executed at 16:04 UTC on Oct. 22. Its governance contract set a voting interval of 720 Bitcoin blocks, commonly described as five days. The rules required 0.25% of eligible DIKO supply to propose, 5% participation for quorum, and more yes than no votes. The supply calculation subtracted DIKO held in the initial-allocation contract.
Those rules did not require token owners to have held tokens before the proposal. The proposing wallet made a swap at 15:03:46 UTC on Oct. 22 and a vote at 15:06:47, committing about 4.573 million DIKO. The proposal closed with the same yes-vote total and zero no votes. Bitquery estimates the voting-token purchases at roughly $51,000, and its tracing puts 77% of the STX sent toward the voting wallet as coming from an earlier StackSwap haul.
The attacker committed funds across multiple transactions and dates, unlike X100’s single-transaction borrowing and repayment. The late purchase was key because it became usable voting power during an already-open ballot. When the ballot closed, the change executed with no separate waiting period before the contract received authority.
The approved malicious contract lacked caller authorization in its withdrawal and USDA-minting functions. Proposal 12 registered it as the vault-operations contract with mint permission. Successful calls removed sBTC at 16:06 UTC and stSTX at 16:09, minutes after activation. Bitquery estimates Arkadiko’s loss at about $1.09 million: roughly $780,000 of stSTX, $135,000 of sBTC, and $173,000 of STX obtained by selling unbacked USDA.
In its Oct. 22 response thread, Arkadiko said it had disabled the malicious contract and paused governance, vault redemptions, and liquidations. It said affected stSTX and sBTC vaults could not be modified because their collateral was unavailable. At 07:57 UTC on Oct. 27, proposal 14, “AIP 32.2 – Restore Vault Operations,” executed, setting the vault-operations entry to Arkadiko’s legitimate v1-3 contract.
Timing and authority
Requiring an older stake or using voting power from an earlier snapshot could have prevented newly acquired tokens from qualifying immediately, while an execution delay would have separated approval from asset movement. If every relevant action had to pass through such a delay, X100’s exact sequence could not have financed itself and repaid its loan in one transaction. An attacker using longer-term capital could wait, but limits on what approved contracts may do remain a separate question.
OpenZeppelin’s governance documentation describes historical voting power and execution timelocks as distinct mechanisms. Applied to these incidents, the test becomes when newly acquired capital gains authority, what that authority can move, and how much usable time remains before execution.
X100’s frozen X could not normally be unfrozen before its lock matured, so an execution delay would not erase that withdrawal restriction. Arkadiko’s legitimate close-vault function provides a conditional exit: an active owner repays debt, pays stability fees, and withdraws collateral when operations are enabled, requiring the necessary funds and available collateral. The roughly five-day proposal window offered advance notice, but the final vote arrived much later, and closure immediately activated the contract.
