On the very first try, 56 out of 59 account-token pairs were emptied down to the exact balance. Not close to it. To the decimal.
That detail appears in Gala’s Sept. 14 postmortem covering the Aug. 18 GalaChain attack, and it explains the incident better than the dollar total ever could. Nine wallets lost roughly 2 billion GALA — about $3 million — along with dozens of additional tokens. There was no trial and error here. Whoever did this already had an inventory.
Within an 18-second window, the four biggest GALA holdings were emptied from largest to smallest. Nobody stumbles into perfect size order.
The groundwork came first
By Gala’s own accounting, the operation was fully prepared before a single unauthorized transfer settled. The company recorded 1,066 submissions spaced at a median of 4.5 seconds, and 73.9% of them landed precisely one block apart.
Those are the fingerprints of an automated submission engine working through a target list assembled in advance — not someone clicking around a wallet UI and learning balances on the fly.
What unlocked all of it: 74 signatures the attacker had scraped out of failed transactions, the oldest of them dating back as much as 55 days.
The verifier put its faith in the wrong input
This next part should unsettle anyone operating a chain that relies on EIP-712 typed-data signing.
Prior to the patch, GalaChain's verifier took the type definitions that came bundled with the request at face value, rather than deriving them from the operation actually being called. The result: a signature that covered one group of fields could be submitted while an entirely different method ran, drawing on data the signer had never agreed to.
The postmortem includes one on-chain illustration — a TransferToken call that moved roughly 1.64 billion GALA while the EIP-712 structure passed to the verifier claimed to describe an AddLiquidity operation. The recipient, the amount and the token instance involved in the transfer all fell outside the signed structure.
At no point was the signature cryptographically invalid. The system just had no mechanism for checking whether the account holder had actually approved what execution was doing.
According to Gala, investigators turned up no indication that private keys, seed phrases or passwords belonging to affected users had been compromised. It’s worth noting that this finding rests in part on internal evidence the company has not made public.
Failed transactions never lost their reusability
It took a second defect to inflate a scope bug into a $3 million one.
GalaChain issued unique transaction keys for the express purpose of preventing a signed payload from being submitted a second time. The problem: when a transaction failed, that key could be rolled back alongside the state changes that didn’t stick.
The signature therefore remained on the public ledger while the replay key was returned to circulation. Failed requests turned into reusable permissions, openly available to anyone willing to index them.
Gala said that of the 60 historical source transactions connected to the exploit, 57 included at least one failed inner operation. Not one of them had executed cleanly from start to finish.
That’s the entire mechanism. Nothing was forged. No private key was lifted from each targeted wallet. Genuine signatures were already sitting on-chain, and the chain had quietly consented to honoring them a second time.
Two audits reviewed this code and walked away
Gala said the verification logic was reviewed in an authorization-focused CertiK engagement during late 2025 and again in a January SDK review by Hashlock. Neither one raised the signature-scope problem.
Since neither report has been released, there’s no way to assess what the engagements covered or how much attention went to the seam joining signature verification and replay protection.
The chronology has a certain irony to it. That replay mechanism only existed because of an earlier CertiK finding, and it performed exactly as intended once a transaction key had been spent. The Aug. 18 attacker simply hunted for the boundary where it stopped applying — and located it in failed transactions whose signed payloads were public while their keys went unconsumed.
A window of two hours and 47 minutes
The first confirmed unauthorized transfer landed at 02:21:54 UTC. Gala halted the bridge at 05:09:19 UTC and started revoking roles from the recipient address at 05:22.
That’s a gap of two hours and 47 minutes. Because Gala has never said when its monitoring first registered the activity, that interval shouldn’t be read as the company’s response time — doing so would be unfair. Gala said that once the pause took effect, efforts to route assets out via the bridge were blocked.
Even so, line the two clocks up next to each other. Submissions landing every 4.5 seconds, versus a containment measure that requires a human to first conclude something is wrong and then choose to pull the lever. That’s the real exposure, and nothing in the postmortem’s list of patches touches it.
What was repaired, and what it costs users
Signature verification now pulls type information from the operation being invoked instead of trusting whatever arrives from the caller. Requests include identifiers that tie signatures to the specific channel, contract and method being authorized, and expiration timestamps limit how long a signed payload remains usable.
On the replay side, the fix persists a unique transaction key even when the underlying business operation fails — so an old request can’t linger in wait of a second shot.
Those are tidy fixes. They hold execution to what the user genuinely signed, and they require no one to exercise discretion.
The remainder of Gala’s response does require it. The company said it has introduced per-identity rate limits, behavioral monitoring on high-value accounts and additional scrutiny of bridge withdrawals past certain thresholds. That moves detection earlier in settlement, which is a benefit. It also hands operators the job of defining what abnormal means, and withdrawal holds will sweep up legitimate users alongside malicious ones. Anyone who has watched a large transfer get frozen pending review knows what that experience is like from the receiving end.
The AI claim is worth a second look
Gala has characterized the attacker as having used AI-assisted tooling. That judgment likewise depends on internal evidence the company has kept private.
Crypto companies have grown fond of framing security incidents in terms of artificial intelligence, and the framing accomplishes something convenient: it recasts a preventable authorization bug as a brush with something without precedent. Nothing in the published postmortem needs an AI to make sense. Indexing public failed transactions and replaying them one block apart is just scripting.
As for recovery, Gala said it has submitted a complaint to the FBI’s Internet Crime Complaint Center and issued preservation and freeze requests to the platforms involved while it follows the proceeds across four chains.
For anyone auditing a chain SDK today, the takeaway is narrower than the headline suggests. Examine signature verification, replay protection and transaction execution in isolation and all three can pass while their combination remains broken. GalaChain’s upcoming audits will need to demonstrate that no comparable authorization gaps are lurking elsewhere in the SDK — and the only credible way to demonstrate that is to publish the scope.