A fraudulent network impersonating GIWA Chain 9134 took approximately 766.25 ETH after 1,335 addresses bridged 767.65 ETH into it, according to DYOR.
The network was not a fake webpage. It operated as a functioning Layer 2, with a bridge accepting ether from Ethereum and a batcher posting transaction data back to the main chain—which is also why DYOR was later able to reconstruct it.
DYOR, the decentralized exchange whose application was deployed on the network, published its account on September 27, 2026, saying the drain came from the fraudulent bridge rather than from any DYOR contract.
Not a Contract Exploit
DYOR’s first point is about what the incident was not. “This was not a DYOR contract exploit,” the statement said. The application was one of those affected by a fraudulent network impersonating GIWA Chain 9134, whose operators controlled the underlying bridge infrastructure and drained the real ETH backing the network.
The distinction shapes what happened to users’ assets. Once the ether backing the fraudulent Layer 2 was removed, everything shown inside the chain, including ETH balances and ETH held in DYOR liquidity pools, no longer had the same underlying redemption backing. DYOR argues that describing the event as DYOR losing or draining 700-plus ETH is therefore inaccurate, since the ETH was taken from the fraudulent bridge infrastructure and DYOR and its users were affected by the same underlying event.
The Timeline DYOR Reconstructed
The fraudulent bridge was deployed on September 27 at 02:10:59 UTC+8, in Ethereum block 26063331, according to DYOR’s account.
Roughly 8.5 hours earlier, the deployer received about 0.045 ETH from an address DYOR associates with ChangeHero, an instant exchange service.
Thirty-nine blocks after the bridge went live, at 02:18:47 UTC+8, three ETH deposits arrived in the same block and at the same second, totalling exactly 0.4 ETH. Two of the three were the first outgoing transactions those wallets had ever made. DYOR traced the first two further back, finding they had been funded roughly 25 days earlier, one from Binance and one from Gate, then left inactive until the fraudulent bridge went live.
DYOR describes its reading of this carefully. Based on the timing and behavior, it said, it believes those wallets are “strongly consistent with pre-positioned internal testing wallets used to verify that the fraudulent bridge could successfully receive funds.” It labels this an on-chain behavioral assessment and says the investigation into the full wallet cluster is continuing.
The drain came later, in Ethereum block 26067309, when approximately 766.25 ETH was removed from the bridge.
Reconstructed From the Scammers’ Own Data
The most unusual part of DYOR’s account is how it recovered what happened on a chain that no longer exists.
Because the fraudulent network operated as a functioning Layer 2 and posted transaction batches to Ethereum, the data those batches contained survived on the main chain after the fake network stopped operating. DYOR re-executed the recovered transactions in their original order and with their original timestamps, reconstructing bridge deposits, affected wallets, trades, token launches, and pool states.
On that chain, DYOR recorded 1,479 actions, of which 1,148 succeeded, across 298 wallets and 104 pools.
The company stresses that these were not user-submitted claims. Spot checks against live chain data recorded before the shutdown matched exactly or within approximately 1.6%, it said. The only known gap is roughly the final two minutes before the chain stopped, because those transactions were never posted to Ethereum.
Compensation Before Conclusions
DYOR said it has already distributed more than 200 ETH to affected users from its own funds and that the compensation activity can be reviewed on-chain.
It framed the decision as a choice not to wait. Although it did not control the fraudulent bridge and did not execute the drain, it said it did not want affected users to face the consequences alone and moved to reconstruct the affected-address dataset and begin compensation rather than waiting for the investigation to conclude. It acknowledged the payments cannot cover every loss.
The investigation continues into the bridge deployer, funding sources, early testing wallets, batcher infrastructure, the drain recipient, and subsequent fund movements. DYOR said it will distinguish between confirmed infrastructure, strongly linked wallets, suspicious addresses, and genuine victims, and will not label an address as belonging to the attacker merely because it deposited a large amount or interacted with a particular contract.
The Chain ID Problem
The mechanism at the center of this incident is not a bug in any contract. It is a property of how EVM networks identify themselves.
A chain ID is a number a network declares to distinguish its transactions from other networks so that a signed transaction on one chain cannot be replayed on another. It is not owned by anyone. Any operator deploying an EVM-compatible network can set its chain ID to any value, including one another project has announced but not yet launched.
That is the gap the operators used. GIWA’s chain ID was publicly known before its network went live, which meant a fraudulent network could adopt it and appear, to infrastructure checking that identifier, to be the real thing.
Also Read: THORChain Rejects Bitget CEO’s Request to Block $387.5M Hacker Wallets
