Technical Post-Mortem

On 18 August 2026, GalaChain was targeted by an autonomous, AI-driven exploit agent that successfully executed unauthorized transfers across nine GalaChain wallets. Notably, the agent discovered and weaponized an edge-case logic flaw that had evaded multiple rounds of rigorous third-party smart contract audits.

Our monitoring systems detected the anomalous machine-speed activity, severed the agent’s exfiltration route mid-execution, and deployed a permanent on-chain patch within 45 minutes of the final transaction.

This post-mortem details the AI-generated exploit vector, our incident response timeline, and the hardened verification controls deployed to counter autonomous threat actors moving forward.

Every claim below is tagged with how it can be independently checked. Claims marked ledger are verifiable against the public GalaChain ledger. Claims marked source are verifiable against our public repository. Claims marked attested rest on internal records and cannot be externally verified — we have labelled them so you can weigh them accordingly.

---

Machine-readable summary

incident:
  id: galachain-2026-08-18
  class: signature-replay / signature-scope-confusion
  first_unauthorized_transfer:  2026-08-18T02:21:54.694Z   # verify: ledger, block 10404040
  largest_single_loss_gala:     1639810337.11548495        # verify: ledger, one transaction
  bridge_paused:                2026-08-18T05:09:19.831Z   # verify: ledger
  attacker_roles_revoked:       2026-08-18T05:22:17.447Z   # verify: ledger
  account_lockdown_completed:   2026-08-18T06:18:52Z       # verify: ledger
  fix_deployed:                 2026-08-18T06:27:00Z       # verify: source
  total_submissions: 1066                                  # verify: ledger
  median_submission_interval_sec: 4.5                      # verify: ledger
  same_block_interval_pct: 73.9                            # verify: ledger
  affected_accounts: 9                                     # verify: ledger
  execution_mode: automated                             # verify: attested
  keys_compromised: none_found                          # verify: attested
  document_as_of: 2026-09-10
verification:
  ledger:  https://explorer.galachain.com
  source:  https://github.com/GalaChain/sdk

---

What happened

ledger At 02:21:54.694 UTC, a single TransferToken call moved 1,639,810,337.11548495 GALA out of the largest affected account — the entire balance, in one operation, in the opening seconds of the attack. The payload declared a signature type set for one operation while invoking another, so the fields that directed the transfer were never covered by the signature the account holder had produced.

ledger The operation ran at machine cadence: a median of 4.5 seconds between submissions, with 73.9% landing exactly one block apart — pinned to block production, with no deliberation interval between actions.

ledger In aggregate, approximately 2.0 billion GALA and quantities of roughly 37 other tokens left nine wallets. Proceeds were bridged out and have been traced across four chains.

We paused the bridge, revoked the operator’s account roles, and deployed a permanent fix at 06:27 UTC the same morning.

---

Findings as of 10 September 2026

Our investigation is ongoing. Based on evidence identified to date:

• attested No evidence that any private key was compromised, ours or any user’s.
• attested No evidence that passwords, seed phrases or credentials were obtained.
• attested No evidence of phishing or social engineering against any affected holder.
• attested No evidence of unauthorized access to Gala systems — no database, key store, server or internal system.
• ledger The transactions we have examined carried cryptographically valid signatures. No evidence of a forged signature has been identified.

---

Technique: signature scope confusion

source GalaChain uses EIP-712 typed-data signing. A client constructs a structured payload, the user’s wallet signs it, and the chaincode verifies that signature before executing the operation.

source EIP-712 hashes a payload according to a declared type set. In the implementation at the time, that type declaration travelled with the payload rather than being derived from the operation being invoked. Verification confirmed the signature over the fields the declaration named, and the dispatch layer executed the operation as described — but the set of fields covered by the signature and the set of fields read at execution were not required to be identical.

Two further properties were relevant:

1. source Verification established authenticity rather than scope. Confirming that an account holder signed a structure is distinct from confirming they authorised a specific operation.
2. ledger Signature material was recoverable from public ledger data. Transaction payloads on a public blockchain are public by design — a property common to public chains generally.

---

Preparation and tooling

The preparation was extensive and is verifiable

ledger The operator did not improvise. It arrived with an inventory of 74 replayable signatures, harvested from transactions that had failed on GalaChain over the preceding eight weeks — the oldest 55 days and 432,190 blocks before the attack began, drawn near-continuously across that window rather than scraped from recent blocks.

ledger Of the 60 source transactions located on chain, 57 contained at least one failed inner operation and none were wholly successful — confirming the harvest mechanism precisely. A transaction that fails publishes its signed payload to the public ledger but does not consume its unique key, leaving that signature replayable.

