Fifty-six of 59 account-token combinations were drained for their exact balance on the first attempt. Not approximately. Exactly.
That detail sits inside Gala’s Sept. 14 postmortem on the Aug. 18 GalaChain attack, and it says more about what happened than the loss figure does. About 2 billion GALA, roughly $3 million, plus dozens of other tokens, left nine wallets. The attacker wasn’t probing. The attacker already knew what was in there.
The four largest GALA positions went out in descending order within 18 seconds. You don’t hit them in size order by accident.
The reconnaissance happened first
Gala’s own numbers describe an operation that was staged before the first unauthorized transfer cleared. The company logged 1,066 submissions at a median interval of 4.5 seconds, with 73.9% arriving exactly one block apart.
That’s an automated submission engine running against a pre-built target list, not a person clicking through a wallet interface and discovering balances as they go.
And the keys to the whole thing were 74 signatures the attacker had harvested from failed transactions, some stretching back as far as 55 days.
The verifier trusted the wrong thing
Here’s the part that should bother anyone running a chain with EIP-712 typed-data signing.
Before the patch, GalaChain’s verifier accepted the type definitions supplied with the request instead of deriving them from the operation actually being invoked. So a signature covering one set of fields could be presented while a completely different method executed, using information the signer never committed to.
One on-chain example from the postmortem: a TransferToken call processed about 1.64 billion GALA while the EIP-712 structure handed to the verifier described an AddLiquidity operation. The destination, the quantity and the token instance the transfer used all sat outside the signed structure.
The signature was cryptographically valid the entire time. The system simply had no way to confirm the account holder had authorized what execution ended up doing.
Gala said investigators found no evidence that affected users’ private keys, seed phrases or passwords were compromised. Worth flagging that this conclusion leans partly on internal evidence the company hasn’t published.
Failed transactions kept their reusability
A second flaw is what turned a scope bug into a $3 million one.
GalaChain assigned unique transaction keys specifically to stop a signed payload from being submitted twice. But when a transaction failed, the key could roll back along with the unsuccessful state changes.
So the signature stayed visible on the public ledger while the replay key went back on the shelf. Failed requests became reusable permissions, sitting in plain sight, for anyone who bothered to index them.
Gala said 57 of the 60 historical source transactions tied to the exploit contained at least one failed inner operation. None of them completed entirely successfully.
That’s the whole trick. No forged signatures. No stolen private keys behind every targeted wallet. The authentic signatures had already been published on-chain, and the chain had quietly agreed to honor them again.
Two audits looked at this code and moved on
The verification logic was examined during an authorization-focused CertiK engagement in late 2025 and an SDK review by Hashlock in January, Gala said. Neither flagged the signature-scope issue.
Neither report has been published, which makes it impossible to judge what was in scope or how closely anyone looked at the seam where signature verification meets replay protection.
There’s an irony in the sequence. The replay mechanism existed in the first place because of an earlier CertiK finding. It worked as designed once a transaction key had been consumed. The Aug. 18 attacker just went looking for the edge where it stopped applying, and found it in failed transactions whose signed payloads were public while their keys stayed unused.
Two hours and 47 minutes
The first verified unauthorized transfer hit at 02:21:54 UTC. Gala paused the bridge at 05:09:19 UTC and began stripping roles from the recipient address at 05:22.
Two hours and 47 minutes between the two. Gala hasn’t disclosed when its monitoring first caught the activity, so that gap isn’t the company’s reaction time, and it would be unfair to read it that way. Gala said attempts to move assets out through the bridge were rejected once the pause landed.
Still, put the clocks side by side. Submissions arriving every 4.5 seconds against a containment step that needs a human to decide something is wrong and then decide to hit the switch. That’s the actual exposure, and no patch in the postmortem addresses it.
What got fixed and what it costs you
Signature verification now derives type information from the operation being called rather than trusting whatever the caller supplies. Requests carry identifiers binding signatures to the channel, contract and method being authorized, and expiration timestamps cap how long a signed payload stays valid.
The replay fix persists a unique transaction key even when the underlying business operation fails, so a historical request can’t sit around waiting for a second attempt.
Those are clean fixes. They enforce what a user actually signed, and they don’t ask anyone to make a judgment call.
The rest of Gala’s response does. The company said it has added per-identity rate limits, behavioral monitoring for high-value accounts and extra review for bridge withdrawals above certain thresholds. Those push detection earlier in settlement, which helps. They also mean operators now define what counts as abnormal, and withdrawal holds will catch legitimate users along with malicious ones. Anyone who’s had a large transfer frozen for review knows how that feels from the other side.
The AI claim deserves a raised eyebrow
Gala has described the attacker as using AI-assisted tooling. That assessment also rests on internal evidence the company hasn’t released.
Crypto firms have gotten comfortable framing security incidents around artificial intelligence, and the framing does convenient work: it makes a preventable authorization bug sound like an encounter with something unprecedented. Nothing in the published postmortem requires an AI to explain it. Indexing public failed transactions and firing them back one block apart is scripting.
On the recovery side, Gala said it has filed a complaint with the FBI’s Internet Crime Complaint Center and sent preservation and freeze requests to platforms involved while it tracks proceeds across four chains.
If you’re auditing a chain SDK right now, the lesson is narrower than the headline. Test signature verification, replay protection and transaction execution separately and you can pass all three while the combination stays broken. GalaChain’s next audits will have to prove no similar authorization gaps are sitting elsewhere in its SDK, and the only honest way to show that is to publish the scope.
