GALA Replay Attack Drains 2B Tokens from GalaChain Wallets

The attacker drained roughly 2 billion GALA (about $3 million) and dozens of other tokens from nine GalaChain wallets on Aug. 18 using 74 signatures harvested from failed transactions stretching back 55 days. Two flaws combined: an EIP-712 verifier that accepted caller-supplied type definitions instead of deriving them from the called operation, and a replay protection system that rolled back unique transaction keys whenever a request failed. Of 59 account-token combinations targeted, 56 were drained for their exact balance on the first attempt, and the four largest GALA positions were taken in descending order within 18 seconds. The pattern points to pre-attack reconnaissance rather than opportunistic discovery.

Why it matters

The signatures behind the drain were cryptographically valid. The economic effects they authorized were not what the original signers had committed to: a single on-chain example shows a TransferToken call processing about 1.64 billion GALA even though the EIP-712 structure submitted for verification described an AddLiquidity operation. Private keys, seed phrases and passwords were not compromised, which is the part that should worry operators of similar infrastructure. A bridge whose security model assumes a signature's intent matches its operation can be drained without forging anything or stealing a key.

Both gaps survived external review. Gala said the relevant authorization logic was examined in a late-2025 CertiK engagement and in a Hashlock SDK review in January. Neither flagged the interaction between signature verification and replay protection. The replay mechanism had itself been introduced after an earlier CertiK finding, meaning the safeguard was added without testing the boundary case where it stopped applying: failed transactions whose signed payloads were already public.

Market impact

Gala paused its bridge about 2 hours and 47 minutes after the first verified unauthorized transfer, then began removing roles from the recipient address roughly 13 minutes later. Attempts to move assets through the bridge after the pause were rejected. The chronology is the broader signal for bridge operators: submissions arrived at a median interval of 4.5 seconds, with 73.9% landing exactly one block apart, while detection, investigation and human-triggered intervention took the better part of a morning. Machine-speed exploitation meets human-speed response, and the gap shows up directly in lost assets.

The patches close the two specific weaknesses but not the underlying audit problem.