ledger It also arrived with a balance table built off-platform: 56 of 59 account-token pairs were drained with the exactly correct amount on the first attempt, to eighteen decimal places. Across 689 replay attempts, only one used a probe value to discover a balance. The four largest GALA holdings were taken in exact descending order of value, inside eighteen seconds. Ranking targets that way requires having indexed and sorted holder balances before the first transaction was sent.

Tooling

attested The class of defect exploited here — a divergence between the fields a signature covers and the fields execution reads — is exactly the kind of flaw that automated source-code analysis has become effective at surfacing. Identifying it required reading verification logic and reasoning about what it did and did not bind, at a scale and speed that has become substantially cheaper than when our review cadence was designed.

attested The development and reconnaissance phases of this operation show the signature of AI-assisted tooling. We note that the identity conducting reconnaissance need not be the identity that executed, and our analysis of the operation spans both.

ledger Execution itself was machine-driven throughout: 1,066 submissions at a median 4.5 second interval, 73.9% exactly one block apart, sustained across more than three hours without a human-scale pause.

---

Independent security review

attested The GalaChain SDK has been under continuous third-party security review by two independent firms since early 2024:

attested The defective verification logic was present in code covered by at least two subsequent independent reviews — CertiK’s authorization-focused engagement of November–December 2025, whose scope was precisely this area, and Hashlock’s full SDK review of January 2026. Neither identified it.

The replay protection this attack had to defeat also came from an audit finding.

attested CertiK’s 2024 review raised replay risk as a class, recorded as “Potential for Replay Attacks due to Lack of Enforced Unique Transaction Keys.” We implemented unique-key enforcement in response, and it worked as specified: a signed payload, once submitted, cannot be submitted again.

ledger The operator’s contribution was identifying that this control had a boundary. A transaction that fails publishes its signed payload but does not consume its unique key — so it remains submittable. Rather than attempting to replay spent payloads, which the audited control would have rejected, it sourced payloads exclusively from failed transactions in historical ledger data, where the protection did not reach.

That is the shape of this incident: a purpose-built, audit-mandated control with an edge case that survived multiple rounds of expert review, and an adversary that found it.

---

Detection characteristics

ledger Every transfer validated cleanly. The signatures were authentic, the accounts existed, and the operations were well-formed, so each request presented to the chaincode as authorised. There were no signature failures or authentication anomalies to alert on — the conventional indicators that security monitoring is built around were entirely absent.

attested The anomalous activity was identified during the event. What the incident exposed was the interval between identifying machine-speed activity and being able to act on it: the controls available at the time required manual intervention, on a timescale the operation did not allow. Controls 4 through 6 below close that interval.

---

Response timeline (UTC, 18 August 2026)

---

Controls now in place

These describe changes to our own systems. They are not warranties, and no control eliminates risk entirely.

1. Signed payloads bound to the operation they authorise · source

The type set used for verification is no longer accepted from the caller. It is derived from the invoked method, and verification fails where the signed structure does not match the operation being executed. Deployed 18 August 2026.

2. Operation binding · source

DTOs carry a dtoOperation field naming the channel, contract and method they authorise. Verification rejects payloads whose declared operation does not match the invocation. Mandatory across our first-party clients.

3. Signature expiry · source

DTOs carry a dtoExpiresAt timestamp; payloads are rejected outside their validity window. This substantially reduces the utility of historical signatures already on the ledger, and operates independently of the primary fix.

4. Verifier rate limiting · attested

Per-identity rate limits apply at the verification layer, constraining high-volume activity in compressed windows independently of whether individual operations validate.

5. Behavioural monitoring on high-value accounts · attested

Balance-change monitoring covers high-value accounts, alerting on transfer patterns rather than authentication events.

6. Bridge release controls · attested

Bridge-out requests above defined thresholds require manual review before release.

7. Continuous, commit-pinned review · attested

The gap this incident exposed is that a point-in-time audit says nothing about code committed after it. We have commissioned a full-repository review pinned to a specific commit, and are moving to a model where security-sensitive paths are re-reviewed on change rather than on a calendar.

---

How to verify this yourself

Ledger claims. Query explorer.galachain.com for the block range covering 2026-08-18T02:21:54Z to 2026-08-18T06:30:00Z. The initial transfer is in block 10404040. Transfer records, their signatures, the failed retry sequence, and the bridge-pause and account-lock state transitions are all on-chain.

Source claims. The SDK is public at github.com/GalaChain/sdk. Verification logic, the dtoOperation and dtoExpiresAt field definitions, and their enforcement are readable in the repository. Commit history establishes when each change landed.

Attested claims. These rest on internal records — audit reports, infrastructure logs and monitoring configuration — that we have not published. Where they matter to you, ask and we will say what we can.

We believe accountability must be demonstrated, not simply asserted.

---

Where things stand

Our investigation remains ongoing. A complaint has been filed with the FBI’s Internet Crime Complaint Center, and preservation and freeze requests are with the relevant platforms. The proceeds remain traced.